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
#
ls
README 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.conf
EJEMPLO.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.realms
grunt.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_init
Realm name [default ATHENA.MIT.EDU ]:
EJEMPLO.COM
You 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
:
#
kstash
Enter 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_edit
Opening 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:
passwd
Instance:
grunt
<Not found>,Create [y] ?
y
Principal: passwd, Instance: grunt, kdc_key_ver: 1New Password:
<---- tecleo aleatorio Verifying passwordNew Password:
<---- tecleo aleatorioRandom password [y] ?
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:
rcmd
Instance:
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 grunt
Enter 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_edit
Opening 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:
jane
Instance:
<Not found>,Create [y] ?
y
Principal: 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 jane
MIT Project Athena (grunt.ejemplo.com) Kerberos Initialization for "jane"Password:
Pruebe a listar los tokens con klist
para ver
si realmente están:
%
klist
Ticket 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:
%
passwd
realm 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_edit
Opening 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:
jane
Instance:
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.root
MIT Project Athena (grunt.ejemplo.com) Kerberos Initialization for "jane.root"Password:
Hemos de agregar al usuario al
.klogin
de root
:
#
cat /root/.klogin
jane.root@EJEMPLO.COM
Ahora trate de hacer su(1):
%
su
Password:
y eche un vistazo a qué tokens tenemos:
#
klist
Ticket 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/.klogin
jane.root@EJEMPLO.COM
De la misma manera, si un usuario tiene en su directorio home lo siguiente:
%
cat ~/.klogin
jane@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:
%
kinit
MIT Project Athena (grunt.ejemplo.com)Password:
%
rlogin grunt
Last 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 jane
MIT 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>.