[Samba] making smbclient work with a DFS setup where mount.cifs does work / disabling krb5 for testing?

[Dr. Thomas Orgis]

Am Thu, 13 Jan 2022 11:08:30 +0100
schrieb Ralph Boehme via samba <samba at lists.samba.org>:

> fwiw, to get useful logs use loglevel 10. Anything below is useless for 
> debugging. Anything above is rarely adding anything important.

Thanks. With -d 10, I get a bit more detail:

 negotiated dialect[SMB3_11] against server[ad.domain.suffix]
Enter user at domain.suffix's password: 
cli_session_creds_prepare_krb5: Doing kinit for user at domain.suffix to access ad.domain.suffix
kerberos_kinit_password_ext: as user at domain.suffix using [MEMORY:cliconnect] as ccache and config [(null)]
kerberos_kinit_password_ext: user at domain.suffix mapped to USER at DOMAIN.SUFFIX
cli_session_creds_prepare_krb5: Successfully authenticated as user at domain.suffix (USER at DOMAIN.SUFFIX) to access ad.domain.suffix using Kerberos
cli_session_setup_spnego_send: Connect to ad.domain.suffix as USER at DOMAIN.SUFFIX using SPNEGO
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'http_negotiate' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Starting GENSEC mechanism spnego
Starting GENSEC submechanism gse_krb5
gensec_update_send: gse_krb5[0x55dde2079670]: subreq: 0x55dde206b760
gensec_update_send: spnego[0x55dde206d760]: subreq: 0x55dde20784c0
gensec_update_done: gse_krb5[0x55dde2079670]: NT_STATUS_MORE_PROCESSING_REQUIRED tevent_req[0x55dde206b760/../../source3/librpc/crypto/gse.c:848]: state[2] error[0 (0x0)]  state[struct gensec_gse_update_state (0x55dde206b910)] timer[(nil)] finish[../../source3/librpc/crypto/gse.c:859]
gensec_update_done: spnego[0x55dde206d760]: NT_STATUS_MORE_PROCESSING_REQUIRED tevent_req[0x55dde20784c0/../../auth/gensec/spnego.c:1631]: state[2] error[0 (0x0)]  state[struct gensec_spnego_update_state (0x55dde2078670)] timer[(nil)] finish[../../auth/gensec/spnego.c:2116]
gse_get_client_auth_token: gss_init_sec_context failed with [ Miscellaneous failure (see text): Message stream modified](2529638953)
gensec_update_send: gse_krb5[0x55dde2079670]: subreq: 0x55dde206baa0
gensec_update_send: spnego[0x55dde206d760]: subreq: 0x55dde207d500
gensec_update_done: gse_krb5[0x55dde2079670]: NT_STATUS_LOGON_FAILURE tevent_req[0x55dde206baa0/../../source3/librpc/crypto/gse.c:848]: state[3] error[-7963671676338569107 (0x917B5ACDC000006D)]  state[struct gensec_gse_update_state (0x55dde206bc50)] timer[(nil)] finish[../../source3/librpc/crypto/gse.c:862]
gensec_spnego_client_negTokenTarg_step: SPNEGO(gse_krb5) login failed: NT_STATUS_LOGON_FAILURE
gensec_update_done: spnego[0x55dde206d760]: NT_STATUS_LOGON_FAILURE tevent_req[0x55dde207d500/../../auth/gensec/spnego.c:1631]: state[3] error[-7963671676338569107 (0x917B5ACDC000006D)]  state[struct gensec_spnego_update_state (0x55dde207d6b0)] timer[(nil)] finish[../../auth/gensec/spnego.c:2039]
SPNEGO login failed: The attempted logon is invalid. This is either due to a bad username or authentication information.
session setup failed: NT_STATUS_LOGON_FAILURE

So there is the most interesting line

cli_session_creds_prepare_krb5: Successfully authenticated as user at domain.suffix (USER at DOMAIN.SUFFIX) to access ad.domain.suffix using Kerberos

that indicates that Kerberos auth is even successful behind the scenes.
But access fails nevertheless. So we got a bug in the gensec code,
perhaps?

> It depends on the version. Iirc in older versions -k no? In 4.15 
> --use-kerberos=off

smbclient -k no … ? That doesn't work here. But this is a reason to try
a custom build of a more recent samba. I'll see to that. 

> You could also just use the server IP instead of the DNS name, that will 
> implicitly prevent Kerberos from being used.

This is probably similar to the case of logging into one of the other
possible entry points, where basic access works, but then the first DFS
link triggers the breakage. That is what I have seen before with
smbclient. The DFS link causes fresh lookup of all sorts of things.

> Well, for debugging the DFS issue a network trace and loglevel 10 log 
> would be helpful and the hopefully someone has some spare time to look 
> into those logs.

OK, I'll try a current samba codebase first, possibly disabling
Kerberos to mirror what mount.cifs does. Or … can someone confirm what
mount.cifs actually does? Is it possibly also doing Kerberos behind the
scenes?


Alrighty then,

Thomas

-- 
Dr. Thomas Orgis
HPC @ Universität Hamburg