Active Directory and OpenLDAP synchronization
I have been digging holes on google to find out the best way to synchronize the user database between AD and OpenLDAP. What i want to achieve is, have user database in AD and then propagate these users to OpenLDAP so these users can access all my applications(email, vpn, file server, print server almost all the opensource apps). I want to create a single sign on database so all users can have same passwords for windows and linux based apps. I also want to make sure the passwords are updated bidirectionally. I will appreciate if anyone can share his experience on how this can be done. Thank you!!
Solution 1:
I did this once for a project -- good luck! Do you have administrative access to the AD server? you might need it. Make friends with your AD admin :-)
Can you please elaborate more what your project is about?
The question is if you just need your users / applications to authenticate against ActiveDirectory or LDAP, or if you need your applications to access the data that's stored in ActiveDirectory, and perhaps augment or modify the entries..
If you just need to authenticate, then as Justin pointed out, either an annonymous or password-protected (not much extra value IMHO) bind account on the ActiveDirectory server is all you need. Talk to your ActiveDirectory admin.
If you want to use the contents of ActiveDirectory as the basis of your own user records, and perhaps augment or modify the data, you might need to set up your own LDAP server (because your IT department might not be thrilled by the idea that you modify "their" records...)
ActiveDirectory looks like LDAP and is similar, but there are differences mainly in the schema.
You will run into a couple of problems:
- AD schema and attributes are quite a bit different from the LDAP Standard
- in particular, from what I understand, the AD schema is somewhat pre-defined and fixed, because all the Micro$oft applications require a certain schema...
- there might not be an anonymous access set up by default for AD , as it is for LDAP (that makes it difficult to just do an LDAP query on the command line to test things out) You might want to ask your AD Admin to set one up for you
- Your authenticated user accessing AD might not have permission to see all AD records and/or the Schema
I remember that i found tons of inconsistent records in AD, e.g. wrong organizational structure, people records mixed-in with records for machines, devices, software - ugh!! and people records strewn accross the schema (not all people records in just one sub-tree as you would expect in an LDAP schema)
... to be completed ...
If you just need people or applications to authenticate against a Directory, then it might not be worth going through all this hastle -- it's better to just use AD directly via a bind account.
Use the openldap command line tools to try to authenticate against ActiveDirectory on the UNIX command line. That will help you to get a feel for the process and the data that is returned.
let me look at my old project notes and i'll update this
I hope this helps you
to authenticate against OpenLDAP, you'll need to know values of "distinguished name" (dn) of your organization, "organizational unit" (ou), the "common name" (cn) of the person authenticating, etc.. but I can't give you a full intro here...
It's best to read in the documentation of OpenLDAP here: http://www.openldap.org/doc/admin24/
it's best to run "ldapsearch" on the command line to try out and verify that you can bind / access LDAP. http://www.openldap.org/software/man.cgi?query=ldapsearch&apropos=0&sektion=0&manpath=OpenLDAP+2.0-Release&format=html
or at the IBM site: http://publib.boulder.ibm.com/infocenter/iseries/v5r3/index.jsp?topic=%2Frzahy%2Frzahyunderdn.htm
Solution 2:
An option worth investigating might be to use Active Directory for authentication and your existing OpenLDAP for authorization:
http://www.openldap.org/doc/admin24/security.html#Pass-Through%20authentication
As noted in the above documentation, you can delegate your username/password verification to Kerberos. In fact, the examples given (see 14.5.2) show how to set this up to authenticate to an AD domain. You will need to set up a user account in Active Directory that can bind to the DC in order to run an LDAP query. This user account should have no permissions to access any Windows servers, nor should it be in any sensitive security groups.
Hope that helps.
Solution 3:
Had to solve the same problem for my company.
Being Linux-centrics, the password had to be synchronized between:
- OpenLDAP shadowAccount userPassword (legacy PAM/LDAP authentication)
- OpenLDAP sambaSamAccount sambaLMPassword and sambaNTPassword (legacy NTLM/Samba authentication)
- OpenLDAP krbPrincipalAux krbPrincipalKey (actual PAM/MIT-Kerberos-V authentication)
- Microsoft Active Directory (satellite Windows domain)
Now, the main problem you have is that:
- passwords are (outght to be!) cryptographically hashed; the original cleartext password can NOT be recovered from what is stored in OpenLDAP or Microsoft Active Directory
- meaning you can not synchronize from one storage backend to the other (EDIT: and each backend has its own hash functions, none being compatible with the other backends)
- meaning you have to change all passwords synchronously on all backends at the time the user changes its password, that is the only time you have the cleartext password handy
- knowing that each backend has its own contingencies and complexities to deal with password changes
- meaning you really ought to let each backend deal with the password change "natively": let Kerberos creates the corresponding keys (many of them, depending on which algos your Kerberos realm supports), let Active Directory change the password its own way (which is not open sourced and changes opaquely whenever Microsoft deem it necessary), etc.
So I came up with this: https://github.com/cedric-dufour/upwdchg ; shortly put:
- a unsecure user-accessible frontend (client) to let users request password change
- a secure processing backend (server) - with appropriate administrative privileges - that performs the password change on all backends, using their own "native" method
By "native" method, I mean:
- OpenLDAP Password Modify (RFC 3062) operation for shadowAccount userPassword
- OpenLDAP 'smbk5pwd' overlay for sambaSamAccount sambaLMPassword and sambaNTPassword (NOT for Kerberos; 'smbk5pwd' only supports Heimdal Kerberos)
- The MIT Kerberos V admin server and its "kadmin" and "password_change" operation
- Microsoft documented way of changing the AD "unicodePwd", as per http://support.microsoft.com/kb/263991