Connection to ad via ldap failing

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

[Jakub Hrozek]

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 ?

[Sumit Bose]

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

bye,
Sumit

>  _______________________________________________
>  sssd-users mailing list
>  sssd-users(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/sssd-users