> 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.