Error de GSS -API Aceptación de contexto: Clave de servicio No disponible - Código Solaris, Windows KDC

Question

Estoy intentando obtener un par de cliente/servidor Kerberos que trabaje en Active Directory. He creado tres usuarios en un dominio de repuesto en nuestra red corporativa, "Richardc", "Server1" y "Server2". Los usuarios de mi servidor se han asignado a diferentes nombres principales del servicio, uno con KRB5_NT_PRIVIPAL, el otro con KRB5_NT_SRV_HOST.

ktpass -out server2.keytab 
          -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
          -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
          -pass ThePassword
          -crypto All
          -pType KRB5_NT_SRV_HOST
          -kvno 2

Esta vez no he utilizado la opción +desonsly, con la esperanza de que en los sistemas de hoy no necesite DES. He reemplazado el nombre de dominio real con Mydomain en esta pregunta para evitar la preocupación de gestión.

Esto me da un keytab. Puedo ponerlo en Klist:

KVNO Principal
---- --------------------------------------------------------------------------
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with CRC-32)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (DES cbc mode with RSA-MD5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (ArcFour with HMAC/md5)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-256 CTS mode with 96-bit SHA-1 HMAC)
   2 server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL (AES-128 CTS mode with 96-bit SHA-1 HMAC)

Incluso puedo usar Kinit -K para iniciar sesión usando la clave del KeyTab, por lo que parece funcionar.

Tengo tanto mi propio programa de prueba como para fallar que el programa de prueba desde http://download.oracle.com/docs/cd/e19683-01/816-1331/sampleprogs-1/index.html. En ese programa, en el servidor, he cambiado GSS_C_NT_HOSTBASED_SERVICE a GSS_C_NT_USER_NAME con ambos KeyTabs para que reconozca el nombre. Estoy ejecutando el servidor de demostración de Oracle como

./gss-server -mech 1.2.840.113554.1.2.2 server2/serbia.mydomain.com    

y el cliente

./gss-client -mech 1.2.840.113554.1.2.2 serbia.mydomain.com server2 "Hello"

El resultado:

GSS-API error accepting context: Invalid credential was supplied
GSS-API error accepting context: Service key not available

Tanto en este caso como con mi propio código de prueba, el error ocurre después de que el cliente haya enviado su primer token, mientras que el servidor está intentando decodificarlo.

Klist muestra la clave otorgada para el cliente. Está usando ArcFour, que está en el keytab

Default principal: RichardC@BENCHMARKING.RDDEV.LOCAL

Valid starting                Expires                Service principal
07/25/11 17:36:49  07/26/11 03:35:18  krbtgt/BENCHMARKING.RDDEV.LOCAL@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:49
07/25/11 17:36:03  07/26/11 03:35:18  server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
    renew until 08/01/11 17:36:03

La máquina Unix (Serbia) podría pertenecer a otro reino (el que he llamado mydomain.com aquí), aunque no parece tener la configuración de Kerberos. Estoy usando un archivo KRB5.conf local que he señalado al reino benchmarking.rddev.local, aunque si la máquina intenta usar el DNS con su nombre de host puede obtener la respuesta incorrecta. Mi krb5.conf tiene

[libdefaults]
    default_keytab_name = /users/dev/core/richardc/server1.keytab
    default_realm = BENCHMARKING.RDDEV.LOCAL
    dns_lookup_kdc = false
    default_tkt_types = DES-CBC-MD5

[realms]
BENCHMARKING.RDDEV.LOCAL = {
    kdc = gbha-dcbench01p.benchmarking.rddev.local
    admin_server = gbha-dcbench01p.benchmarking.rddev.local
}

[domain_realm]
benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
.benchmarking.rddev.local = BENCHMARKING.RDDEV.LOCAL
mydomain.com = BENCHMARKING.RDDEV.LOCAL
.mydomain.com = BENCHMARKING.RDDEV.LOCAL

Parece que opciones como default_tkt_types han sido ineficaces.

La pregunta es: ¿cómo soluciono mi error?

Gracias - Richard

Answer 1

El problema estaba en el

ktpass -out server2.keytab 
      -princ server2/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser2@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto All
      -pType KRB5_NT_SRV_HOST
      -kvno 2

Esto hace que Windows aumente el número de versión clave. La clave resultante no es un problema para el inicio de sesión de "Kinit -K" por alguna razón, pero hace que el código del servidor GSS -API falle con la "clave de servicio inútil no disponible" en los sistemas Solaris.

El sistema de Windows fue 2008R2. Entiendo que el comportamiento de este comando ha variado entre diferentes versiones de Windows.

He probado con éxito con Desonly. Tendría que regresar al pobre departamento de TI asustado para cualquier otra prueba :-)

La solución es perder el argumento -kvno.

 ktpass -out server4.keytab 
      -princ server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL
      -mapuser ServerUser4@BENCHMARKING.RDDEV.LOCAL
      -pass ThePassword
      -crypto DES-CBC-MD5
      -pType KRB5_NT_USER_PRINCIPAL

Esto da la salida

Targeting domain controller: GBHA-DCBENCH01P.benchmarking.rddev.local
Using legacy password setting method
Successfully mapped server4/serbia.mydomain.com to Server4.
Key created.
Output keytab to server4.keytab:
Keytab version: 0x502
keysize 79 server4/serbia.mydomain.com@BENCHMARKING.RDDEV.LOCAL ptype 1
     (KRB5_NT_PRINCIPAL) vno 5 etype 0x3 (DES-CBC-MD5) keylength 8 (0xd1532a6d0f2a8631)
Account Server4 has been set for DES-only encryption.

Tenga en cuenta el "VNO 5" en la salida.

He probado con ambos valores para -pType. Ambos trabajan.

Mi código GSS está usando GSS_C_NT_HostBased_Service, pero todo lo que parece alterar es el formato requerido para ingresar el nombre.

(He cambiado la clave anterior)

Apéndice

Mi solución final usa -ptype KRB5_NT_USER_PRIVIPAL

Mi código GSS usa GSS_C_NT_USER_NAME para buscar el nombre, y especifico el nombre completo server4/serbia.mydomain.com@benchmarking.rddev.local. Descubrí que no todas las plataformas en las que estaba trabajando aceptaba el GSS_C_NT_HostBased_Service, pero todas aceptan GSS_C_NT_USER_NAME.

La persona que instala nuestra aplicación de servidor establece el nombre principal del servidor como una opción de configuración. Esta parecía la forma más confiable. La persona que configura la clave, por lo que sabe qué es, le dice a la aplicación directamente qué clave usar.