Introduction to LDAP Directory Services

The acronym LDAP stands for Lightweight Directory Access Protocol, a protocol invented to access directory services and intended as a simplification of DAP (Directory Access Protocol) family of protocols which are defined in the X.500 family of standards. Today, LDAP is widely used mainly thank to the strong support of the protocol in OpenLDAP (Open Source Directory Service), Novell eDirectory (formerly Novell Directory Services) and Microsoft Active Directory.

For more information about LDAP, please refer to the following documents:

http://tools.ietf.org/rfc/rfc4510.txt
http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
How to view and set LDAP policy in Active Directory http://support.microsoft.com/kb/315071

From the Dispatcher Paragon perspective, LDAP support is essential because it is now one of the major ways how to access corporate user account information. Dispatcher Paragon uses such information for seamless authentication of users.

Dispatcher Paragon may retrieve the following information from a directory service (depends on configuration):

User account information (name, e-mail address, login name and any aliases, assigned cost center). Password is not retrieved.
Card number and PIN.
Group membership (translated to Dispatcher Paragon roles).
Groups (translated to Dispatcher Paragon roles for Role-based Access Control)

Dispatcher Paragon LDAP Replication

LDAP Replication is a technology for integrating Dispatcher Paragon with LDAP-based directory services. Instead of querying data of individual users, it periodically replicates data from selected directory trees directly to Dispatcher Paragon.

Traditional approaches to replication usually provide a challenge in designing and configuring the system integration with directory service or multiple directory services, however Dispatcher Paragon LDAP Replication technology is designed to be deployable in small and big environments.

Replication is a process where data are copied from one data source to another. We only need to discuss the one-way replication where one source acts as master, where modifications happen and the other acts as subordinate, which stores data in read only manner. In our case, the master is the directory service and the subordinate in Dispatcher Paragon. During the replication, new data are copied from directory service to Dispatcher Paragon, existing data are updated and deleted data are marked as deleted.

The Dispatcher Paragon LDAP Replication technology comes with the following features:

Integration with multiple directory services. Dispatcher Paragon can also handle situations where single user account exists in multiple directory trees or services or when user is a member of a group, which exists in different tree or service.
Security awareness. Dispatcher Paragon never replicates user passwords, even if it is technically possible or permitted by the directory service.
Performance. Dispatcher Paragon LDAP Replication operates in two modes: differential and full replication . Differential replication replicates only changes occurred since the last (differential) replication. Full replication replicates the entire directory tree(s) according to configuration.

By default, Dispatcher Paragon replicates the following attributes (applies to Microsoft Active Directory configuration):

User: GUID, sAMAccountName, cn, sn, mail, memberOf; optional attributes: homeDirectory, department, custom attribute with card ID such as otherPager
Group: GUID, sAMAccountName, description
User membership in a group is determined using the memberOf attribute. All replicated groups are translated into Dispatcher Paragon roles.

Dispatcher Paragon LDAP Replication Concerns

Using data replication may raise concerns about the integrity of the data stored in the system. Here we list typical problems into which the IT Administrator may run and their solutions. Also we list typical concerns and explain why Dispatcher Paragon LDAP Replication is a solid and viable solution. The explanation is provided as pairs of concerns and explanations.

Area	Concern	Explanation
Data Redundancy	Dispatcher Paragon stores a redundant copy of my data which may get invalid by local changes.	Dispatcher Paragon stores a read only copy of the replicated data and correctly propagates all changes to the system. This way, data are only provided in a way which generates less overhead - data are replicated more efficiently in batches.
Data Redundancy	It is not feasible to make local modifications as they will be overriden when replication occurs.	Dispatcher Paragon maintains local and replicated data separately. For example if a user account has two ID cards, one replicated and one added manually, the system will never automatically delete the manually added card.
Replication of Sensitive Data	Dispatcher Paragon leaks out potentially sensitive data by using replication.	All data stored in the system would be available to Dispatcher Paragon even by using online connection anyway. all the replicated data would be available to Dispatcher Paragon anyway and stored in-memory, visible in reports, log files, web interface and other parts of the system which tracks and displays information.
Leaking Passwords	Replication leaks out user passwords or at least stores them in less secure way.	Dispatcher Paragon never replicates user passwords, even if it is technically possible. Password-based authentication is handled using online connection to the directory service.
Invalidation of User Credentials	It is impossible to quickly invalidate user credentials.	Differential replication (which also propagates user credentials) has a very low overhead (depending on the amount of changes in your directory service) and can be run every few minutes without raising the load imposed on the directory service agents. This way, the credential change is propagated very quickly.

How does Differential Replication work?

Differential Replication mode requires a means of tracking changes in the directory service to operate correctly. When connected to Active Directory, USN (Universal Sequence Numbers) are used to track changes. When connected to Novell eDirectory, modification timestamps are used to track changes.

Differential Replication has currently one limitation: it is not possible to replicate deletion of objects. This is based on the limitation of the most common directory services (Microsoft Active Directory and Novell eDirectory) which provide no reliable way to track object deletion. Full Replication however replicates even object deletion correctly.

Recommended Configuration

Regardless of the number of directory services you are going to use, you should follow some basic guidelines when configuring LDAP replication.

Schedule Differential Replication to run several times a day (even as often as every couple of minutes) and Full Replication to run once a day, out of office hours. If you have 24/7 environment, schedule the full replication to run off peak hours.

If you have a complex rule structure, do not forget to correctly configure maximum page size in Dispatcher Paragon. Otherwise, only portion of the data will be replicated to Dispatcher Paragon.

Securing LDAP via SSL/TLS

When configuring the LDAP server address, specifying LDAPS as a protocol will lead to encrypted connection using SSL/TLS. Supported SSL/TLS versions are SSL 3.0, TLS 1.0, TLS 1.1 and TLS 1.2. By default, TLS 1.0 is the only enabled protocol version because of the compatibility reasons. It is highly recommended to enable communication via TLS 1.2, since several weaknesses were found in the lower versions.

Also the list of ciphers used for LDAPS communication can be customized, the default value is the default list enabled in Java 11.

The authentication is assured via SSL/TLS certificates. There are two options for certificate verification - comparison of the thumbprints and the standard validation using digital signature. For more information about the configuration please refer to Configuring secured connection to the LDAP server.