Unable to authenticate the trusted(external trust) domain users.

Hemanth Thummala hemanth.thummala at nutanix.com
Fri May 5 23:07:07 UTC 2017


Looks like the authentication issue is specific to external trust. 
If I change the trust type for the same domain from “Extrenal” to “Forest”, authentication goes though fine. 

Following error doesn’t seem to be occurring when the trust type is changed to “Forest” 
gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Server not found in Kerberos database]


Thanks,
Hemanth.




On 5/5/17, 11:24 AM, "Hemanth Thummala" <hemanth.thummala at nutanix.com> wrote:

>Interestingly, wbinfo -a works for the trusted domain users.
>
>From winbindd logs, I could see that the RPC “NetrSamLogon” request is being made to the local domain DC which in turn talking to the remote DC. There was no direct connection made to trusted domain.
>
>Whereas, using smbclient or regular windows client access workflow, we are trying to establish session with remote trusted DC which is failing with internal error.
>
>Thanks,
>
>Hemanth.
>
>On 5/5/17, 10:24 AM, "Hemanth Thummala" <hemanth.thummala at nutanix.com> wrote:
>
>>Hi Scott,
>>
>>We have actually found the clock skew problem on the same DC. And the error that time was more informative.
>>
>>[2017/05/04 19:37:35.081722,  0, pid=118359, effective(0, 0), real(0, 0)] ../source3/libads/kerberos_util.c:74(ads_kinit_password)
>>  kerberos_kinit_password NUTEST875651$@AUTOMATION.NUTANIX.COM failed: Clock skew too great
>>[2017/05/04 19:37:35.081901,  1, pid=118359, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>>  ads_connect for domain MINERVA_QA-2-- failed: Clock skew too great
>>
>>
>>After fixing the clock skew, error become “Internal error”
>>
>>[2017/05/04 20:04:48.526788,  1, pid=140452, effective(0, 0), real(0, 0)] ../auth/gensec/spnego.c:619(gensec_spnego_create_negTokenInit)
>>  SPNEGO(gse_krb5) creating NEG_TOKEN_INIT failed: NT_STATUS_INTERNAL_ERROR
>>[2017/05/04 20:04:48.526877, 10, pid=140452, effective(0, 0), real(0, 0)] ../auth/gensec/spnego.c:672(gensec_spnego_create_negTokenInit)
>>  Failed to setup SPNEGO negTokenInit request: NT_STATUS_INTERNAL_ERROR
>>[2017/05/04 20:04:48.526907,  0, pid=140452, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:773(ads_sasl_spnego_bind)
>>  kinit succeeded but ads_sasl_spnego_gensec_bind(KRB5) failed: An internal error occurred.
>>[2017/05/04 20:04:48.526971,  1, pid=140452, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>>  ads_connect for domain MINERVA_QA-2-- failed: An internal error occurred.
>>
>>
>>As you can see from the log, kinit is actually succeeded. But, ads_sasl_spnego_gensec_bind() is failed.
>>
>>Thanks,
>>Hemanth.
>>
>>
>>
>>On 5/5/17, 12:52 AM, "Scott Lovenberg" <scott.lovenberg at gmail.com> wrote:
>>
>>>>Any pointers here to know what could have caused the ads connect errors?
>>>>
>>>>Thanks,
>>>>Hemanth.
>>>>
>>>
>>>While looking at that stack trace makes me think that this isn't the
>>>problem, I'll throw it out there on the low chance that it caused the
>>>conditions that this is the effect of - are the clocks on all of the
>>>machines fairly in sync?  Kerberos is fairly time sensitive and I've
>>>had a wandering clock on a VM cause issues until I made it practice to
>>>have an NTP server on site that's handed off in DHCP to keep all of
>>>the clocks from drifting enough that kinit would fail from time to
>>>time.  Low chance this is your underlying issue, but it's also low
>>>effort to check/correct.
>>>
>>>-- 
>>>Peace and Blessings,
>>>-Scott.
>>>


More information about the samba-technical mailing list