%20jedoch%20schon..png)
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 krbtgt
fü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.