What I am doing...
Trying to implement single-sign-on for our organization’s all machines, blogs, wiki’s, CRM, HRM, project management tools, SVN, etc, etc...
We have OpenLDAP installed and configured on our dedicated server running CentOS. I used phpLdapAdmin to add organization structure and info about various users, clients, resources.
An example entry for a user...
DN is :: cn=Bill Gates, ou=users, dc=example, dc=com
userid :: bill.gates
mail :: [email protected]
userpassword :: as2%$%66789ds (some md5 cryptic value)
Where I am now...
OpenLDdap is working fine. Bind test also ran successfully.
What I want to do...
Bind using higher privilege user and then search users by their entered userid or mail, which are slightly different from CN. Point is I want to authenticate user against an attribute which is not part of RDN.
Where I am stuck...
- I can’t bind using userid as its not apart of DN. Is this allowed in general?
- I can bind using different LDAP user say, high-privileged user and do ldap_search to get a unique record based on filter userId but then md5 of user entered password doesn't match with userPassword field. OpenDLdap encrypts using some salt. I don't want to remove salt either. Is there any way out?
My questions (finally)
- Can we do ldap_bind on an attribute which is not part of RDN?
- Can we send a unencrypted password (I will use HTTPS tunnel for security) to OpenLDAP server and ask OpenLDAP to encrypt is and check against userpassword filed? This is normally we do in all web-apps, right?
- (off-topic) Can userid contain . (dots) and spaces. We need some char between “First Name(givenName)” and "Last Name(sn)". Which one is safe character? I mean which non-aplha-numeric character is allowed in usernames by world's all (or most) application?
My biggest concern is to go with an approach, which can be easily made to work with most apps. There are many web-based apps, desktop softwares, etc which we will be modifying during our mission single sign-on!
Thanks for reading... and thanks in advance for some help!
-Rahul
Regarding the first question:
I've worked with another LDAP system that allowed 'login' against various user attributes. The solution was to do two connections. The first connection, probably anonymously bound, queries LDAP with the user-supplied information to locate the RDN of their user object. The second connection attempts a bind-with-password with the discovered RDN and the supplied password. It's a two step process, and it works.
Though, if this app is going to get a lot of logins with supplied attributes that are not the RDN itself, it'll be a real good idea to index those attributes. It's a performance thing.
Two:
OpenLDAP supports LDAP-SSL so far as I remember (TCP/636), which may be a better route than an HTTPS tunnel. By default LDAP binds are in the clear, but there are LDAP extensions that allow additional methods. Active Directory allows NTLM LDAP-binds for instance, and I'm pretty sure LDAP has been kerberized as well at some point. I don't know what methods openLDAP supports.
Three:
I have LDAP sources that have emails of the "[email protected]" format in attributes. Where it gets more dicey is with the naming attributes, and that's where my openLDAP experience falls flat. I don't know what it supports for that. I know that Active Directory allows spaces in the naming attributes, and Novell eDirectory allows both spaces and periods (though it isn't recommended to do so). Typically the naming attribute is userID and attributes like givenName, surname, emailAddress, contain the special characters. As they're not naming attributes they don't have the same restrictions.
I'm afraid I don't know OpenLDAP well enough to help with it specifically, but I wonder if it has a feature analogous to OpenDS's identity mapping feature that you could use.
The idea is that a client can identity itself with a custom identity and then the mapping uses a regular expression to match this to any other attribute on the user's entry. In OpenDS, this seems to use the SASL options and so using their tools, I can supply options such as:
The authentication ID is then used by the identity mapper, which in this case matches the uid attribute on my user entry.
Hope that helps!