[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: translucent overlay and local objects?
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
>