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(a)A.FOO.COM
Password for myuser(a)A.FOO.COM:
# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: myuser(a)A.FOO.COM
Valid starting Expires Service principal
06/24/15 20:52:34 06/25/15 06:52:39 krbtgt/A.FOO.COM(a)A.FOO.COM
renew until 07/01/15 20:52:34
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.
Carl