Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

What's the most obvious way of achieving the following: The site has an working AD infrastructure and certain parts of the infrastructure are tightly coupled GNU/Linux machines where people from the AD OU ou=linux-users,dc=example,dc=com should be able to log onto the Linux part of the infrastructure using their AD credentials but without using the DC in the Linux machine's PAM stack, ie there should be some kind of synchronization plus augmentation with the POSIX attributes (uid,gid,homedir,password) from AD to slapd. The slapd on the linux machines is OpenLDAP, the schema of the AD is from Windows 2003 without the POSIX attributes.

share|improve this question
add comment

2 Answers

up vote 2 down vote accepted

Ldap Synchronization Connector (LSC) can be used to set up a continuous synchronization from AD to an OpenLDAP server, while adding extra attributes generated however you like.

However, this won't directly allow use of the AD's credentials, unless you set up OpenLDAP to forward BIND requests to the AD servers... but then you depend on the AD infrastructure being available.

Relying on the credentials in AD is tough, because you either need to have the credentials in clear text elsewhere, or depend on using AD for binds, or set up password synchronization. Check out Active Directory password synchronization options.

One option not described on that page is exporting the list of hashed passwords from an AD server, but that is a one-shot operation, not continuous sync.

share|improve this answer
add comment

Is there a particular reason you don't want the AD servers in the PAM stack? The best solution here is to add the POSIX/RFC2307 attributes to your AD users and point pam_ldap/nss_ldap (or nss_ldapd) at the AD servers.

If you have network security / load concerns that prevent you from querying AD directly you can use OpenLDAP's proxy/cache capabilities or deploy limited AD slaves to service the Linux hosts.

I would advise against having "augmented" accounts -- it can be done through some pretty dirty hacks, but in my experience it is too fragile to trust in a production environment. It also breaks the "one authoritative source" paradigm: If AD is your authoritative account store the POSIX attributes should be added and managed there.

share|improve this answer
    
The reason I can't use the AD servers there is that the Linux machines in question are pretty much self enclosed and should not depend on the AD infrastructure to be available, the other reason is that users from an other non-trusted domain should be able to logo on too. The Linux hosts are kinda shared between two orgs with no common infrastructure in place. –  pfo Jan 26 '10 at 23:35
add comment

Your Answer

 
discard

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.