samba - Jan 2022 - making smbclient work with a DFS setup where mount.cifs does work / disabling krb5 for testing?

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

Am Thu, 13 Jan 2022 13:04:09 +0100
schrieb "Dr. Thomas Orgis via samba" <samba at lists.samba.org>:
> 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?
Ah, thanks a lot for the pointer to --use-kerberos with newer samba!

Things work nicely with a fresh smbclient and

	smbclient  --use-kerberos=off -U user at domain.suffix //ad.domain.suffix/data

so that it can be concluded that the handling of Kerberos in the DFS is
at fault. It happily uses NTLMSSP to authenticate, which is fine by me.
So I just need to roll out custom builds of smbclient to my users that
offer the switch (or even default the switch to off).

But considering the line

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

with following failures to actually connect, do you think that this
points to a bug in samba, or rather to a bug in the DFS setup? Since
things work for the Windows clients in the domains, one could assume
that it means that the non-standard client is at fault, by default:-/


Alrighty then,

Thomas

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

On 1/13/22 14:44, Dr. Thomas Orgis wrote:
> But considering the line
> 
> cli_session_creds_prepare_krb5: Successfully authenticated as user at
domain.suffix (USER at DOMAIN.SUFFIX) to access ad.domain.suffix using Kerberos
> 
> with following failures to actually connect, do you think that this
> points to a bug in samba, or rather to a bug in the DFS setup?
possibly. You may want to file a bug and attach a network trace and a 
parallel loglevel 10 log.

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 840 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20220113/dc91fcbc/OpenPGP_signature.sig>