Active Directory and OpenLDAP synchronization

Question

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!!

Active Directory *is* LDAP (or at least a derivative of it), and can be accessed as an LDAP server. In the past, rather than introducing a separate OpenLDAP server for non-Windows systems I simply created a "bind" account in AD and then used the domain controllers as my LDAP servers. If you don't already have an OpenLDAP infrastructure in place, this might get you up and running faster. — Justin ᚅᚔᚈᚄᚒᚔ, Oct 05 '11 at 18:31
@Justin: i did that in the past, and had to do significant data clean-up before I could use the AD data in my LDAP server instance. The AD schema is just to wacko. If he wants to just bind and authenticate, then having a bind account might be ok. — , Oct 05 '11 at 18:37
@Tilo: I agree, AD schema is strange. However, I was successful in using it for basic authentication and authorization in several instances. Recognizing that "sAmAccountName" is the username is usually sufficient to achieve simple authentication. For more complex setups, or if you need to store any custom attributes, a separate LDAP infrastructure is highly recommended. — Justin ᚅᚔᚈᚄᚒᚔ, Oct 05 '11 at 18:42
@Justin: yes, definitely good enough for basic authentication and authorization. — , Oct 05 '11 at 19:05
@Tilo peolple find strange what they don't understand. Be careful to understand what LDAP is and is not. Much of the things that look strange in AD are just comming from X500 standard, or from the needs of the main application working on it which is Microsoft domains. — JPBlanc, Oct 05 '11 at 19:11
@Justin: yes, I'm aware of that.. :) coming from NSCP, I never liked AD too much ;-) — , Oct 05 '11 at 19:31

score 3 · Answer 1 · answered Oct 05 '11 at 18:25

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

thanks for your quick response. We already have a full OpenLDAP database in our office. i dont think so forcing open source applications(postfix, dovecot, vpn, file server etc) which are currently being authenticated by OpenLDAP to contact AD is a good idea. Plus i am not sure if AD supports all the opensource applications which we may bring in our office in the future. What i really want is for AD to just manage the user database and then propagate it to openLDAP. I dont want my applications to authenticate to AD, i will prefer to stick to openLDAP for application authentication. — , Oct 05 '11 at 19:42
I am not sure how AD with bind accound works? can someone share some tutorial i can look at to better understand how i can help me solve this problem. btw i have full permission to all the systems in my office :) — , Oct 05 '11 at 19:45
if you already have openLDAP infrastructure in place, then by all means authenticate against it! I'll add a note at the end of my answer — , Oct 05 '11 at 22:44
in simple words "binding to LDAP" is similar to "logging in and connecting" .. it means that you are authenticating against LDAP and gaining access to LDAP based on who you are and what your privileges are: http://msdn.microsoft.com/en-us/library/windows/desktop/aa366092(v=vs.85).aspx — , Oct 05 '11 at 22:57
please accept / up-vote if this answered your question. thank you. — , Oct 05 '11 at 22:58

score 1 · Answer 2 · answered Oct 05 '11 at 20:46

1

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.

answered Oct 05 '11 at 20:46

Justin ᚅᚔᚈᚄᚒᚔ

426
4
13

that does seem like a easy solution. But do you think with this implementation the users created in AD will be able to access applications such as email or fileserver which are connected to OpenLDAP and are currently only accessible to users created in openldap. thanks – Oct 05 '11 at 21:52
It depends on how you set it up. The implementation described above assumes that you're going to create users in OpenLDAP and then use the domain controller to authenticate them. In this case, you can set whatever authorizations are needed on the OpenLDAP account when creating the user. – Justin ᚅᚔᚈᚄᚒᚔ Oct 05 '11 at 22:13
@Justin: +1 good point – Oct 05 '11 at 23:00
I wish to create users in AD so i can apply group policy password rules at users password. that is one of the primary reason why we are bringing AD into our network. is there a way to create users in AD and then simply synchronize them?? – Oct 05 '11 at 23:01

score 1 · Answer 3 · answered Sep 16 '16 at 07:57

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

score 0 · Answer 4 · answered Oct 07 '11 at 21:43

I did similar project 2 years ago and I was in similar position not knowing where to start and how to tie the ends together.

Step1: Figure out what you want to accomplish and write it down. Step2: See if the requirements are realistic and can be accomplished altogether. If not, what items are you willing to sacrifice. (This is where it takes a long time). step3: Choose a platform for LDAP. in your case, you already have an existing one. step4: Documenting & Testing. step5: The cut over plan is most critical as it doesn't matter if you accomplish all you wanted to but also to make sure there is a smooth transition. In my case, we had to do in a phased manner.

From reading you comments above looks like you already have Openldap in production. Your requirements look like:

a) Allowing users to use same password policy on AD.

b) User accounts to propagate to LDAP automatically.

Answer to a) You can setup a PAM pass-through module in LDAP to delegate password authentication to a DC via kerberos. In this way you will not have the headache of maintaining password in two places. I did on 389-DS LDAP, and the documentation link should be sufficient. When a user authenticates, the PAM module checks if user account exists in LDAP and if so, passes the passwd to PAM stack with krb5.so to authenticate. Check 389-DS documentation which should apply here too.

Answer to b) I hit all the cylinders to figure out a way to use a ready solution but nothing came close. This is because you have to massage the schema for accounts and groups. So I with the help of a colleague wrote a script in perl to sync the users & groups from AD to LDAP. A snippe to f code is here.

thanks prashanth.. I am trying to implement your suggested solution now. thanks dude... hopefully this will solve my problem. I will post any issues i may face. — , Oct 07 '11 at 22:43

Active Directory and OpenLDAP synchronization

4 Answers4