LDAP integration with AEM (Apache Directory Server)

In this post I’ll talk about configuring LDAP with your AEM author instance. This is particularly useful within large enterprises where you would like to leverage the existing user profiles which are are typically maintained in LDAP.

We are using the following software stack:
CQ server – AEM 5.6.1
LDAP server – Apache DS 2.0.M15

First off, setup an LDAP server. There are a host of open source and free alternatives available to choose from such as openLdap, Apache DS etc.
For this blog post we’ll make use of Apache Directory server. To setup sample groups and users follow this excellent blog post: Configuring Apache Directory in Eclipse

After that its pretty much simple road to follow:

1. Follow all instructions as mentioned in the official documentation.
2. Create a dedicated group to which all LDAP imported users would be made members of.
   – Log into AEM as adminstrator and create a group called “iggroup“. All LDAP imported users would be made members of this group.
   – Add this group as a member of the default “contributer” group. This would ensure that all members of “iggroup” have minimum read access throughout the repository.
   If this is not done then while logging into AEM using the imported LDAP user’s credentials would result in a 404 error. This happens because of insufficient READ priviledges on the group to which the imported LDAP users are assigned.
   – You may modify the permission settings for “iggroup” as per your project requirements.
3. I have modified some entries in my “ldap_config.conf” file as explained below:a) The following attribute will ensure that all imported users from LDAP are placed under this group. You could specify more than one group here (Comma separated).
   autocreate.user.membership=”iggroup”b) Other user and group level property mappings such as:[js]autocreate.user.mail="profile/email"
   autocreate.user.givenname="profile/givenName"
   autocreate.user.sn="profile/familyName"
   autocreate.group.description="profile/aboutMe"
   autocreate.group.mail="profile/email"
   autocreate.group.cn="profile/givenName"[/js]

   You could similarly include other properties from LDAP user profile into CRX by extending the mappings.
   c) autocreate.path="none"
   This attribute controls how within CRX the users get created. It can have 2 more values which are, “direct” and “splitdn“. These two have been discussed at great length in the official documentation so will not explain further. But what is worth sharing is that for both these values (“direct” & “splitdn“), the users are created directly under /home/users and groups under /home/group.While creating users and groups via AEM you would notice that groups and users are created by further breaking down the user/group node by the first letter.

   Example, content-authors and contributor groups are placed under “/home/groups/c” folder structure. If you intend to keep this for imported users as well, use “none” as the attribute value.

4. Restart CQ instance. Also include the ldap_config.conf file in the start script.

If something is wrong with your configuration(such as Appropriate LoginModule cannot be determined etc), then your instance will not start. You should see a blank login/welcome screen. Refer Troubleshooting section below.
If you see the default login screen, then log in with an LDAP user credential. If everything has been setup correctly you should be logged in.
A way to test if LDAP has been integrated with your CQ instance is via the Felix JMX console http://<host>:<port>/system/console/jmx. You should see an entry like “com.adobe.granite.ldap”. If you click on this entry then you’ll see some LDAP details such as LDAP host, port, user, user.root etc

All methods under this JMX entry are self explanatory though I would like to clarify one named syncAllUsers(). This will only update already imported users in CRX (50 users) with latest changes from LDAP server (10000 users). When this method is invoked, only the already existing (50 users) will be updated with latest LDAP profile data.
Please note that all users in LDAP are not imported into AEM/CRX. A Lazy loading mechanism is used to import users into CRX. The sequence of action is such that when user logs into AEM, first the user is looked at within CRX. If not found in CRX, then this request is sent to LDAP. When LDAP successfully authenticates the passed credentials, that user’s profile is imported into CRX (cached).

Troubleshooting steps

1. Repository.xml -> Make sure there are no “–” within comments, as this can interfere with the xml parsing. Tail “stdout.log” file to detect XML parsing error messages.
2. Start script parameters ordering is important. Check “quickstart.bat” to get an idea.
   Example: java -Xmx1024M -Xms512M -XX:MaxPermSize=384M -Djava.security.auth.login.config=crx-quickstart/conf/ldap_login.conf -jar cq5-author-4602.jar -nofork
3. If you are forking JVM, make sure to include the -fork -forkargs -- %forkparams% at the end. And the fork arguments should be at the very end of the command line arguments.
   (If allocated memory is found to be low, forking happens automatically. Can be stopped via “-nofork” argument)
4. After setting up LDAP, you restart AEM with appropriate LDAP config and log in using an LDAP user credential and are presented with a 404 error code and an error stack trace on welcome page.
   This means that the imported user does not have appropriate READ permissions. You could give READ permission to this user although the appropriate way would be to give READ permission to the group (iggroup) to which imported LDAP users are assigned as members. For this reason we had started off by making “iggroup” as member of the “contributor” group so that “iggroup” inherits the default permissions from the “contributor” group.

Ashish