I have been using Liferay EE 6.1 with OpenLDAP the past few days, using different testing scenarios for functionality and determining pitfalls. The goal was to test complete functionality, such as authentication, importing, exporting, and password policies, implemented at the same time.
My LDAP directory contained a few key pieces of information: Users, Groups, and Password Policy
“Users” values:
Authentication Search Filter = (uid=@screen_name@)Import Search Filter = (objectClass=inetOrgPerson)Screen Name = uidPassword = userPasswordEmailAdress = mailFirst Name = givenNameLast Name = snJob Title = titleBlank fields: Full Name, Middle Name, Portrait, Group, and UUID“Groups” values:
Import Search Filter = (objectClass=groupOfNames)Group Name = cnDescription = descriptionUser = member“Export” values:
Users DN = ou=Users,ou=Accounts,dc=jparkertest,dc=comUser Default Object Classes = top,person,inetOrgPerson,organizationalPerson,shadowAccountGroups DN = ou=Groups,ou=Accounts,dc=jparkertest,dc=comGroup Default Object Classes = top,groupOfNames
With a properly configured LDAP directory, these options are sufficient to make all of the requirements function. This includes authentication, importing, and exporting from LDAP.
Initially I tested a user “Jason Parker” not in any groups (not found as a member of my Group DN records). When this user did not belong to a group, the user could properly authenticate and use Liferay. While testing group permissions, I added the user to a group, and tried to login again. I began receiving errors.
With Exporting turned on, this user no longer could login once they were part of a group. The Liferay UI may or may not throw an exception (depending if you are using clustering).
From Liferay (Tomcat) logs:
Caused by: javax.naming.directory.InvalidAttributeIdentifierException: [LDAP: error code 17 - : empty AttributeDescription]; remaining name 'cn=Jason Parker,ou=Users,ou=Accounts,dc=jparkertest,dc=com'
From slapd.log (OpenLDAP logging):
slapd[7219]: send_ldap_result: err=17 matched="" text=": empty AttributeDescription"
I began browsing through Liferay forums and issues online. I found quite a few people mention “AttitbuteDescription” as an error. In general, it is due to there being a value Liferay is requesting to read or write that the configured filters are not matching. It can occur for issues other than this Groups issue (example: Invalid uid code is one I came across, but it’s error code 21).
I confirmed from previous imports and exports to MySQL that Liferay was reading the Groups and associated members I had in LDAP properly. For some reason a user belonging to one caused an exception and failure to login.
Reviewing the Users strings, I noticed I lacked a value for “Group” under the User DN. In my LDAP directory, the Users DN records do not contain listings of groups they belong to, that’s handled in the Groups DN records. To properly utilize Liferay’s LDAP Exporting functionality, something has to be in the “Group” field under Users LDAP strings, if they in fact belong to a group and it’s found via the Groups DN listing.
I proved this by running tcpdump. tcpdump is great for capturing unencrypted network traffic for analysis. In this case, I wanted to know what Liferay was sending to LDAP to receive the “empty AttributeDescription” error in slapd.log.
My environment has OpenLDAP listening on localhost (same instance as Tomcat Liferay EE 6.1 Cluster). In an ideal environment, they would be separated. So long as encryption is not in use for LDAP, the following will capture data sent from Liferay to LDAP:
(As root):
tcpdump -i <interface> port <port> -w <filename.pcap>
For my needs (ldap://localhost), I used:
tcpdump -i lo port 389 -w ldap.pcap
I started the tcpdump command right before I logged in to Liferay UI. I terminated the capture once login failed (CTRL+C). I then copied this pcap file to a system with wireshark GUI on it to analyze (this can be done on console with pcap tools, but wireshark is a wonderful program for sysadmins, natively reads tcpdump pcap output).
After loading ldap.pcap, I search (CTRL+F) for a String (select the String radio box) “AttributeDescription” (the exception in both LDAP and Liferay lgos). I run “Find” in Wireshark, and it pulls up a list of packets which match. From here, simply right click the first one that matches (Wireshark selects it in the list), and choose “Follow TCP Stream”. This brings up a text box with what happened in that TCP stream. You can see Liferay is pushing the “member” value from the configured “Group DN” for our user back to LDAP (export function), without specifying where to put this data.
I have attached a screenshot below showing this output, it can be useful in many troubleshooting scenarios outside of simply Liferay and LDAP.
In red is the data sent from Liferay to LDAP (inbound to LDAP). In Blue is data sent from LDAP to Liferay. I have highlighted the first portion — it shows the “sn” value, “givenName” value, “title”, value, etc from “Users” filters in Liferay LDAP settings being pushed to LDAP. The following section in a separate box shows the values from Group memberships (per our Group DN lookup) are being pushed back to LDAP User DN, and that’s where it fails. There are NO values proceeding them, so LDAP doesn’t know where it’s to put the data, hence the “empty AttributeDescription” error.
In this case, using “businessDepartment” for the User DN “Group” value/filter in LDAP settings for Liferay resolved the problem. Liferay needs to send the member Group roles back to a User DN, even if that’s not in use in your LDAP environment (When exporting is in use).
Failure to configure this properly prevents LDAP authentication from working when Export is turned on.