☰

El cliente de Windows no puede obtener un ticket entre dominios, pero uno de Linux (de WSL) puede

tag-icon • tag-icon active-directory kerberos trust-relationship cross-domain
El cliente de Windows no puede obtener un ticket entre dominios, pero uno de Linux (de WSL) puede

Intento y no logro autenticar mis credenciales de Kerberos cuando hago sshdeun cliente de Windows 11 unido a un dominio de Windows Server 2019 (llamémoslo AD.LOCAL)aun host Linux unido a un dominio administrado por FreeIPA (llamémoslo IPA.LOCAL).

Ya tengo la relación de confianza establecida como confianza "Bosque", y para desglosar los problemas verifiqué que si cambio el cliente (a Linux) o el destino (a un host en el mismo dominio) funciona.

Para demostrar el problema, la salida del comando se recorta por motivos de brevedad y el host y las IP se anonimizan.

❌ DesdeventanasaAPIanfitrión:

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

✅ DeventanasaANUNCIOanfitrión:

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

✅ DelinuxaAPIanfitrión:

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

✅ DelinuxaANUNCIOanfitrión:

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

Mis tickets después de ejecutar los comandos anteriores:

Boleto de 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

billete de 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

Y para completar, no tengo nada de interés en /etc/krb5.confla caja de Linux, comenté intencionalmente casi todo.

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

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

Versiones del sistema operativo

Cliente de 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

Actualización para responder preguntas en un comentario:

ventanascliente:

$ 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: La confianza está configurada como tipo "Externa".

linuxEl cliente no tiene sssd instalado en absoluto.

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

Pero 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

Ahora bien, esto me hace pensar que las herramientas del cliente de Linux simplemente se comportan de manera diferente con respecto a la resolución de las credenciales del nombre de host. Por ejemplo, el siguiente comando, cuando se le dice que la credencial deseada es un nombre de host, tiene éxito y obtiene un krbtgtfor IPA.LOCAL de AD.LOCAL, luego va a los servidores IPA.LOCAL para obtener el 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

PD: Se actualizó la descripción a medida que actualizamos la confianza del tipo "Externo" al tipo "Bosque". Sigue siendo el mismo problema.

información relacionada