Windows client cannot get cross-domain ticket, but a Linux one (from WSL) can

Question

I am trying to and failing to authenticate my Kerberos credentials when doing ssh from a Windows 11 client joined to a Windows Server 2019 domain (let's call it AD.LOCAL) to a Linux host joined to a domain managed by FreeIPA (let's call it IPA.LOCAL).

I already have the trust relationship established as "Forest" trust, and to break down the issues I verified that if I change the client (to Linux), or the destination (to a host on the same domain) it works.

To demonstrate the problem, the command output is trimmed for brevity and the host and IPs anonymized.

❌ From Windows to IPA host:

PS C:\Users\user> ssh -v -K -l user@ad.local host02.ipa.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host02.ipa.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: GSS_S_FAILURE
debug1: Next authentication method: publickey
...

✅ From Windows to AD host:

PS C:\Users\user> ssh -v -K -l user@ad.local host01.ad.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host01.ad.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Delegating credentials
debug1: sspi delegation was requested but not fulfilled
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host01.ad.local ([192.168.0.62]:22).
...

✅ From Linux to IPA host:

$ ssh -v -K -l user@ad.local host02.ipa.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host02.ipa.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host02.ipa.local ([192.168.0.181]:22).
...

✅ From Linux to AD host:

$ ssh -v -K -l user@ad.local host01.ad.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host01.ad.local:22 as 'user@ad.local'
...
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password,keyboard-interactive
debug1: Next authentication method: gssapi-with-mic
debug1: Delegating credentials
debug1: Delegating credentials
debug1: Authentication succeeded (gssapi-with-mic).
Authenticated to host01.ad.local ([192.168.0.62]:22).
...

My tickets after running the above commands:

Windows ticket:

PS C:\Users\user> klist
Current LogonId is 0:0xe934d3
Cached Tickets: (2)
#0>     Client: user @ AD.LOCAL
        Server: krbtgt/AD.LOCAL @ AD.LOCAL
        KerbTicket Encryption Type: RSADSI RC4-HMAC(NT)
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent name_canonicalize
        Start Time: 6/17/2022 14:55:54 (local)
        End Time:   6/18/2022 0:55:54 (local)
        Renew Time: 6/24/2022 14:55:54 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0x1 -> PRIMARY
        Kdc Called: dc02.ad.local
#1>     Client: user @ AD.LOCAL
        Server: host/host01.ad.local @ AD.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a10000 -> forwardable renewable pre_authent name_canonicalize
        Start Time: 6/17/2022 14:55:54 (local)
        End Time:   6/18/2022 0:55:54 (local)
        Renew Time: 6/24/2022 14:55:54 (local)
        Session Key Type: AES-256-CTS-HMAC-SHA1-96
        Cache Flags: 0
        Kdc Called: dc02.ad.local

Linux ticket:

$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user@AD.LOCAL
Valid starting       Expires              Service principal
06/17/2022 14:31:40  06/18/2022 00:30:36  host/host02.ipa.local@
        renew until 06/18/2022 14:30:34
        Ticket server: host/host02.ipa.local@IPA.LOCAL
06/17/2022 14:31:39  06/18/2022 00:30:36  krbtgt/IPA.LOCAL@AD.LOCAL
        renew until 06/18/2022 14:30:34
06/17/2022 14:31:09  06/18/2022 00:30:36  host/host01.ad.local@
        renew until 06/18/2022 14:30:34
        Ticket server: host/host01.ad.local@AD.LOCAL
06/17/2022 14:30:36  06/18/2022 00:30:36  krbtgt/AD.LOCAL@AD.LOCAL
        renew until 06/18/2022 14:30:34

And for completeness, I have nothing of interest in /etc/krb5.conf on the Linux box, I intentionally commented out pretty much everything.

$ grep -v \# /etc/krb5.conf
[libdefaults]
    default_ccache_name = KEYRING:persistent:%{uid}

OS versions

Windows client:

PS C:\Users\user> cmd /c ver
Microsoft Windows [Version 10.0.22000.675]

Linux client:

$ lsb_release -a
LSB Version:    :core-4.1-amd64:core-4.1-noarch
Distributor ID: Rocky
Description:    Rocky Linux release 8.6 (Green Obsidian)
Release:        8.6
Codename:       GreenObsidian

Update to answer questions in a comment:

Windows client:

$ klist get host/host02.ipa.local
Current LogonId is 0:0xe934d3
Error calling API LsaCallAuthenticationPackage (GetTicket substatus): 0x6fb
klist failed with 0xc000018b/-1073741429: The SAM database on the Windows Server does not have a computer account for this workstation trust relationship.

Note: The trust is configured as "External" type.

Linux client does not have sssd installed at all.

$ rpm -qa sss\* | grep . ; echo $?
1

But for completeness:

$ env SSSD_KRB5_LOCATOR_DISABLE=1 kvno host/host02.ipa.local
kvno: Configuration file does not specify default realm while parsing principal name host/host02.ipa.local

Now, this makes me think that the Linux client tools simply behave differently in respect to resolving hostname credentials. E.g., the following command, when told that the wanted credential is a hostname, it succeeds and it goes gets a krbtgt for IPA.LOCAL from AD.LOCAL, then goes to the IPA.LOCAL servers to get the ticket:

$ env SSSD_KRB5_LOCATOR_DISABLE=1 kvno -S host host02.ipa.local
host/host02.ipa.local@: kvno = 1
$ klist
Ticket cache: KEYRING:persistent:1000:1000
Default principal: user@AD.LOCAL
Valid starting       Expires              Service principal
06/20/2022 11:57:32  06/20/2022 21:56:38  host/host02.ipa.local@
        renew until 06/21/2022 11:56:34
        Ticket server: host/host02.ipa.local@IPA.LOCAL
06/20/2022 11:57:32  06/20/2022 21:56:38  krbtgt/IPA.LOCAL@AD.LOCAL
        renew until 06/21/2022 11:56:34
06/20/2022 11:56:38  06/20/2022 21:56:38  krbtgt/AD.LOCAL@AD.LOCAL
        renew until 06/21/2022 11:56:34

P.S. Updated the description as we upgraded the trust from "External" type to "Forest" type. Still the same problem.

Windows client cannot get cross-domain ticket, but a Linux one (from WSL) can

Update to answer questions in a comment:

0 Answers0