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

LDAP Access

What is LDAP?

  • Lightweight Directory Access Protocol (LDAP) provides a central repository of user information, passwords, and other data.
  • 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.

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:
Both LDAP and Agiloft may contain custom attributes - 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 Integration

LDAP can be used by Agiloft in three ways:

  • Synchronization: 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.
  • Login authentication: 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.

LDAP Mapping Wizard

  • 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 LDAP tab, choose the server type. Use "LDAP" for non-Microsoft servers.

  • 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.
    Note: subdomains will automatically be synchronized as long as the account has delegated control to subdomain directory objects. 
  • Geographical: "c=US" specifies the country. This is a throwback to LDAP's X.500 roots, which was potentially one big global hierarchy.

  • On the Login tab, enter the login authentication info for your LDAP server and the connection type:

  • Object classes separate LDAP attributes into logical categories. The "user" class is often used for entries that have the appropriate user authentication attributes. If you want to restrict Agiloft logins to certain users, you could add custom objectClass such as "EWusers" to these users and specify it here. Multiple user authentication classes can be selected by holding the CTRL key. 

  • LDAP provides no easy method for finding all attributes in use, so Agiloft scans all attributes in the first 1000 records.
  • In addition, the administrator can nominate one user that contains any additional attributes for which mappings are needed.
  • Specify desired mappings of LDAP attributes on the Field Mapping tab.
  • If the specified Group attribute contains an Agiloft group name, the user is added to that group. This is not a nested/recursive search. The specified attribute in the user record must directly contain the Agiloft group name in order for it to be mapped.
  • If the specified Team attribute contains an Agiloft team name, the user is added to that team. This is not a nested/recursive search. The specified attribute in the user record must directly contain the Agiloft group name in order for it to be mapped.
  • LDAP users are always assigned to a designated primary team.

  • Agiloft fields in the Employee table are populated by LDAP attributes according to these mappings. You will likely want to add some custom LDAP attributes to your user entries for this purpose. Common mappings:

    LDAP

    Agiloft

    sAMAccountName

    Login

    givenName

    First Name

    sn (surname)

    Last Name

    name

    Full Name

    mail

    Email

  • At the bottom of the Field Mapping tab you can specify that you want to have Agiloft store certain user attributes instead of storing them in LDAP.

  • Group mapping allows LDAP groups to be granted group privileges in Agiloft. The default group catches users who are not in an appropriate LDAP group. You can also choose not to update groups and teams from LDAP after the first synchronization or login of a user. When LDAP synchronization is run for the first time, user records will be created with the default groups and teams values you select in the next option. After that first import, you may edit the group membership in the user record of Agiloft at any time, and LDAP will never overwrite this value when the user logs in. This setting also affects the Primary Team field.

  • Similar to Group Mapping, the Team Mapping tab assigns LDAP groups to Agiloft Teams. The setup will likely be very similar.

  • Here you choose when and how often you want to automatically synchronize with LDAP.

  • If you chose "Do not import users automatically", or chose to automatically synchronize "Never", or simply want an update from LDAP before the scheduled time, you can at any time click "Synchronize LDAP/AD users". If you do not synchronize, LDAP users are only created in Agiloft if they log in.

  • Instead of or in addition to copying LDAP data to an Agiloft table, you can choose to query LDAP using an ActiveX control. An explicit Agiloft login is not required.

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.