Kerberos - Administracion de Sistemas Operativos en Red

Kerberos
Fabiola Martinez Peñaranda 1150123
Carlos Rincon Avila 1150101
Henry Alexander Peñaranda 1150111
Ingeniería de Sistemas
Universidad Francisco de Paula Santander
Cucuta
2012
Kerberos
Fabiola Martinez Peñaranda 1150123
Carlos Rincon Avila 1150101
Henry Alexander Peñaranda 1150111
Examen Final
Administración de Sistemas Operativos en red
Ing. Jean Polo Cequeda Olago
Ingeniería de Sistemas
Universidad Francisco de Paula Santander
Cucuta
2012
Kerberos
La seguridad e integridad del sistema dentro de una red puede ser complejo. Se peude
necesita varios administradores solo para poder conocer qué servicios son los que
están ejecutándose en una red, y la manera en que están siendo utilizados.
Es más, la autenticación de usuarios en los servicios de red puede ser peligrosa
cuando los métodos usados por el protocolo sean inseguros, como lo demuestran
los protocolos tradicionales FTP y Telnet, que transfieren contraseñas no encriptadas
sobre la red.
Kerberos es una forma de eliminar la necesidad de protocolos que permitan métodos
inseguros de autenticación, por lo que mejora la seguridad general de la red.
¿Qué es Kerberos?
Kerberos es un protocolo de autenticación de red creado por el MIT (Massachusetts
Institute of Technology), y utiliza una criptografía de llave simétrica para autenticar a los
usuarios de los servicios de red, lo que en pocas palabras significa que las contraseñas
nunca son enviadas a través de la red.
Una llave simétrica es un sistema donde tanto el cliente como el servidor comparten
una clave común que es utilizada para encriptar y desencriptar comunicaciones a
través de una red
Cuando los usuarios se autentican con servicios de red usando Kerberos, los usuarios
no autorizados que intenten averiguar las contraseñas monitoreando el tráfico de red
son efectivamente bloqueados.
Historia
Kerberos fué creado en el Massachusetts Institute of Technology (MIT) como una
solución a los problemas de seguridad de la red. El protocolo Kerberos utiliza
criptografía fuerte para que un cliente pueda demostrar su identidad en un servidor (y
viceversa) a través de una conexión de red insegura.
Kerberos es el nombre de un protocolo de autentificación vía red y un adjetivo para
describir programas que implementan el programa (Kerberos telnet, por ejemplo,
conocido también como el “telnet kerberizado”). La versión actual del protocolo es la 5,
descrita en RFC 1510.
Existen diversas implementaciones libres de este protocolo, cubriendo un amplio
rango de sistemas operativos. El MIT, donde Kerberos fué desarrollado, continúa
desarrollando su propio paqueteKerberos. Suele usarse en los EEUU como producto
criptográfico y como tal ha sufrido las regulaciones de exportación de los EEUU. El
Kerberos del MIT existe como un port en (security/krb5). Heimdal Kerberos es otra
implementación de la versión 5, y fué desarrollada de forma intencionada fuera de
los EEUU para sortear las regulaciones de exportación (y por eso puede incluirse en
versiones no comerciales de UNIX®). La distribución Heimdal Kerberos está en el port
(security/heimdal), y se incluye una instalación mínima en el sistema base de FreeBSD.
Para alcanzar la mayor audiencia estas instrucciones asumen el uso de la distribución
Heimdal incluída en FreeBSD.
Ventajas de Kerberos
La mayoría de los servicios convencionales de red utilizan esquemas de autenticación
basados en contraseñas. Estos esquemas piden que los usuarios se identifiquen en un
servidor de red determinado mediante su nombre y contraseña. Desafortunadamente,
la transmisión de los datos para la autenticación de muchos servicios no es encriptada.
Para que este tipo de esquemas sean seguros, la red tiene que permanecer inaccesible
a los usuarios extraños a ella, y todos los equipos y todos los usuarios pertenecientes a
ella deben ser considerados confiables.
Pero aun en este caso, una red que se encuentre conectada a Internet no puede ser
considerada como una red segura. Cualquier atacante que tenga acceso a la red
puede utilizar un simple analizador de paquetes, también conocido como "rastreador"
de paquetes, para interceptar nombres de usuario y contraseñas, comprometiendo las
cuentas de usuario y la integridad de toda la infraestructura de seguridad.
El objetivo primario del diseño de Kerberos es eliminar la transmisión de contraseñas
encriptadas en la red. Si se usa apropiadamente, Kerberos elimina efectivamente la
amenaza de los husmeadores (sniffers) de paquetes en la red.
Desventajas de Kerberos
Aunque Kerberos elimina una amenaza de seguridad común y severa, puede ser difícil
de implementar por una variedad de razones:
● Puede ser algo muy tedioso migrar las contraseñas de los usuarios de una base
de datos UNIX estándar, como ser por ejemplo /etc/passwd o /etc/shadow
hacia una base de datos para contraseñas Kerberos, ya que no hay ningún
mecanismo automatizado para realizar esta tarea.
● Kerberos sólo tiene compatibilidad parcial con el sistema PAM de módulos de
autenticación conectables, utilizado por la mayoría de los servidores Fedora.
● Kerberos presupone que cada usuario es confiable, pero que está utilizando un
equipo o una red que no lo es. Su objetivo principal es prevenir la transmisión en
la red de contraseñas no encriptadas. Sin embargo, si alguien más tiene acceso
al único equipo que envía los comprobantes utilizados para la autenticación —
denominado el centro de distribución de claves (KDC, por las siglas en inglés
de Key Distribution Center) —, además del usuario correspondiente, todo el
sistema de autenticación Kerberos está corre riesgo.
● Para que una aplicación utilice Kerberos, su origen debe ser modificado para
que pueda realizar las llamadas apropiadas a las bibliotecas de Kerberos. Las
aplicaciones modificadas de esta manera son consideradas como compatibles
con Kerberos, o kerberizadas. Para algunas, esto puede ser bastante
problemático debido al tamaño de la aplicación o debido a su diseño. Para otras
aplicaciones incompatibles, los cambios deben ser hechos de manera tal de
permitir que el cliente y el servidor puedan comunicarse. De nuevo, esto puede
necesitar una programación extensa. Las aplicaciones de código propietario que
no tienen soporte para Kerberos por defecto, son más difíciles de configurar.
● Kerberos es una herramienta de tipo "todo o nada". Si Kerberos es utilizado
en la red, cualquier contraseña no encriptada transferida a un servicio no
compatible con Kerberos (o no Kerberizado), se encuentra en riesgo. Por lo
tanto, la red no obtiene beneficio alguno al utilizarlo. Para asegurar una red con
Kerberos, se debe utilizar versiones kerberizadas de todas las aplicaciones de
tipo servidor/cliente que transmitan contraseñas no encriptadas, o que no utilicen
ninguna de este tipo de aplicaciones.
Terminología de Kerberos
Kerberos tiene su propia terminología para definir varios aspectos del servicio. Antes
de aprender cómo funciona Kerberos, es importante conocer algunos de los siguientes
términos:
● Servidor de autenticación (SA)
Un servidor que envía comprobantes (o tickets) para un servicio determinado,
comprobantes que en su momento serán enviados a los usuarios para
que puedan acceder a ese servicio. El AS responde con una petición a las
solicitudes de los clientes que, o no tienen o no han enviado sus credenciales
de autenticación. Generalmente, para tener acceso al servidor que emite
las garantías de los comprobantes (TGS, por las siglas en inglés de TicketGranting Server), se envía un comprobante de obtención de garantía de
comprobante (TGT, Ticket-Granting Ticket). Por último, el AS generalmente
se ejecuta en el mismo equipo que el centro de distribución de claves (KDC,
Key Distribution Center).
● ciphertext
Datos encriptados.
● cliente
Una entidad en la red (un usuario, equipo o aplicación) que puede recibir tickets
desde Kerberos.
● credenciales
Un conjunto de credenciales electrónicas temporales que verifican la
identidad de un cliente para un servicio particular. También llamado ticket.
● caché de credenciales o archivo de ticket
Un archivo que contiene las claves para encriptar las comunicaciones entre
un usuario y varios servicios de red. Kerberos 5 soporta un marco de trabajo
para el uso de otros tipos de cache, tales como memoria compartida, pero los
archivos son los más completamente soportados.
● hash de encriptado
Un hash de una vuelta se usa para autenticar los usuarios. Estos son más
seguros que usar datos no encriptados, pero todavía son relativamente
fáciles de desencriptar para craqueadores experimentados.
● GSS-API
La Interfaz del Programa de la Aplicación de Servicios Generales de
Seguridad (API, por las siglas en inglés de Generic Security Service
Application Program Interfaz), es un conjunto de funciones que proveen
servicios de seguridad, definida en RFC-2743, publicada por el Equipo de
Tareas de Ingeniería de Internet. La API es utilizada por servicios y clientes
para autenticarse mutuamente sin que sus programas posean conocimientos
específicos de los mecanismos subyacentes. Si un servicio de red (como por
ejemplo cyrus-IMAP) utiliza GSS-API, entonces puede autenticarse mediante
Kerberos.
● hash
También conocido como valor hash. Un valor generado por el paso de una
cadena a través de una función hash. Estos valores son típicamente usados
para asegurar que los datos transmitidos no fueron interceptados y modificados.
● llave
Los datos usados cuando se encriptan o desencriptan otros datos. Los datos
encriptados no pueden ser desencriptados sin una clave apropiada o una
extrema buena suerte de parte del craqueador.
● centro de distribución de claves (KDC)
Un servicio que emite tickets de Kerberos, y que usualmente corre en el
mismo equipo que el servidor de garantía de ticket (TGS).
● tabla de clave (keytab)
Un archivo que incluye una lista no encriptada de principales con sus
respectivas claves. Los servidores obtienen las claves que necesitan desde
los archivos keytab en lugar de utilizar kinit. El archivo keytab establecido
por defecto es /etc/krb5.keytab. El servidor que administra el KDC /usr/
kerberos/sbin/kadmind, es el único servicio que utiliza cualquier otro
archivo (utiliza /var/kerberos/krb5kdc/kadm5.keytab).
● kinit
El comando kinit permite a un principal que ya ingresó obtener y hacer caché
del ticket inicial de garantía de tickets (TGT). Vaya a la página man de kinit
para más información.
● principal (o nombre principal)
The principal is the unique name of a user or service allowed to authenticate
using Kerberos. A principal follows the form root[/instance]@REALM. For a
typical user, the root is the same as their login ID. The instance is optional.
If the principal has an instance, it is separated from the root with a forward
slash ("/"). An empty string ("") is considered a valid instance (which differs
from the default NULL instance), but using it can be confusing. All principals
in a realm have their own key, which for users is derived from a password or
is randomly set for services.
● reinado
Una red que use Kerberos, compuesta de uno o más servidores llamados
KDCs y un número potencialmente grande de clientes.
● servicio
Un programa accedido por la red.
● ticket
Un conjunto temporal de credenciales electrónicas que verifican la identidad
de un cliente para un servicio particular. También llamados credenciales o
comprobantes.
● servidor de garantías de tickets (TGS)
Un servidor que emite tickets para un servicio deseado que son a su vez
dados a los usuarios para acceder al servicio. El TGS corre normalmente en
el mismo equipo que el KDC.
● ticket de garantía de ticket (TGT)
Un ticket especial que permite al cliente obtener tickets adicionales sin aplicar
nuevamente en el KDC.
● contraseña no encriptada
Una contraseña en texto plano, legible al humano.
Como Funciona Kerberos
Kerberos se diferencia de los métodos de autenticación de nombre de usuario /
contraseña. En lugar de autenticar cada usuario en cada servicio de red, Kerberos
utiliza cifrado simétrico y un tercero de confianza (un KDC), para autenticar a los
usuarios de red. Cuando un usuario se autentica en el KDC, el KDC envía un ticket
específico para esa sesión de nuevo a la máquina del usuario y cualquier servicio
Kerberos-aware buscar el billete en la máquina del usuario, en lugar de requerir que el
usuario se autentique utilizando una contraseña.
Cuando un usuario kerberizado de una red se loguea en su estación de trabajo, su
principal es enviado al KDC como parte de un pedido para un TGT del servidor de
Autenticación. Este pedido puede ser enviado por el programa de logueo de modo que
sea transparente para el usuario, o puede ser enviado por el programa kinit luego que
el usuario se haya logueado.
El KDC entonces verifica el principal en su base de datos. Si lo encuentra, el KDC crea
un TGT, que se encripta usando las claves del usuario y devuelto al usuario.
El inicio de sesión o el programa kinit en el cliente descifra el TGT utilizando la clave
del usuario, que se analiza desde la contraseña del usuario. La clave de usuario se
utiliza sólo en la máquina cliente y no se transmite por la red.
El TGT, que caduca después de un cierto período de tiempo (generalmente de diez a
veinticuatro horas) y se almacena en la memoria caché del equipo cliente credenciales.
Un tiempo de caducidad de manera que un TGT vulnerado, pueda ser utilizado por
un atacante sólo durante un corto período de tiempo. Después de que el TGT se ha
emitido, el usuario no tenga que volver a introducir su contraseña hasta que el TGT
caduque o hasta que finalice la sesión y volver a iniciar sesión.
Siempre que el usuario necesite acceso a un servicio de red, el software del cliente
utiliza el TGT para pedirle al TGS un nuevo comprobante específicamente para ese
servicio. El comprobante del servicio es entonces utilizado para autenticar de manera
transparente al usuario frente al servicio en cuestión.
Importante:
El sistema Kerberos puede ser vulnerado si un usuario en la red se autentica frente a
un servicio no kerberizado transmitiendo una contraseña con formato de texto simple.
La utilización de servicios no kerberizados es altamente desalentada. Entre tales
servicios se encuentra Telnet y FTP. Es preferible la utilización de otros protocolos
encriptados, como servicios asegurados mediante SSH o SSL, aunque no es lo ideal.
Configuración de servidores KDC
Después de instalar el software Kerberos, debe configurar los servidores KDC. La
configuración de un servidor KDC maestro y de, al menos, un servidor KDC esclavo
proporciona el servicio que emite credenciales. Estas credenciales son la base para el
servicio Kerberos, por lo que los KDC se deben instalar antes de intentar otras tareas.
La diferencia más importante entre un KDC maestro y un KDC esclavo es que sólo
el KDC maestro puede manejar solicitudes de administración de bases de datos.
Por ejemplo, el cambio de una contraseña o la adición de un nuevo principal se
deben realizar en el KDC maestro. Estos cambios, luego, se pueden propagar a los
KDC esclavos. Tanto el KDC esclavo como el KDC maestro generan credenciales.
Esta función proporciona redundancia en el caso de que el KDC maestro no pueda
responder.
Configuración de servidores KDC (mapa de tareas)
Tarea
Descripción
Configurar un
servidor KDC
maestro
Configura y genera el servidor KDC maestro y la
base de datos para un dominio mediante un proceso
manual, que se necesita para instalaciones más
complejas.
Configura y genera el servidor KDC maestro y la
base de datos para un dominio mediante un proceso
manual y un LDAP para el KDC.
Configurar un
servidor KDC
esclavo
Configura y genera un servidor KDC esclavo para
un dominio mediante un proceso manual, que se
necesita para instalaciones más complejas.
Actualizar las claves
del principal en un
servidor KDC
Actualiza la clave de la sesión en un servidor KDC
para utilizar nuevos tipos de cifrado.
Cómo configurar manualmente un KDC maestro
En este procedimiento, se configura la propagación incremental. Además, se utilizan
los siguientes parámetros de configuración:
●
●
●
●
●
Nombre de dominio = EXAMPLE.COM
Nombre de dominio DNS = example.com
KDC maestro = kdc1.example.com
Principal admin = kws/admin
URL de ayuda en pantalla = http://denver:8888/ab2/coll.384.1/SEAM/
@AB2PageView/6956
● Nota - Ajuste la dirección URL para que enlace a la sección "Herramienta gráfica
de administración de Kerberos", como se describe en URL de ayuda en pantalla
en la herramienta gráfica de administración de Kerberos.
Antes de empezar
Este procedimiento requiere que el host esté configurado para usar DNS. Para obtener
instrucciones específicas de nomenclatura si este maestro se va a intercambiar,
consulte Intercambio de un KDC maestro y un KDC esclavo.
1. Ingrese como usuario root para tener acceso a todas las opciones del
sistema.
2. Instale los paquetes krb5-libs, krb5-server y krb5-workstation en la máquina
dedicada que correrá KDC. Esta máquina necesita ser muy segura — si es
posible, no debe correr ningún otro servicio más que KDC.
3. Edite el archivo de configuración de Kerberos (krb5.conf).
Necesita cambiar los nombres de dominio y los nombres de los servidores.
Consulte la página del comando man krb5.conf(4) para obtener una descripción
completa de este archivo.
kdc1 # nano /etc/krb5/krb5.conf
[libdefaults]
default_realm = EXAMPLE.COM
[realms]
EXAMPLE.COM = {
kdc = kdc1.example.com
admin_server = kdc1.example.com
}
[domain_realm]
.example.com = EXAMPLE.COM
#
# if the domain name and realm name are equivalent,
# this entry is not needed
#
[logging]
default = FILE:/var/krb5/kdc.log
kdc = FILE:/var/krb5/kdc.log
[appdefaults]
gkadmin = {
help_url = http://denver:8888/ab2/coll.384.1/SEAM/@AB2PageView/6956
}
En este ejemplo, se modificaron las líneas para las entradas default_realm, kdc,
admin_server y domain_realm. Además, se editó la línea que define help_url.
Nota - Si desea restringir los tipos de cifrado, puede definir las líneas
default_tkt_enctypes o default_tgs_enctypes. Consulte Uso de los tipos de cifrado de
Kerberos para obtener una descripción de los problemas relacionados con la restricción
de los tipos de cifrado.
4. Edite el archivo de configuración de KDC (kdc.conf).
Necesita cambiar el nombre de dominio. Consulte la página del comando man
kdc.conf(4) para obtener una descripción completa de este archivo.
nano /var/kerberos/kbr5kdc/kdc.conf
[kdcdefaults]
kdc_ports = 88,750
[realms]
EXAMPLE.COM = {
profile = /etc/krb5/krb5.conf
database_name = /var/krb5/principal
admin_keytab = /etc/krb5/kadm5.keytab
acl_file = /etc/krb5/kadm5.acl
kadmind_port = 749
max_life = 8h 0m 0s
max_renewable_life = 7d 0h 0m 0s
sunw_dbprop_enable = true
sunw_dbprop_master_ulogsize = 1000
}
En este ejemplo, se modificó la definición del nombre de dominio en la sección realms.
Además, en la sección realms, se agregaron líneas para permitir la propagación
incremental y para seleccionar el número de actualizaciones que el KDC maestro
mantiene en el registro.
Nota - Si desea restringir los tipos de cifrado, puede definir las líneas
permitted_enctypes, supported_enctypes o master_key_type. Consulte Uso de los tipos
de cifrado de Kerberos para obtener una descripción de los problemas relacionados
con la restricción de los tipos de cifrado.
5. Cree la base de datos KDC mediante el comando kdb5_util.
El comando kdb5_util crea la base de datos KDC. Además, cuando se utiliza con la
opción -s, este comando crea un archivo intermedio que se utiliza para autenticar el
KDC para él mismo antes de que los daemons kadmindy krb5kdc se inicien.
/usr/sbin/kdb5_util create -s
Initializing database '/var/krb5/principal' for realm 'EXAMPLE.COM'
master key name 'K/M@EXAMPLE.COM'
You will be prompted for the database Master Password.
It is important that you NOT FORGET this password.
Enter KDC database master key: <Type the key>
Re-enter KDC database master key to verify: <Type it again>
6. Edite el archivo de la lista de control de acceso de Kerberos (kadm5.acl).
Una vez que se rellena, el archivo /var/kerberos/krb5kdc/kadm5.acl debe contener
todos los nombres de principales que tienen permitido administrar el KDC.
kws/admin@EXAMPLE.COM *
La entrada da al principal kws/admin en el dominio EXAMPLE.COM la capacidad
de modificar los principales o las políticas en el KDC. La instalación predeterminada
incluye un asterisco (*) para que concuerde con todos los principales admin. Este valor
predeterminado puede ser un riesgo de seguridad, por lo que es más seguro incluir una
lista de todos los principales admin. Consulte la página del comando man kadm5.acl(4)
para obtener más información.
7. Inicie el comando kadmin.local y agregue principales.
Los próximos pasos secundarios crean los principales que son utilizados por el servicio
Kerberos.
kdc1 # /usr/sbin/kadmin.local
kadmin.local:
a. Agregue principales de administración a la base de datos.
Puede agregar tantos principales admin como necesite. Debe agregar, al menos,
un principal admin para completar el proceso de configuración del KDC. Para
este ejemplo, se agrega un principal kws/admin. Puede sustituir un nombre de
principal adecuado en lugar de “kws”.
kadmin.local: addprinc kws/admin
Enter password for principal kws/admin@EXAMPLE.COM:<Type the password>
Re-enter password for principal kws/admin@EXAMPLE.COM: <Type it again>
Principal "kws/admin@EXAMPLE.COM" created.
kadmin.local:
b. Cree los principales kiprop.
Ingrese el comando siguiente kadmin.local en la terminal KDC para crear el
primer principal:
/usr/kerberos/sbin/kadmin.local -q "addprinc username/admin"
La herramienta kadmin permite la comunicación con el servidor kadmind a través
de la red, y utiliza kerberos para manipular la autenticación. Consecuentemente, el
primer principal debe existir previamente antes de intentar conectarse con el servidor
a través de la red para administrarlo. Genere el primer principal con el comando
kadmin.local, que ha sido específicamente diseñado para ser utilizado en el mismo
equipo en el que funciona el KDC, y no utiliza Kerberos para su autenticación.
8. Inicie Kerberos usando los siguientes comandos:
● /sbin/service krb5kdc start
● /sbin/service kadmin start
● /sbin/service krb524 start
Agregue principales para los usuarios mediante el comando addprinc dentro de kadmin.
kadmin y kadmin.local son interfaces de líneas de comando al KDC. Como este,
existen disponibles otros comandos — como por ejemplo addprinc — luego de iniciar el
programa kadmin. Para obtener mas información, consulte la página de kadmin.
Verifique que KDC está emitiendo tiques. Primero, corra kinit para obtener un tique
y guardarlo en un archivo cache de credencial. Luego, use klist para ver la lista de
credenciales en el caché y use kdestroy para destruir el caché y las credenciales que
contiene.
Configuración de un Cliente Kerberos 5
Configurar un cliente de Kerberos 5 es menos complicado que configurar un servidor.
Como mínimo, instale los paquetes del cliente y otórguele a cada cliente un archivo de
configuración krb5.conf válido. Mientras que ssh y slogin son los métodos preferidos
para loguearse remotamente en sistemas cliente, las versiones Kerberizadas de rsh
y rloginsiguen estando disponibles, aunque para habilitarlas es necesario realizar
algunos cambios adicionales en la configuración.
1. Asegúrese que la sincronización de tiempo entre el cliente Kerberos y KDC
exista y sea la adecuada. Diríjase aSección 2.6.5, “Configurando un servidor
Kerberos 5” para obtener mayors información. Además, verifique que el DNS
está funcionando apropiadamente en el cliente Kerberos antes de configurar con
los programas cliente de Kerberos.
2. Instale los paquetes krb5-libs y krb5-workstation en todas las máquinas clientes.
Provea un archivo /etc/krb5.conf válido para cada cliente (normalmente este
puede ser el mismo archivo krb5.conf usado por el KDC).
3. Antes de que una estación de trabajo de la red pueda utilizar Kerberos para
autenticar a los usuarios que se conectan mediante ssh o rsh o rlogin, debe
tener su propio host principal en la base de datos de Kerberos. El sshd, kshd, y
los programas de servidor klogind todos deben tener acceso a las claves para el
director del servicio de acogida. Además, con el fin de utilizar el rsh kerberizado
y servicios rlogin, esa estación de trabajo debe tener el paquete xinetd instalado.
4. Usando kadmin, añada un host principal para la estación de trabajo en el KDC.
El ejemplo en este caso es el nombre de la estación de trabajo. Utilice la opciónrandkey para el comando kadmin addprinc para crear el principal y asignarle una
clave aleatoria:
addprinc -randkey host/blah.example.com
5. Ahora que se ha creado el principal, las claves se pueden extraer para la
estación trabajo ejecutando kadmin en la misma estación de trabajo y usando el
comando ktadd dentro de kadmin:
ktadd -k /etc/krb5.keytab host/blah.example.com
6. Para usar otros servicios de red kerberizados, primero deben iniciarse. A
continuación mostramos una lista de los servicios kerberizados comunes y las
instrucciones acerca de cómo habilitarlos:
○ ssh — OpenSSH usa GSS-API para autenticar a los usuarios
a los servidores si el cliente y la configuración del servidor
GSSAPIAuthentication ambos han sido habilitadas. Si el cliente también
ha GSSAPIDelegateCredentials habilitado, las credenciales del usuario
están disponibles en el sistema remoto.
○ rsh y rlogin — Para usar las versiones kerberizadas de rsh y rlogin,
habilite klogin, eklogin y kshell.
○ Telnet — Para usar Telnet kerberizado, debe habilitar krb5-telnet.
○ FTP — Para proveer acceso FTP, crear y extraer una clave para el
principal con una raíz de ftp. Asegúrese de poner la instancia al nombre
de equipo completo del servidor FTP, luego habilite gssftp.
○ IMAP — Para utilizar un servidor kerberizado IMAP, el paquete cyrusimap utilizará Kerberos 5, si también se encuentra instalado el paquete
cyrus-sasl-gssapi. El paquete cyrus-sasl-gssapi contiene el complemento
Cyrus SASL que tiene soporte para autenticación GSS-API. Cyrus IMAP
debería funcionar correctamente con Kerberos siempre y cuando el
usuario cyrus sea capaz de encontrar la clave correspondiente en /etc/
krb5.keytab, y que la raíz para el principal esté definida para imap (creada
con kadmin).
○ Una alternativa a cyrus-imap se puede encontrar en el paquete dovecot,
que también se ofrece con Fedora. Este paquete contiene un servidor
IMAP pero por el momento no da soporte ni a GSS-API ni a Kerberos.
○ CVS — Para usar un servidor CVS kerberizado, gserver usa un principal
con una raíz de cvs y por lo demás es idéntico al servidor CVS pserver.