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

Fri May 5 07:52:12 UTC 2017

On Fri, May 5, 2017 at 2:08 AM, Hemanth Thummala via samba-technical
<samba-technical at lists.samba.org> wrote:
> Hello All,
>
> We are using samba 4.3.11 stack. And currently, we are facing an issue with authenticating trusted(External trust) domain users. Child trust domains is working fine.
> Session setup is actually failing with STATUS_UNSUCCESSFUL.
>
> Looking at winbindd logs, found that we are unable to bring the specific domain online. And the attempt to connect to trusted domain DC is failing with internal error.
>
> ….
>
> [2017/05/04 23:59:56.360862,  5, pid=24430, effective(0, 0), real(0, 0)] ../auth/gensec/gensec_start.c:680(gensec_start_mech)
>
>   Starting GENSEC submechanism gse_krb5
>
> [2017/05/04 23:59:56.361007,  3, pid=24430, effective(0, 0), real(0, 0)] ../lib/krb5_wrap/krb5_samba.c:2502(kerberos_get_principal_from_service_hostname)
>
>   kerberos_get_principal_from_service_hostname: cannot get realm from, desthost 2012dc1.minerva-2012d.com or default ccache. Using default smb.conf realm AUTOMATION.NUTANIX.COM
>
> [2017/05/04 23:59:56.468892,  1, pid=24430, effective(0, 0), real(0, 0)] ../source3/librpc/crypto/gse.c:340(gse_get_client_auth_token)
>
>   gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Server not found in Kerberos database]
>
> [2017/05/04 23:59:56.468998,  1, pid=24430, 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 23:59:56.469060, 10, pid=24430, 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 23:59:56.469097, 10, pid=24430, effective(0, 0), real(0, 0)] ../source3/libads/sasl.c:761(ads_sasl_spnego_bind)
>
>   ads_sasl_spnego_gensec_bind(KRB5) failed with: An internal error occurred., calling kinit
>
> [2017/05/04 23:59:56.469172, 10, pid=24430, effective(0, 0), real(0, 0)] ../source3/libads/kerberos.c:217(kerberos_kinit_password_ext)
>
>   kerberos_kinit_password: as CUSTOMER$@AUTOMATION.NUTANIX.COM using [MEMORY:winbind_ccache] as ccache and config [(null)]
>
> [2017/05/04 23:59:56.579211,  5, pid=24430, effective(0, 0), real(0, 0)] ../auth/gensec/gensec_start.c:680(gensec_start_mech)
>
>   Starting GENSEC mechanism spnego
>
> [2017/05/04 23:59:56.579328,  5, pid=24430, effective(0, 0), real(0, 0)] ../auth/gensec/gensec_start.c:680(gensec_start_mech)
>
>   Starting GENSEC submechanism gse_krb5
>
> [2017/05/04 23:59:56.579410,  3, pid=24430, effective(0, 0), real(0, 0)] ../lib/krb5_wrap/krb5_samba.c:2502(kerberos_get_principal_from_service_hostname)
>
>   kerberos_get_principal_from_service_hostname: cannot get realm from, desthost 2012dc1.minerva-2012d.com or default ccache. Using default smb.conf realm AUTOMATION.NUTANIX.COM
>
> [2017/05/04 23:59:56.667456,  1, pid=24430, effective(0, 0), real(0, 0)] ../source3/librpc/crypto/gse.c:340(gse_get_client_auth_token)
>
>   gss_init_sec_context failed with [Unspecified GSS failure.  Minor code may provide more information: Server not found in Kerberos database]
>
> [2017/05/04 23:59:56.667521,  1, pid=24430, 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 23:59:56.667588, 10, pid=24430, 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 23:59:56.667625,  0, pid=24430, 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 23:59:56.667814,  1, pid=24430, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_ads.c:136(ads_cached_connection_connect)
>
>   ads_connect for domain MINERVA_2012D failed: An internal error occurred.
>
> [2017/05/04 23:59:56.667901, 10, pid=24430, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:575(refresh_sequence_number)
>
>   refresh_sequence_number: failed with NT_STATUS_UNSUCCESSFUL
>
> [2017/05/04 23:59:56.667960, 10, pid=24430, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:500(wcache_store_seqnum)
>
>   wcache_store_seqnum: success [MINERVA_2012D][4294967295 @ 1493967596]
>
> [2017/05/04 23:59:56.668002, 10, pid=24430, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_cache.c:587(refresh_sequence_number)
>
>   refresh_sequence_number: MINERVA_2012D seq number is now -1
>
> [2017/05/04 23:59:56.668025,  1, pid=24430, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:439(ndr_print_function_debug)
>
>        wbint_QueryUser: struct wbint_QueryUser
>
>           out: struct wbint_QueryUser
>
>               info                     : *
>
>                   info: struct wbint_userinfo
>
>                       acct_name                : NULL
>
>                       full_name                : NULL
>
>                       homedir                  : NULL
>
>                       shell                    : NULL
>
>                       primary_gid              : 0x0000000000000000 (0)
>
>                       user_sid                 : S-0-0
>
>                       group_sid                : S-0-0
>
>               result                   : NT_STATUS_UNSUCCESSFUL
>
> ….
>
> Packet capture on trusted domain DC shows that, samba has closed the socket after negotiation response from client. From the above logs, it shows that we have trouble in doing the session setup request. DNS was setup properly and samba server is able to lookup the trusted domain Dcs.
>
> 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.