Poking the UWWI with ldapsearch

Why does group-based access control fail?

The UWWI denies read access to most user attributes, and in particular, to the attribute that is needed for access control by group: "memberOf".

Here I describe my experimental probing of the UWWI's access permissions using the linux ldapsearch utility.

Using your own UW NetID credentials, do a search for your own memberships. You do have permission to see your own attributes, but nobody elses. Here is what I see when I search for myself:


    [root@uwwi-test-vm1 ~]# ldapsearch -LLL -ZZ -x \
    -H ldap://sidious.netid.washington.edu:389 \
    -D "CN=ketcham,ou=UWNetID,dc=netid,dc=washington,dc=edu" -W \
    -b "DC=netid,DC=was hington,DC=edu" -s sub CN=ketcham memberOf

    Enter LDAP Password: 

    dn: CN=ketcham,OU=UWNetID,DC=netid,DC=washington,DC=edu
    memberOf: CN=uw_chem_nmr_admins,OU=Standard,OU=GDS,OU=Groups,DC=netid,DC=washington,DC=edu
    memberOf: CN=uw_chem_nmr_users,OU=Standard,OU=GDS,OU=Groups,DC=netid,DC=washington,DC=edu
    memberOf: CN=u_unixgrp_vmail-chem,OU=Standard,OU=GDS,OU=Groups,DC=netid,DC=washington,DC=edu
    memberOf: CN=u_uware_matlab-cul,OU=Standard,OU=GDS,OU=Groups,DC=netid,DC=washington,DC=edu

    ...etc

But if I search for any other user's attributes, I will not get any membership information back.

To see things from sssd's point of view, you can search using your domain-joined computer's kerberos credentials, thus:


    [root@uwwi-test-vm1 ~]# kinit -k 'UWWI-TEST-VM1$@NETID.WASHINGTON.EDU'
    [root@uwwi-test-vm1 ~]# ldapsearch -LLL  -Y GSSAPI -N  \
    -H ldap://sidious.netid.washington.edu:389 \
    -b "DC=netid,DC=washington,DC=edu" -s sub CN=ketcham memberOf

    dn: CN=ketcham,OU=UWNetID,DC=netid,DC=washington,DC=edu

Again, no membership information is returned, because users' memberOf atttributes are hidden from your machine.

That's the gist of it: a user's memberOf attribute is hidden by policy, and so any access control strategy that depends on it will fail!

A Workaround Strategy

Here is, however, a way of inferring a user's membership in a given group by querying the attributes of the group (as opposed to querying attributes of the user). MemberOf is an attribute of objectClass:user to which UWWI does not allow us read access. However, a user's memberOf attributes are mapped from the member attributes of group objects of objectClass:group. I have created a group named uw_chem_nmr_users.


    [root@uwwi-test-vm1 ~]# ldapsearch -LLL -Y GSSAPI -N \
    -H ldap://sidious.netid.washington.edu:389 \
    -b "OU=Standard,OU=GDS,OU=Groups,DC=netid,DC=washington,DC=edu" \
    -s sub "(CN=uw_chem_nmr_users)" member
    
    dn: CN=ketcham,OU=UWNetID,DC=netid,DC=washington,DC=edu
    member: CN=amr0311,OU=UWNetID,DC=netid,DC=washington,DC=edu 
    member: CN=chemtest,OU=UWNetID,DC=netid,DC=washington,DC=edu 
    member: CN=gladden,OU=UWNetID,DC=netid,DC=washington,DC=edu 
    member: CN=ketcham,OU=UWNetID,DC=netid,DC=washington,DC=edu 
    member: CN=rajanp,OU=UWNetID,DC=netid,DC=washington,DC=edu

My query to list members of my group succeeds, indicating that these attributes are viewable/readable.

So we just need to enumerate the members of the groups that we want to use for access control and then use this list to match against users. I have not found a way to do this directly in sssd. We might need to create a local user database to hold this group membership information obtained in this way -- many ways to do that.