[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: ACL inconsistency
- To: openldap-technical@openldap.org
- Subject: Re: ACL inconsistency
- From: "John Alex." <alexoz66@gmail.com>
- Date: Wed, 04 Jun 2014 14:17:31 +0300
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=/3x3Z3bxSeJEMe7up9W3yWku7pIxHh2k9cd/g9EthsQ=; b=m3/Y12oS3lg2iHEqZKK6gQxMBgh5UEnPkeSAoGUjDxnPytFAmG2EvCBEMFfnETqMcz pSm6I2ZIR8bT5uoIpMPvo4kzhd6g4AUmQ55kfl+G+eZb4c5rUm9XStfzzRseSmCsq8mP vceppcdcNd/A4Rd6N/Q+4c70bRGWqOn1FSaLOYaWFkuDjgq/868wDHkJE/+WbZIqOUu6 XhKAu/JUF4WG1bRmesPgf6su283dP/luR/anB1+uHfqh0UIDB7Ndwl5VyOrIbCDJlFXm Apcltx2SZrHEpqaKr6XE+IeqbvuQkOElNHbd9RHgfyTka3JlToN5F49aZa9uEczERzrc y9cg==
- In-reply-to: <538C833A.3010809@gmail.com>
- References: <538C833A.3010809@gmail.com>
- User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
It looks like the problem was with the rwm overlay which I had been using with the
following configuration:
dn: olcOverlay={3}rwm,olcDatabase={1}mdb,cn=config
objectClass: olcConfig
objectClass: olcOverlayConfig
objectClass: olcRwmConfig
objectClass: top
olcOverlay: {3}rwm
olcRwmRewrite: {0}rwm-rewriteEngine on
olcRwmRewrite: {1}rwm-rewriteContext bindDN
olcRwmRewrite: {2}rwm-rewriteRule "^uid=([^,]+),dc=xmpl,dc=co$" "uid=$1,ou=p
eople,dc=xmpl,dc=co" ":"
We plan on moving all user entries under ou=people, and I had configured the above to
allow users to bind using the current DN, at least until we've informed everyone about
this change. I know rwm overlay is considered experimental but never thought that it might
interfere with ACL parsing. Setting rewriteEngine to off had no effect on this issue, so I
had to remove the rwm overlay completely from the configuration, and everything is back to
normal.
Regards,
John
On 02/06/2014 04:59 ÎÎ, John Alex. wrote:
> Hi all,
>
> I use the following rules in my configuration:
>
> olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=extern
> al,cn=auth" manage by * break
> olcAccess: {1}to dn.one="ou=people,dc=xmpl,dc=co" filter="(pwdReset=TRUE)" a
> ttrs=userPassword by * none
> olcAccess: {2}to dn.subtree="ou=people,dc=xmpl,dc=co" by dn.base="cn=radius,
> ou=admins,dc=xmpl,dc=co" read by * break
> olcAccess: {3}to attrs=userPassword by anonymous auth
> olcAccess: {4}to dn.base="dc=xmpl,dc=co" by * read
> olcAccess: {5}to dn.subtree="ou=people,dc=xmpl,dc=co" by * read
>
> I have issues with rule {1} which I have set in order to disallow ldap bind and radius
> authentication from users whose password has been reset. I found out that this rule works
> when I request all attributes of a matching entry (uid=jdoe,ou=people,dc=xmpl,dc=co), but
> if I request specifically the attribute userPassword, its value is returned as if this
> rule did not exist:
>
> % ldapsearch -H ldapi:/// -D "cn=radius,ou=admins,dc=xmpl,dc=co" -W -x -b
> "ou=people,dc=xmpl,dc=co" "uid=jdoe"
>
> # extended LDIF
> #
> # LDAPv3
> # base <ou=people,dc=xmpl,dc=co> with scope subtree
> # filter: uid=jdoe
> # requesting: ALL
> #
>
> # jdoe, people, xmpl.co
> dn: uid=jdoe,ou=people,dc=xmpl,dc=co
> objectClass: inetOrgPerson
> objectClass: organizationalPerson
> objectClass: person
> objectClass: top
> cn: John Doe
> sn: Doe
> uid: jdoe
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
>
>
> % ldapsearch -H ldapi:/// -D "cn=radius,ou=admins,dc=xmpl,dc=co" -W -x -b
> "ou=people,dc=xmpl,dc=co" "uid=jdoe" "userPassword"
>
> # extended LDIF
> #
> # LDAPv3
> # base <ou=people,dc=xmpl,dc=co> with scope subtree
> # filter: uid=jdoe
> # requesting: userPassword
> #
>
> # jdoe, people, xmpl.co
> dn: uid=jdoe,ou=people,dc=xmpl,dc=co
> userPassword:: dGVzdDEyMw==
>
> # search result
> search: 2
> result: 0 Success
>
> # numResponses: 2
> # numEntries: 1
>
> ------------------------------------------
>
> slapacl shows it should be ok in any case:
>
> % slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D "cn=radius,ou=admins,dc=xmpl,dc=co" -b
> "uid=jdoe,ou=people,dc=xmpl,dc=co"
>
> authcDN: "cn=radius,ou=admins,dc=xmpl,dc=co"
> entry: read(=rscxd)
> children: read(=rscxd)
> objectClass=inetOrgPerson: read(=rscxd)
> objectClass=organizationalPerson: read(=rscxd)
> objectClass=person: read(=rscxd)
> objectClass=top: read(=rscxd)
> structuralObjectClass=inetOrgPerson: read(=rscxd)
> entryUUID=e959dfb8-76b6-1033-8972-4b1922a532ac: read(=rscxd)
> creatorsName=cn=admin,dc=xmpl,dc=co: read(=rscxd)
> createTimestamp=20140523111245Z: read(=rscxd)
> cn=John Doe: read(=rscxd)
> sn=Doe: read(=rscxd)
> uid=jdoe: read(=rscxd)
> userPassword=****: none(=0)
> pwdChangedTime=20140602101409Z: read(=rscxd)
> pwdReset=TRUE: read(=rscxd)
> entryCSN=20140602101723.590271Z#000000#000#000000: read(=rscxd)
> modifiersName=cn=admin,dc=xmpl,dc=co: read(=rscxd)
> modifyTimestamp=20140602101723Z: read(=rscxd)
>
>
>
> % slapacl -F /usr/local/etc/openldap/slapd.d/ -v -D "cn=radius,ou=admins,dc=xmpl,dc=co" -b
> "uid=jdoe,ou=people,dc=xmpl,dc=co" userPassword/read
>
> authcDN: "cn=radius,ou=admins,dc=xmpl,dc=co"
> read access to userPassword: DENIED
>
> ------------------------------------------
>
> If I change the rule and keep just the filter or the attribute, like:
>
> olcAccess: {1}to dn.one="ou=people,dc=xmpl,dc=co" filter="(pwdReset=TRUE)" b
> y * none
>
> OR
>
> olcAccess: {1}to dn.one="ou=people,dc=xmpl,dc=co" attrs=userPassword by * no
> ne
>
> then it seems to work ok in all cases.
>
> # /usr/local/libexec/slapd -V
> @(#) $OpenLDAP: slapd 2.4.39 (May 9 2014 09:26:03) $
> root@xmpl.co:/usr/ports/net/openldap24-server/work/openldap-2.4.39/servers/slapd
>
> Am I doing something wrong or is this a bug?
>
> Thanks in advance,
> John
>