On Tue, Feb 18, 2014 at 09:40:46PM +0000, Nordgren, Bryce L -FS wrote:
> 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. :)
I'm sorry, but I don't have a good idea on what's going on. Is there
anything of interest in either the domain log or the ldap_child.log ?