Hi Eugene,

All changes you make to a translucent proxy will be written to the local database. They are not written upstream. I think you will want to mess with the chain overlay to produce an affect like that.

I have been able to achieve what you are proposing by creating a subordinate database for my entirely new objects. The translucent proxy serves and modifies objects at dc=example,dc=org, and the subordinate database lives at ou=ext,dc=example,dc=org.

Cheers, David

On Tue, Apr 10, 2012 at 9:10 AM, Eugene Vilensky evilensky@gmail.com wrote:

On Mon, Apr 9, 2012 at 5:15 PM, Howard Chu hyc@symas.com wrote:

...

Read slapo-translucent(5).

Thanks, it's a good read.  Since it only mentions the remote Search operation, my next questions might be moot...

...

...

but is it possible to store entities locally using the translucent overlay?

No.

Will entities created against the translucent overlay be created in the 'upstream' directory, provided our bind dn to that directory has necessary privileges?

...

...

The overlay works for what we are trying to do when it comes to search and modifying attributes on an entry, but I would like to create an entire local groupofnames, consisting of remote UIDs.

That is not supported.

Would it be found anywhere on the roadmap?

Thanks again, Eugene

Eugene Vilensky wrote:

I am on RHEL5, slapd 2.3.43, hence I'm still working with slapd.conf. (Learning the 2.4 dynamic configuration style is on my to do list...I think I will want the memberof attribute overlay)

The dynamic configuration mechanism was released in 2.3. It is documented in the 2.3 Admin Guide. There is no reason to stay with slapd.conf.

David N. Blank-Edelman wrote:

Hi Howard-

On Apr 12, 2012, at 7:01 AM, Howard Chu wrote:

...

The dynamic configuration mechanism was released in 2.3. It is documented in the 2.3 Admin Guide. There is no reason to stay with slapd.conf.

Back in June of 2011 on this list, you had said:

Howard Chu wrote:

...

As of several months ago, only back-sql and back-meta remain incompatible. All of the overlays have already been converted.

The back-meta conversion was the thing holding us back from moving to the correct config method. Has that and back-sql been converted? If so, that would be great.

back-sql has been converted.

Eugene Vilensky wrote:

So the meta-backend cannot be used in 2.4 releases, which mandate dynamic configuration?

2.4 still supports slapd.conf. Nobody has mandated anything.

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