Keep AD Group Synced in OpenLDAP with POSIX Account Augmentation

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.

Solution 1:

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.

Solution 2:

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.