On Tue, 10 Mar 2015, Traiano Welcome wrote:
However, I'm still not able to authenticate via the ssh->sssd path (I
cn get kerberos tickets for ad users via cli though), so I think that
incorrect dc discovery is not really the issue here. Instead, it seem
the ldap query against the discovered AD domain controller is failing
with some kid of policy related error:
Here's a snippet what we're seeing in the IPA master sssd logs during
an a client connection attempt:
---
.
.
.
(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0100): Executing sasl bind mech: gssapi, user:
host/lolospr-idm-mstr.idmdc2.com
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0020): ldap_sasl_bind failed (-2)[Local error]
(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send]
(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI
Error: Unspecified GSS failure. Minor code may provide more
information (KDC policy rejects request)]
When AD says "KDC policy rejects request" it means that trust is not
working well -- AD DC was unable to complete trust validation when it
was established. See another emails around the trust last week or so,
they have details on how to debug this.
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
