Windows Authentication Notes
Definitions:
- Authentication ensures that you are who you say you are.
- Authorization relates to the privileges accorded to your account following authentication.
- WSI = Windows Security Integration
- LDAP = Lightweight Directory Access Protocol
- AD = Active Directory
- SG = Security Group
- The prefix "VTScada-" is 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.
WSI mode uses the LDAP default naming context for the host machine as a basis for the AD account query operations. This is the LDAP equivalent of the domain to which the host machine is joined and thus does not support user accounts from a domain other than that of the host machine.
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.
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.
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.
You can add two options for Security Manager configuration to the <SECURITYMANAGER-ADMIN> section of the application's Settings.Dynamic file.
- ADUserSearchBase
- ADGroupSearchBase
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.
