openldap-technical

openldap-technical@openldap.org

9 participants
9868 discussions

Is there a simple document that explains the various admin passwords?
by Paul Pathiakis 11 Sep '19

11 Sep '19

Hi, I am trying to figure out all the various passwords and access controls. I seem unable to get my previously documented systems/configurations to work. I understand that slaptest is supposed to convert my slapd.conf to a new configuration and everything should be fine going forward. However, I'm having various password and access issues. Basically, I use my ldap.conf file and everything seems good. I start slapd and it works fine. I perform an ldap search and everything seems fine as it returns my domain. After that, I try to import my memberof.ldif file and it gives me an access issue. ldapadd -f /etc/openldap/memberof.ldif -v -D "cn=config" -H ldap://192.168.2.113 -W -c dn: cn=module,cn=config cn: module objectClass: olcModuleList objectclass: top olcModuleLoad: memberof.la olcModulePath: /usr/lib64/openldap dn: olcOverlay=memberof,olcDatabase={0}config,cn=config objectclass: olcconfig objectclass: olcMemberOf objectclass: olcoverlayconfig objectclass: top olcoverlay: memberof ldap_initialize( ldap://192.168.2.113:389/??base ) Enter LDAP Password: ldap_bind: Invalid credentials (49) Obviously, that's a password problem. My question is why? What step did I miss in my documentation? Thank you! P.

3 8

slapd and LetsEncrypt certificates: does a cert renewal necessitate a server restart?
by Jean-Francois Malouin 10 Sep '19

10 Sep '19

Hi, As the subject say, I'm contemplating the use of LetsEncrypt TLS certificates. Is there a way to make slapd aware of a cert renewal (they happen every 90 days) without restarting it, ie, with minimal service interruption? thanks, jf

6 6

Re: search request not blocked by ACLs
by Manuela Mandache 10 Sep '19

10 Sep '19

Le lun. 9 sept. 2019 à 18:25, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > > > --On Thursday, September 5, 2019 10:35 AM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > > > > > > > > > > > > > Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a > > écrit : > > > > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > > <manuela3mandache(a)gmail.com> wrote: > > > >> olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > >> dn.base="cn=adm > >> in,dc=example,dc=com" manage by * break > >> olcAccess: {1}to dn.base="" by * read > >> olcAccess: {2}to dn.base=cn=Subschema by * read > >> olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > >> auth > >> olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > >> olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > >> olcAccess: {6}to * by anonymous none by * read > > > > On what cn=config entry have you set these ACLs? > > > > > > > > > > They're on > > olcDatabase={2}mdb,cn=config > > This is the DB containing the actual data of the directory, with > > olcSuffix: dc=example,dc=com > > Given that, I would make the following notes: > > a) rootDNs are never subject to ACLs, so the access for cn=admin,cn=config > manage in {0} is suspect, as I would infer that is a rootdn. > > b) ACL {1} is invalid for this database. It should be set in the dn: > olcDatabase={-1}frontend,cn=config database > > c) ACL {2} is invalid for this database. See solution listed in (b) > > d) ACL {3} should only give auth access to anonymous, not * > > e) ACLs 3-5 should be rewritten to drop the dn.subtree="dc=example,dc=com" > bit entirely. You're already only setting ACLs for that database, no need > to list that restriction. You can also combine ACLs 4 & 5. > > olcAccess: {3} to attrs=userPassword by anonymous auth > olcAccess: {4} to attrs=entry,cn,mail by * read > olcAccess: {5} to * by anonymous none by * read > > Hello Quanah, Thank you for the detailed analysis of the ACLs - I wrote them based on very old inherited ones, but this is no excuse. Although I (believed I had) thoroughly RTFM, I feel like I only begin to really understand the way they must be defined. Well, back to the drawing board. Do poorly written ACLs have a strong impact on performance? > As for your question in general, I don't think you understand how ACLs > work > in relation to incoming search requests. The server did exactly what your > ACLs said it should do: It provided no information when someone tried to > search for data using an attribute that access is not granted to, and > correctly returned 0 entries. It sounds as though you expected the > connection to be dropped when the search was initiated because it was > filtering off of sn. No, I didn't think the connection would be dropped, but I thought no data which are never to be returned would be searched. E.g.: - there are three branches in the directory, ou=people,dc=example,dc=com, ou=dogs,dc=... and ou=carpets,...; - a user has read rights on ou=dogs and none on the two other branches; - this user makes a search with -b dc=example,dc=com and no filter. As far as I understand, the whole content is recovered, then the people and the carpets are dropped and only the dogs are returned. I expected the request to be parsed against the ACLs before performing the actual search in the directory, and so this search to be done only on ou=dogs. Maybe this example is completely different from the one in my first post: It's true that I do not know how requests-and-ACLs actually work. Is there some documentation I could read on the topic? Best regards, Manuela > That is now how things work. > > Regards, > Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

ldap_add: Insufficient Access (50)
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi all, I'm trying to restore/move a database from one machine to another and start making sure that my client uses all the correct .ldif files. Now, I've always done a slapcat to an ldif file and used sed in place to modify/remove all the extraneous entries from the dump so I can reload. Strangely, this doesn't look like it's working this time around. I get the "Insufficient access (50) additional info: no write access to parent" Seems obvious that I don't have some type of access at the beginning of the load near the base of the tree. (After I get this, I'm inundated with ldap_add: No such object (32) since it wasn't able to write things into a non-existent structure further down) I see a potential problem in that the tree was originally defined as dc=example,dc=com and, now, everything lives in: dc=hq,dc=example,dc=com . Is that the problem? If so, what's the easiest way around it? Ldap.conf has: BASE dc=example,dc=com Slapd.conf has: access to attrs=userPassword by self write by anonymous auth by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * compare access to attrs=sambaLMPassword,sambaNTPassword by dn="uid=syncuser,dc=hq,dc=example,dc=com" read by * none access to * by self write by * read access to dn.subtree="dc=hq,dc=example,dc=com" by self write by set="[cn=itlevel1,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by set="[cn=ntadmins,ou=Groups,dc=hq,dc=example,dc=com]/member* & user" write by * break authz-regexp "gidNumber=0\\\+uidNumber=0,cn=peercred,cn=external,cn=auth" "cn=root,dc=hq,dc=example,dc=com" database mdb suffix "dc=hq,dc=example,dc=com"rootdn "cn=root,dc=hq,dc=example,dc=com" Thank you all! P.

1 0

Re: search request not blocked by ACLs
by Manuela Mandache 09 Sep '19

09 Sep '19

Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount <quanah(a)symas.com> a écrit : > --On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache > <manuela3mandache(a)gmail.com> wrote: > > > olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by > > dn.base="cn=adm > > in,dc=example,dc=com" manage by * break > > olcAccess: {1}to dn.base="" by * read > > olcAccess: {2}to dn.base=cn=Subschema by * read > > olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * > > auth > > olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read > > olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read > > olcAccess: {6}to * by anonymous none by * read > > On what cn=config entry have you set these ACLs? > They're on olcDatabase={2}mdb,cn=config This is the DB containing the actual data of the directory, with olcSuffix: dc=example,dc=com Regards, Manuela > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

2 1

Why is dc=my-domain,dc=com in my namingContext?
by Paul Pathiakis 09 Sep '19

09 Sep '19

Hi, Something is amiss and I decided to rebuild from the start. # # LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example,dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never TLS_CACERTDIR /etc/openldap/cacerts # Turning this off breaks GSSAPI used with krb5 when rdns = false SASL_NOCANON on #TLS_CACERT /etc/openldap/cacert.pem #TLSCACertificateFile /etc/openldap/cacert.pem #TLSCertificateFile /etc/openldap/server.crt #TLSCertificateKeyFile /etc/openldap/private.key ssl start_tls TLS_REQCERT allow BASE dc=joescompany,dc=com URI ldap://127.0.0.1/ I start the ldap server and go to see if everything is ok. ldapsearch -x -b '' -s base '(objectclass=*)' namingContexts # extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts # # dn: namingContexts: dc=joescompany,dc=com namingContexts: dc=my-domain,dc=com # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 Should that second line even be there? Where in the world is it getting my-domain from? Is it a default? Thank you, P.

2 2

slapo-memberof(5) confusing documentation
by Norman Gray 09 Sep '19

09 Sep '19

Greetings. The slapo-memberof(5) manpage mentions limitations on when it can be used, in the context of replication. The current text is very confusing, and possibly not self-consistent. This message might be more appropriate as an ITS PR, but I'm sending it here first, partly in case I've got the wrong end of the stick, and partly as google-bait for the benefit of anyone as puzzled as I was. The text currently says: > The memberof overlay may be used with any backend that provides full > read-write functionality, but it is mainly intended for use with local > storage backends. The maintenance operations it performs are internal > to the server on which the overlay is configured and are never > replicated. Replica servers should be configured with their own > instances of the memberOf overlay if it is desired to maintain these > memberOf attributes on the replicas. Fine -- that seems to me to say very clearly that the memberof attribute is OK to use across replicas, as long as each replica has its own memberof overlay. However, immediately after that, the text says: > Note that slapo-memberOf is not compatible with syncrepl based > replication, and should not be used in a replicated environment. An > alternative is to use slapo-dynlist to emulate slapo-memberOf > behavior. This seems to flatly contradict (my understanding of) the first part of the paragraph. So which is it? A 2009 list thread [1] seems to suggest that you can sort of get away with it, but only just. However another list thread (2015) [2] describes an apparently successful setup using simple syncrepl, with memberof in the provider and consumer, and where the memberof attribute is automatically excluded from the replication (there’s explicit advice not to exclude it using exattrs=memberof in the syncrepl setup). The latter posting refers to ITS issue 7400 [3], ‘Memberof and Syncrepl incompatibility’, which last had activity in 2012, but which still appears to be open. The latter issue notes in passing that ‘memberof must be configured on each replica’, which implies that this is a feasible setup. **However**: closed ITS 8613 (2017) [4] says baldly that > The slapo-memberOf overlay is not safe to use in a replicated > environment due to the way in which replication occurs. It also explains why, and gives a (compressed but complete) suggestion of how one might use the dynlist overlay to do something similar. A 2018 list message [5] says in passing > Unfortunately, there is no defined standard for the “memberOf” > functionality (it’s a MS hack) and so there’s nothing that details > how it should or shouldn’t behave with replication. Going with the most recent statement, therefore, it seems that this it's simply not possible to use memberOf in a replicated environment, unless (rather precariously, I'd have thought) you completely avoid 'refresh' mode in replication, as mentioned in [4]. I suggest adjusting the text in the slapo-memberof manpage. If the third sentence (‘Replica servers should...’) were simply removed, that would remove most of the contradiction. In the following sentence (‘Note that...’), the sentence first seems to suggest that it's only syncrepl replication that the overlay is incompatible with (ie, that there are other replication mechanisms which will work), but it goes on to state that it's incompatible with _all_ replication methods. Which is it? Finally, given the aside in [5], it might be worth indicating in the manpage that memberOf should only be used when other considerations force it, and should (by the sound of it) be avoided otherwise. Have I misunderstood something? Best wishes, Norman [1] https://www.openldap.org/lists/openldap-software/200910/msg00037.html [2] https://www.openldap.org/lists/openldap-technical/201505/msg00127.html [3] https://www.openldap.org/its/index.cgi/Software%20Bugs?id=7400;selectid=7400 [4] http://www.openldap.org/its/index.cgi/?findid=8613 [5] https://www.openldap.org/lists/openldap-technical/201809/msg00099.html -- Norman Gray : https://nxg.me.uk

2 2

slapd-sock as overlay
by Shiva Prasad Thagadur Prakash 09 Sep '19

09 Sep '19

Hello Guys, Could you please tell me where I could find a guide to configure slapd-sock as overlay for an existing database? I am not using slapd.conf but olc. I tried the configuring but I am getting "error 80, implementation error, could not open socket". Below is the configuration: dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=ericsec,dc=com olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read olcLastMod: TRUE olcRootDN: cn=admin,dc=ericsec,dc=com olcRootPW: {SSHA}lxpvQanVD5GoVXKiDB1HNEInKYussacd .. dn: olcOverlay={0}sock,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcOverlayConfig objectClass: olcOvSocketConfig olcOverlay: {0}sock olcDbSocketPath: /tmp/sockoverlay-listener1 olcDbSocketExtensions: binddn peername ssf olcOvSocketOps: bind unbind search Eagerly waiting for the reply. Thanks, Shiva

2 3

search request not blocked by ACLs
by Manuela Mandache 04 Sep '19

04 Sep '19

Hello all, My previous email address doesn't seem able to communicate with the list anymore... I sent this question yesterday and I don't find it in the September list of submitted subjects - sorry if I got it wrong and I'm double-posting. On an OpenLDAP directory, the ACLs are olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by dn.base="cn=adm in,dc=example,dc=com" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base=cn=Subschema by * read olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * auth olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read olcAccess: {6}to * by anonymous none by * read For the requests, the behavior is the expected one from user's point of view : $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'cn=Name*' dn: uid=someuid,ou=people,dc=example,dc=com mail: FirstName.Name(a)domain.com cn: Name FirstName $ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'sn=Name' Checking the log, the first requests appears as 2019-09-03T14:22:17.537815+02:00 myServer slapd[4765]: conn=1141654 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55188 (IP=0.0.0.0:390) 2019-09-03T14:22:17.538004+02:00 myServer slapd[4765]: conn=1141654 op=0 BIND dn="" method=128 2019-09-03T14:22:17.538044+02:00 myServer slapd[4765]: conn=1141654 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:17.546713+02:00 myServer slapd[4765]: conn=1141654 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(cn=Name*)" 2019-09-03T14:22:17.550421+02:00 myServer slapd[4765]: conn=1141654 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text= 2019-09-03T14:22:17.562783+02:00 myServer slapd[4765]: conn=1141654 op=2 UNBIND 2019-09-03T14:22:17.562835+02:00 myServer slapd[4765]: conn=1141654 fd=13 closed which is once again the expected behavior. But the second request generates in the log 2019-09-03T14:22:04.293120+02:00 myServer slapd[4765]: conn=1141645 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55186 (IP=0.0.0.0:390) 2019-09-03T14:22:04.293262+02:00 myServer slapd[4765]: conn=1141645 op=0 BIND dn="" method=128 2019-09-03T14:22:04.293328+02:00 myServer slapd[4765]: conn=1141645 op=0 RESULT tag=97 err=0 text= 2019-09-03T14:22:04.302404+02:00 myServer slapd[4765]: conn=1141645 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(sn=Name)" 2019-09-03T14:22:04.304850+02:00 myServer slapd[4765]: <= mdb_equality_candidates: (sn) not indexed 2019-09-03T14:22:04.334020+02:00 myServer slapd[4765]: conn=1141645 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= 2019-09-03T14:22:04.342618+02:00 myServer slapd[4765]: conn=1141645 op=2 UNBIND It actually looks as if the search was performed first, and the ACLs were checked only afterwards to prevent any return. As sn is not supposed to be used in the filter, it is not indexed (but we have no control over the requests sent to the directory to prevent the use of unauthorized filters). Am I misreading the log? And if I'm not, is there some parameter to be set to block the actual search on unauthorized filters? Thank you, and please let me know if I need to supply more configuration information. Regards, Manuela

2 1

Dynamic ACL in OpenLDAP with set:expand not working
by Martin W. 27 Aug '19

27 Aug '19

Dear OpenLDAP technical list, I‘ve been running into a little problem with my permission structures – and was wondering if you could help me with it. I want the members of a group to administer a tree structure, the group is member of it. I've tried some acl settings – I'll post my trials below the basic structure. Basic structure The structure is somehow like that tree – behind an # symbol, there is a brief description what the entries are meant for. > dc=example,dc=com > │ > ├── cn=admin # OpenLDAP default admin user > │ > ├── ou=entities # organisational entities > │ │ > │ ├── o=e1 # first of these entities > │ │ │ > │ │ ├── cn=admin # groupOfNames – see bullet points below > │ │ │ ┆ > │ │ │ └ ┄▸ member: cn=admin,dc=example,dc=com > │ │ │ └ ┄▸ member: uid=j.doe,ou=people,dc=example,dc=com > │ │ │ > │ │ ├── cn=role1 # groupOfNames to be reused below > │ │ │ ┆ as recursive group members within > │ │ │ ┆ permission groups > │ │ │ ┆ > │ │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ │ │ > │ │ └── cn=role2 > │ │ ┆ > │ │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ │ > │ └── o=e2 > │ ├── cn=admin > │ ├── cn=role1 > │ └── cn=role2 > │ > ├── ou=groups # permission groups for applications > │ │ that authenticate against OpenLDAP > │ │ > │ ├── cn=globaladmins # groupOfNames – superusers in all applications > │ │ ┆ > │ │ └ ┄▸ member: cn=admin,dc=example,dc=com > │ │ > │ ├── cn=ldapadmins # groupOfNames – same rights as admin user > │ │ ┆ > │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ │ └ ┄▸ member: uid=l.dap,ou=people,dc=example,dc=com > │ │ > │ ├── cn=permissiongroup1 # groupOfNames – authentication group > │ │ ┆ for specific application > │ │ ┆ > │ │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ │ └ ┄▸ member: cn=role1,o=e1,ou=entities,dc=example,dc=com > │ │ └ ┄▸ member: cn=role1,o=e2,ou=entities,dc=example,dc=com > │ │ > │ └── cn=permissiongroup2 > │ ┆ > │ └ ┄▸ member: cn=globaladmins,ou=groups,dc=example,dc=com > │ └ ┄▸ member: cn=role2,o=e1,ou=entities,dc=example,dc=com > │ └ ┄▸ member: cn=role2,o=e2,ou=entities,dc=example,dc=com > │ > └── ou=people # finally the "real people" accounts > │ > ├── uid=j.doe > ├── uid=l.dap > └── uid=m.muster cn=admin,dc=example,dc=com is basic member of the admin groups (since every group needs at least one member). uid=l.dap,ou=people,dc=example,dc=com is member of the cn=ldapadmins,ou=groups,dc=example,dc=com group. Therefor every member should have same rights within LDAP structure as cn=admin,dc=example,dc=com ou=people is the only structure, (personal) accounts are maintained ou=groups is the only structure, authentication groups for (web)applications are maintained (with nested members) The cn=admin,o=e1,ou=entities,dc=example,dc=com DN members should be able to admin everything below o=e1,ou=entities,dc=example,dc=com. e1 should be dynamic. The entity admins should not be able to administer other entities than the ones, they are admins from. Permission LDIF I've tried some different things ... and none Regex was successful :( Since I'll post some fragments, I put every LDIF fragment within such a bash fragment: > touch /permissions.ldif > > cat >/permissions.ldif <<EOF > # first of all delete all permissions > dn: olcDatabase={1}mdb,cn=config > changetype: modify > delete: olcAccess > - > > ######## > ## LDIF blocks from below > ######## > > - > # add general permissions > add: olcAccess > olcAccess: to * > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by users read > by * none > EOF > > ldapmodify -Q -Y EXTERNAL -H ldapi:/// <ldapi:///> -f /permissions.ldif trial 1 > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="([^,]+,)?o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=admin,o=$2,ou=entities,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The result is, that admin and any member of ldapadminscan edit, the members of specific entity admin subgroups cannot edit. The specific admin subgroups cannot even see the entities subtree. trial 2 > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=admin,o=$1,ou=entities,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The same result as with trial 1 ... trial 3 Additional groups – as a tree: > dc=example,dc=com > ┆ > └── ou=entity_admins > │ > ├── cn=e1 > │ ┆ > │ └ ┄▸ member: cn=admin,o=e1,ou=entities,dc=example,dc=com > │ > └── cn=e2 And the LDIF: > # add administrative access to LVe admin subgroups > add: olcAccess > olcAccess: to dn.regex="o=([^,]+),ou=entities,dc=example,dc=com" > by self write > by dn="cn=admin,dc=example,dc=com" write > by set="[cn=ldapadmins,ou=groups,dc=example,dc=com]/member* & user" write > by set.expand="[cn=$1,ou=entity_admins,dc=example,dc=com]/member* & user" write > by set="this/member* & user" read > by * none The result is again: admin and any member of ldapadminscan edit, entity_admins subgroups user cannot edit – even not their "owned" entities. trial 4 If I put an by set="[cn=admin,o=e1,ou=entities,dc=example,dc=com]/member* & user" write for EVERY single olcAccess: to dn.regex="([^,]+,)?o=jpbay,ou=entities,dc=example,dc=com" (with all the other stuff from trial 1), everything works fine. BUT: that's not maintainable or dynamic. So that's no solution, I can accept. I do not know why set.expand doesn't work as expected (as explained within different online examples on openldap.com <http://openldap.com/>) – and was not able to find a proper documentation that could explain why. Or if there has to be some enablement of an OpenLDAP module? If you could support me with that problem – probably with a solution – it would be great =) Thanks a lot, Martin

3 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical