LDAP/Microsoft Active Directory
- LDAP provides a central repository of user information, passwords,
and other data
- Microsoft Active Directory is an LDAP implementation with proprietary
- A mapping is created between standard or custom LDAP attributes
fields in the Employee table (including group and team membership)
to allow synchronized logon
- Integrating Agiloft
successfully with LDAP will most likely require additions to your
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.
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 what users are
part of what 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
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.
LDAP Mapping Wizard
- To define the LDAP mapping go to Setup/Access and click LDAP/AD
- 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 tab Server.
- Next choose the server type. Use "LDAP" for non-Microsoft
- 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
- Enter the login authentication info for your LDAP server and the
- 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
logins to certain users, you could add a custom objectClass such as
"EWusers" to these users and specify it here.
- LDAP provides no easy method for finding all attributes in use,
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 here.
- If the specified Group attribute contains an Agiloft
group name, the user is added to that group.
- If the specified Team attribute contains an Agiloft
team name, the user is added to that team.
- LDAP users are always assigned to a designated primary team.
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:
|sn (surname)||Last Name|
- 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
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
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, this 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
- 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
login is not required.