2:34 p.m.
Greetings,
Pardon if this is an RTFM (I'd love a link), but is it possible to
store entities locally using the translucent overlay?
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.
For example, this LDIF imports OK:
#!RESULT OK
#!CONNECTION ldap://xxxxx
#!DATE 2012-04-09T16:01:33.961
dn: cn=instructors,ou=Groups,dc=xxxx,dc=zzz
changetype: add
objectClass: groupofnames
member: uid=nate
member: uid=penelope
member: uid=rhonda
cn: instructors
But searching for it does not bring back a result.
However, it must have gone somewhere since if I try to import the same
LDIF again:
#!RESULT ERROR
#!CONNECTION ldap://xxxxx
#!DATE 2012-04-09T16:21:28.221
#!ERROR [LDAP: error code 68 - Entry Already Exists]
Kind regards,
Eugene
3:15 p.m.
Eugene Vilensky wrote:
Greetings,
Pardon if this is an RTFM
Yes.
(I'd love a link),
Read slapo-translucent(5).
but is it possible to
store entities locally using the translucent overlay?
No.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:10 a.m.
On Mon, Apr 9, 2012 at 5:15 PM, Howard Chu <hyc(a)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
3:33 p.m.
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(a)gmail.com> wrote:
On Mon, Apr 9, 2012 at 5:15 PM, Howard Chu <hyc(a)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
7:49 a.m.
Hi David
On Tue, Apr 10, 2012 at 5:33 PM, David Arroyo <david.a.arroyo(a)gmail.com> wrote:
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.
This would explain the behavior that objects already exist :) Thank you.
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.
Is it possible you could share with me a skeleton of your
configuration? 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)
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="
4:01 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
7:40 a.m.
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.
-- dNb
11:10 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:20 a.m.
On Thu, Apr 12, 2012 at 1:10 PM, Howard Chu <hyc(a)symas.com> wrote:
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.
So the meta-backend cannot be used in 2.4 releases, which mandate
dynamic configuration?
Thank you,
Eugene
6:47 a.m.
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.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
2:10 p.m.
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
5:28 p.m.
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(a)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
4223
days inactive
4261
days old
openldap-technical@openldap.org
11 comments
4 participants
participants (4)
-
David Arroyo -
David N. Blank-Edelman -
Eugene Vilensky -
Howard Chu