LDAP Settings
Enable LDAP—When checked, the system will attempt to use the provided values to perform user authentication via LDAP. If the authentication is successful, the value returned from the field defined as Local ID will be used to identify the person to Alexandria. If unable to authenticate using LDAP, the system will use the previous authentication method as a fallback.
LDAP Domain— This is the Domain of the LDAP server, as in “yourdomain.com”. This is used in conjunction with sAMAccountName to produce a complete userPrincipalName.
LDAP Server—This is the full name of the LDAP server, as in “ldap.yourdomain.com”. This is the host address of the LDAP server used for network communication.
Allow Non-Secure Connections—When checked, the system will use non-TLS connections if it cannot make an TLS connection. For the best security, don't check this.
Base DN for all LDAP users—This is a DN that matches all the users, as in “cn=users,dc=ldap,dc=yourdomain,dc=com”, so that any search using the User ID field specifies a unique user. Multiple Base DNs can be specified if separated by semicolons: “cn=staff,ou=COMPanion,dc=demo,dc=goalexandria,dc=com;cn=student,ou=COMPanion,dc=demo,dc=goalexandria,dc=com”.
User ID—This is the name of the LDAP database attribute whose value is the LDAP login name (e.g. “uid=yourlogin" in the context of the Base DN). For an Open Directory, this is typically uid. For an Active Directory this is typically cn, sAMAccountName, or userPrincipalName.
Local ID—This is the name of the LDAP database attribute whose value contains the Patron Username or Patron Barcode in Alexandria. This MUST be one of the users' LDAP attributes. Common attribute names include uid, uidNumber, givenName, cn, and others.
Operator Usernames and Patron Barcodes must be unique across the system. Please ensure no patrons using Alexandria share a Patron Barcode with an Operator Username. |
Note: In a Centralized Catalog, these settings will apply to all sites.
Test your LDAP settings before saving. Attempting to connect to an invalid server (and other invalid settings), can cause the test to take several minutes before failing.
Test Login—Enter the test login.
Test Password—Enter the password for the test login.
Test—Clicking on this button initiates a test, which attempts to log into the LDAP server using the settings and credentials provided above.
More on Testing LDAP
If configured correctly, your users should be able to log into Alexandria using the same login credentials as configured on the directory server for their account. However, sometimes difficulty arises. In these cases, verify your preferences settings and test whether the Base DN and other information you have specified is accurate to your configuration.
We have found that Active Directory configurations seem to prefer binds using the user's CN while OSXs Open Directory prefers the uid (i.e. user identification).
The use of ldapsearch tool is suggested.
For example:ldapsearch -x -v -H ldap://LDAP.yourdomain.com -b"cn=users, dc=LDAP, dc=yourdomain, dc=com" -D"cn=testing user id, cn=users, dc=LDAP, dc=yourdomain, dc=com" -w the users password -ZZ
- NOTE - |
---|
| The -ZZ parameter requires successful connection utilizing StartTLS over port 389. If you have selected to Allow Non-Secure Connections, omit this in your testing with ldapsearch as well. |
Alternately, ldp.exe can be utilized for testing in a Windows environment.