Cómo funciona el servicio Kerberos

A continuación, se ofrece una descripción general del sistema de autenticación Kerberos. Para obtener una descripción más detallada, consulte Cómo funciona el sistema de autenticación Kerberos.

Desde el punto de vista del usuario, una vez que se inició la sesión Kerberos, el servicio Kerberos queda invisible la mayor parte del tiempo. Los comandos, como ssh o ftp, funcionan de manera similar. Normalmente, para inicializar una sesión Kerberos sólo se debe iniciar sesión y proporcionar una contraseña de Kerberos.

El sistema Kerberos se basa en el concepto de tickets. Un ticket es un conjunto de información electrónica que identifica a un usuario o servicio, como el servicio NFS. Así como su licencia de conducir lo identifica e indica qué privilegios tiene para conducir un automóvil, el ticket lo identifica e indica qué privilegios tiene para acceder a la red. Cuando realiza una transacción que se basa en Kerberos (por ejemplo, si inicia sesión en otro equipo de manera remota), envía de manera transparente una solicitud de un ticket a un Centro de distribución de claves (KDC). El KDC accede a una base de datos para autenticar su identidad y devuelve un ticket que le concede permiso para acceder a otro equipo. La expresión "de manera transparente" implica que no necesita solicitar un ticket de manera explícita. La solicitud forma parte de la actividad del comando rlogin. Debido a que sólo los clientes que están autenticados pueden obtener un ticket para un servicio específico, los demás clientes no pueden usar rlogin con una identidad asumida.

Los tickets tienen ciertos atributos asociados a ellos. Por ejemplo, un ticket puede ser reenviable, lo que significa que se puede utilizar en otro equipo sin que se realice un nuevo proceso de autenticación. Asimismo, un ticket puede ser posfechado, que significa que no adquiere validez hasta un momento especificado. El modo de uso de los tickets, por ejemplo, para especificar qué usuarios pueden obtener los distintos tipos de tickets, se establece mediante políticas. Las políticas se determinan durante la instalación o administración del servicio Kerberos.

Las siguientes secciones explican más detalladamente el proceso de autenticación Kerberos.

Autenticación inicial: el ticket de otorgamiento de tickets

La autenticación de Kerberos tiene dos fases: una autenticación inicial que permite que se lleven a cabo todas las autenticaciones posteriores y las autenticaciones posteriores en sí mismas.

La siguiente figura muestra cómo se lleva a cabo la autenticación inicial.

Figura 19-1 Autenticación inicial para una sesión Kerberos

1. Un cliente (un usuario o un servicio como NFS) comienza una sesión Kerberos mediante la solicitud de un ticket de otorgamiento de tickets (TGT) desde el Centro de distribución de claves (KDC). Esta solicitud se suele llevar a cabo automáticamente en el inicio de sesión.

   Se necesita un ticket de otorgamiento de tickets para obtener otros tickets de servicios específicos. El ticket de otorgamiento de tickets funciona de manera similar a un pasaporte. Como el pasaporte, el ticket de otorgamiento de tickets lo identifica y le permite obtener muchas “visas” (tickets), que en este caso no son para entrar en países extranjeros sino en equipos remotos o servicios de red. Como los pasaportes y las visas, el ticket de otorgamiento de tickets y otros tickets diversos tienen una duración limitada. La diferencia radica en que los comandos “Kerberizados” detectan que tiene un pasaporte y entonces obtienen las visas para usted. No es necesario que se encargue de efectuar las transacciones.

   También puede establecerse un analogía entre el ticket de otorgamiento de tickets y un pase de esquí por tres días que sirve para acceder a cuatro centros de esquí diferentes. Puede exhibir el pase en cualquiera de los centros al que quiera acceder y así obtener un ticket de ascenso para dicho centro, siempre que el pase no esté vencido. Una vez que tenga el ticket de ascenso, puede esquiar cuanto quiera en el centro que eligió. Si el día siguiente quiere ir a otro centro, vuelve a exhibir el pase para conseguir otro ticket de ascenso para ese nuevo centro. La diferencia radica en que los comandos basados en Kerberos detectan que tiene un pase de esquí para el fin de semana y entonces obtienen un ticket de ascenso para usted. No es necesario que se encargue de efectuar las transacciones.

2. El KDC crea un ticket de otorgamiento de tickets y lo envía de vuelta al cliente en formato cifrado. El cliente descifra el ticket de otorgamiento de tickets con la contraseña del cliente.

3. Con un ticket de otorgamiento de tickets válido, el cliente puede solicitar tickets para todo tipo de operaciones de red, como rlogin o telnet, durante todo el período de validez del ticket de otorgamiento de tickets. Por lo general, este ticket dura algunas horas. Cada vez que el cliente realiza una operación de red única, solicita al KDC un ticket para esa operación.

Autenticaciones Kerberos posteriores

Una vez que el cliente ha recibido la autenticación inicial, cada autenticación posterior sigue el patrón que se muestra en la siguiente figura.

Figura 19-2 Obtención de acceso a un servicio con la autenticación Kerberos

1. El cliente solicita al KDC un ticket para un servicio en particular; por ejemplo, para iniciar sesión en otro equipo de manera remota. Para ello, envía al KDC su ticket de otorgamiento de tickets como prueba de identidad.

2. El KDC envía el ticket por el servicio específico al cliente.

   Por ejemplo, suponga que el usuario joe quiere acceder a un sistema de archivos NFS que se ha compartido con la autenticación krb5 requerida. Como ya se encuentra autenticado (es decir, ya tiene un ticket de otorgamiento de tickets), cuando intenta acceder a los archivos, el sistema de cliente NFS obtiene un ticket del KDC de manera automática y transparente para el servicio NFS.

   Por ejemplo, suponga que el usuario joe utiliza rlogin en el servidor boston. Como ya se encuentra autenticado, (es decir, ya tiene un ticket de otorgamiento de tickets), obtiene un ticket de manera automática y transparente mediante el comando rlogin. Este ticket le permite iniciar sesión de manera remota en boston tantas veces como quiera hasta que el ticket caduque. Si joe inicia sesión de manera remota en el equipo denver, obtiene otro ticket, como en el paso 1.

3. El cliente envía el ticket al servidor.

   Cuando se usa el servicio NFS, el cliente NFS envía el ticket de manera automática y transparente al servidor NFS para el servicio NFS.

4. El servidor permite el acceso de clientes.

Según estos pasos, parece que el servidor nunca se comunica con el KDC. Sin embargo, el servidor sí se comunica. Se registra con el KDC, como lo hace el primer cliente. A fin de simplificar el proceso, esa parte se excluye.

Aplicaciones remotas de Kerberos

Los comandos basados en Kerberos (o “Kerberizados”) que un usuario como joe puede utilizar son los siguientes:

• ftp

• rcp, rlogin, rsh

• ssh, scp, sftp

• telnet

Estas aplicaciones son iguales a las aplicaciones de Solaris que tienen el mismo nombre. Sin embargo, se han ampliado a fin de utilizar los principales de Kerberos para autenticar las transacciones y proporcionar así una seguridad basada en Kerberos. Consulte Principales de Kerberos para obtener información sobre los principales.

Estos comandos se analizan detalladamente en Comandos de usuario de Kerberos.

Principales de Kerberos

Un cliente en el servicio Kerberos se identifica con su principal. Un principal es una identidad única a la que el KDC puede asignar tickets. Un principal puede ser un usuario, como joe, o un servicio, como nfs o telnet.

Por convención, el nombre de principal consta de tres componentes: el nombre primario, la instancia y el dominio. Un principal de Kerberos típico sería, por ejemplo, joe/admin@ENG.EXAMPLE.COM. En este ejemplo:

• joe es el nombre primario. El nombre primario puede ser un nombre de usuario, como se muestra aquí, o un servicio, como nfs. El nombre primario también puede ser la palabra host, lo cual significa que el principal es un principal de servicio que está configurado para proporcionar distintos servicios de red, ftp, scp, ssh, etc.

• admin es la instancia. La instancia es opcional en el caso de los principales de usuario, pero es necesaria para los principales de servicio. Por ejemplo, si el usuario joe a veces actúa como administrador del sistema, puede utilizar joe/admin para distinguirse de su identidad de usuario habitual. Del mismo modo, si joe tiene cuentas en dos hosts diferentes, puede utilizar dos nombres de principal con instancias diferentes, por ejemplo, joe/denver.example.com y joe/boston.example.com. Tenga en cuenta que el servicio Kerberos trata joe y joe/admin como dos principales completamente diferentes.

  En el caso de un principal de servicio, la instancia es el nombre de host completo. Un ejemplo de una instancia así es bigmachine.eng.example.com. La combinación nombre primario/instancia para este ejemplo podría ser ftp/bigmachine.eng.example.com o host/bigmachine.eng.example.com.

• ENG.EXAMPLE.COM es el dominio de Kerberos. En Dominios de Kerberos, se analizan los dominios.

Todos los nombres de principal que aparecen a continuación son válidos:

• joe

• joe/admin

• joe/admin@ENG.EXAMPLE.COM

• nfs/host.eng.example.com@ENG.EXAMPLE.COM

• host/eng.example.com@ENG.EXAMPLE.COM

Dominios de Kerberos

Un dominio es una red lógica, similar a un dominio, que define un grupo de sistemas con el mismo KDC principal. La Figura 19-3 muestra el modo en que los dominios pueden relacionarse entre sí. Algunos dominios son jerárquicos, lo que implica que un dominio es un superconjunto de los otros dominios. De lo contrario, los dominios son no jerárquicos (o “directos”), y la asignación entre los dos dominios debe definirse. Una característica del servicio Kerberos es que permite la autenticación entre dominios. Cada dominio sólo necesita una entrada de principal para el otro dominio en su KDC. Esta función de Kerberos se denomina autenticación entre dominios.

Figura 19-3 Dominios de Kerberos

Servidores Kerberos

Cada dominio debe incluir un servidor que mantenga la copia maestra de la base de datos del principal. Este servidor se llama servidor KDC maestro. Además, cada dominio debe contener por lo menos un servidor KDC esclavo, que contenga las copias duplicadas de la base de datos del principal. Tanto el servidor KDC maestro como el servidor KDC esclavo crean tickets que se utilizan para establecer la autenticación.

El dominio también puede incluir un servidor de aplicaciones Kerberos. Este servidor proporciona acceso a los servicios Kerberizados (como ftp, telnet, ssh y NFS). Si tiene instalado SEAM 1.0 o 1.0.1, puede que el dominio incluya un servidor de aplicaciones de red Kerberos, pero este software no viene incluido con estas versiones.

La siguiente figura muestra lo que un dominio hipotético puede llegar a contener.

Figura 19-4 Un dominio de Kerberos típico