Page tree
Skip to end of metadata
Go to start of metadata

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 "+"  icon.  

You must restart the application after installing this module.  ADS authentication will be active after the restart.

Configure

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.

Default Domain

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 "smith@nwoca.org" when logging in and the username field in the application's user must contain "smith@nwoca.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:

(&(objectClass=user)(userPrincipalName={0}))

Which simply looks the up the username by the LDAP userPrincipalName

To remove 'admin' users from the filters, you would use the following filter:

(&(objectClass=user)(userPrincipalName={0}) (!(userPrincipalName=admin*))  )


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)

Starting in March 2020, Microsoft is going to disable the use of unsigned LDAP .  UPDATE: This has been delayed- estimated date is second half of 2020  It is still important to make these changes.

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)

LDAPS  settings

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: 
    • ldap://1.2.3.4:389/
  • Change for ldaps:
    • ldaps://ldaps.sitename.org:636
    • Note that ldaps://1.2.3.4: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:

Run ldp.exe:

Connect to localhost with port 636, using SSL


This is an example of a successful connection:



Update 2/11/2020 - Disabling certificate validation is not supported in the software. We are leaving this documentation in here for reference only.
  -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true 

For example, the JAVA_OPTS variable might look like:

environment:
  - JAVA_OPTS=-Xmx=2g -Dcom.sun.jndi.ldap.object.disableEndpointIdentification=true



  • No labels