> On 2 May 2018, at 17:54, JOHE (John Hearns) <JOHE@novozymes.com> wrote:
>
> I would appreciate some pointers.
> I have a sandbox setup running on VMs. There is an AD controller using the VM image which Microsoft has available for testing.
> I have created a domain called ad.test
>
> On my client machine I am continually getting this error:
> [sssd[be[adtest.private]]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)
>
I find it easier to debug this kind of an issue with:
KRB5_TRACE=/dev/stderr ldapsearch -Y GSSAPI -H ldap://your.ad.dc -s base -b “”
Also, what version and on what OS are you running?
>
> On the client klist-k | uniq returns
>
> KVNO Principal
> ---- ------------------------------------------------------------ --------------
> 3 CLIENT1$@ADTEST.PRIVATE
> 3 host/CLIENT1@ADTEST.PRIVATE
> 3 host/client1@ADTEST.PRIVATE
> 3 RestrictedKrbHost/CLIENT1@ADTEST.PRIVATE
> 3 RestrictedKrbHost/client1@ADTEST.PRIVATE
>
> The funny thing is ONLY kinit -k CLIENT1$\@ADTEST.PRIVATE will work.
This is expected, only the client$@realm principal is a user/computer principal, the rest are service principals.
> I do get a tgt:
> Ticket cache: FILE:/tmp/krb5cc_0
> Default principal: CLIENT1$@ADTEST.PRIVATE
>
> Just in the sandbox I am also setting:
> ldap_auth_disable_tls_never_use_in_production = true
Please don’t use this, not only it is very insecure, but also it doesn’t make any sense, this option is only useful if you use auth_provider=ldap. With id_provider/auth_provider=ad, TLS is not used, but GSSAPI is.
>
> Any pointers please? I have cranked debug up to 8 and this error message seems to be the crucial one.
>
> By the way, why does the debug level not go up to 11?
Because 9 is the highest?
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org