[SSSD-users] Undocumented ldap_sasl_authid feature causing sssd to succeed?

[Spike White]

All,

We’re auditing for successful & healthy AD join of our 32K+ servers.  Our
check is basically this:

AUTHID=$(grep ldap_sasl_authid /etc/sssd/sssd.conf | awk '{print $3}')

[[ $AUTHID != host/* ]]  && AUTHID=host/$AUTHID

kinit -k $AUTHID

i.e., kinit with the same service principal that sssd uses (prepending the
"host/" prefix if not already existing).

We’ve identified about 200 “failing” servers, but upon closer inspection
only about 30 of them are really failing.

The other 170 are failing the above naïve check, but sssd is properly
working.  Here’s an example:

Server ddlplhdc4036.us.company.com has

ldap_sasl_authid = [e-mail]

but in /etc/krb5.keytab file ii has:

host/[e-mail]

If you look at the sssd-ldap man page, it states:

ldap_sasl_authid (string)
           Specify the SASL authorization id to use. When GSSAPI/GSS-SPNEGO
are used, this represents the Kerberos principal used for authentication to
the directory. This option can
           either contain the full principal (for example host/
[e-mail]) or just the principal name (for example host/myhost). By
default, the value is not set and the
           following principals are used:

hostname@REALM
               netbiosname$@REALM
               host/hostname@REALM
               *$@REALM
               host/*@REALM
               host/*

If none of them are found, the first principal in keytab is
returned.

Default: host/hostname@REALM

If we have ldap_sasl_authid defined in /etc/sssd/sssd.conf file and it
fails, does it try those other permutations above?

I'm guessing so, based on these 170 servers that are allegedly failing, but
sssd is truly succeeding.

Spike White