Here’s the general premise to ALI Directory Services: ALI 6.5 ships with this new Directory Services component that provides an LDAP service for Portal User accounts.  The idea is that historically, the portal has been great at synching users from external repositories (from AD, LDAP, or custom sources) into its own database. Once those users get synched and aggregated into the portal, though, they’re not exposed to any other services.  Directory Services aim to resolve that problem: 6.5 provides an LDAP server that uses the industry-standard LDAP protocol to expose users that have been synched to the portal.  So any other system can use LDAP to get user information.

Fantastic feature, right? But with the dearth of documentation out there, what may not be immediately obvious is that this Directory Service is also used by internal components such as the Notification Server.

I’ve only begun to scratch the surface with how all these components work together, but if you’re interested in reading about how they DON’T work together (saving yourself hours of diagnostic time), hit the jump.

This was the problem: The notification service was throwing the following exception:

Unable to retrieve user with UUID '{75AC0C94-1191-50A1-7217-1348987BA000}'
com.plumtree.security.InternalServerException
at com.plumtree.security.client.impl.util.ExceptionHelper.translate(ExceptionHelper.java:38)
at com.plumtree.security.client.impl.entity.UserManagerImpl.findUserByUuid(UserManagerImpl.java:79)
at com.plumtree.security.entity.UserManagerWrapper.findUserByUuid(UserManagerWrapper.java:48)

At first I thought the problem was with the “BEA ALI Security and Directory Service” component, but then started to focus on the “BEA ALI LDAP Directory” service (Don’t get me started on the worthlessness of the exception itself.)

Anyway, the moral of this story is that the port set in the Configuration Manager for the “AquaLogic Notification Service” (under “User and Group Directory”) didn’t match the port for the “ALUI Directory” (under “LDAP Listener Settings”).

Because we already had an LDAP server running on that machine, I had to change the port for the LDAP service to 2389.  But I also needed to change the port that Notification Server used to connect to it – which is fine, but isn’t that the point of the Configuration Manager – change a setting once and it’s reflected everywhere?

All well and good, sure, but how do you authenticate against this fancy new LDAP service in the ALI stack?  I tried using an LDAP Browser (stay tuned for that “cool tool” coming up) to see what the service had to offer, and had no idea how to authenticate against it.  It kept requesting a password, and I kept using “administrator” and the admin password.  No dice.

So I turned to another trust Cool Tool, TcpTrace, and exploited the fact that the Configuration Manager allows you to specify which port the LDAP server listens on separately from the port the Notification Service connects to it on (again, see the last post).  By getting the LDAP Server to listen on port 2389 and the Notification Service to connect on port 9999, I ran TcpTrace to proxy those connections from 9999 to 2389.  Here’s what I saw:

Aha!  The User ID isn’t just “administrator”; it’s “uid=administrator,ou=users,dc=bea,dc=com“.  (the red blobs are actually censoring our administrator users’ password).  Remind me again, how was I supposed to know that?  Oh yeah, maybe I wasn’t…

Anyway, when you do your 6.5 upgrade, you should be able to use the same format to connect to this LDAP service and check it out for yourself.  How?  Stay tuned!