i just happened to notice that the following search(es) don't return the expected results:
ldapsearch -xs base -b '' +
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + #
# search result search: 2 result: 0 Success
# numResponses: 1
ldapsearch -xs base -b '' namingContexts
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts #
# search result search: 2 result: 0 Success
# numResponses: 1
below is the debug output from slapd for the first search - what am i doing wrong?
i'm using 2.4.21, courtesy of ubuntu.
thanks -ben
daemon: activity on 1 descriptor daemon: activity on: slap_listener_activate(7): daemon: epoll: listen=7 busy
slap_listener(ldap:///)
daemon: listen=7, new connection on 14 daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: added 14r (active) listener=(nil) daemon: activity on 1 descriptor daemon: activity on: 14r conn=1000 fd=14 ACCEPT from IP=192.168.1.1:51467 (IP=0.0.0.0:389) daemon: read active on 14 daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(14) connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 60 07 02 0....`.. ldap_read: want=6, got=6 0000: 01 03 04 00 80 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x20cf3b90 ptr=0x20cf3b90 end=0x20cf3b9c len=12 0000: 02 01 01 60 07 02 01 03 04 00 80 00 ...`........ op tag 0x60, time 1277686599 ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL conn=1000 op=0 do_bind ber_scanf fmt ({imt) ber: ber_dump: buf=0x20cf3b90 ptr=0x20cf3b93 end=0x20cf3b9c len=9 0000: 60 07 02 01 03 04 00 80 00 `........ ber_scanf fmt (m}) ber: ber_dump: buf=0x20cf3b90 ptr=0x20cf3b9a end=0x20cf3b9c len=2 0000: 00 00 ..
dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <> conn=1000 op=0 BIND dn="" method=128 do_bind: version=3 dn="" method=128 send_ldap_result: conn=1000 op=0 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=1 tag=97 err=0 ber_flush2: 14 bytes to sd 14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ ldap_write: want=14, written=14 0000: 30 0c 02 01 01 61 07 0a 01 00 04 00 04 00 0....a........ conn=1000 op=0 RESULT tag=97 err=0 text= daemon: activity on 1 descriptor daemon: activity on: 14r daemon: read active on 14 daemon: epoll: listen=7 active_threads=0 tvp=NULL connection_get(14) daemon: epoll: listen=8 active_threads=0 tvp=NULL do_bind: v3 anonymous bind connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ldap_read: want=8, got=8 0000: 30 28 02 01 02 63 23 04 0(...c#. ldap_read: want=34, got=34 0000: 00 0a 01 00 0a 01 00 02 01 00 02 01 3c 01 01 00 ............<... 0010: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 03 04 ..objectclass0.. 0020: 01 2b .+ ber_get_next: tag 0x30 len 40 contents: ber_dump: buf=0x20cf43a8 ptr=0x20cf43a8 end=0x20cf43d0 len=40 0000: 02 01 02 63 23 04 00 0a 01 00 0a 01 00 02 01 00 ...c#........... 0010: 02 01 3c 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c ..<.....objectcl 0020: 61 73 73 30 03 04 01 2b ass0...+ op tag 0x63, time 1277686599 connection_input: conn=1000 deferring operation: binding ber_get_next ldap_read: want=8 error=Resource temporarily unavailable daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL conn=1000 op=1 do_search ber_scanf fmt ({miiiib) ber: ber_dump: buf=0x20cf43a8 ptr=0x20cf43ab end=0x20cf43d0 len=37 0000: 63 23 04 00 0a 01 00 0a 01 00 02 01 00 02 01 3c c#.............< 0010: 01 01 00 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 .....objectclass 0020: 30 03 04 01 2b 0...+
dnPrettyNormal: <>
<<< dnPrettyNormal: <>, <> SRCH "" 0 0 0 60 0 begin get_filter PRESENT ber_scanf fmt (m) ber: ber_dump: buf=0x20cf43a8 ptr=0x20cf43be end=0x20cf43d0 len=18 0000: 87 0b 6f 62 6a 65 63 74 63 6c 61 73 73 30 03 04 ..objectclass0.. 0010: 01 2b .+ end get_filter 0 filter: (objectClass=*) ber_scanf fmt ({M}}) ber: ber_dump: buf=0x20cf43a8 ptr=0x20cf43cb end=0x20cf43d0 len=5 0000: 00 03 04 01 2b ....+ attrs: + conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=+ => test_filter PRESENT => access_allowed: search access to "" "objectClass" requested => acl_get: [1] attr objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth <= check a_dn_pat: * <= acl_mask: [2] applying +0 (break) <= acl_mask: [2] mask: =0 <= acl_get: done. => slap_access_allowed: no more rules => access_allowed: no more rules <= test_filter 50 send_ldap_result: conn=1000 op=1 p=3 send_ldap_result: err=0 matched="" text="" send_ldap_response: msgid=2 tag=101 err=0 ber_flush2: 14 bytes to sd 14 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ ldap_write: want=14, written=14 0000: 30 0c 02 01 02 65 07 0a 01 00 04 00 04 00 0....e........ conn=1000 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text= daemon: activity on 1 descriptor daemon: activity on: 14r daemon: read active on 14 daemon: epoll: listen=7 active_threads=0 tvp=NULL connection_get(14) daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_get(14): got connid=1000 connection_read(14): checking for input on id=1000 ber_get_next ldap_read: want=8, got=7 0000: 30 05 02 01 03 42 00 0....B. ber_get_next: tag 0x30 len 5 contents: ber_dump: buf=0x20cf3b90 ptr=0x20cf3b90 end=0x20cf3b95 len=5 0000: 02 01 03 42 00 ...B. op tag 0x42, time 1277686599 ber_get_next ldap_read: want=8, got=0
ber_get_next on fd 14 failed errno=0 (Success) connection_read(14): input error=-2 id=1000, closing. connection_closing: readying conn=1000 sd=14 for close daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: epoll: listen=8 active_threads=0 tvp=NULL connection_close: deferring conn=1000 sd=14 conn=1000 op=2 do_unbind conn=1000 op=2 UNBIND connection_resched: attempting closing conn=1000 sd=14 connection_close: deferring conn=1000 sd=14 connection_resched: attempting closing conn=1000 sd=14 connection_close: conn=1000 sd=14 daemon: removing 14 conn=1000 fd=14 closed
i just happened to notice that the following search(es) don't return the expected results:
ldapsearch -xs base -b '' +
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + #
# search result search: 2 result: 0 Success
# numResponses: 1
ldapsearch -xs base -b '' namingContexts
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: namingContexts #
# search result search: 2 result: 0 Success
# numResponses: 1
below is the debug output from slapd for the first search - what am i doing wrong?
i'm using 2.4.21, courtesy of ubuntu.
[...]
conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=+ => test_filter PRESENT => access_allowed: search access to "" "objectClass" requested => acl_get: [1] attr objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth <= check a_dn_pat: * <= acl_mask: [2] applying +0 (break) <= acl_mask: [2] mask: =0 <= acl_get: done. => slap_access_allowed: no more rules => access_allowed: no more rules <= test_filter 50
This 50 means insufficient access, as pointed out by the above logs. Your ACLs prevent searching the rootDSE entry.
p.
On Jun 27, 2010, at 22.47, masarati@aero.polimi.it wrote:
i just happened to notice that the following search(es) don't return the expected results:
ldapsearch -xs base -b '' +
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + #
# search result search: 2 result: 0 Success
# numResponses: 1
i'm using 2.4.21, courtesy of ubuntu.
[...]
conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=+ => test_filter PRESENT => access_allowed: search access to "" "objectClass" requested => acl_get: [1] attr objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth <= check a_dn_pat: * <= acl_mask: [2] applying +0 (break) <= acl_mask: [2] mask: =0 <= acl_get: done. => slap_access_allowed: no more rules => access_allowed: no more rules <= test_filter 50
This 50 means insufficient access, as pointed out by the above logs. Your ACLs prevent searching the rootDSE entry.
i see, thank you. where can i read more about possible values used here and what they mean?
below are my current acls. olcAccess: to dn.base="" by * read is what i'd expected would allow such searches - but, it occurs to me now that defining that in the context of a specific database/suffix is perhaps not right?
#>ldapsearch -ZZLLLWD 'cn=admin,cn=config' -b 'cn=config' '(|(objectclass=olcglobal)(objectclass=olcdatabaseconfig))' olcdatabase olcaccess olcsuffix Enter LDAP Password: dn: cn=config
dn: olcDatabase={-1}frontend,cn=config olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
dn: olcDatabase={0}config,cn=config olcDatabase: {0}config olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
dn: olcDatabase={1}monitor,cn=config olcDatabase: {1}monitor
dn: olcDatabase={2}bdb,cn=config olcDatabase: {2}bdb olcSuffix: dc=dipswitch,dc=net olcAccess: {0}to dn.base="" by * read olcAccess: {1}to attrs=userPassword by self =xw by anonymous auth by * none olcAccess: {2}to filter=(&(objectclass=iphost)(cn=flip.dipswitch.net)) attrs=authorizedservice val.exact=sshd by group.exact="cn=ssh,ou=all_servers,ou=servers,ou=groups,dc=dipswitch,dc=net" compare by group.exact="cn=ssh,ou=flip,ou=servers,ou=groups,dc=dipswitch,dc=net" compare by * =dxrs olcAccess: {3}to filter=(&(objectclass=iphost)(cn=flip.dipswitch.net)) attrs=authorizedservice val.exact=login by group.exact="cn=console,ou=all_servers,ou=servers,ou=groups,dc=dipswitch,dc=net" compare by group.exact="cn=console,ou=flip,ou=servers,ou=groups,dc=dipswitch,dc=net" compare by * =dxrs olcAccess: {4}to * by self write by group.exact="cn=directory_administrators,ou=general,ou=groups,dc=dipswitch,dc=net" manage by users read by * none
ben thielsen btb@bitrate.net writes:
On Jun 27, 2010, at 22.47, masarati@aero.polimi.it wrote:
i just happened to notice that the following search(es) don't return the expected results:
ldapsearch -xs base -b '' +
# extended LDIF # # LDAPv3 # base <> with scope baseObject # filter: (objectclass=*) # requesting: + #
# search result search: 2 result: 0 Success
# numResponses: 1
i'm using 2.4.21, courtesy of ubuntu.
[...]
conn=1000 op=1 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1000 op=1 SRCH attr=+ => test_filter PRESENT => access_allowed: search access to "" "objectClass" requested => acl_get: [1] attr objectClass => acl_mask: access to entry "", attr "objectClass" requested => acl_mask: to all values by "", (=0) <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth <= check a_dn_pat: * <= acl_mask: [2] applying +0 (break) <= acl_mask: [2] mask: =0 <= acl_get: done. => slap_access_allowed: no more rules => access_allowed: no more rules <= test_filter 50
This 50 means insufficient access, as pointed out by the above logs. Your ACLs prevent searching the rootDSE entry.
i see, thank you. where can i read more about possible values used here and what they mean?
below are my current acls. olcAccess: to dn.base="" by * read is what i'd expected would allow such searches - but, it occurs to me now that defining that in the context of a specific database/suffix is perhaps not right?
#>ldapsearch -ZZLLLWD 'cn=admin,cn=config' -b 'cn=config' '(|(objectclass=olcglobal)(objectclass=olcdatabaseconfig))' olcdatabase olcaccess olcsuffix Enter LDAP Password: dn: cn=config
dn: olcDatabase={-1}frontend,cn=config olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
this rule only allows root to access rootDSE via local socket, that is ldapi:/// that is, as root: ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base +
[...]
-Dieter
dn: olcDatabase={-1}frontend,cn=config olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
this rule only allows root to access rootDSE via local socket, that is ldapi:/// that is, as root: ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base +
[...]
thank you - that explains it. i'm left wondering how those acls for frontend and config got there - i don't recall ever explicitly setting them. slapd isn't listening on a local socket, which would render them quite useless, right?
on a related note, regarding the frontend database - reading a bit in the admin guide, my understanding is that the frontend database is the appropriate location for such acls as olcAccess: to dn.base="" by * read - is this correct? i've done this, and the behavior is now as i expect, but just curious about typical practices.
-ben
dn: olcDatabase={-1}frontend,cn=config olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
this rule only allows root to access rootDSE via local socket, that is ldapi:/// that is, as root: ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base +
[...]
thank you - that explains it. i'm left wondering how those acls for frontend and config got there - i don't recall ever explicitly setting them. slapd isn't listening on a local socket, which would render them quite useless, right?
on a related note, regarding the frontend database - reading a bit in the admin guide, my understanding is that the frontend database is the appropriate location for such acls as olcAccess: to dn.base="" by * read - is this correct? i've done this, and the behavior is now as i expect, but just curious about typical practices.
i've found this comment - http://www.mail-archive.com/openldap-technical@openldap.org/msg00491.html - which would seem to confirm my understanding of the frontend database as it relates to acls.
ben thielsen btb@bitrate.net writes:
dn: olcDatabase={-1}frontend,cn=config olcDatabase: {-1}frontend olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
this rule only allows root to access rootDSE via local socket, that is ldapi:/// that is, as root: ldapsearch -Y EXTERNAL -H ldapi:/// -b "" -s base +
[...]
thank you - that explains it. i'm left wondering how those acls for frontend and config got there - i don't recall ever explicitly setting them. slapd isn't listening on a local socket, which would render them quite useless, right?
This is probably the default configutration of ubuntu. In order to connect to slapd via a local socket, just add ldapi:/// to the init script.
on a related note, regarding the frontend database - reading a bit in the admin guide, my understanding is that the frontend database is the appropriate location for such acls as olcAccess: to dn.base="" by * read - is this correct? i've done this, and the behavior is now as i expect, but just curious about typical practices.
Yes, this is correct.
i've found this comment - http://www.mail-archive.com/openldap-technical@openldap.org/msg00491.html - which would seem to confirm my understanding of the frontend database as it relates to acls.=
-Dieter
openldap-technical@openldap.org
-
ben thielsen -
btb＠bitrate.net
-
Dieter Kluenter -
masarati＠aero.polimi.it