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

Hello,

On 1/13/22 00:24, Dr. Thomas Orgis via samba wrote:
> # smbclient -d 7 -U user at domain.suffix //ad.domain.suffix/daten
> INFO: Current debug levels:
fwiw, to get useful logs use loglevel 10. Anything below is useless for 
debugging. Anything above is rarely adding anything important.
> [?]
> My question at that point: It very much looks like smbclient is trying
> to get things running using krb5 authentication. I'm pretty sure that
> mount.cifs is not attempting that. Is there some way to make smbclient
> try something else? Or fall back to NTLMSSP? I only found an option to
> explicitly _enforce_ krb5, not disable it.
It depends on the version. Iirc in older versions -k no? In 4.15 
--use-kerberos=off

You could also just use the server IP instead of the DNS name, that will 
implicitly prevent Kerberos from being used.
> I'd like to debug smbclient not working and any possible path down into
> Kerberos realms separately. I do remember trying krb5 explicitly on a
> system where kinit/klist worked just fine getting a ticket, but I got
> the same ?Message stream modified? error when trying to access DFS
> links. On that system, mount.cifs also doesn't do the trick with DFS.
> There could be all kinds of fun with network limitations for machines
> not in segregated Windows networks, so I am trying to establish a
> baseline here on a system that is just fine with the DFS using
> mount.cifs.
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.

-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/8608846e/OpenPGP_signature.sig>

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