LDAP provides a central repository of user information, passwords, and other data
Microsoft Active Directory is an LDAP implementation with proprietary extensions
A mapping is created between standard or custom LDAP attributes and Agiloft fields in the Employee table (including group and team membership) to allow synchronized logon
Successful integration with LDAP will most likely require additions to your LDAP database.
So, LDAP can hold any kind of data, but it is usually used to provide a central repository of user information and passwords. This allows other enterprise applications to check passwords against a single LDAP repository, rather than each application storing them individually. This reduces maintenance costs and improves security.
In addition to login names and passwords, Agiloft allows other information such as email addresses, groups, teams and custom fields to be mapped between LDAP attributes and their equivalents in Agiloft.
The use of LDAP for more than login/passwords provides some interesting challenges for Agiloft as detailed below:
1) Both LDAP and Agiloft may contain custom attributes (aka fields), Unfortunately, there is no way to find all the custom attributes in an LDAP database, other than by reading the users one-by-one and noting their attributes. For LDAP databases with hundreds of thousands of users, this could take hours.
Agiloft resolves this problem by searching the first 1,000 users for attributes, and asking the administrator to nominate one user that contains the additional attributes that must be mapped. The actual values of the attributes in this user do not matter, they just need to exist. For example, if the user has a Telephone Number attribute of 0, the system will add Telephone Number to the list of mappable attributes.
Workflow rules that send email to a Team need to know which users are part of which teams. The Agiloft system can instantly search its own tables with an SQL query to find all the matching users, but there is no way to perform an equivalent search on the LDAP database. Instead it would be necessary to read every LDAP user in turn to determine whether they were a member of that team. For large LDAP repositories, this would be very slow.
This class of issues is resolved as follows: When a user logs into Agiloft using LDAP authentication, a dummy entry is created for them in the Agiloft user table and the data cached in this entry is refreshed from LDAP each time they subsequently login. This allows the system to rapidly find Team members and avoid unnecessary calls to the LDAP server. Of course, password information is not cached, so centralized password control is maintained.
This strategy allows Agiloft to automatically restrict Team emails to those LDAP users who actually use Agiloft. If you want all users to receive email, you can set it up to automatically sync with LDAP at regular intervals and use it at least once, but some administrators see this as an advantage since users who do not use Agiloft may not expect to receive email from it.
LDAP can be used by Agiloft in three ways:
Synchronize: Agiloft will import LDAP users automatically at a specified interval, or manually using the GUI. LDAP users will be Agiloft users even if they have never logged in to Agiloft.
At login: LDAP will be queried for a specific user when they attempt to log in to Agiloft.
Single Sign-on (SSO): Using a special hyperlink and an ActiveX control, LDAP will be queried with a user's domain login credentials so that they can access Agiloft without an explicit login.
To define the LDAP mapping go to Setup > Access and click LDAP/AD Authentication.
Add the server or select the existing one. New server is always added with the temporary name and a default port (389). Once the server is selected these settings can be changed on the Server tab.
On the Server tab, enter the name of your company's LDAP server and the base directory. Common schemes for base directories:
Domain: "dc=mycompany, dc=com" specifies each domain component of mycompany.com in order.
Geographical: "c=US" specifies the country. This is a throwback to LDAP's X.500 roots, which was potentially one big global hierarchy.
|sn (surname)||Last Name|
Agiloft uses the standard LDAP v2 protocol to connect and query an LDAP/AD server through simple Bind authentication. It does not add any proprietary extensions to it.
If an LDAP sync through Agiloft does not return an entity/attribute that you are looking for, please download a third-party LDAP client like Jxplorer from http://jxplorer.org and test through it using the same base DN and query filter.
If the entity/attribute returns through a third-party client but not through Agiloft, then please report the incident to Agiloft support through https://www.agiloft.com/support-login.htm for further investigation. Otherwise, it is more likely that the LDAP user specified on the Login tab of the LDAP wizard is missing necessary permissions to view the entity/attribute. The user must have view access to all records you want to synchronize or authenticate against. The problem may also be caused by an incorrect filter in the LDAP query.