Windows Security Integration
Windows® security integration enables Windows to authenticate on behalf of select users. Authentication can be used in place of, or in addition to VTScada user accounts. Instead of prompting the user for a separate username and password, the application requests credentials directly from Windows.
The VTScada Security system has three basic elements: Accounts, Roles & Privileges. When using Windows Security Integration, accounts (users) are managed in Windows. The privileges that are related to VTScada functionality are managed within the VTScada Security Manager, via assignment to roles. Windows accounts are linked to VTScada roles using Active Directory Groups that are named for the VTScada roles.
Benefits and differences:
- External account control.
- Fewer passwords for users to remember.
- Privilege sets are created only for roles, which are then assigned to accounts.
It is not possible to assign privileges directly to Windows-based accounts. - Rule-Scope can be applied to privileges within a role, but not to roles assigned to accounts.
- Limited control over domain account configuration within VTScada. Passwords cannot be changed and privileges cannot be granted
When Windows Security Integration (WSI) is in effect, VTScada managers (accounts with both the Manager privilege and the Administrator privilege) retain responsibility for granting privileges to roles. They may also disable individual accounts and can set the automatic log-out time for each account.
Alternative ID values, for the Alarm Notification system and other purposes, are still controlled within the VTScada interface.
Using Both Windows and VTScada Authentication
It is possible to have both VTScada accounts and Windows accounts. Accounts that existed prior to the enabling of WSI will continue to exist, but it is expected that many sites will prefer to disable or delete some or all of those accounts. If there are users who should have access to the SCADA system but not have an account on the domain, they should be given a VTScada account within the application. This feature might be used to send out application ChangeSets to someone who is trusted to work on the application, but who will not be given access to the corporate network.
A feature of WSI is that authorized local users may logon with their full account name (myname@company.com) or with their user name (myname). For trusted domain users, the domain must be specified, therefore full account name (myname@company.com) is required. If that user name matches a valid VTScada account name, then it will be assumed that the user intends to logon with the VTScada account. A dialog will open during the logon process to remind you of this.
Definitions and common terms:
- Authentication - The process of verifying a user is who they claim to be.
- Authorization - Relates to the privileges accorded to an account following authentication.
- Trust - reciprocal recognition of credentials between jurisdictions.
- WSI - Windows Security Integration
- LDAP - Lightweight Directory Access Protocol
- AD - Active Directory
- SG - Security Group
- Domain - A security and administrative boundary that contains users, machines, groups, and policies.
- Forest - Top- level Active Directory structure containing one or more domains that share a common schema, configuration and trust relationships. It is the security boundary of Active Directory.
- VTScada- -An Active Directory prefix set by the property, ADGroupPrefix.
When enabled, VTScada uses Windows® Authentication services, which connect to the domain controllers using a secure channel. For your applications, Windows Security Integration is enabled through the VTScada Security Manager's Administrative Settings dialog.
After an account is authenticated, the privileges accorded to that account are determined by its membership in Active Directory Security Groups that are named for VTScada roles. VTScada privileges are assigned to roles, not to domain accounts. The queries are performed using the default settings for the machine, which are set in the domain group policy.
Windows accounts that do not have membership in at least one of these security groups cannot sign in to VTScada.
Upon logon, and at regular intervals while an account is signed in, VTScada will check that the domain account is still enabled and the list of active directory groups it is a member of, updating the logged-on account's privileges as needed.
Active Directory Security Groups
Active Directory Security Groups must be created by someone who has permission to modify AD security groups. To work with VTScada, these must be named by prepending the letters "VTScada-" before the VTScada role name. For example, "VTScada-Operator" and "VTScada-Configurer".
The prefix "VTScada-" is set in the application property, ADGroupPrefix. Role names are under the control of the VTScada manager, and so may vary from these examples. This property can be edited only by working directly in the application's Settings.Dynamic file.
Trusted domain users must also be added to the Windows security groups on the host domain (the domain of the machine on which VTScada is running). To allow adding users of trusted domains, Group scope of security groups should be set to Domain Local.
Accounts are accorded privileges in VTScada according to their role (SG) membership. It is not possible to grant privileges to accounts directly.
The title bar will display the Windows account "displayname" attribute rather than the Windows logon name, e.g. "Another User" rather than "another.user@company.com".
Realm Filtering
If you are using realm filtering within your VTScada application, Active Directory users cannot be added automatically. You must add each AD user directly in VTScada, along with the realm:
"realm:another.user@company.com"
An AD account can be associated with only one realm. VTScada does not support having the same AD account in multiple realms or using the same AD account as both a member of a realm, and also a super-user who is not a member of a realm.
Running Multiple Applications with WSI
In the situation where two or more VTScada applications are running, it may be necessary to distinguish between them for logons. The recommended practice is to set a different ADPrefix value for each application. For example, if a site has both a water treatment application and a power generation application, then instead of using "VTScada-" for both, they might use "Power-" for one and "Water-" for the other. It would then be clear whether an account was a member of the "Power-Operators" security group, "Water-Operators" security group, or both.
Alternatively, you could ensure that role names are unique in each application.
If you have enabled WSI for two or more applications, you have not set a unique ADPrefix value per application, and you have not created unique role names in each applications, then an account with access to the ADPrefix-RoleName role will have that role in both applications. (For example, VTScada-Operator.) This may cause confusion if the privileges assigned to the role vary between the two applications.
Account caching
For accounts that have been added to the VTScada Security Manager, either automatically or manually, the VTScada host machine will cache Windows logon credentials (if permitted by AD Group Policy) such that if the machine is temporarily isolated from the domain, e.g. a laptop out in the field, then user logons will succeed for those logons that have been cached.
Account roles are not updated when isolated from the domain. Attempts to logon with an account that has not been cached on the host machine will fail.
Credentials are stored in a manner that meets current industry best practice.
You can configure the VTScada Security Manager to add Windows accounts automatically upon first successful log-on. By default, automatic storage is enabled. To change the configuration of automatic storage of domain accounts on, add the property, AutoAddADUsers, to the <SecurityManager> section of your application's Settings.Dynamic file.
If Windows domain accounts are not being stored automatically, then a user with the Manager privilege must add accounts to VTScada individually.
When connected to the domain, the Security Manager's cached set of account rules are updated on each domain logon. A periodic check (default 15 minutes) is made to ensure that each logged-on Windows account is still enabled, updating its assigned roles if necessary.
If the WSI option is deselected, cached domain users remain in the cache and may continue to logon using their domain accounts until those accounts are deleted from within VTScada.
Application Properties
The following privileges in Settings.Dynamic are used when Windows Authentication and Active Directory Authorization are in effect:
- ADGroupPrefix - The prefix added to a VTScada role name for the equivalent AD Security Group.
- ADRefreshPeriod - The interval in seconds between checks for changes to the signed in users account in Active Directory.
- AutoAddADUsers - Enable within the security Options dialog (Administrative Settings) if you want VTScada to automatically add domain accounts to the local cache upon successful logon. If a domain account is not cached in VTScada, logon is not possible when the workstation is disconnected from the domain.
If using Windows Security Integrationand Security Realms, you must add the realm name and prefix to the account using the VTScada accounts dialog. (e.g. realm:username@company.com)
AutoAddADUsers cannot be enabled when a security realm delimiter is defined.
VTScada as a Windows service
Windows Security Integration can be used when VTScada is run as a service, but the account that the service is run under must allow the COM operations required for the AD queries. A domain account must be used.
Allowing WSI users to authenticate with Thin Clients
- Create a role in VTScada (e.g. "Internet User")
- Add "Thin Client Access" and other required privileges to the role.
- Create a security group called "VTScada-InternetUser" in Active Directory.
- Add users to the security groups.
Warning for Internet and Mobile Client Connections
Thin clients transmit the user sign in credentials (username and password) using Basic Authentication, which is a simple, non-encrypted, Base 64 encoding of "username:password", and which can be decoded by network snooping tools if they can capture the message content. Wireshark as one example, will show the decoded credentials if connected to a local machine or switch that performs the communications (Because switches don't broadcast network traffic for all to hear, the "listener" must be local to the communications path versus being anywhere on the network.) If Windows Security Integration mode is enabled, then the potential consequences will extend beyond the SCADA system should the operator's Windows credentials be stolen.
To secure user credentials against listeners that may have access to switches or workstations carrying this traffic, it is essential that you encrypt thin client sessions with TLS (transport layer security) by installing an X.509 certificate on the VTScada Internet server. The certificate can be obtained from a 3rd party issuer such as Verisign, Thawte, GoDaddy, from an organization's own Certificate Authority (CA) infrastructure, or via local ad-hoc creation. (e.g. By using Open SSL tools.) To allow clients (browsers) to verify the certificate and not display an untrusted warning, they need the "root" certificate from the CA to be installed. The root certificate for most third-party issuers is already installed in most Web browsers.
VTScada maintains a salted, key-stretched, SHA2-512 hash of the Windows Logon password in the same manner as Security Manager logon passwords and this meets current industry best practice.
Authentication is always carried out by the server the client is connected to. Thin clients use the thin client server they are connecting to for authentication. If the application is configured for WSI mode, then the thin client server MUST be able to authenticate the user with the domain controller and successfully make the required LDAP queries against the domain. If the domains are in separate forests (e.g. servers.com and users.com) then a forest trust will have to be configured so that the users domain trusts the servers domain.
Slow Sign-ins Due to Large Numbers of AD Groups
In circumstances where the user belongs to a large number of AD security groups (where large is defined as greater than 100), the LDAP query can take time to execute, resulting in a slow logon.
You can improve logon performance by configuring VTScada to restrict AD LDAP queries for the user and group to a specific portion of the AD LDAP tree.
Use the following information only when absolutely necessary in the circumstance noted. A side effect is that external changes to the AD such as renaming an OU specified in a search base will then cause all AD logons for VTScada to fail.
Add two options for Security Manager configuration to the <SECURITYMANAGER-ADMIN> section of the application's Settings.Dynamic file.
- ADUserSearchBase
- ADGroupSearchBase
ADUserSearchBase is only for host domain users. For trusted domain users, no search option is currently available.
ADUSerSearchBase is the same for both host and trusted domain users.
These entries are used to restrict the AD LDAP queries for the user and group respectively to a particular portion of the AD LDAP tree.
By default, if the entries are not present the Default Naming Context (DFN) is used, which points to the root of the AD forest. For example, for a domain "example.com" the DFN is "dc=example, dc=com".
Each entry can be set to a portion of the AD LDAP tree using LDAP syntax, e.g. "OU=SCADA, dc=example, dc=com" to restrict that particular search to the SCADA OU in the example.com domain.
