Preliminary tasks for AD integration - SSO
SSL certificate
NOTE: It is possible to set up Windows to enforce SSL client certificate authentication (which may be the default behavior). This can be controlled by modifying the registry entry: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\ldapclientintegrity.
NOTE: If you want to use TLS 1.2 with SHA512 on Windows, you need to install a special update on Windows.
https://support.microsoft.com/en-us/kb/2973337
The usage of SSL is required when making the LDAP connection from Ubisecure SSO to Active Directory. First the SSL certificate needs to be created for example by using the Microsoft Certificate Authority. To use a self-signed certificate for test purposes the following article can be used http://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx
Then the CA certificate needs to be transferred to the Ubisecure SSO server and added to the trusted certificates in the Java Runtime Environment.Â
The Active Directory certificate can be added to the Java certificate store using the keytool command. Here is example command for Windows and Linux installations assuming keytool is in the path:Â
keytool -importcert -cacerts -trustcacerts -alias mytrustedca -file <insert filename here> -storepass changeit
AD integration user
A dedicated user should be created in Active Directory so it can be used when performing the LDAP bind.
The user must have the following privileges set for Active Directory:
- read privileges
- reset password
- write lockoutTime
These privileges should involve every AD user that will be included in the Ubisecure Active Directory integration. It is recommended that those privileges should be defined for the correct user groups using delegation.
For test or development purposes, the existing built-in user group "Account Operators" group is suitable if there is no need to reset passwords for other account operators, domain admins or administrators. "Domain Admins" group membership gives too many rights and should not be used for this purpose. For production environments, evaluate carefully and create appropriate privileges.Â
NOTE: In Windows Server 2012 Account Operator permissions are not sufficient. Account Admins works for testing.