Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

share|improve this question

migrated from Oct 10 '11 at 11:09

This question came from our site for professional and enthusiast programmers.

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 5 '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. – Tilo Oct 5 '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 5 '11 at 18:42
@Justin: yes, definitely good enough for basic authentication and authorization. – Tilo Oct 5 '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 5 '11 at 19:11

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:

it's best to run "ldapsearch" on the command line to try out and verify that you can bind / access LDAP.

or at the IBM site:

share|improve this answer
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. – linuxcraft Oct 5 '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 :) – linuxcraft Oct 5 '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 – Tilo Oct 5 '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:… – Tilo Oct 5 '11 at 22:57
please accept / up-vote if this answered your question. thank you. – Tilo Oct 5 '11 at 22:58

An option worth investigating might be to use Active Directory for authentication and your existing OpenLDAP for authorization:

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.

share|improve this answer
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 – linuxcraft Oct 5 '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 5 '11 at 22:13
@Justin: +1 good point – Tilo Oct 5 '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?? – linuxcraft Oct 5 '11 at 23:01

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

share|improve this answer
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. – linuxcraft Oct 7 '11 at 22:43

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.