USxS Redesign projects optionally support Windows Active Directory Services (ADS) using LDAP queries. Support for ADS is provided by an optional module which supports up to three ADS domains.
Install ADS Module
To install the module, login as the admin user and navigate to System -> Modules, and install the
org.ssdt_ohio:ssdt.common.authnz-ads module by clicking the "
You must restart the application after installing this module. ADS authentication will be active after the restart.
WIth the module installed, navigate to System->Module Configuration and edit the Windows Active Directory Authentication configuration:
Enable one or more of the configurations and enter at least the LDAP URL of the domain server. Hover your cursor over each field for more details and defaults. It is not necessary to restart the application after changing this configuration. The configuration changes take effect immediately when the configuration is saved.
If multiple ADS domains are configured, each one is attempted in order. If authentication succeeds, the user profile in the application is checked. The username field in the application profile must match the user's login name. See Authentication & Authorization for details on the authentication process.
The "ADS Domain" in the configuration affects the users login name. For example, consider the user "smith" in a domain "nwoca.org". If the "ADS Domain" field is left blank, then the user must specify the fully qualified name of "email@example.com" when logging in and the username field in the application's user must contain "firstname.lastname@example.org". However, if the "ADS Domain" field contains "nwoca.org", then the user can login without specifying the domain, and the profile username is simply "smith".
For this reason, when configuring multiple domains, it is strongly recommended that only one domain specify an "ADS Domain". The others should be blank to force the user to specify the fully qualified name to prevent collisions. If a default is provided for more than one domain, and a user "smith" exists in both domains, they will share the same profile in the application.
Preventing External Authentication
It may be necessary to restrict which user(s) can authenticate using Windows ADS or LDAP. For example, you may wish to force the 'admin' user to authentication locally. One choice is to specify an LDAP "Search Filter" to restrict users or attribute who are allowed to authenticate with a particular domain. The default "Search Filter" is:
Which simply looks the up the username by the LDAP
To remove 'admin' users from the filters, you would use the following filter:
In the future, it will be possible to implement custom rules to future customize which user can authenticate using various authentication sources.
Using LDAPS (LDAP over SSL)
To use LDAPS, you should specify the "ldaps:" scheme in the LDAP URL. However, by default, Java's LDAP client will perform standard certificate identification. Therefore, the LDAP certificate must be signed and the certificate's Common Name must match the host name in the URL.
Basically, LDAPS needs to have a valid certificate matching the name where it is being referenced. So, for LDAPS to work, there need to be two things.
- A certificate loaded in the correct place (this has been tested with a wildcard certificate)
- The certificate must include any intermediate and root certificates to form a complete chain.
- A DNS entry that points to the server with that certificate (i.e. ldaps.sitename.org)
The LDAPS string must have the domain match the certificate, as the cert check is on the connection name, not the Active Directory Fully Qualified Name. For example:
- Current, working ldap string:
- Change for ldaps:
- Note that ldaps://22.214.171.124:636/ will not work.
Install a certificate to use LDAPS:
Open the console snap-in - for windows, do start, and type run. In the command, type mmc
Select File, and chose Add/Remove Snap-in
Go to Certificates, and Add
Select Manage for Service Account
Select Local computer
Select Active Directory Domain Services
To test the ldaps connection to see if it is working on your local AD controller:
Connect to localhost with port 636, using SSL
This is an example of a successful connection:
For example, the JAVA_OPTS variable might look like: