☰

Клиент Windows не может получить кросс-доменный билет, но клиент Linux (из WSL) может

tag-icon • tag-icon active-directory kerberos trust-relationship cross-domain
Клиент Windows не может получить кросс-доменный билет, но клиент Linux (из WSL) может

Я пытаюсь и не могу аутентифицировать свои учетные данные Kerberos при использовании sshотклиент Windows 11, присоединенный к домену Windows Server 2019 (назовем его AD.LOCAL)кLinux-хост, присоединенный к домену, управляемому FreeIPA (назовем его IPA.LOCAL).

У меня уже установлены доверительные отношения типа «Лес», и чтобы разобраться в проблемах, я проверил, что если я изменю клиента (на Linux) или пункт назначения (на хост в том же домене), то все будет работать.

Чтобы продемонстрировать проблему, вывод команды сокращен для краткости, а хост и IP-адреса анонимизированы.

❌ ОтОкнакИПАхозяин:

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

✅ ОтОкнакОБЪЯВЛЕНИЕхозяин:

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

✅ ОтЛинукскИПАхозяин:

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

✅ ОтЛинукскОБЪЯВЛЕНИЕхозяин:

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

Мои тикеты после выполнения вышеуказанных команд:

Билет Windows:

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:

$ 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

И для полноты картины, у меня нет ничего интересного /etc/krb5.confв Linux-боксе, я намеренно закомментировал почти все.

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

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

Версии ОС

Windows-клиент:

PS C:\Users\user> cmd /c ver

Microsoft Windows [Version 10.0.22000.675]

Linux-клиент:

$ 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

Обновление для ответа на вопросы в комментарии:

Окнаклиент:

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

Примечание: доверие настроено как «Внешний» тип.

Линуксу клиента вообще не установлен sssd.

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

Но для полноты картины:

$ 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

Теперь это заставляет меня думать, что клиентские инструменты Linux просто ведут себя по-разному в отношении разрешения учетных данных имени хоста. Например, следующая команда, когда ей сообщают, что требуемые учетные данные — это имя хоста, успешно выполняет и получает для krbtgtIPA.LOCAL из AD.LOCAL, а затем переходит к серверам IPA.LOCAL, чтобы получить билет:

$ 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 Обновил описание, так как мы повысили доверие с "Внешнего" типа до "Лесного". Проблема осталась прежней.

Связанный контент