On Thu, Feb 20, 2014 at 09:42:26PM +0100, Jakub Hrozek wrote:
On Tue, Feb 18, 2014 at 09:40:46PM +0000, Nordgren, Bryce L -FS
> > 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
> > 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 ?
Maybe if you call kinit directly with KRB5_TRACE enabled we can get more
details about the issue.
KRB5_TRACE=/dev/sdtout kinit -k your@principal
sssd-users mailing list