2.6.9. Configurando la autenticación cruzada de reinados

La autenticación cruzada de reinado es el término usado para describir situaciones en que los clientes (normalmente usuarios) de un reinado utilizan Kerberos para autenticarse con servicios (típicamente procesos servidor corriendo en un sistema servidor particular) que pertenecen a otro reinado distinto al propio.

Para el caso más simple, para que un cliente de un reinado con nombre A.EJEMPLO.COM acceda a un servicio en el reinado B.EJEMPLO.COM, ambos reinados deben compartir una clave para el principal con nombre krbtgt/B.EJEMPLO.COM@A.EJEMPLO.COM, y ambas claves deben tener el mismo número de versión de clave asociadas a ellas.

Para hacer esto, debe seleccionar una contraseña o frase de acceso muy fuerte y crear una entrada para el principal de ambos reinados usando kadmin.

# kadmin -r A.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit # kadmin -r B.EXAMPLE.COM kadmin: add_principal krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM Enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Re-enter password for principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM": Principal "krbtgt/B.EXAMPLE.COM@A.EXAMPLE.COM" created. quit

Use el comando get_principal para verificar que ambas entradas tienen un número de versión de claves (valores kvno) y tipos de encriptados coincidentes.

El volcado de la base de datos no lo hace

Los administradores conscientes de los procesos de seguridad, podrían intentar utilizar la opción -randkey del comando add_principal, para asignar una clave aleatoria en lugar de una contraseña, descargar la nueva entrada desde una base de datos del primer reinado, e importarla al segundo. Esto no va a funcionar a menos que las claves maestras de la base de datos del reinado sean idénticas, ya que las claves contenidas en una base de datos descargada, son encriptadas utilizando la clave maestra.

Los clientes en el reinado A.EJEMPLO.COM son capaces ahora de autenticarse en los servicios del reinado B.EJEMPLO.COM. Dicho de otra manera, el reinado B.EJEMPLO.COM ahora confía en el reinado A.EJEMPLO.COM, o, más sencillo aún, ahora B.EJEMPLO.COM confía en A.EJEMPLO.COM.

Esto nos lleva a un punto importante: la confianza generada entre los reinados es, por defecto, unidireccional. El KDC para el reinado B.EJEMPLO.COM podría confiar en clientes del reinado A.EJEMPLO.COM para autenticarse en sus servicios, pero este hecho no significa que el reinado A.EJEMPLO.COM confíe en los clientes del reinado B.EJEMPLO.COM cuando estos intenten autenticarse en sus servicios. Para establecer una confianza bidireccional entre dos reinados, ambos van a necesitar compartir claves para el servicio krbtgt/A.EJEMPLO.COM@B.EJEMPLO.COM (tome nota de la forma invertida de acuerdo a los dos reinados comparados en el ejemplo anterior).

Si las relaciones de confianza directa fueran la única manera de hacer que dos reinados confíen entre sí, sería bastante complicado configurar redes con gran cantidad de ellos. Afortunadamente, la confianza generada entre reinados es transitiva. Si los clientes del reinado A.EJEMPLO.COM pueden autenticarse en servicios del reinado B.EJEMPLO.COM, y los clientes del reinado B.EJEMPLO.COM pueden autenticarse en servicios del reinado C.EJEMPLO.COM, entonces los clientes de A.EJEMPLO.COM pueden también autenticarse en los servicios del reinado C.EJEMPLO.COM, aún cuando C.EJEMPLO.COM no confíe directamente en los clientes del reinado A.EJEMPLO.COM. Esto significa que lo ideal para poder reducir la cantidad de esfuerzo al configurar una red con múltiples reinados, que necesiten confiar unos en otros, será realizar las elecciones correctas a la hora de definir las relaciones de confianza entre ellos.

Ahora se enfrenta a problemas más convencionales: el sistema cliente debe ser configurado para que pueda deducir apropiadamente el reinado al que un servicio particular pertenece, y debe poder determinar cómo obtener las credenciales en ese reinado.

Vayamos en orden: el nombre del principal para un servicio provisto desde un sistema servidor específico en un reinado dado normalmente es parecido a:

service/server.ejemplo.com@EJEMPLO.COM

En el ejemplo siguiente, el servicio es generalmente, o bien el nombre del protocolo en uso (otros valores comunes pueden ser ldap, imap, cvs, y HTTP), o bien equipo. server.ejemplo.com es el nombre del dominio del sistema completamente calificado que ejecuta el servicio, y EJEMPLO.COM es el nombre del reinado.

Para deducir el dominio al que el servicio pertenece, los clientes por lo general consultan el DNS o la sección domain_realm del archivo /etc/krb5.conf para mapear ya sea el nombre del equipo (server.ejemplo.com) o el nombre del dominio DNS (.ejemplo.com) hacia el nombre del reinado (EJEMPLO.COM).

Habiendo determinado a qué reinado pertenece el servicio, un cliente tiene que determinar luego el conjunto de reinados que debe contactar y en qué orden debe hacerlo, para obtener las credenciales a usar en la autenticación con el servicio.

Esto se puede hacer de una o dos formas.

El método establecido por defecto, que no requiere una configuración explícita, es dar a los reinados nombres dentro de una jerarquía compartida. Como ejemplo, suponer los reinados llamados A.EJEMPLO.COM, B.EJEMPLO.COM, and EJEMPLO.COM. Cuando un cliente del reinado A.EJEMPLO.COM intente autenticarse en un servicio del reinado B.EJEMPLO.COM, por defecto, lo primero que hará será intentar obtener credenciales para el reinado EJEMPLO.COM, y luego utilizar esas credenciales para obtener unas nuevas para poder utilizarlas en el reinado B.EJEMPLO.COM.

En este escenario el cliente trata el nombre del dominio como uno podría tratar un nombre DNS. Reiteradamente va quitando los componentes de su propio nombre de reinado para generar los nombres del reinado que se encuentre jerárquicamente "por encima del suyo", hasta que llegue a un punto que incluso sea jerárquicamente superior al reinado del servicio. En ese punto empieza a analizar los componentes del nombre del servicio del reinado, hasta que obtiene el servicio del reinado. Cada reinado que se encuentre involucrado en el proceso, es considerado otro "salto".

Por ejemplo, el uso de credenciales en A.EJEMPLO.COM, autenticando a un servicio en B.EJEMPLO.COMA.EJEMPLO.COM → EJEMPLO.COM → B.EJEMPLO.COM

A.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/EJEMPLO.COM@A.EJEMPLO.COM
EJEMPLO.COM y B.EJEMPLO.COM comparten una clave krbtgt/B.EJEMPLO.COM@EJEMPLO.COM

Otro ejemplo, usando credenciales en SITIO1.VENTAS.EJEMPLO.COM, para autenticar a un servicio en CUALQUIERLUGAR.EJEMPLO.COMSITIO1.VENTAS.EJEMPLO.COM → VENTAS.EJEMPLO.COM → EJEMPLO.COM → CUALQUIERLUGAR.EJEMPLO.COM

SITIO1.VENTAS.EJEMPLO.COM y VENTAS.EJEMPLO.COM comparten una clave para krbtgt/VENTAS.EJEMPLO.COM@SITIO1.VENTAS.EJEMPLO.COM
VENTAS.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/EJEMPLO.COM@VENTAS.EJEMPLO.COM
EJEMPLO.COM y CUALQUIERLUGAR.EJEMPO.COM comparten una clave para krbtgt/CUALQUIERLUGAR.EJEMPLO.COM@EJEMPLO.COM

Otro ejemplo, esta vez utilizando nombres de reinados que no compartan sufijos comunes (DEVEL.EJEMPLO.COM y PROD.EJEMPLO.ORG DEVEL.EJEMPLO.COM → EJEMPLO.COM → COM → ORG → EJEMPLO.ORG → PROD.EJEMPLO.ORG

DEVEL.EJEMPLO.COM y EJEMPLO.COM comparten una clave para krbtgt/EJEMPLO.COM@DEVEL.EJEMPLO.COM
EJEMPLO.COM y COM comparten una clave para krbtgt/COM@EJEMPLO.COM
COM y ORG comparten una clave para krbtgt/ORG@COM
ORG y EJEMPLO.ORG comparten una clave para krbtgt/EJEMPLO.ORG@ORG
EJEMPLO.ORG y PROD.EJEMPLO.ORG comparten una clave para krbtgt/PROD.EJEMPLO.ORG@EJEMPLO.ORG

El método más complicado, pero que al mismo tiempo es el más flexible, reside en configurar la sección capaths del archivo /etc/krb5.conf, de modo que los clientes que tengan credenciales para un reinado específico, deberán buscar qué reinado es el que le sigue en la cadena y que, eventualmente, será quien permita su autenticación con los servidores.

El formato de la sección capaths es relativamente sencillo: cada entrada en la sección tiene el mismo nombre que el reinado en el que pudiera existir el cliente. Dentro de cada subsección, el conjunto de los reinados intermedios desde donde el cliente tiene que obtener las credenciales, se muestran como los valores de la llave que se corresponde con el reinado en el que puede residir el servicio. Si no existen reinados intermedios, será utilizado el valor ".".

Aquí hay un ejemplo:

[capaths]
                A.EJEMPLO.COM = {
                B.EJEMPLO.COM = .
                C.EJEMPLO.COM = B.EJEMPLO.COM
                D.EJEMPLO.COM = B.EJEMPLO.COM
                D.EJEMPLO.COM = C.EJEMPLO.COM
                }

En este ejemplo, los clientes en el reinado A.EJEMPLO.COM pueden obtener credenciales de reinados cruzados para B.EJEMPLO.COM directamente del KDC de A.EJEMPLO.COM.

Si esos clientes desean contactar un servicio en el reinado C.EJEMPLO.COM, necesitarán obtener primero credenciales necesarias del reinado B.EJEMPLO.COM (esto requiere que krbtgt/B.EJEMPLO.COM@A.EJEMPLO.COM exista), y entonces utilizar esas credenciales para obtener otras para ser utilizadas en el reinado C.EJEMPLO.COM (utilizando krbtgt/C.EJEMPLO.COM@B.EJEMPLO.COM).

Si esos clientes desean contactar un servicio en el reinado D.EJEMPLO.COM, necesitarán obtener primero las credenciales necesarias del reinado B.EJEMPLO.COM, y luego las credenciales del reinado C.EJEMPLO.COM, antes de obtener, finalmente, las credenciales necesarias para utilizar con el reinado D.EJEMPLO.COM.

Nota

Sin una entrada que indique lo contrario, Kerberos asume que las relaciones de confianza de reinados cruzados forman una jerarquía.

Los clientes en el reinado A.EJEMPLO.COM pueden obtener credenciales cruzadas del reinado B.EJEMPLO.COM directamente. Sin el "." indicando esto, el cliente intentaría sino usar un camino jerárquico, en este caso:

A.EXAMPLE.COM → EXAMPLE.COM → B.EXAMPLE.COM