I think this is because the keytab is missing. I think we should do
a
better job reporting the reason for the failure.
...
The AD provider is more or less a wrapper around LDAP and Kerberos
back ends with defaults tailored for AD and leveraging some AD-specific features.
The only 'assumption' it makes is the presence of a keytab to use
GSSAPI for authenticated searches.
I think you're right about the keytab: using ktutil, I created /etc/krb5.keytab with
my principal and password in a handful of enctypes. Also, I told sssd to use me as the
principal using ldap_sasl_authid. This seems to allow sssd to start. It also allows sssd
to try and request a TGT from my kdc using my principal.
What I'm seeing now, using wireshark (attached), is a Kerberos failure. The sequence
is :
AS_REQ (no preauth)
KRB_ERROR (preauth required)
AS_REQ (PA-ENC-TIMESTAMP)
KRB_ERROR (PA-ENCTYPE-INFO2)
My understanding from rfc4120 is that the "info2" is AD "hinting" to
my client about the salt it wants the timecode to be encrypted with. If that were the
case, shouldn't there be a third exchange where sasl (or sssd) applies the salt?
Is this a sasl thing or an sssd thing? Or am I just plain mistaken?
I'll try the new release next time around to see if that fixes my id-mapping
problem...Now I gotta get back to work. :)
Bryce
This electronic message contains information generated by the USDA solely for the intended
recipients. Any unauthorized interception of this message or the use or disclosure of the
information it contains may violate the law and subject the violator to civil or criminal
penalties. If you believe you have received this message in error, please notify the
sender and delete the email immediately.