Capítulo 7 Referencia de SEAM

Este capítulo enumera muchos de los archivos, comandos y daemons que forman parte del producto SEAM. Además, proporciona información detallada sobre cómo funciona el sistema de autenticación Kerberos.

Ésta es una lista de la información de referencia de este capítulo.

• "Archivos de SEAM"

• "Comandos de SEAM"

• "Daemons de SEAM"

• "Terminología de SEAM"

• "Funcionamiento del sistema de autenticación"

• "Obtención de acceso a un servicio mediante SEAM"

• "Uso de la tabla gsscred"

Archivos de SEAM

Archivo de configuración de PAM

El archivo de configuración de PAM predeterminado que se proporciona con SEAM incluye entradas para manejar las nuevas aplicaciones adaptadas a Kerberos. El archivo nuevo contiene entradas para los módulos del servicio de autenticación, la gestión de cuentas, de sesiones y de contraseñas.

Para el módulo de autenticación, las nuevas entradas son para rlogin, login, dtlogin, krlogin, ktelnet y krsh. A continuación se muestra un ejemplo de estas entradas. Todos estos servicios utilizan la nueva biblioteca PAM, /usr/lib/security/pam_krb5.so.1, para proporcionar la autenticación Kerberos.

Las tres primeras entradas utilizan la opción try_first_pass, que solicitan la autenticación mediante la contraseña inicial del usuario. Utilizar la contraseña inicial significa que no se solicitará otra contraseña al usuario incluso si hay enumerados varios mecanismos.

Las tres entradas siguientes utilizan la opción acceptor para evitar que el módulo PAM realice el paso para obtener el cupón de obtención de cupones inicial. Para las aplicaciones de servidor adaptadas a Kerberos la aplicación ya realiza el intercambio, de forma que no es necesario hacer el paso mediante PAM. Además, se incluye una entrada other como la predeterminada para todas las entradas no especificadas que requieran autenticación.

# cat /etc/pam.conf
 . 
. 
rlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
login auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
dtlogin auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass
krlogin auth required /usr/lib/security/pam_krb5.so.1 acceptor 
ktelnet auth required /usr/lib/security/pam_krb5.so.1 acceptor 
krsh auth required /usr/lib/security/pam_krb5.so.1 acceptor 
other auth optional /usr/lib/security/pam_krb5.so.1 try_first_pass

Para la gestión de cuentas, dtlogin tiene una entrada nueva que utiliza la biblioteca de Kerberos, como se muestra a continuación. Se incluye una entrada other para proporcionar una regla predeterminada. Actualmente, la entrada other no realiza ninguna acción.

dtlogin account optional /usr/lib/security/pam_krb5.so.1 
other account optional /usr/lib/security/pam_krb5.so.1

A continuación se muestran las dos últimas entradas del archivo /etc/pam.conf. La entrada other para la gestión de sesiones destruye las credenciales de usuario. La nueva entrada other para la gestión de contraseñas selecciona la biblioteca de Kerberos.

other session optional /usr/lib/security/pam_krb5.so.1 
other password optional /usr/lib/security/pam_krb5.so.1 try_first_pass

Comandos de SEAM

Este apartado enumera algunos de los comandos incluidos en el producto SEAM.

Cambios en el comando share

Además de los comandos nuevos de SEAM, el producto SEAM incluye cambios en el comando share que se proporciona en las versiones 2.6 y 7 de Solaris. El comando share puede utilizar tres nuevas modalidades de seguridad:

krb5

Seleccionar la autenticación Kerberos

krb5i

Seleccionar la autenticación Kerberos con integridad

krb5p

Seleccionar la autenticación Kerberos con integridad y privacidad

Cuando se incluyen varias modalidades con el comando share se utilizará de forma predeterminada la primera modalidad enumerada si el cliente no especifica una. De lo contrario, se utilizará la modalidad seleccionada por el cliente.

Si falla una solicitud de montaje que utiliza una modalidad de Kerberos, se completa la modalidad mediante none como modalidad de seguridad. Esto sucede a menudo cuando no está autenticado el principal raíz del cliente NFS. Puede que la solicitud de montaje sea satisfactoria pero que el usuario no pueda acceder a los archivos hasta que se autentiquen mediante Kerberos. Todas las transacciones entre el cliente y el servidor requieren la autenticación Kerberos, incluso si el sistema de archivos no está montado mediante una modalidad de seguridad de Kerberos.

Daemons de SEAM

En la tabla siguiente se enumeran los daemons que se utilizan en el producto SEAM.

Terminología de SEAM

El apartado siguiente presenta términos que se utilizan a lo largo de la documentación de SEAM y sus definiciones. Para poder seguir muchas de las explicaciones, es esencial comprender estos términos.

Terminología específica de la autenticación

Los términos explicados a continuación son necesarios para comprender el proceso de autenticación. Los programadores y los administradores de sistemas deben estar familiarizados con estos términos.

Un cliente es el software que se ejecuta en la estación de trabajo de un usuario. El software SEAM que se ejecuta en el cliente hace muchas solicitudes durante este proceso y es importante diferencias las acciones de este software de las del usuario.

A menudo, los términos servidor y servicio se utilizan de forma intercambiable. Para aclarar las cosas, el término servidor se utiliza para definir el sistema físico en el que se está ejecutando el software de SEAM. El término servicio corresponde a una función determinada que se admite en un servidor (por ejemplo, ftp o nfs). A menudo, la documentación menciona a los servidores como parte de un servicio, pero el uso de esta definición confunde el significado de los términos; por tanto, los servidores hacen referencia al sistema físico y el servicio hace referencia al software.

El producto SEAM incluye tres tipos de claves. Una de ellas es la clave privada. que se proporciona a todos los principales de usuario y sólo la conocen el usuario del principal y el KDC. Para los principales de usuario, la clave se basa en la contraseña del usuario. Para los servidores y los servicios, la clave se conoce como clave de servicio, que sirve la misma función que la clave privada, pero la utilizan los servidores y los servicios. El tercer tipo de clave es la clave de sesión, que es una clave generada por el servicio de autenticación o el servicio de obtención de cupones. La clave de sesión se genera para proporcionar transacciones seguras entre un cliente y un servicio.

Un cupón es un paquete de información utilizado para pasar la identidad de un usuario a un servidor o un servicio de forma segura. Un cupón sólo es válido para un único cliente y un servicio determinado de un servidor específico. Contiene el nombre de principal del servicio, el nombre de principal del usuario, la dirección IP del sistema del usuario, una marca de tiempo y un valor para definir la vigencia del cupón. Los cupones se crean con una clave de sesión aleatoria para que la utilicen el cliente y el servidor. Después de que se haya creado un cupón, se puede volver a utilizar hasta que caduque.

Una credencial es un paquete de información que incluye un cupón y una clave de sesión concordante. A menudo, las credenciales están encriptadas mediante una clave privada o de servicio, dependiendo de lo que las desencriptará.

Un autenticador es otro tipo de información. Cuando se utiliza con un cupón, se puede utilizar un autenticador para autenticar a un principal de usuario. Los autenticadores incluyen el nombre de principal del usuario, la dirección IP del sistema del usuario y una marca de tiempo. A diferencia de un cupón, un autenticador sólo se puede utilizar una vez, habitualmente cuando se solicita el acceso a un servicio. Los autenticadores están encriptados mediante la clave de sesión para ese cliente y ese servidor.

Tipos de cupones

Los cupones tienen propiedades que regulan su uso, asignadas en el momento de su creación, aunque siempre es posible modificarlas con posterioridad (por ejemplo, un cupón puede cambiar de remitible a remitido.) Puede ver las propiedades de los cupones con el comando klist (véase "Visualización de los cupones").

Uno o varios de los términos siguientes pueden describir los cupones:

remitible/remitido

Los cupones remitibles se pueden enviar de un sistema a otro, lo que evita la necesidad de que un cliente se vuelva a autenticar. Por ejemplo, si el usuario david obtiene un cupón remitible mientras está en la máquina de susana, puede iniciar una sesión en su propia máquina sin tener que obtener un cupón nuevo (y tener que autenticarse de nuevo). Véase "Ejemplo: creación de un cupón" para obtener un ejemplo de un cupón remitible. Compare los cupones remitibles con los delegables, descritos a continuación.

inicial

El cupón inicial es el que se genera directamente, sin estar basado en un cupón de obtención de cupones. Algunos servicios, como las aplicaciones que cambian las contraseñas, pueden requerir que los cupones estén marcados como iniciales para asegurarse de que el cliente pueda demostrar el conocimiento de su clave secreta, ya que los cupones iniciales indican que el cliente se ha autenticado recientemente (en lugar de depender de un cupón de obtención de cupones, de mayor vigencia).

no válido

Los cupones no válidos tienen una fecha futura por lo que todavía no se pueden utilizar (véase fecha futura a continuación). Los servidores de aplicaciones los rechazarán hasta que estén validados. Para ello, el cliente debe presentarlos al KDC en una solicitud de TGS, con el indicador VALIDATE definido, después de que haya pasado su tiempo inicial.

que admite fecha futura/con fecha futura

Los cupones con fecha futura son los que no adquieren validez hasta un tiempo especificado después de su creación. Estos cupones son útiles, por ejemplo, para los trabajos por lotes que están previstos que se ejecuten por la noche, ya que si se robara el cupón no se podría utilizar hasta que se fuera a ejecutar este trabajo. Un cupón con fecha futura, se genera como no válido y permanece así hasta que: haya pasado su hora de inicio y el cliente solicite su validación por parte del KDC (véase no válido, anteriormente). Normalmente, los cupones con fecha futura son válidos hasta la hora de caducidad del cupón de obtención de cupones; no obstante, si están marcados como renovables, normalmente se define su vigencia para que sea igual a la duración de la vida completa del cupón de obtención de cupones. Véase renovable a continuación.

delegable/delegado

A veces, puede ser necesario que un principal permita que un servicio lleve a cabo una operación en su nombre (un ejemplo puede ser cuando un principal solicita que un servicio ejecute un trabajo de impresión en un tercer sistema). El servicio debe poder asumir la identidad del cliente, pero sólo es necesario para esa única operación. En ese caso, se dice que el servidor está actuando como delegado para el cliente. Cuando se crea el cupón, debe especificarse el nombre de principal del delegado.

Los cupones delegables son similares a los remitibles, exceptuando en que sólo son válidos para un único servicio, mientras que los remitibles conceden al servicio el uso completo de la identidad del cliente. Por tanto, puede pensarse que un cupón remitible es un tipo de super-delegado.

renovable

Como tener cupones de vigencia larga es un riesgo de seguridad, pueden designarse los cupones como renovables. Éstos pueden caducar en dos tiempos diferentes: el momento en el que caduca el ejemplar actual del cupón y la vigencia máxima para cualquier cupón. Si un cliente desea seguir utilizando un cupón, lo renueva antes de que se produzca la primera caducidad. por ejemplo, un cupón puede ser válido durante una hora y todos los cupones tienen una vigencia máxima de diez horas. Si el cliente que posee el cupón desea mantenerlo durante más de una hora, debe renovarlo durante esa hora. Cuando un cupón llega a su vigencia máxima (10 horas), caduca automáticamente y no es posible renovarlo.

Para obtener información sobre cómo ver los cupones para conocer sus atributos, véase "Visualización de los cupones".

Vigencia del cupón

Cada vez que un principal obtiene un cupón, incluidos los cupones de obtención de cupones, se define su vigencia como el más pequeño de los valores de vigencia siguientes:

• El valor de vigencia especificado por la opción -l de kinit, si se utiliza kinit para obtener el cupón

• El valor de vigencia máximo (max_life) especificado en el archivo kdc.conf

• El valor de vigencia máximo especificado en la base de datos de Kerberos para el principal de servicio que proporciona el cupón (en el caso de kinit, el principal de servicio es krbtgt/ámbito)

• El valor de vigencia máximo especificado en la base de datos de Kerberos para el principal de usuario que solicita el cupón.

Figura 7-1 muestra cómo se determina la vigencia de un TGT e ilustra de dónde provienen los cuatro valores de vigencia. Aunque Figura 7-1 muestra cómo se determina la vigencia de un TGT, básicamente sucede lo mismo cuando cualquier principal obtiene un cupón. Las únicas diferencias son que kinit no proporciona un valor de vigencia y que el principal de servicio que proporciona el cupón proporciona un valor de vigencia máximo (en lugar del principal krbtgt/ámbito ).

Figura 7-1 Determinación de la vigencia de un TGT

La vigencia de los cupones renovables también está determinada por el mínimo de cuatro valores, pero se utilizan en su lugar los valores de vigencia renovables:

• El valor de vigencia renovable especificado por la opción -r de kinit, si se utiliza kinit para obtener o renovar el cupón

• El valor de vigencia renovable máximo (max_renewable_life) especificado en el archivo kdc.conf

• El valor de vigencia renovable máximo especificado en la base de datos de Kerberos para el principal de servicio que proporciona el cupón (en el caso de kinit, el principal de servicio es krbtgt/ámbito)

• El valor de vigencia renovable máximo especificado en la base de datos de Kerberos para el principal de usuario que solicita el cupón

Nombres de principal

Un nombre de principal identifica todos los cupones. El nombre de principal puede identificar a un usuario o a un servicio. Éstos son ejemplos de varios nombres de principal.

Funcionamiento del sistema de autenticación

Las aplicaciones le permiten iniciar una sesión en un sistema remoto si puede proporcionar un cupón que pruebe su identidad y una clave de sesión concordante, la cual contiene información específica para el usuario y el servicio al que se accede. El KDC crea un cupón y una clave de sesión para todos los usuarios cuando inician su sesión; ambos forman una credencial. Al utilizar varios servicios de conexión en red, un usuario puede acumular muchas credenciales. El usuario necesita tener una credencial para cada servicio que se ejecute en un servidor determinado. Por ejemplo, para el acceso al servicio ftp de un servidor con nombre puebla se necesita una credencial, y para el acceso al servicio ftp de otro servidor se necesita su propia credencial.

El proceso de creación y almacenamiento de las credenciales es transparente. Las credenciales las crea el KDC que envía la credencial al solicitante. Cuando se recibe, la credencial se almacena en una antememoria de credenciales.

Obtención de acceso a un servicio mediante SEAM

Para que un usuario pueda acceder a un servicio específico de un servidor concreto, debe obtener dos cosas. La primera es una credencial para el servicio de obtención de cupones (conocido como TGT). Cuando éste haya desencriptado esta credencial, crea una segunda para el servidor al que el usuario solicita el acceso. A continuación, puede utilizarse esta segunda credencial para solicitar acceso al servicio del servidor. Después de que éste haya desencriptado satisfactoriamente la segunda credencial, se concederá el acceso al usuario. Este proceso se describe con más detalle más adelante.

Obtención de una credencial para el servicio de obtención de cupones

1. Para iniciar el proceso de autenticación, el cliente envía al servidor de autenticación para un principal de usuario específico una solicitud en la que no se incluye ninguna información protegida, de forma que no es necesario utilizar la encriptación.

2. Cuando el servicio de autenticación recibe la solicitud comprueba el nombre de principal del usuario en la base de datos del KDC. Si concuerda un principal, el servicio de autenticación obtiene su clave privada. A continuación, genera una clave de sesión para que la utilice el cliente y el servicio de obtención de cupones (llamémosla clave de sesión 1) y un cupón para el servicio de obtención de cupones (cupón 1). Este cupón también se conoce como el cupón de obtención de cupones (TGT). Tanto la clave de sesión como el cupón se encriptan mediante la clave privada del usuario y se devuelve la información al cliente.

3. El cliente utiliza esta información para desencriptar la clave de sesión 1 y el cupón 1 mediante la clave privada del principal de usuario. Como la clave privada únicamente debería conocerla el usuario y la base de datos del KDC, la información del paquete debe ser segura. El cliente almacena la información en la antememoria de credenciales.

Normalmente, durante este proceso se solicita una contraseña al usuario. Si ésta coincide con la que se utilizó para crear la clave privada almacenada en la base de datos del KDC, el cliente puede desencriptar satisfactoriamente la información que envió el servicio de autenticación. El cliente tendrá entonces una credencial para utilizar con el servicio de obtención de cupones y estará listo para solicitar una credencial para un servidor.

Figura 7-2 Obtención de una credencial para el servicio de obtención de cupones

Obtención de una credencial para un servidor

1. Para solicitar el acceso a un servidor específico, primero el cliente debe haber obtenido una credencial para este servidor en el servicio de autenticación (véase "Obtención de una credencial para el servicio de obtención de cupones"); a continuación envía una solicitud al servicio de obtención de cupones, que incluye el nombre del principal de servicio, el cupón 1 y un autenticador encriptado con la clave de sesión 1. El cupón 1 fue encriptado originariamente por el servicio de autenticación mediante la clave de servicio del servicio de obtención de cupones.

2. Como el servicio de obtención de cupones conoce la clave de servicio, es posible desencriptar el cupón 1. La información incluida en éste incorpora la clave de sesión 1, para que el servicio de obtención de cupones pueda desencriptar el autenticador. En este punto, se autentica el principal de usuario con el servicio de obtención de cupones.

3. Si la autenticación es satisfactoria, el servicio de obtención de cupones genera una clave de sesión para el principal de usuario y el servidor (clave de sesión 2) y un cupón para el servidor (cupón 2). A continuación, se encriptan la clave de sesión 2 y el cupón 2 mediante la clave de sesión 1. Como ésta sólo la conocen el cliente y el servicio de obtención de cupones, esta información está protegida y se puede enviar de forma segura a través de la red.

4. Cuando el cliente recibe este paquete de información, desencripta la información mediante la clave de sesión 1, que había almacenado en la antememoria de credenciales. El cliente ha obtenido una credencial para utilizarla con el servidor. Ahora, está listo para solicitar el acceso a un servicio determinado del servidor.

Figura 7-3 Obtención de una credencial para un servidor

Obtención del acceso a un servicio específico

1. Para solicitar el acceso a un servicio específico, primero el cliente debe haber obtenido una credencial para el servicio de obtención de cupones desde el servidor de autenticación y una credencial desde el servicio de obtención de cupones (véase "Obtención de una credencial para el servicio de obtención de cupones" y "Obtención de una credencial para un servidor"). El cliente puede enviar una solicitud al servidor que incluye el cupón 2 y otro autenticador, que se encripta mediante la clave de sesión 2.

2. El cupón 2 lo encriptó el servicio de obtención de cupones con la clave de servicio del servicio. Como el principal de servicio conoce la clave, el servicio puede desencriptar el cupón 2 y obtener la clave de sesión 2. A continuación, puede utilizarse ésta para desencriptar el autenticador. Si éste se desencripta satisfactoriamente, se proporciona acceso al servicio al cliente.

Figura 7-4 Obtención del acceso a un servicio específico

Uso de la tabla gsscred

La tabla gsscred la utiliza un servidor NFS cuando el servidor intenta identificar a un usuario de SEAM. Los servicios de NFS utilizan los ID de UNIX para identificar a los usuarios, pero este ID no forman parte de los principales o credenciales de usuario. La tabla gsscred proporciona una reasignación de los UID de UNIX (del archivo de contraseñas) a los nombres de principal. La tabla debe crearse y administrarse después de llenar la base de datos del KDC.

Cuando se recibe una solicitud de un cliente, los servicios de NFS intentan reasignar el nombre del principal a un ID de UNIX. Si falla el mecanismo de reasignación, se consulta la tabla gsscred. Con el mecanismo kerberos_v5 los principales root/nombre_sistema se reasignan automáticamente al UID 0 y no se consulta la tabla gsscred. Esto significa que no es posible realizar reasignaciones especiales de root mediante la tabla gsscred.

¿Qué mecanismo se debe seleccionar para la tabla gsscred ?

La elección del mecanismo correcto para la tabla gsscred depende de varios factores.

• ¿Le interesa mejorar el tiempo de consulta?

• ¿Le interesa mejorar la seguridad del acceso a los datos?

• ¿Necesita crear el archivo rápidamente?

Sigue una lista de todos los mecanismos de componente trasero que se pueden seleccionar, junto con una descripción de sus ventajas.

files

La tabla gsscred se almacena en un sistema de archivos. Los sistemas de archivos locales no compartidos proporcionan el componente trasero más seguro, ya que después de que se cree la tabla no se realizará ninguna transmisión a través de la red. Esta versión del archivo es la que se crea más rápido.

xfn_files

La tabla gsscred se almacena en el sistema de archivos /var/fn. Este sistema de archivos puede estar compartido o no estarlo. Todos los archivos xfn tardan mucho tiempo en crearse.

xfn_nis

La tabla gsscred se almacena en el espacio de nombres de NIS. Las consultas de este sistema de archivos no son seguras. Todos los archivos xfn tardan mucho tiempo en crearse.

xfn_nisplus

La tabla gsscred está almacenada en el espacio de nombres de NIS+. Las consultas de este sistema de archivos no son seguras. Todos los archivos xfn tardan mucho tiempo en crearse.

xfn

La tabla gsscred se almacena en el sistema predeterminado para xfn. Todos los archivos xfn tardan mucho tiempo en crearse.

La consulta inicial puede ser lenta para el mecanismo de componente trasero files. Para el resto de mecanismos, la consulta inicial puede ser más rápida mediante un servicio de nombres. Para todos los mecanismos, después de almacenar los datos en la antememoria el tiempo de recuperación debería ser aproximadamente el mismo.