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. Note that Ubisecure SSO Server includes its own Java implementation and that is where the certificate needs to be added.

In Windows the Java certificate storage that Ubisecure SSO Server uses is by default in the following file:

C:\Program Files\Ubisecure\ubilogin-sso\java\lib\security\cacerts

The Active Directory certificate can be added to the Java certificate store using the keytool command. Here are example commands for Windows and Linux installations:

Listing 1. Windows:

cd /d "C:\Program Files\Ubisecure\ubilogin-sso\"
setenv.cmd
cd %JRE_HOME%\lib\security
keytool -importcert -keystore cacerts -trustcacerts -alias mytrustedca -file <insert filename here> -storepass changeit

Listing 2. Linux:

cd /usr/local/ubisecure/ubilogin-sso/
. setenv.sh
cd $JRE_HOME/lib/security
keytool -importcert -keystore 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.

Browser not supported