If your institution has an LDAP server available with potential Ares users in it, you can use that server to authenticate any Ares patrons. This server does not necessarily need to contain all potential Ares users, as those who do not exist can be added through the client by staff or register themselves if given a link to the First Time Users form. The advantage to using LDAP is that the username and password a user enters is the same as other systems at your institution and if a user changes his/her password with the LDAP directory, that password is automatically used for Ares authentication as well. The disadvantage is that if your server loses connectivity to your LDAP server, those users cannot login to Ares because they cannot be authenticated by that external system.
LDAP passwords are not stored in the Ares database and are only used when typed in by the user to match against the LDAP server during registration and login. The password field in the Ares database will store the encrypted version of a blank value, but is not used for any authentication.
Customizing your LDAP Settings
Setting up LDAP authentication requires a few customization keys to be updated in the User Authentication section of the Ares Customization Manager.
|
AuthenticationMethod |
The default method for authenticating users to the Ares system. Example: LDAP |
|---|---|
|
EnableUserValidationNewUsers |
Indicates if the User Validation tables should be used when authenticating non-registered users. Example: Yes, No |
|
LDAPBindStyle |
OneStep performs one or more binds to find the user while TwoStep does an initial bind to allow Ares to search the directory and then searches for that user. Example: OneStep, TwoStep |
|
LDAPInitialBindDN |
Used only for TwoStep LDAP where this is the initial bind that authenticates Ares to search for the user attempting to register or login. Example: cn=Manager,dc=youruniversity,dc=edu |
|
LDAPInitialBindPassword |
Used only for TwoStep LDAP and is the password for the LDAPInitialBindDN. Example: ldappassword |
|
LDAPServerPort |
The port used for connecting to the LDAP server (389 by default, if you use SSL the default is typically 636). |
|
LDAPSearchFilter |
Used only for TwoStep LDAP where the initial authentication is a bind and Ares then performs a search for the potential Ares user. Example: (cn=$cn) |
|
LDAPSearchPrefix |
Used only for OneStep LDAP and is the prefix to the bind used to find the potential Ares user. Example: cn= |
|
LDAPSearchScope |
Used only for TwoStep LDAP and should rarely need to be changed from Subtree. Example: Subtree |
|
LDAPSearchSuffix |
Used for both OneStep and TwoStep LDAP but in slightly different ways. Example: dc=youruniversity,dc=edu |
|
LDAPSecureSSL |
If set to Yes, Ares uses the LDAPSecureSSLPort and not the LDAPServerPort value. Example: Yes, No |
|
LDAPServerName |
LDAP Server Name/IP. Example: ldap.atlas-sys.com |
|
LDAPVersion |
Tells Ares which version of LDAP to connect to. Example: 3 |
Binding
LDAPSearchSuffix is used by both OneStep and TwoStep LDAP but in slightly different ways.
One Step
For OneStep LDAP the suffix is either a single suffix or pipe separated list of different suffixes for Ares to attempt to use for a bind. The entire bind would involve the values from: LDAPSearchPrefix + <username entered> + , + LDAPSearchSuffix. If that bind fails, Ares will attempt the same combination but with the second LDAPSearchSuffix in the customization key.
Two Step
For TwoStep LDAP, Ares users the LDAPSearchFilter to search in the LDAPSearchSuffix and any subtrees under that location in the LDAP directory. Most sites using TwoStep set this value fairly high in the directory to allow for searching in multiple subtrees for a match, but that may vary based on who is allowed to use Ares.
Setup
For LDAP authentication, users who validate against the LDAP server can be cleared automatically by setting the AutoClearPreregisteredUsers customization key to Yes.
Because Ares does not store or sync the LDAP password, you would not enable the password reset feature for LDAP customers.
Example Scenario
If John Smith exists in the LDAP server with a username of jsmith7 and a password of "myunivrocks" but has never used Ares before, he can enter his LDAP username and password on the logon form for Ares. Ares will check to see if he exists in the Ares Users table under jsmith7. If not, it checks to see if he exists in the LDAP directory with that username and password. If the LDAP bind is successful, Ares creates a username called jsmith7 (with a blank password since it's not saved) and directs John Smith to the NewAuthRegistration.html or ChangeUserInformation.html form (if NewAuthRegistration doesn't exist) for Smith to fill out the rest of his information. Ares only grabs the username from LDAP and no other user data. The next time John Smith attempts to login to Ares, the system will check his AuthType in the Users table. If his AuthType is LDAP (which gets set when he first registers against the LDAP database), it will check the LDAP directory again to verify the username and password Smith typed into the logon form.
If Fred Funk would like to use Ares but is not in the LDAP directory, he can register himself from the First Time Users link (Create Account ) or can be added to the system by staff via the client. His username can be whatever he would like, but should not conflict with a username that might be in the LDAP directory. If his username is ffunk and his password is "Aresrocks", then he can login on the same logon form as LDAP users. Because he manually registered or was created through the client, his AuthType is Ares and the web DLL knows not to try to authenticate him against the LDAP server.