Kerberos es un sistema/protocolo de red agregado que permite a los usuarios identificarse a través de los servicios de un servidor seguro. Los servicios como login remoto, copia remota, copias de ficheros de un sistema a otro y otras tantas tareas arriesgadas pasan a ser considerablemente seguras y más controlables.
Las siguientes instrucciones pueden usarse como una guía para configurar Kerberos tal y como se distribuye con FreeBSD. De todas maneras, debe consultar diversas páginas de manual para conocer todos los detalles.
Kerberos es un componente opcional de FreeBSD. La manera
más fácil de instalar este software es
seleccionando la distribución krb4 o
krb5 en sysinstall
durante la instalación inicial de FreeBSD. Desde ahí
instalará la implementación de Kerberos
“eBones” (KerberosIV) o
“Heimdal” (Kerberos5).
Estas implementaciones se incluyen porque a que han sido
desarrolladas fuera de EEUU y Canadá, lo que las
convertía en accesibles para administradores de sistemas
del resto del mundo durante la época restrictiva de control
control de exportaciones de código
criptográfico desde EEUU.
También puede instalar la implementación de Kerberos del MIT desde la colección de ports (security/krb5).
Esto solo debe hacerse en el servidor Kerberos. Lo primero
es asegurarse de que no tiene bases de datos de Kerberos
anteriores. Entre al directorio /etc/kerberosIV
y asegúrese de que solo estén los siguientes
ficheros:
#cd /etc/kerberosIV#lsREADME krb.conf krb.realms
Si existe cualquier otro fichero (como
principal.*
o master_key) utilice
kdb_destroy para destruir la base
de datos antigua de Kerberos. Si Kerberos no está
funcionando simplemente borre los ficheros sobrantes.
Edite krb.conf
y krb.realms para definir su dominio
Kerberos. En nuestro ejemplo el dominio será
EJEMPLO.COM y el servidor es
grunt.ejemplo.com.
Editamos o creamos krb.conf:
#cat krb.confEJEMPLO.COM EJEMPLO.COM grunt.ejemplo.com admin server CS.BERKELEY.EDU okeeffe.berkeley.edu ATHENA.MIT.EDU kerberos.mit.edu ATHENA.MIT.EDU kerberos-1.mit.edu ATHENA.MIT.EDU kerberos-2.mit.edu ATHENA.MIT.EDU kerberos-3.mit.edu LCS.MIT.EDU kerberos.lcs.mit.edu TELECOM.MIT.EDU bitsy.mit.edu ARC.NASA.GOV trident.arc.nasa.gov
Los demás dominios no deben estar forzosamente en la configuración. Los hemos incluido como ejemplo de cómo puede hacerse que una máquina trabaje con múltiples dominios. Si quiere mantener todo simple puede abstenerse de incluirlos.
La primera línea es el dominio en el que el
sistema funcionará. Las demás líneas
contienen entradas dominio/equipo. El primer componente de cada
línea es un dominio y el segundo es un equipo de ese
dominio, que actúa como
“centro de distribución de llaves”.
Las palabras admin server que siguen al
nombre de equipo significan que ese equipo también
ofrece un servidor de base da datos administrativo.
Si quiere consultar una explicación más completa de
estos términos consulte las páginas de manual de
de Kerberos.
Ahora añadiremos
grunt.ejemplo.com al dominio
EJEMPLO.COM y también una entrada
para poner todos los equipos en el dominio
.ejemplo.com Kerberos
EJEMPLO.COM. Puede actualizar su
krb.realms del siguiente modo:
#cat krb.realmsgrunt.ejemplo.com EJEMPLO.COM .ejemplo.com EJEMPLO.COM .berkeley.edu CS.BERKELEY.EDU .MIT.EDU ATHENA.MIT.EDU .mit.edu ATHENA.MIT.EDU
Igual que en caso previo, no tiene por qué incluir los demás dominios. Se han incluido para mostrar cómo puede usar una máquina en múltiples dominios. Puede eliminarlos y simplificar la configuración.
La primera línea pone al sistema específico en el dominio nombrado. El resto de las líneas muestran cómo asignar por defecto sistemas de un subdominio a un dominio Kerberos.
Ya podemos crear la base de datos. Solo se ejecuta en el
servidor Kerberos (o centro de distribución de
llaves). Ejecute kdb_init:
#kdb_initRealm name [default ATHENA.MIT.EDU ]:EJEMPLO.COMYou will be prompted for the database Master Password. It is important that you NOT FORGET this password.Enter Kerberos master key:
Ahora tendremos que guardar la llave para que los servidores en
la máquina local puedan recogerla. Utilice
kstash:
#kstashEnter Kerberos master key:Current Kerberos master key version is 1. Master key entered. BEWARE!
Esto guarda la contraseña cifrada
maestra en /etc/kerberosIV/master_key.
Tendrá que añadir a la base de datos dos
entradas en concreto para cada sistema
que vaya a usar Kerberos: kpasswd y
rcmd. Se hacen para cada sistema individualmente
cada sistema, y el campo “instance” es el nombre
individual del sistema.
Estos dæmons kpasswd y rcmd permiten a otros sistemas cambiar contraseñas de Kerberos y ejecutar órdenes como rcp(1), rlogin(1) y rsh(1).
Ahora vamos a añadir estas entradas:
#kdb_editOpening database...Enter Kerberos master key:Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value.Principal name:passwdInstance:grunt<Not found>,Create [y] ?yPrincipal: passwd, Instance: grunt, kdc_key_ver: 1New Password:<---- tecleo aleatorio Verifying passwordNew Password:<---- tecleo aleatorioRandom password [y] ?yPrincipal's new key version = 1Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?Edit O.K.Principal name:rcmdInstance:grunt<Not found>,Create [y] ?Principal: rcmd, Instance: grunt, kdc_key_ver: 1New Password:<---- tecleo aleatorio Verifying passwordNew Password:<---- tecleo aleatorioRandom password [y] ?Principal's new key version = 1Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?Edit O.K.Principal name:<---- si introduce datos nulos saldrá del programa
Ahora tendremos que extraer todas las instancias que definen
los servicios en cada máquina; para ello usaremos
ext_srvtab. Esto creará un
fichero que debe ser copiado o movido por medios
seguros al directorio
/etc/kerberosIV de cada
cliente Kerberos. Este fichero debe existir en todos los
servidores y clientes dada su importancia clave para el
funcionamiento de Kerberos.
#ext_srvtab gruntEnter Kerberos master key:Current Kerberos master key version is 1. Master key entered. BEWARE! Generating 'grunt-new-srvtab'....
Esta orden solo genera un fichero temporal al que tendrá
que cambiar el nombre a srvtab para que todos
los servidores puedan recogerlo. Utilice
mv(1) para moverlo al lugar correcto en el sistema
original:
#mv grunt-new-srvtab srvtab
Si el fichero es para un sistema cliente y la red no puede
considerarse segura copie el
cliente-new-srvtab
en un medio extraíble y transpórtelo por medios
físicos seguros. Asegúrese de cambiar su nombre a
srvtab en el directorio
/etc/kerberosIV del cliente, y
asegúrese también de que tiene modo 600:
#mv grumble-new-srvtab srvtab#chmod 600 srvtab
Ahora tenemos que añadir entradas de usuarios a la
base de datos. Primero vamos a crear una entrada para el usuario
jane. Para ello usaremos
kdb_edit:
#kdb_editOpening database...Enter Kerberos master key:Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value.Principal name:janeInstance:<Not found>,Create [y] ?yPrincipal: jane, Instance: , kdc_key_ver: 1New Password:<---- introduzca una constraseña segura Verifying passwordNew Password:<---- introduzca de nuevo la contraseña Principal's new key version = 1Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?Attributes [ 0 ] ?Edit O.K.Principal name:<---- si introduce datos nulos saldrá del programa
Primero tenemos que iniciar los dæmons de Kerberos.
Tenga en cuenta que si su /etc/rc.conf
está configurado correctamente el inicio tendrá
ligar cuando reinicie el sistema. Esta prueba solo es necesaria
en el servidor Kerberos; los clientes Kerberos tomarán
lo que necesiten automáticamente desde el directorio
/etc/kerberosIV.
#kerberos &Kerberos server starting Sleep forever on error Log file is /var/log/kerberos.log Current Kerberos master key version is 1. Master key entered. BEWARE! Current Kerberos master key version is 1 Local realm: EJEMPLO.COM#kadmind -n &KADM Server KADM0.0A initializing Please do not use 'kill -9' to kill this job, use a regular kill instead Current Kerberos master key version is 1. Master key entered. BEWARE!
Ahora podemos probar a usar kinit
para obtener un ticket para el ID jane
que creamos antes:
%kinit janeMIT Project Athena (grunt.ejemplo.com) Kerberos Initialization for "jane"Password:
Pruebe a listar los tokens con klist para ver
si realmente están:
%klistTicket file: /tmp/tkt245 Principal: jane@EJEMPLO.COM Issued Expires Principal Apr 30 11:23:22 Apr 30 19:23:22 krbtgt.EJEMPLO.COM@EJEMPLO.COM
Ahora trate de cambiar la contraseña usando passwd(1) para comprobar si el dæmon kpasswd está autorizado a acceder a la base de datos Kerberos:
%passwdrealm EJEMPLO.COMOld password for jane:New Password for jane:Verifying passwordNew Password for jane:Password changed.
Kerberos nos permite dar a cada
usuario que necesite privilegios de root
su propia contraseña para su(1).
Podemos agregar un ID que esté autorizado a ejecutar
su(1) root. Esto se controla
con una instancia de root
asociada con un usuario. Vamos a crear una entrada
jane.root en la base de datos, para lo que
recurrimos a kdb_edit:
#kdb_editOpening database...Enter Kerberos master key:Current Kerberos master key version is 1. Master key entered. BEWARE! Previous or default values are in [brackets] , enter return to leave the same, or new value.Principal name:janeInstance:root<Not found>, Create [y] ? y Principal: jane, Instance: root, kdc_key_ver: 1New Password:<---- introduzca una contraseña SEGURA Verifying passwordNew Password:<---- introduzca otra vez la constraseña Principal's new key version = 1Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?Max ticket lifetime (*5 minutes) [ 255 ] ?12<--- Keep this short!Attributes [ 0 ] ?Edit O.K.Principal name:<---- si introduce datos nulos saldrá del programa
Ahora trate de obtener los tokens para comprobar que todo funciona:
#kinit jane.rootMIT Project Athena (grunt.ejemplo.com) Kerberos Initialization for "jane.root"Password:
Hemos de agregar al usuario al
.klogin de root:
#cat /root/.kloginjane.root@EJEMPLO.COM
Ahora trate de hacer su(1):
%suPassword:
y eche un vistazo a qué tokens tenemos:
#klistTicket file: /tmp/tkt_root_245 Principal: jane.root@EJEMPLO.COM Issued Expires Principal May 2 20:43:12 May 3 04:43:12 krbtgt.EJEMPLO.COM@EJEMPLO.COM
En un ejemplo anterior creamos un usuario llamado
jane con una instancia root.
Nos basamos en un usuario con el mismo nombre del
“principal” (jane),
el procedimiento por defecto en Kerberos:
<principal>.<instancia> con la
estructura
<nombre de usuario>.root
permitirá que <nombre de usuario>
haga su(1) a root si existen
las entradas necesarias en el
.klogin que hay en el directorio home de
root:
#cat /root/.kloginjane.root@EJEMPLO.COM
De la misma manera, si un usuario tiene en su directorio home lo siguiente:
%cat ~/.kloginjane@EJEMPLO.COM jack@EJEMPLO.COM
significa que cualquier usuario del dominio
EJEMPLO.COM que se identifique como
jane o como jack
(vía kinit, ver más arriba)
podrá acceder a la cuenta de jane o
a los ficheros de este sistema (grunt) vía
rlogin(1), rsh(1) o
rcp(1).
Veamos por ejemplo cómo jane se
se identifica en otro sistema mediante Kerberos:
%kinitMIT Project Athena (grunt.ejemplo.com)Password:%rlogin gruntLast login: Mon May 1 21:14:47 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
Aquí jack se identifica con la
cuenta de jane en la misma
máquina (jane tiene configurado
su fichero .klogin como se ha mostrado
antes, y la persona encargada de la administración de
Kerberos ha configurado un usuario principal
jack con una instancia nula):
%kinit%rlogin grunt -l janeMIT Project Athena (grunt.ejemplo.com)Password:Last login: Mon May 1 21:16:55 from grumble Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995
Puede descargar éste y muchos otros documentos desde ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/
Si tiene dudas sobre FreeBSD consulte la
documentación antes de escribir a la lista
<questions@FreeBSD.org>.
Envíe sus preguntas sobre la documentación a
<doc@FreeBSD.org>.