Dear Users,
for research purposes i have installed a RHEL6 system to test the new OLC feature.
I only have the cn=config DIT available.
The ACLS are:
# ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=config' '(olcAccess=*)' olcAccess
SASL/EXTERNAL authentication started
SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (olcAccess=*)
# requesting: olcAccess
#
# {0}config, config
dn: olcDatabase={0}config,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none
# {1}monitor, config
dn: olcDatabase={1}monitor,cn=config
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.base="cn=manager,dc=my-domain,dc=com" read by * none
so it looks like only UID=0 (root) should be able to interoperate with the directory. However all local users can connect but do not have access to cn=config (this is expected).
[user@host ~]$ ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=config'
SASL/EXTERNAL authentication started
SASL username: gidNumber=501+uidNumber=501,cn=peercred,cn=external,cn=auth
SASL SSF: 0
# extended LDIF
#
# LDAPv3
# base <cn=config> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#
# search result
search: 2
result: 32 No such object
# numResponses: 1
So why am i even able to logon and state a query?
Regards,
Stefan Bauer sb@plzk.de writes:
I only have the cn=config DIT available.
(You actually have cn=monitor, too.)
dn: olcDatabase={0}config,cn=config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none [...] so it looks like only UID=0 (root) should be able to interoperate with the directory. However all local users can connect but do not have access to cn=config (this is expected).
[user@host ~]$ ldapsearch -Y EXTERNAL -H ldapi:/// -b 'cn=config' [...] search: 2 result: 32 No such object
So why am i even able to logon and state a query?
You do not "logon", you use external authentication, which means there's no separate BIND step, like with simple bind (-x) for example. External authenication is not done by slapd (hence its name; it's done by the kernel in the above case), thus slapd can't fail it. The only LDAP operation it sees is a search, and the authenticated DN (gidNumber=X+uidNumber=Y,...) is not authorized for that, so the result is "No such object". As ACLs belong to target objects, they are not suitable for forcing server disconnection as soon as the authenticated DN is known. Maybe LDAP doesn't even allow such behaviour.
Ferenc Wagner wrote:
You do not "logon", you use external authentication, which means there's no separate BIND step,
Strictly speaking this is not correct because indeed a separate SASL/EXTERNAL bind request is sent by the client.
External authenication is not done by slapd (hence its name; it's done by the kernel in the above case), thus slapd can't fail it.
slapd indeed extracts the Unix peer credentials, which are provided by the OS, only in case it receives a SASL/EXTERNAL bind request over LDAPI.
In summary that's probably what you meant but let us be more precise because it makes a difference when looking at LDAP client support.
Ciao, Michael.
Michael Ströder michael@stroeder.com writes:
Ferenc Wagner wrote:
You do not "logon", you use external authentication, which means there's no separate BIND step,
Strictly speaking this is not correct because indeed a separate SASL/EXTERNAL bind request is sent by the client.
External authenication is not done by slapd (hence its name; it's done by the kernel in the above case), thus slapd can't fail it.
slapd indeed extracts the Unix peer credentials, which are provided by the OS, only in case it receives a SASL/EXTERNAL bind request over LDAPI.
In summary that's probably what you meant but let us be more precise because it makes a difference when looking at LDAP client support.
Actually I didn't know these details, thanks for spelling them out.
openldap-technical@openldap.org