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 SafeQ perspective, LDAP support is essential because it is now one of the major ways how to access corporate user account information. SafeQ uses such information for seamless authentication of users.

SafeQ 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 SafeQ roles).
Groups (translated to SafeQ Roles for Role-based Access Control)

YSoft SafeQ LDAP Replication

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

Traditional approaches to replication usually provide a challenge in designing and configuring the system integration with directory service or multiple directory services, however SafeQ 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 SafeQ. During the replication, new data are copied from directory service to SafeQ, existing data are updated and deleted data are marked as deleted.

The SafeQ LDAP Replication technology comes with the following features:

Integration with multiple directory services. SafeQ 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. SafeQ never replicates user passwords, even if it is technically possible or permitted by the directory service.
Performance. SafeQ 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, SafeQ 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 SafeQ roles.

SafeQ 5.0 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 YSoft SafeQ LDAP Replication is a solid and viable solution. The explanation is provided as pairs of concerns and explanations.

Area	Concern	Explanation
Data Redundancy	SafeQ stores a redundant copy of my data which may get invalid by local changes.	SafeQ 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.	SafeQ 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	SafeQ leaks out potentially sensitive data by using replication.	All data stored in the system would be available to SafeQ even by using online connection anyway. all the replicated data would be available to SafeQ 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.	SafeQ 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 SafeQ. Otherwise, only portion of the data will be replicated to SafeQ.

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 communciation 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 7.

By default, the actual hostname used for LDAP connection is not checked against the value in the SSL/TLS certificate. This allows easy setup and backward compatibility but can allow an attacker to intercept the communication between SafeQ CML and the LDAP server in some scenarios. To prevent the possible attack, it is recommended to set the Mode of LDAP server certificate check option in Expert settings in LDAP replication page to secure and rewrite the system property com.sun.jndi.ldap.object.disableEndpointIdentification from true to false in wrapper configurations (see below).

For CML is it in:

c:\SafeQ5\bin\wrapper.conf
c:\SafeQ5\binc\wrapper.conf
c:\SafeQ5\binldapreplicator\wrapper.conf

For ORS is it in:

c:\SafeQORS\bin\wrapper.conf

For CRS is it in:

c:\SafeQCRS\bin\wrapper.conf

Restart all components to apply the changes. With this settings, the LDAP server certificate must have SAN (Subject Alternative Name) or Common Name extensions correctly set as specified in RFC 2830. The value in that field has to match the hostname or IP address configured by the URL of LDAP server setting. For example, if the certificate contains only the domain name of the LDAP server in SAN, the configured URL has to use that domain name and not the IP address nor a different domain name pointing to the server.