Re: [nssldap] RV: Unix id command and Openldap

[Buchan Milne <bgmilne [at] mandriva.org>]

On Tuesday 30 December 2008 13:19:34 okossuth@antel.com.uy wrote:
> Hi guys
>
> i solved my problem. Apparently it was a misconfiguration in the slapd.conf
> file of my opneldap server. it had this line:
>
> access to attrs=userPassword,userPKCS12,memberUid,member
>         by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
>         by self write
>         by * auth
>
> For some reason that line was blocking somehow the correct behaviour of the
> id command... after removing it and restarting the ldap server everything
> worked as expected.
>
> Any ideas why this line made my life misaerable?? hehe

Yes, in order to save one access statement, you put userPassword and other 
non-credential attributes (memberUid, member) in the same rule. Since you 
probably don't want userPassword readable by everyone who should be able to 
enumerate group members, the only access you gave besides to cn=admin was 
auth, which does not include read. So, no non-admin users (except possibly the 
group's DN itself, if it has a means of authentication itself to the LDAP 
servers) could read any of the membership attributes.

Don't combine attributes with different access requirements into the same 
access statement!

BTW, if cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy is your rootdn, you 
can just drop memberUid and member from the access statement (assuming you 
have a blanket read access rule at the end), it will get write access anyway. 
If it is not the rootdn, then you should split this rule:

access to attrs=userPassword,userPKCS12
        by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
        by self write
        by * auth

access to attrs=memberUid,member
        by dn="cn=admin,dc=vmlx-ldapauth-test,dc=in.iantel.com.uy" write
        by * read

or, you could move the memberUid and member attributes to some other more 
appropriate rule covering attributes with the same access requirements.

(Further discussion of OpenLDAP ACLs probably doesn't belong on this list, but 
openldap-software, or openldap-technical in the case where you touch on non-
OpenLDAP software as well, such as nss_ldap).

Oh, and you could have included your slapd.conf at some stage (instead of 
asking other people for theirs), this could have been solved a *lot* sooner!

Regards,
Buchan