Remote PowerShell session creation failing from Linux to windows with latest Kerberos package krb5-1.21.3-1.cm2.

[rotiwari]

I was trying to create a remote PowerShell session from a Linux Mariner distro to a windows machine and the same is failing. The same is working with krb5-1.19.4-2.cm2 version whereas it fails with krb5-1.21.3-1.cm2.
Please let me know what logs/additional info I can help with to get to the root cause of the issue. Or do we have some known issue reported around the same. It looks like there is fixes introduced for CVE-2024-37370 and CVE-2024-37371 as part of kerberos package and I am not very sure if that needs some additional changes as part of gssntlm-ssp package as well for handling aes256-sha1 session keys

This is the how the packet flow looks like

[simo5]

Usually getting what kind of auth error the Windows system logs in its system log helps in these situations.

[rotiwari]

Basically in this case the session is hanged for ever. Tried checking the Kerberos event logs but didn't find anything. Do you want me to check some more specific logs.

[rotiwari]

Is there steps to collect some relevant traces from gssntlmssp communication front.

[simo5]

gssntlmssp runs as a plugin of the gssapi library so there isn't much more except std gssapi logging facilities or gdb

[matuag]

I am having the same issue. Is there a resolution to the problem? Thanks

[rotiwari]

@matuag - Currently I don't have a resolution to the problem. To confirm what is the Linux distro you are using, and which is the last version of Kerberos package where it worked for you.

[yevheniilavrenchuk]

We've got similar problem but using dotnet8 on Alpine Docker image to authenticate on Windows.
It broke when krb5 krb5-1.21.3-r0 was released, because on krb5-1.20.2-r0 authorization works.
Also openssl package updated from openssl-3.1.6-r0 to openssl-3.3.1-r3

I don't really know if the problem is in gssntlm or in krb5 package tbh, still investigating, but decided to ask here as well, since I had issue with gssntlm before, which was resolved, by patching gssntlm

Error is not saying much: Authentication validation failed with error - InvalidToken.

Here is a gssntlm log (nothing special I guess):

[1726583811] ALLOK: string_split() @ src/gss_names.c:60 [0:0]
[1726583811] ALLOK: gssntlm_acquire_cred_from() @ src/gss_creds.c:501 [0:0]
[1726583811] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583811] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583811] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583811] ALLOK: gssntlm_init_sec_context() @ src/gss_sec_ctx.c:246 [1:0]
[1726583811] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583811] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583811] ALLOK: gssntlm_spnego_req_mic() @ src/gss_sec_ctx.c:1270 [0:0]
[1726583811] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583811] ALLOK: gssntlm_cli_auth() @ src/gss_auth.c:277 [0:0]
[1726583811] ALLOK: gssntlm_init_sec_context() @ src/gss_sec_ctx.c:416 [0:0]
[1726583811] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583811] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583811] ALLOK: gssntlm_spnego_req_mic() @ src/gss_sec_ctx.c:1270 [0:0]
[1726583811] ALLOK: gssntlm_get_mic() @ src/gss_signseal.c:52 [0:0]
[1726583811] ALLOK: gssntlm_reset_crypto() @ src/gss_sec_ctx.c:1202 [0:0]
[1726583811] ALLOK: gssntlm_delete_sec_context() @ src/gss_sec_ctx.c:483 [0:0]
[1726583812] ALLOK: string_split() @ src/gss_names.c:60 [0:0]
[1726583812] ALLOK: gssntlm_acquire_cred_from() @ src/gss_creds.c:501 [0:0]
[1726583812] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583812] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583812] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583812] ALLOK: gssntlm_init_sec_context() @ src/gss_sec_ctx.c:246 [1:0]
[1726583812] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583812] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583812] ALLOK: gssntlm_spnego_req_mic() @ src/gss_sec_ctx.c:1270 [0:0]
[1726583812] ALLOK: gssntlm_import_name_by_mech() @ src/gss_names.c:355 [0:0]
[1726583812] ALLOK: gssntlm_cli_auth() @ src/gss_auth.c:277 [0:0]
[1726583812] ALLOK: gssntlm_init_sec_context() @ src/gss_sec_ctx.c:416 [0:0]
[1726583812] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583812] ALLOK: gssntlm_release_name() @ src/gss_names.c:633 [0:0]
[1726583812] ALLOK: gssntlm_spnego_req_mic() @ src/gss_sec_ctx.c:1270 [0:0]
[1726583812] ALLOK: gssntlm_get_mic() @ src/gss_signseal.c:52 [0:0]
[1726583812] ALLOK: gssntlm_reset_crypto() @ src/gss_sec_ctx.c:1202 [0:0]
[1726583812] ALLOK: gssntlm_delete_sec_context() @ src/gss_sec_ctx.c:483 [0:0]

Thanks in advance for any information

[matuag]

@rotiwari We are upgrading from CentOS 7 to Rocky Linux 9.
The last working solution for our application on CentOS 7 had the following:
Kerberos 5 release 1.15.1
GSSNTLMSSP - 1.2.0

[styladj1]

@rotiwari Did you ever find a solution for your issue?

I am facing a similar issue and the culprit in my case is the missing NTLM SSP library under CentOS Stream 9.