SSSD - The Problem with AD POSIX Unix IDs

In my previously posted sssd.conf, I used ldap_id_mapping = true to enable the SID to UID id mapping algorithm. This was before I learned that the POSIX attributes uidNumber and gidNumber are provided for each netID. I want to convert my system to use the POSIX attributes, so I edit my sssd.conf, setting ldap_id_mapping = false. This creates a conflict with my pre-existing sssd database. So I delete everything and reinstall to get a clean start.

    systemctl stop sssd
    rm -f /var/log/sssd/*
    rm -rf /var/lib/sss
    rm /etc/krb5.keytab
    rm -rf /home/netid.washington.edu/*
    yum reinstall sssd\*
    adcli join netid.washington.edu

Now I log in as my netID. After entering my password it takes a very long time, but finally succeeds. It works... sort of:

    id: cannot find name for group ID 1100224681
    [ketcham@c7-nmr-3 ~]$ 
    [ketcham@c7-nmr-3 ~]$ ls -l udrive/

. . . (wait for 30 second timeout)

        total 0
    drwxr-xr-x 2 ketcham 1100224681 0 Feb 16 19:00 dir1
    -rwxr-xr-x 1 ketcham 1100224681 0 Feb 16 19:00 file1
    -rwxr-xr-x 1 ketcham 1100224681 0 Feb 16 19:00 file2

The system can resolve my uidNumber, but not my gidNumber.

    [root@c7-nmr-3 c7-nmr-3]# getent passwd ketcham
    ketcham:*:6445:1100224681:ketcham:/home/ketcham:/bin/bash
    [root@c7-nmr-3 c7-nmr-3]# getent passwd 6445
    ketcham:*:6445:1100224681:ketcham:/home/ketcham:/bin/bash
    [root@c7-nmr-3 c7-nmr-3]# getent group 1100224681

    [root@c7-nmr-3 c7-nmr-3]#

In fact, looking up my gidNumber results in a 30 second timeout:

    [root@c7-nmr-3 c7-nmr-3]# time getent group 1100224681
    real	0m30.030s
    user	0m0.001s
    sys	0m0.000s
    [root@c7-nmr-3 c7-nmr-3]#

I find the actual ldap query in the log:

    [root@c7-nmr-3 c7-nmr-3]# grep 'Fri Mar  4 10:2' \
    /var/log/sssd/sssd_netid.washington.edu.log |grep 1100224681
    ...
    (Fri Mar  4 10:20:40 2016) [sssd[be[netid.washington.edu]]] \
    [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with \
    [(&(gidNumber=110022468)(objectClass=group)(sAMAccountName=*)\
    (&(gidNumber=*)(!(gidNumber=0))))][DC=netid,DC=washington,DC=edu].
    ...

I copy and paste that query string to the ldapsearch command line:

    [root@c7-nmr-3 sssd]#  ldapsearch -H \
    ldap://sidious.netid.washington.edu:389 -Y GSSAPI -N  \
    -b "DC=netid,DC=washington,DC=edu" -s sub \
    '(&(gidNumber=1100224681)(objectClass=group)(sAMAccountName=*) \
     (&(gidNumber=*)(!(gidNumber=0))))'

Indeed, it returns with nothing found. However, if I change objectClass=group to objectClass=user:

    [root@c7-nmr-3 sssd]#  ldapsearch -LLL -H \
    ldap://sidious.netid.washington.edu:389 -Y GSSAPI -N  \
    -b "DC=netid,DC=washington,DC=edu" -s sub \
    '(&(gidNumber=1100224681)(objectClass=user)(sAMAccountName=*)\
     (&(gidNumber=*)(!(gidNumber=0))))' dn

my netid user is found:

    SASL/GSSAPI authentication started
    SASL username: C7-NMR-3$@NETID.WASHINGTON.EDU
    SASL SSF: 56
    SASL data security layer installed.
    dn: CN=ketcham,OU=UWNetID,DC=netid,DC=washington,DC=edu

So now we see what the problem is: the guiNumber attribute is not a real group, in the Active Directory.