[SSSD-users] Unexpected result from ldap: Referral(10), 0000202B: RefErr: DSID-0310082F

Jakub Hrozek jhrozek at redhat.com
Wed Jun 24 19:26:48 UTC 2015


On Wed, Jun 24, 2015 at 07:03:26PM +0000, Carl Pettersson (EXT BN) wrote:
> > On Wed, Jun 24, 2015 at 06:38:21PM +0000, Carl Pettersson (EXT BN) wrote:
> > > > No, it's a bug in SSSD.
> > > 
> > > >
> > > 
> > > > 6.6 is already quite old in SSSD terms, could you please try a newer
> > > 
> > > > version from this COPR repo?
> > > 
> > > >    https://copr.fedoraproject.org/coprs/lslebodn/sssd-1-12/
> > > 
> > > >
> > > 
> > > > 1.12.5 is more-or-less equivalent to what 6.7 will include..
> > > 
> > > Thanks! I installed that version, and now I get a different error:
> > > (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] 
> > > (0x0100): Executing sasl bind mech: gssapi, user: MACHINE$ (Wed Jun 24 
> > > 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): 
> > > ldap_sasl_bind failed (-2)[Local error] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Server not found in Kerberos database)] (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [22372].
> > > (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [22372] finished successfully.
> > > (Wed Jun 24 20:21:26 2015) [sssd[be[AD.EXAMPLE.COM]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'foo-ad02.a.foo.com' as 'not working'
> > > 
> > > (I hope this gets threaded properly, I didn't get the reply to my 
> > > mailbox, but read your answer on the archive web)
> > > 
> > > Best regards,
> > > Carl
> > 
> > This is unrelated, I think. Can you check if your CentOS machine's DNS record is resolvable in both directions, iow if A and PTR records match?
> > 
> > Can you acquire a ticket with kinit and search the AD directory with ldapsearch -Y GSSAPI ?
> 
> Tickets seem fine:
>   # kinit myuser at A.FOO.COM
>   Password for myuser at A.FOO.COM:
>   # klist
>   Ticket cache: FILE:/tmp/krb5cc_0
>   Default principal: myuser at A.FOO.COM
>   
>   Valid starting     Expires            Service principal
>   06/24/15 20:52:34  06/25/15 06:52:39  krbtgt/A.FOO.COM at A.FOO.COM
>           renew until 07/01/15 20:52:34

I'm sorry, I wasn't specific enough. I wanted you to test the same
identity SSSD uses, which is the machine account from the keytab (klist
-k would show you the principals)

But I think even with the user principal, you found the issue..

> 
> Ldapsearch does not look good:
>   # ldapsearch -h foo-ad02.a.foo.com -Y GSSAPI -b OU=...
>   SASL/GSSAPI authentication started
>   ldap_sasl_interactive_bind_s: Local error (-2)
>           additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.  Minor code may provide more information (Cannot determine realm for numeric host address)
> 
> And this I guess comes back to the DNS records? Because in ad.example.com, both A and PTR look good, but if I lookup from foo-ad02.a.foo.com, I can only resolve the A record. It looks like that domain only has conditional forwarders for the forward zone, not reverse. 

OK, then I think this is the issue.  btw it help to add -N to the ldapsearch
options to tell libldap to not canonicalize the hostnames?

Would it help if you add a record to /etc/hosts?


More information about the sssd-users mailing list