Re: ACL inconsistency

["John Alex." <alexoz66@gmail.com>]

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
>