Hi Eugene,
I've gone through my config and pulled out the useful bits. It's in the cn=config ldif format. I'm succesfully using this in production to give Active Directory users under dc=company,dc=com the extra bits (uid/gid, homeDir etc) needed to access our unix machines. We cannot get the AD admins to put this information into AD itself. We can also make "local" users, groups, nisMaps and anything else under ou=local_ext,dc=company,dc=com.
# All I need from AD is the sAMAccountName, which I use as user's UID. I do not # use AD groups but rather create my own groups under ou=local_ext. dn: cn=ADext,cn=schema,cn=config objectClass: olcSchemaConfig cn: ADext olcAttributeTypes: {0}( 1.2.840.113556.1.4.221 NAME 'sAMAccountName' DESC 'MS User identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SY NTAX 1.3.6.1.4.1.1466.115.121.1.15{256} )
# Completeley new records go under ou=local_ext. Note the subordinate declaration # to define a glue database dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap/local_ext olcSubordinate: TRUE olcSuffix: ou=local_ext,dc=company,dc=com olcRootDN: cn=config
# The database to hold annotations to entries in the remote AD dn: olcDatabase={3}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {3}bdb olcDbDirectory: /var/lib/ldap/translucent olcSuffix: dc=company,dc=com
# The translucentLocal declaration is important for nss_ldap to work dn: olcOverlay={0}translucent,olcDatabase={3}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcTranslucentConfig olcOverlay: {0}translucent olcTranslucentLocal: uidNumber,gidNumber,loginShell,homeDirectory
# The IDAuthzFrom decl effectively grants anonymous read-only access to AD # to clients. You may not want this. You wouldn't want to ignore the ssl cert # in production, either. dn: olcDatabase={0}ldap,olcOverlay={0}translucent,olcDatabase={3}bdb,cn=config objectClass: olcLDAPConfig objectClass: olcTranslucentDatabase olcDatabase: {0}ldap olcDbRebindAsUser: TRUE olcDbURI: ldaps://company.com:3269 olcDbACLBind: bindmethod=simple timeout=0 network-timeout=0 binddn="cn=readonly,dc=company,dc=com" credentials="secret" tls_reqcert=allow olcDbIDAssertBind: bindmethod=simple binddn="cn=readonly,dc=company,dc=com" credentials="secret" mode=none tls_reqcert=allow olcDbIDAssertAuthzFrom: {0}dn.regex:.*
That's what works for me. There is a lot of extra work I put in to setup a redundant pair, caching, etc, but this should get you the core functionality you're looking for.
Cheers, David
On Tue, May 15, 2012 at 5:10 PM, Eugene Vilensky evilensky@gmail.com wrote:
I implemented desired functionality minus translucency by having the following database clauses -- (I can create entities within the ou=groups and searches against the ou=Users are results from remote LDAP.
database bdb suffix "dc=dept,dc=example,dc=org"
database meta suffix "dc=example,dc=org"
uri "ldap://remoteldap.example.org/ou=people,dc=example,dc=org" uri "ldap://localhost/ou=groups,dc=dept,dc=example,dc="
It's probably bad form to reply to my own query, but maybe someone has experience with this?:
Given the meta directory proposed above, what would be the best way to add translucency as as well?
Thanks for any advice, Eugene