openldap-technical

openldap-technical@openldap.org

1 participants
9989 discussions

Re:
by Gavin Henry 14 Aug '12

14 Aug '12

Excellent. Thanks for following up. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 14 Aug 2012, at 10:25, "非人協會" <hkuhaorg(a)gmail.com> wrote: Dear Henry, Thanks for the kindness follow up. The problem has fixed. The root cause of the problem is the wrongly configured slapd.conf Thanks and Regards, Donald 2012/8/10 Gavin Henry <ghenry(a)suretecsystems.com> > On 8 August 2012 04:59, 非人協會 <hkuhaorg(a)gmail.com> wrote: > > Dear All, > > I am new to ldap, I would like to have your kindness assistance in > setting > > up the directory. > > > > We are working on move our old ldap server to a new openldap server, I > have > > install the openldap in Solaris 10 x86 successfully. However I am not > able > > to browse the content using the ldap browser, it shows "Invalid > > Credentials". > > Hi Donald, > > All fixed? > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 279484 > M +44 (0) 7930 323266 > F +44 (0) 1224 824887 > E ghenry(a)suretecsystems.com > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > > Suretec Systems is a limited company registered in Scotland. Registered > number: SC258005. Registered office: 24 Cormack Park, Rothienorman, > Inverurie, > Aberdeenshire, AB51 8GL. > > Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html > > Do you know we have our own VoIP provider called SureVoIP? See > http://www.surevoip.co.uk > > Did you see our API news? > http://www.surevoip.co.uk/news-events/surevoip-launches-innovative-api >

1 0

Re: representing file pathnames
by Chuck Lever 14 Aug '12

14 Aug '12

Hi- On Aug 9, 2012, at 7:22 PM, Howard Chu wrote: > Michael Ströder wrote: >> Chuck Lever wrote: >>> On Aug 9, 2012, at 2:46 PM, Howard Chu wrote: >>>> Michael Ströder wrote: >>>>> Chuck Lever wrote: >>>>>> We could also use an NFS URL, which would allow us to express the server >>>>>> hostname, a port number, and the pathname in a single string. But both the >>>>>> hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL >>>>>> format employs a fixed pathname separator character. >>>>> >>>>> That's what I would prefer. Think of file browsers which can open the NFS >>>>> mount point just by clicking on it. Same encoding steps as with file URLs. >>>> >>>> This seems the most obvious and natural solution (NFS URL). After all, you are >>>> specifying an NFS resource... >>> >>> I've looked more closely at this idea. While it's got some surface appeal, >>> NFS URLs (RFC 2224) don't specify a generic NFS resource. They specify a >>> webDAV like resource that can be accessed with NFS, called WebNFS (RFC >>> 2054, RFC 20550), which gives clients access via a so-called "public file >>> handle," which is a degenerate NFS FH. >>> >>> WebNFS is defined only for legacy versions of NFS, not for NFSv4. >>> Referrals are supported only in NFSv4. In fact, section 4 of RFC 2224 >>> specifies that clients try version 3 then version 2. NFS version 4 is not >>> discussed. >>> >>> Thus, the form of an NFS URL might be rich enough, but the existing >>> semantics are not equivalent. >> >> I see no reason why it should not be able to use NFS URLs and define the exact >> usage of them for NFSv4. Maybe I'm overlooking something though. > > Agreed. AFAICS the semantics of the URL are for your actual application to > define. We're not talking about URLs that are meant to be served up by an HTTP > server. > > IMO RFC2224 is defective in that it specifies both the URL format and its > associated access methods. URL formats are meant to be "Uniform" which should > mean they are independent of their access methods. In order to use the NFS URL format, I think we would be compelled to correct RFC 2224, probably by issuing an RFC that supersedes it. While certainly possible, I'm not sure the NFSv4 working group is prepared to hold up the NSDB draft for such an undertaking at this point. Naturally there may be simpler alternatives. That said, I can present this design choice (the use of an NFS URL to represent an fs_locations entry in LDAP) to them for discussion. Thanks for the excellent feedback. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

2 3

AW: overlay nssov + SASL
by Uwe Werler 13 Aug '12

13 Aug '12

-----Ursprüngliche Nachricht----- An: openldap-technical(a)openldap.org; Von: Uwe Werler <uwe.werler(a)retiolum.eu> Gesendet: Mo 13.08.2012 09:50 Betreff: overlay nssov + SASL > Hello list, > > I want to use overlay nssov and it works great in my test setup. Up to now we > use pass through authentication with saslauthd to authenticate against an > AD-Domain. > > Internally nssov uses simple binds against the local database so I can't use > pass through authentication. With overlay pbind I can do simple binds against > an external ldap server. Is there another possibility to use overlay nssov in > combination with saslauthd? > > Thanks for any hints. > > Regards Uwe Ok, I found two ways. First use back relay + overlay pbind and second use back-meta/back-ldap. Both within the same naming context as the real database but configured with "hidden on" to avoid naming context issues. Both work now. Another question is if it's possible to use overlay nssov within multiple databases like one for hosts and another for users? Thanks! Regards Uwe

1 0

How to enable LDAP ports in iptables for OpenLDAP client node
by Qian Zhang 13 Aug '12

13 Aug '12

Hi All, I have a RHEL 6.2 machine which is set up as an OpenLDAP client, and I can log into it with LDAP user. Now for security concern, I need to prohibit any not-root user to access the network: # /etc/init.d/iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination 1 REJECT all -- 0.0.0.0/0 0.0.0.0/0 ! owner UID match 0 reject-with icmp-port-unreachable But if I did this in iptables, LDAP has problems, "getent passwd" can not get any LDAP users, and I can no longer log into this machine with LDAP user. So I think I need to open LDAP ports in iptables, what I did is: # /etc/init.d/iptables status Table: filter Chain INPUT (policy ACCEPT) num target prot opt source destination Chain FORWARD (policy ACCEPT) num target prot opt source destination Chain OUTPUT (policy ACCEPT) num target prot opt source destination 1 ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 tcp spt:389 dpt:389 2 ACCEPT udp -- 0.0.0.0/0 0.0.0.0/0 udp spt:389 dpt:389 3 REJECT all -- 0.0.0.0/0 0.0.0.0/0 ! owner UID match 0 reject-with icmp-port-unreachable But it did not work, any ports I missed? Or what I set up in iptables are not correct? My /etc/openldap/ldap.conf: URI ldap://172.17.27.159:389 BASE dc=base,dc=com TLS_CACERTDIR /etc/openldap/cacerts Regards, Qian

3 4

overlay nssov + SASL
by Uwe Werler 13 Aug '12

13 Aug '12

Hello list, I want to use overlay nssov and it works great in my test setup. Up to now we use pass through authentication with saslauthd to authenticate against an AD-Domain. Internally nssov uses simple binds against the local database so I can't use pass through authentication. With overlay pbind I can do simple binds against an external ldap server. Is there another possibility to use overlay nssov in combination with saslauthd? Thanks for any hints. Regards Uwe

1 0

Windows SSPI, NTLMSSP and OpenLDAP with SASL/GSSAPI
by Diego Morales 12 Aug '12

12 Aug '12

Hello, I have a proprietary windows application trying to bind on my OpenLDAP server using GSSAPI with NTLMSSP mechanism, instead of Kerberos. Is it possible to support this on a (unix) OpenLDAP server? Another option would be to make the software use GSSAPI + Kerberos instead. Let me further explain: I have a working samba + openldap setup with many windows workstations. The said proprietary app has LDAP auth support, and according to its maker it works with Active Directory and Novell NDS. It does not support simple bind, nor LDAPS, (and probably not StartTLS either). We don't have access to the app's source code and help from its developers/tech-support is pretty unavailable. Checking slapd's debug, we saw the app trying to use SASL+GSSAPI to bind. So we went on and configured a minimal Kerberos setup and SASL+GSSAPI support for OpenLDAP on a test ldap server. It seems to be working perfectly. We acquire a ticket and run ldapsearch from another machine using -Y GSSAPI bind and it works. Logs from slapd debug seem ok. But that evil app still fails. Here's a piece from slapd debug log: conn=1000 op=1 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8813 end=0x7f73f6af8856 len=67 0000: 60 84 00 00 00 3d 02 01 03 04 00 a3 84 00 00 00 `....=.......... 0010: 32 04 06 47 53 53 41 50 49 04 28 4e 54 4c 4d 53 2..GSSAPI.(NTLMS 0020: 53 50 00 01 00 00 00 97 82 08 e2 00 00 00 00 00 SP.............. 0030: 00 00 00 00 00 00 00 00 00 00 00 06 01 b1 1d 00 ................ 0040: 00 00 0f ... ber_scanf fmt ({m) ber: ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af881e end=0x7f73f6af8856 len=56 0000: 00 84 00 00 00 32 04 06 47 53 53 41 50 49 04 28 .....2..GSSAPI.( 0010: 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 08 e2 NTLMSSP......... 0020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0030: 06 01 b1 1d 00 00 00 0f ........ ber_scanf fmt (m) ber: ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af882c end=0x7f73f6af8856 len=42 0000: 00 28 4e 54 4c 4d 53 53 50 00 01 00 00 00 97 82 .(NTLMSSP....... 0010: 08 e2 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 0020: 00 00 06 01 b1 1d 00 00 00 0f .......... ber_scanf fmt (}}) ber: ber_dump: buf=0x7f73f6af8810 ptr=0x7f73f6af8856 end=0x7f73f6af8856 len=0 >>> dnPrettyNormal: <> <<< dnPrettyNormal: <>, <> conn=1000 op=1 BIND dn="" method=163 do_bind: dn () SASL mech GSSAPI ==> sasl_bind: dn="" mech=GSSAPI datalen=40 SASL [conn=1000] Failure: GSSAPI Error: An unsupported mechanism was requested (Unknown error) send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=49 matched="" text="SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context" send_ldap_response: msgid=11 tag=97 err=49 ber_flush2: 87 bytes to sd 13 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure: 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure: 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_ 0050: 63 6f 6e 74 65 78 74 context ldap_write: want=87, written=87 0000: 30 55 02 01 0b 61 50 0a 01 31 04 00 04 49 53 41 0U...aP..1...ISA 0010: 53 4c 28 2d 31 33 29 3a 20 61 75 74 68 65 6e 74 SL(-13): authent 0020: 69 63 61 74 69 6f 6e 20 66 61 69 6c 75 72 65 3a ication failure: 0030: 20 47 53 53 41 50 49 20 46 61 69 6c 75 72 65 3a GSSAPI Failure: 0040: 20 67 73 73 5f 61 63 63 65 70 74 5f 73 65 63 5f gss_accept_sec_ 0050: 63 6f 6e 74 65 78 74 context conn=1000 op=1 RESULT tag=97 err=49 text=SASL(-13): authentication failure: GSSAPI Failure: gss_accept_sec_context (btw, this is slapd 2.4.21, from a 10.04 ubuntu package) I believe the application uses Windows SSPI, and I known SSPI supports several GSSAPI mechanisms, including NTLMSSP and Kerberos. I'm afraid Windows is auto selecting NTLMSSP cause its running on a pre-windows 2000 domain (non AD, in this case, Samba). Hoping to make windows use Kerberos instead, I've also tried publishing some SRV records on DNS. I have sniffed DNS queries from the workstation while the app tries to login, caught only one _ldap._tcp SRV request, registered that ... and nothing has changed. I don't know how could I force the app to use GSSAPI + kerberos without touching its source code. And I can't find much about a unix NTLM(SSP)-as-a-mechanism-of-GSSAPI implementation. Maybe there's something inside samba4 or in Likewise software, but I haven't found it yet. So ... does somebody have any advice or info? Thanks in advance, Diego Morales +55 (51) 3024-3568 Propus Informática LTDA. http://www.propus.com.br

2 1

Re: got into a "checksum error" situation
by Gavin Henry 12 Aug '12

12 Aug '12

On 12 August 2012 20:24, Jeff Dickens <jeff(a)seamanpaper.com> wrote: > > Thanks, I will certainly do that in the future. So is there a way to recalculate the checksum on my config as it is now, so that I can get back to normal? slapcat it, check it and make any edits needed, then delete what's in slapd.d/* and then slapadd it back. Checksums will sort themselves. > As an aside, my TLS config does indeed work now. Nice work! -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api

1 0

Re: got into a "checksum error" situation
by Jeff Dickens 12 Aug '12

12 Aug '12

Yes, I edited it by hand. Clearly not advisable since the comments said "don't do that", but since the server wouldn't start I couldn't use ldapmodify. On Fri, Aug 10, 2012 at 6:51 AM, Gavin Henry <ghenry(a)suretecsystems.com>wrote: > Not knowing what else to do, I removed the lines containing > > "olcTLS" from /etc/ldap/slapd.d/cn=config.ldif. Then I was able to > restart > > slapd (congratulating myself) and then re-ran my ldapmodify command to > enter > > the correct locations of the cert and key. But I still get a checksum > error > > in syslog: > > > Aug 8 17:04:53 grackle slapd[2028]: slapd starting > > Aug 8 17:05:01 grackle slapd[2028]: ldif_read_file: checksum error on > > "/etc/ldap /slapd.d/cn=config.ldif" > > So you edited this by hand? > > > > > I haven't even tried to see if I have TLS working, but I have two > > questions: > > > > #1. How should I have recovered from this (human) error? What I did > > didn't seem to work out very well. > > > > and > > > > #2. How do I un-screw my config and resolve the checksum problem? > > > > Thanks in advance for any assistance. > > > > -- > > Jeff Dickens > > IT Manager 978-632-1513 > > > > > > > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 279484 > M +44 (0) 7930 323266 > F +44 (0) 1224 824887 > E ghenry(a)suretecsystems.com > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > > Suretec Systems is a limited company registered in Scotland. Registered > number: SC258005. Registered office: 24 Cormack Park, Rothienorman, > Inverurie, > Aberdeenshire, AB51 8GL. > > Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html > > Do you know we have our own VoIP provider called SureVoIP? See > http://www.surevoip.co.uk > > Did you see our API news? > http://www.surevoip.co.uk/news-events/surevoip-launches-innovative-api > -- * Jeff Dickens* IT Manager 978-632-1513

3 2

access to inherited attributes
by Michael Ströder 11 Aug '12

11 Aug '12

HI! I cannot find anything in slapd.access(5) indicating that access attrs=mysupattr by <who> <access> also grants <access> to attributes inherited from mysupattr (which have SUP mysupattr in the attribute type description). Is this the expected behaviour? Where is this documented? (testing with 2.4.32) Ciao, Michael.

1 0

Re: ACL: access to all values vs. to value
by Dora Paula 10 Aug '12

10 Aug '12

Gavin Henry wrote: >> is there a possibility to create an acl statement that grants access to any >> (unknown) value of an attribute but denys access to all values of the same >> attribute? > > Can you explain that again? BTW: Your answer didn't find its way into the openldap-technical archive: http://www.openldap.org/lists/openldap-technical/201208/threads.html Nevertheless, please let me try to explain using a short (but complete) example: Sample slapd.conf: ================== include /openldap/schema/core.schema pidfile /openldap/schema/slapd.pid argsfile /openldap/schema/slapd.args access to * by self write by users read by anonymous auth database mdb suffix "o=test" rootdn "cn=Manager,o=test" rootpw secret directory /openldap/var/openldap-data/test index objectClass eq access to dn.one="ou=persons,o=test" attrs=description by users write by * none Sample val.ldif: ================ dn: o=test objectClass: organization objectClass: top o: test dn: ou=persons,o=test objectClass: organizationalUnit objectClass: top ou: persons dn: cn=PersonA,ou=persons,o=test objectClass: person objectClass: top cn: PersonA sn: PersonA userPassword:: UGVyc29uQQ== Sample modifications.ldif: ========================== #mod 1 (should succeed) dn: cn=PersonA,ou=persons,o=test changetype: modify add: description description: Description of A #mod 2 (should succeed) dn: cn=PersonA,ou=persons,o=test changetype: modify add: description description: Another description of A description: Just another description of A #mod 3 (should succeed) dn: cn=PersonA,ou=persons,o=test changetype: modify delete: description description: Another description of A description: Just another description of A #mod 4 (should fail) dn: cn=PersonA,ou=persons,o=test changetype: modify delete: description slapd startup: (version: git master) ==================================== deepee@test:~$ /openldap/libexec/slapd -f slapd.conf.acl -u openldap -g openldap -d 128 -h "ldap://0.0.0.0:1389/ ldapi://%2Ftmp%2Fldapi_acl/" 50258437 @(#) $OpenLDAP: slapd 2.X (Aug 10 2012 20:44:06) $ deepee@test:/.../slapd Backend ACL: access to * by self write by users read by anonymous auth Backend ACL: access to dn.one="ou=persons,o=test" attrs=description by users write by * none Backend ACL: access to * by * none 50258437 config_back_db_open: line 0: warning: cannot assess the validity of the ACL scope within backend naming context 50258437 mdb_monitor_db_open: monitoring disabled; configure monitor database to enable 50258437 slapd starting ldapmodify: =========== deepee@test:~$ cat /tmp/val.ldif | /openldap/bin/ldapmodify -c -x -H "ldap://localhost:1389" -D "cn=PersonA,ou=persons,o=test" -w PersonA modifying entry "cn=PersonA,ou=persons,o=test" modifying entry "cn=PersonA,ou=persons,o=test" modifying entry "cn=PersonA,ou=persons,o=test" modifying entry "cn=PersonA,ou=persons,o=test" slapd.log (level 128): ====================== 50258ca0 => access_allowed: result not in cache (userPassword) 50258ca0 => access_allowed: auth access to "cn=PersonA,ou=persons,o=test" "userPassword" requested 50258ca0 => dn: [1] ou=persons,o=test 50258ca0 => acl_get: [1] matched 50258ca0 => acl_get: [2] attr userPassword 50258ca0 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "userPassword" requested 50258ca0 => acl_mask: to value by "", (=0) 50258ca0 <= check a_dn_pat: self 50258ca0 <= check a_dn_pat: users 50258ca0 <= check a_dn_pat: anonymous 50258ca0 <= acl_mask: [3] applying auth(=xd) (stop) 50258ca0 <= acl_mask: [3] mask: auth(=xd) 50258ca0 => slap_access_allowed: auth access granted by auth(=xd) 50258ca0 => access_allowed: auth access granted by auth(=xd) 50258ca0 => access_allowed: result not in cache (description) 50258ca0 => access_allowed: add access to "cn=PersonA,ou=persons,o=test" "description" requested 50258ca0 => dn: [1] ou=persons,o=test 50258ca0 => acl_get: [1] matched 50258ca0 => acl_get: [1] attr description 50258ca0 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "description" requested 50258ca0 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 50258ca0 <= check a_dn_pat: users 50258ca0 <= acl_mask: [1] applying write(=wrscxd) (stop) 50258ca0 <= acl_mask: [1] mask: write(=wrscxd) 50258ca0 => slap_access_allowed: add access granted by write(=wrscxd) 50258ca0 => access_allowed: add access granted by write(=wrscxd) 50258ca0 acl: internal mod entryCSN: modify access granted 50258ca0 acl: internal mod modifiersName: modify access granted 50258ca0 acl: internal mod modifyTimestamp: modify access granted 50258ca0 => access_allowed: result not in cache (description) 50258ca0 => access_allowed: add access to "cn=PersonA,ou=persons,o=test" "description" requested 50258ca0 => dn: [1] ou=persons,o=test 50258ca0 => acl_get: [1] matched 50258ca0 => acl_get: [1] attr description 50258ca0 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "description" requested 50258ca0 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 50258ca0 <= check a_dn_pat: users 50258ca0 <= acl_mask: [1] applying write(=wrscxd) (stop) 50258ca0 <= acl_mask: [1] mask: write(=wrscxd) 50258ca0 => slap_access_allowed: add access granted by write(=wrscxd) 50258ca0 => access_allowed: add access granted by write(=wrscxd) 50258ca0 => access_allowed: result was in cache (description) 50258ca0 acl: internal mod entryCSN: modify access granted 50258ca0 acl: internal mod modifiersName: modify access granted 50258ca0 acl: internal mod modifyTimestamp: modify access granted 50258ca0 => access_allowed: result not in cache (description) 50258ca0 => access_allowed: delete access to "cn=PersonA,ou=persons,o=test" "description" requested 50258ca0 => dn: [1] ou=persons,o=test 50258ca0 => acl_get: [1] matched 50258ca0 => acl_get: [1] attr description 50258ca0 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "description" requested 50258ca0 => acl_mask: to value by "cn=persona,ou=persons,o=test", (=0) 50258ca0 <= check a_dn_pat: users 50258ca0 <= acl_mask: [1] applying write(=wrscxd) (stop) 50258ca0 <= acl_mask: [1] mask: write(=wrscxd) 50258ca0 => slap_access_allowed: delete access granted by write(=wrscxd) 50258ca0 => access_allowed: delete access granted by write(=wrscxd) 50258ca0 => access_allowed: result was in cache (description) 50258ca0 acl: internal mod entryCSN: modify access granted 50258ca0 acl: internal mod modifiersName: modify access granted 50258ca0 acl: internal mod modifyTimestamp: modify access granted 50258ca0 => access_allowed: result not in cache (description) 50258ca0 => access_allowed: delete access to "cn=PersonA,ou=persons,o=test" "description" requested 50258ca0 => dn: [1] ou=persons,o=test 50258ca0 => acl_get: [1] matched 50258ca0 => acl_get: [1] attr description 50258ca0 => acl_mask: access to entry "cn=PersonA,ou=persons,o=test", attr "description" requested 50258ca0 => acl_mask: to all values by "cn=persona,ou=persons,o=test", (=0) 50258ca0 <= check a_dn_pat: users 50258ca0 <= acl_mask: [1] applying write(=wrscxd) (stop) 50258ca0 <= acl_mask: [1] mask: write(=wrscxd) 50258ca0 => slap_access_allowed: delete access granted by write(=wrscxd) 50258ca0 => access_allowed: delete access granted by write(=wrscxd) 50258ca0 acl: internal mod entryCSN: modify access granted 50258ca0 acl: internal mod modifiersName: modify access granted 50258ca0 acl: internal mod modifyTimestamp: modify access granted So far so good, all four modification operations succeeded. That's slapd's known default behavior and completely correct in regard to the above defined acl. My intention is to let the first three operations (to value(s)) succeed and the last operation (to all values) fail by "Insufficient access (50)". After studying the documentation, doing some (unstructured, trial and error) testing with various combinations of acl statements, I finally had a closer look into slapd's source: Am I right, that slapd's acl engine currently does not offer a chance to differentiate between these two types of modification?

2 1

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical