☰

Ein Windows-Client kann kein Cross-Domain-Ticket abrufen, ein Linux-Client (von WSL) jedoch schon.

tag-icon • tag-icon active-directory kerberos trust-relationship cross-domain
Ein Windows-Client kann kein Cross-Domain-Ticket abrufen, ein Linux-Client (von WSL) jedoch schon.

Ich versuche, meine Kerberos-Anmeldeinformationen bei der Verwendung von SSH zu authentifizieren, scheitere jedoch daranausein Windows 11-Client, der einer Windows Server 2019-Domäne beigetreten ist (nennen wir sie AD.LOCAL)Zuein Linux-Host, der einer von FreeIPA verwalteten Domäne beigetreten ist (nennen wir ihn IPA.LOCAL).

Ich habe die Vertrauensbeziehung bereits als „Forest“-Vertrauensbeziehung eingerichtet und um die Probleme zu beheben, habe ich überprüft, dass es funktioniert, wenn ich den Client (zu Linux) oder das Ziel (zu einem Host in derselben Domäne) ändere.

Um das Problem zu demonstrieren, wird die Befehlsausgabe der Kürze halber gekürzt und der Host und die IPs anonymisiert.

❌ VonWindowsZuIPAGastgeber:

PS C:\Users\user> ssh -v -K -l [email protected] host02.ipa.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host02.ipa.local:22 as '[email protected]'
...
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
...

✅ VonWindowsZuANZEIGEGastgeber:

PS C:\Users\user> ssh -v -K -l [email protected] host01.ad.local
OpenSSH_for_Windows_8.1p1, LibreSSL 3.0.2
...
debug1: Authenticating to host01.ad.local:22 as '[email protected]'
...
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).
...

✅ VonLinuxZuIPAGastgeber:

$ ssh -v -K -l [email protected] host02.ipa.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host02.ipa.local:22 as '[email protected]'
...
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).
...

✅ VonLinuxZuANZEIGEGastgeber:

$ ssh -v -K -l [email protected] host01.ad.local
OpenSSH_8.0p1, OpenSSL 1.1.1k  FIPS 25 Mar 2021
...
debug1: Authenticating to host01.ad.local:22 as '[email protected]'
...
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).
...

Meine Tickets nach dem Ausführen der obigen Befehle:

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: [email protected]

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/[email protected]
06/17/2022 14:31:39  06/18/2022 00:30:36  krbtgt/[email protected]
        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/[email protected]
06/17/2022 14:30:36  06/18/2022 00:30:36  krbtgt/[email protected]
        renew until 06/18/2022 14:30:34

Und der Vollständigkeit halber: Ich habe auf der Linux-Box nichts Interessantes /etc/krb5.conf, ich habe absichtlich so ziemlich alles auskommentiert.

$ grep -v \# /etc/krb5.conf

[libdefaults]
    default_ccache_name = KEYRING:persistent:%{uid}

Betriebssystemversionen

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 zur Beantwortung von Fragen in einem Kommentar:

WindowsKlient:

$ 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.

Hinweis: Das Vertrauen ist als Typ „Extern“ konfiguriert.

LinuxAuf dem Client ist überhaupt keine SSD installiert.

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

Aber der Vollständigkeit halber:

$ 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

Das lässt mich nun denken, dass sich die Linux-Client-Tools beim Auflösen von Hostnamen-Anmeldeinformationen einfach anders verhalten. Wenn beispielsweise der folgende Befehl mitgeteilt wird, dass die gewünschte Anmeldeinformation ein Hostname ist, ist er erfolgreich und holt sich ein Ticket krbtgtfür IPA.LOCAL von AD.LOCAL. Anschließend geht er zu den IPA.LOCAL-Servern, um das Ticket abzurufen:

$ 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: [email protected]

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/[email protected]
06/20/2022 11:57:32  06/20/2022 21:56:38  krbtgt/[email protected]
        renew until 06/21/2022 11:56:34
06/20/2022 11:56:38  06/20/2022 21:56:38  krbtgt/[email protected]
        renew until 06/21/2022 11:56:34

PS: Die Beschreibung wurde aktualisiert, da wir das Vertrauen vom Typ „Extern“ auf den Typ „Gesamtstruktur“ aktualisiert haben. Immer noch das gleiche Problem.

verwandte Informationen