Tipos de tickets
Los tickets tienen propiedades que establecen el modo en que pueden utilizarse. Estas propiedades se asignan al ticket en el momento que éste se crea, pero pueden modificarse más adelante. Por ejemplo, un ticket puede cambiar de forwardable a forwarded. Puede ver las propiedades del ticket con el comando klist. Consulte Visualización de tickets de Kerberos.
Los tickets pueden describirse con uno o más de los siguientes términos:
- Reenviable/reenviado
Un ticket reenviable puede enviarse de un host a otro, sin la necesidad de que un cliente vuelva a autenticarse. Por ejemplo, si el usuario david obtiene un ticket reenviable mientras está en el equipo de jennifer, david puede iniciar sesión en su propio equipo sin tener que obtener un ticket nuevo (y, por lo tanto, autenticarse nuevamente). Consulte el Example 6–1 para ver un ejemplo de un ticket reenviable.
- Inicial
Un ticket inicial es un ticket que se emite directamente en lugar de emitirse por medio de un ticket de otorgamiento de tickets. Algunos servicios, como las aplicaciones que cambian las contraseñas, posiblemente requieran que los tickets se marquen como “iniciales” para garantizar que el cliente pueda demostrar que conoce su clave secreta. El ticket inicial indica que, recientemente, el cliente se ha autenticado por sí mismo, en lugar de recurrir al ticket de otorgamiento de tickets, que puede ser anterior.
- No válido
Un ticket no válido es un ticket posfechado que todavía no se puede usar. Un servidor de aplicaciones rechaza un ticket no válido hasta que se valide. Para validar un ticket, el cliente debe presentarlo al KDC en una solicitud de ticket de otorgamiento de tickets, con el indicador –VALIDATE definido, después de que haya pasado la hora de inicio.
- Posfechable/posfechado
Un ticket posfechado no es válido hasta que transcurra un tiempo especificado tras su creación. Un ticket de este tipo es útil, por ejemplo, para los trabajos por lotes que deben ejecutarse tarde por la noche, ya que si el ticket es robado, no se puede utilizar hasta que se ejecute el trabajo por lotes. Los tickets posfechados se emiten como no válidos y siguen teniendo ese estado hasta que haya pasado su hora de inicio, y el cliente solicite la validación por parte del KDC. Generalmente, un ticket posfechado es válido hasta la hora de vencimiento del ticket de otorgamiento de tickets. Sin embargo, si el ticket se marca como renovable, su duración suele definirse para que coincida con la duración total del ticket de otorgamiento de tickets.
- Que admite proxy/proxy
A veces, es posible que necesite permitir que un principal de servicio realice una operación en su nombre. El nombre de principal del proxy debe especificarse cuando se crea el ticket. Oracle Solaris no admite proxy ni con tickets proxy.
Un ticket que admite proxy es similar al ticket reenviable, excepto en que sólo es válido para un único servicio. Un ticket reenviable otorga al servicio el uso total de la identidad del cliente. Por lo tanto, el ticket reenviable se puede considerar como una especie de superproxy.
- Renovable
Debido a que los tickets con duraciones muy largas constituyen un riesgo de seguridad, los tickets se pueden designar como renovables. Un ticket renovable tiene dos horas de vencimiento: la hora de vencimiento de la instancia actual del ticket y la duración máxima de cualquier ticket, que es de una semana. Si un cliente desea seguir utilizando un ticket, debe renovarlo antes del primer vencimiento. Por ejemplo, suponga que un ticket puede ser válido por una hora, pero todos los tickets tienen una duración máxima de 10 h. Si el cliente que tiene el ticket desea conservarlo durante más de una hora, debe renovarlo dentro de esa hora. Cuando un ticket alcanza la duración máxima (10 h), vence automáticamente y no se puede renovar.
Para obtener más información sobre cómo ver los atributos de tickets, consulte Visualización de tickets de Kerberos.
Duración de los tickets
El valor de duración que establece la opción –l de kinit, si se usa kinit para obtener el ticket. De manera predeterminada, kinit usa el valor de duración máxima.
El valor de duración máxima (max_life) que se encuentra especificado en el archivo kdc.conf.
El valor de duración máxima que se especifica en la base de datos de Kerberos para el principal de servicio que proporciona el ticket. En el caso de kinit, el principal de servicio es krbtgt/realm.
El valor de duración máxima que se especifica en la base de datos de Kerberos para el principal de usuario que solicita el ticket.
Cuando un principal obtenga un ticket, incluido un ticket de otorgamiento de tickets (TGT), la duración del ticket se establece como el menor de los siguientes valores de duración:
La figura siguiente muestra cómo se determina la duración de un TGT y dónde se originan los cuatro valores de duración. Cuando algún principal obtiene un ticket, la duración del ticket se determina de forma similar. Las únicas dos diferencias radican en que kinit no proporciona un valor de duración, y el principal de servicio que otorga el ticket proporciona un valor de duración máxima en lugar del principal krbtgt/realm.
Figura 7-1 Cómo se determina la duración de un TGT
El valor de duración renovable que especifica la opción –r de kinit, si kinit se utiliza para obtener o renovar el ticket.
El valor de duración máxima renovable (max_renewable_life) que se especifica en el archivo kdc.conf.
El valor de duración máxima renovable que se especifica en la base de datos de Kerberos para el principal de servicio que proporciona el ticket. En el caso de kinit, el principal de servicio es krbtgt/realm.
El valor de duración máxima renovable que se especifica en la base de datos de Kerberos para el principal de usuario que solicita el ticket.
La duración del ticket renovable se determina a partir del mínimo de los cuatro valores de duración renovables, de la siguiente manera:
Nombres de principales de Kerberos
Cada ticket se identifica con un nombre de principal. El nombre de principal puede identificar un usuario o un servicio. Los siguientes ejemplos muestran los típicos nombres de principal:
- changepw/kdc1.example.com@EXAMPLE.COM
Un principal para el servidor KDC maestro que permite el acceso al KDC cuando se cambian las contraseñas.
- clntconfig/admin@EXAMPLE.COM
Un principal que es empleado por la utilidad de instalación kclient.
- ftp/boston.example.com@EXAMPLE.COM
Un principal que es empleado por el servicio ftp. Este principal puede utilizarse en lugar de un principal de host.
- host/boston.example.com@EXAMPLE.COM
Un principal que es empleado por las aplicaciones de Kerberos (por ejemplo, klist y kprop) y los servicios (como ftp y telnet). Este principal se llama principal de host o de servicio. El principal se utiliza para autenticar los montajes de NFS. Este principal también lo utilizan los clientes para verificar que el TGT que reciben provenga del KDC correspondiente.
- K/M@EXAMPLE.COM
El nombre de principal clave maestro. Se asocia un nombre de principal clave maestro con cada KDC maestro.
- kadmin/history@EXAMPLE.COM
Un principal que incluye una clave utilizada para mantener los historiales de las contraseñas de otros principales. Cada KDC maestro tiene uno de los siguientes principales.
- kadmin/kdc1.example.com@EXAMPLE.COM
Un principal para el servidor KDC maestro que permite el acceso al KDC con kadmind.
- kadmin/changepw.example.com@EXAMPLE.COM
Un principal que se utiliza para aceptar solicitudes de cambio de contraseña de clientes que no están ejecutando una versión de Oracle Solaris.
- krbtgt/EXAMPLE.COM@EXAMPLE.COM
Este principal se utiliza cuando se genera un ticket de otorgamiento de tickets.
- krbtgt/EAST.EXAMPLE.COM@WEST.EXAMPLE.COM
Este principal es un ejemplo de un ticket de otorgamiento de tickets entre dominios.
- nfs/boston.example.com@EXAMPLE.COM
Un principal que emplea el servicio NFS. Este principal puede utilizarse en lugar de un principal de host.
- root/boston.example.com@EXAMPLE.COM
Un principal que está asociado a la cuenta root en un cliente. Este principal se denomina principal de root y proporciona acceso root a los sistemas de archivos montados en NFS.
- username@EXAMPLE.COM
Un principal para un usuario.
- username/admin@EXAMPLE.COM
Un principal de admin que se puede utilizar para administrar la base de datos del KDC.