☰

O cliente Windows não pode obter tíquete entre domínios, mas um cliente Linux (da WSL) pode

tag-icon • tag-icon active-directory kerberos trust-relationship cross-domain
O cliente Windows não pode obter tíquete entre domínios, mas um cliente Linux (da WSL) pode

Estou tentando e não consegui autenticar minhas credenciais Kerberos ao fazer sshdeum cliente Windows 11 associado a um domínio do Windows Server 2019 (vamos chamá-lo AD.LOCAL)paraum host Linux associado a um domínio gerenciado pelo FreeIPA (vamos chamá-lo de IPA.LOCAL).

Já tenho a relação de confiança estabelecida como confiança "Floresta", e para detalhar os problemas verifiquei que se eu mudar o cliente (para Linux), ou o destino (para um host no mesmo domínio) funciona.

Para demonstrar o problema, a saída do comando é reduzida por questões de brevidade e o host e os IPs são anonimizados.

❌ DejanelasparaIPAhospedar:

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

✅ DejanelasparaDE ANÚNCIOShospedar:

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

✅ DeLinuxparaIPAhospedar:

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

✅ DeLinuxparaDE ANÚNCIOShospedar:

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

Meus tickets após executar os comandos acima:

Bilhete do 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

Bilhete 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

E para completar, não tenho nada de interesse /etc/krb5.confna caixa do Linux, comentei intencionalmente quase tudo.

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

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

Versões do sistema operacional

Cliente Windows:

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

Microsoft Windows [Version 10.0.22000.675]

Cliente 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

Atualização para responder perguntas em um comentário:

janelascliente:

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

Nota: A confiança está configurada como tipo "Externo".

Linuxo cliente não tem o sssd instalado.

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

Mas para completar:

$ 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

Agora, isso me faz pensar que as ferramentas cliente Linux simplesmente se comportam de maneira diferente em relação à resolução de credenciais de nome de host. Por exemplo, o comando a seguir, quando informado de que a credencial desejada é um nome de host, é bem-sucedido e obtém um krbtgtpara IPA.LOCAL de AD.LOCAL e, em seguida, vai para os servidores IPA.LOCAL para obter o 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: [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 Atualizada a descrição conforme atualizamos a confiança do tipo "Externo" para o tipo "Floresta". Ainda o mesmo problema.

informação relacionada