\chapter{Servidor Horario de Red}
\section{El protocolo NTP}
NTP(Network Time Protocol) es el protocolo estandar de sincronización de la hora en equipos de una misma red.
El servidor devuelve la Hora UTC (Horario de Greenwich u horario universal), con lo cual hay que modificar este horario para los paises en que estemos y su uso horario.
Amplia documentación puede ser encontrada en \hlink{http://www.ntp.org/} y servidores ntp públicos en \hlink{http://pool.ntp.bitic.net/} y \hlink{http://www.eecis.udel.edu/~mills/ntp/servers.html}.
Sigue los siguientes RFC: RFC 778, RFC 891, RFC 956, RFC 958, y RFC 1305.
El servidor NTP y el cliente correspondiente serán necesarios para su utilización con Kerberos, ya que este protocolo de autentificación necesita gran precisión horaria.
\section{NTP-server}
\subsection{Instalación}
Es el servidor oficial, que puede ser descargado de \hlink{http://ntp.isc.org/bin/view/Main/SoftwareDownloads}, una vez descargado y descomprimido en /usr/src/ntp-4.X.X haremos:
\jump
\begin{rbox}
# cd build-refclock && ../configure --prefix=/usr \
--enable-all-clocks --enable-parse-clocks --enable-SHM \
--disable-debugging --sysconfdir=/var/lib/ntp \
--cache-file=../config.cache --disable-errorcache \
--enable-linuxcaps
# make
# make install
\end{rbox}
\jump
\subsection{Configuración}
La configuración se guarda en /etc/ntp.conf y esta es una configuración básica:
\jump
\begin{rbox}
# Donde guardamos los registros.
logfile /var/log/ntpd
# Indica la dirección del archivo de frecuencia.
driftfile /var/lib/ntp/ntp.drift
# Directorio donde se volcarán estadísticas
statsdir /var/log/ntpstats/
# Mas de estadísticas
statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable
# Usaremos pool.ntp.org ya que redirecciona a gran cantidad
# de servidores ntp publicos
server pool.ntp.org
# Restricciones de acceso
restrict your.lan kod notrap nomodify nopeer noquery
restrict 127.0.0.1 nomodify
restric default ignore
# Para proveer de hora a la subred
broadcast your.subnet.255
\end{rbox}
\jump
ntp-server soporta muchos mas parámetros de configuración como autentificación, certificados, monitorización, etc. Que se salen de las necesidades de este manual.
\section{Chrony}
\subsection{Instalación}
Chrony es otro servidor horario mas ligero que el anterior y tambien ampliamente utilizado, lo descargaremos de \hlink{http://chrony.sunsite.dk/download.php} y como hacemos con todos los paquetes lo ponemos en /usr/src:
\jump
\begin{rbox}
# cd /usr/src/chrony-
# ./configure --prefix='/usr'
# make
# make install
\end{rbox}
\jump
Mas documentación la encontraremos en \hlink{http://chrony.sunsite.dk/guide/chrony.html} .
\subsection{Configuración}
El archivo de configuración básico es /etc/chrony/chrony.conf y sería como:
\jump
\begin{rbox}
# See www.pool.ntp.org for an explanation of these servers. Please
# consider joining the project if possible. If you can't or don't want to
# use these servers I suggest that you try your ISP's nameservers. We mark
# the servers 'offline' so that chronyd won't try to connect when the link
# is down. Scripts in /etc/ppp/ip-up.d and /etc/ppp/ip-down.d use chronyc
# commands to switch it on when the link comes up and off when it goes
# down. If you have an always-on connection such as cable omit the
# 'offline' directive and chronyd will default to online.
# Configuración para pool.net.org, al igual que en ntp-server, en este caso
# usaremos tres intentos por si nuestra primera petición da con un servidor offline.
server pool.ntp.org minpoll 8
server pool.ntp.org minpoll 8
server pool.ntp.org minpoll 8
# Clave del administrador,
keyfile /etc/chrony/chrony.keys
# Clave para el ejecutable (la primera del anterior)
commandkey 1
# Fichero de frecuencias
driftfile /var/lib/chrony/chrony.drift
# Registro del servidor
log tracking measurements statistics
logdir /var/log/chrony
# Stop bad estimates upsetting machine clock.
maxupdateskew 100.0
# Volcar las mediciones al cerrar el servidor
dumponexit
# Y donde:
dumpdir /var/lib/chrony
# Let computer be a server when it is unsynchronised.
local stratum 10
# Clientes permitidos
allow your.subnet
# Envia un registro si tiene que actualizar hora de mas de x segs:
logchange 0.5
# Idem pero enviando un correo
# if chronyd applies a correction exceeding a particular threshold to the
# system clock.
mailonchange root@your.domain 0.5
\end{rbox}
\jump
\section{ntpdate}
\subsection{Instalación y Funcionamiento}
ntpdate es un cliente que viene con ntp-server, se instalara al mismo tiempo que ntp-server, su funcionamiento básico es muy sencillo, aunque soporte autentificación, en este caso supondremos que el cliente se ejecuta en la maquina a traves de un sistema periódico (cron):
\jump
\begin{rbox}
# /usr/sbin/ntpdate your.ntp.server
\end{rbox}
\jump
\section{¿Cómo uso pool.ntp.org?}
El fichero de frecuencias deberia quedar así:
\jump
\begin{rbox}
server pool.ntp.org
server pool.ntp.org
server pool.ntp.org
\end{rbox}
\jump
¿Sencillo, no?
\chapter{Servicios de seguridad - Kerberos}
\section{Seguridad e identificación}
¿Quién se conecta al servidor?\\
¿Puedo estar seguro de que se puede confiar en el cliente, y el cliente en el servidor?
Esto es solo un pequeño resumen, para mas documentación vease Criptografía y Seguridad en Computadores\cite{cripto1} en español.
Los rfc mas interesantes son:
\jump
\begin{itemize}
\item The Kerberos Network Authentication Service (V5),\cite{1510}
\item Encryption and Checksum Specifications for Kerberos 5,\cite{3961}
\item Advanced Encryption Standard (AES) Encryption for Kerberos 5,\cite{3961}
\end{itemize}
\subsection{Caso 1: Las contraseñas van en texto plano}
Están ahí, todo aquel que vea el tráfico de la red las verá.
Solo es factible si se están usando canales que se consideren seguros (SSL,ipsec,etc).
\subsection{El problema del hombre de enmedio}
Si alguien ve tu usuario y tu contraseña puede hacer algo peor que simplemente ver que haces, puede suplantarte.
El hombre de enmedio (man in the middle) es un sistema que esta entre el cliente y el servidor que coge las peticiones del cliente, las manipula y las envia al servidor, por supuesto tambien puede manipular lo que viene del servidor.
\subsection{Caso 2: Las contraseñas tienen codificación simetrica}
\begin{enumerate}
\item Mejora mucho la seguridad, cuanto mejor sea la encriptación sera mas seguro.
\item Aún así es problemático y deberia usarse bajo canales seguros.
\item ¿Como enviamos la clave con la que encriptamos la contraseña?
\item Si esta clave cae, se producira una situación como la del envio en texto plano, y volvemos a estar en situación de que un sistema intermedio tome nuestra personalidad.
\item Se considera segura a partir de 128bits de longitud.
\item No autentifica quien envio el mensaje.
\end{enumerate}
\subsection{Caso 3: Cifrado por bloques (Hashes)}
\begin{enumerate}
\item Las contraseñas se codifican de tal manera que no se puede volver a conseguir la contraseña por otro metodo que no sea la fuerza bruta.
\item Es menos problemático, pero deberia usarse solo bajo canales seguros.
\item Se envían de esta manera por la red, cualquiera puede identificar que es una contraseña e intentar romper por fuerza bruta la contraseña.
\item Sigue siendo sensible al problema del robo de identidad, ya que no autentifica quien envio el mensaje.
\item Se puede mejorar usando tecnicas de desafio, enviando antes de pedir la clave un codigo al usuario con el que mejorar la seguridad del código resultante.
\end{enumerate}
\subsection{Caso 4: Cifrado Asimetrico, Certificados SSL}
\begin{enumerate}
\item Se dividen en dos partes: la privada, aquella con la que codificamos, y la publica, que es aquella con la que decodifican los mensajes los clientes.
\item Necesita logitudes de clave muy largas para ser seguros (>1024bits) y mucho mas tiempo de computación que los cifrados simetricos.
\item En la práctica se utilizan para el envio de la clave y despues los mensaje se envian con codificación simetrica.
\item Es mas resistente a sistemas intermedios, ya que este no puede acceder a la clave privada y por lo tanto no puede codificar mensajes.
\end{enumerate}
\subsection{Caso 5: Kerberos para identificación}
\begin{enumerate}
\item El protocolo supone que la red es insegura y que hay sistemas intermedios que pueden escuchar.
\item Los usuarios y servicios (principales) deben autentificarse ante un tercero, el servidor kerberos, el cual es aceptado como autentico.
\item Usa cifrado simetrico convirtiendo el conjunto en una red segura.
\end{enumerate}
\section{El protocolo Kerberos}
\subsection{El servidor Kerberos}
El servidor kerberos no sirve un unico servicio, sino tres:
\jump
\begin{itemize}
\item AS = Servidor de autentificación.
\item TGS = Servidor de Tickets.
\item SS = Servidor de servicios.
\end{itemize}
\subsection{Clientes y Servidores}
El cliente autentifica contra el AS, despues demuestra al TGS que esta autorizado para recibir el ticket para el servicio que quiere usar, y por último demuestra ante el SS que esta autorizado para usar el servicio.
\subsection{Que es un ticket y como funciona Kerberos}
\begin{enumerate}
\item[1.-] Un usuario introduce una clave y contraseña en el cliente.
\item[2.-] El Cliente usa un hash sobre la contraseña y la convierte en la clave secreta del cliente.
\item[3.-] El cliente envía un mensaje al AS pidiendo servicio para el cliente.
\item[4.-] El AS comprueba si el usuario existe en la base de datos. Si existe le envia dos mensajes al cliente.\\
El mensaje A: Tiene una clave de sesión del TGS codificada usando la clave secreta del usuario.\\
El mensaje B: (TGT)Ticket-Granting Ticket. Este incluye el identificador del cliente, la dirección de red es este, un periodo de valided, y la clave de sesión del TGS, todo codificado usando la clave secreta del TGS.
\item[5.-] El cliente recibe los mensajes A y B, con su clave secreta decodifica el mensaje A y coge la clave de sesión del TGS, con esta podra comunicarse con el TGS. Se observa que el cliente no puede decodificar el mensaje B al no tener la clave secreta del TGS.
\item[6.-] Cuando el cliente quiere usar algún servicio, envia los siguientes mensajes al TGS:\\
Mensaje C: Compuesto por el TGT del mensaje B y el identificador de petición de servicio.\\
Mensaje D: Autentificador (El cual está compuesto por el identificador del cliente y una marca horaria - timestamp -) codificado con la clave de sesión del TGS.
\item[7.-] Al recibir los dos mensajes, el TGS decodifica el autentificador usando la clave de sesión del usuario y envia los siguientes mensajes al cliente:\\
Mensaje E: Ticket Cliente Servidor, que contiene el identificador del cliente, su dirección de red, un periodo de valided, y la clave de sesión del TGS, codificado usando la clave secreta del servidor.\\
Mensaje F: Clave de sesión Cliente / Servidor codificada con la clave de sesión del TGS del cliente.
\item[8.-] Una vez recibidos desde el TGS los mensajes, el cliente tiene información suficiente para autentificarse ante el SS. El cliente se conectara al SS y le enviara los siguientes mensajes:\\
Mensaje G: El ticket de cliente / servidor codificado con la clave secreta del servidor. (Mensaje E).\\
Mensaje H: Un nuevo autentificador que contiene el identificador del cliente, una marca horaria y que esta codificado usando la clave de sesión cliente / servidor.
\item[9.-] El SS decodifica el Mensaje G usando su propia clave secreta y usando la clave Cliente/TGS en el mensaje F consigue la clave de sesion cliente/servidor, entonces le enviara el siguiente mensaje al cliente para confirmar su identidad:\\
Mensaje I: La marca horaria del Autentificador mas 1, codificado usando la clave de sesión cliente/servidor.
\item[10.-] El cliente decodifica el mensaje de confirmación y comprueba si la marca horaria ha sido actualizada correctamente. Si todo es correcto, el cliente confiara en el servidor y puede comenzar a hacer peticiones al servidor.
\item[11.-] El servidor responde a las peticiones de ese cliente que ha sido autentificado.
\end{enumerate}
\section{MIT Kerberos}
El Intituto de Tecnologias de Massachusetts (MIT, Massachusetts Institute of Technology) junto con DEC e IBM comenzaron el proyecto Athena para computación distribuida. Parte de este proyecto es el protocolo de autentificación Kerberos. El proyecto comenzo su funcionamiento en 1983.
La versión 4 del protocolo salio en 1980 para el proyecto Athena, y en 1993 salio la versión 5\cite{1510} que superaba las limitaciones y problemas de su predecesor.
MIT Kerberos es distribuido libremente bajo licencia tipo BSD.
\subsection{Instalación}
\label{down_kerberos_mit}
Antes de nada, nos bajaremos una librería de las que depende MIT kerberos:
\jump
\begin{itemize}
\item[e2fsprogs]
Se puede descargar de \htmladdnormallink{http://e2fsprogs.sourceforge.net}{http://e2fsprogs.sourceforge.net} para acceso al sistema de archivos y para las librerías libss y libcomerr2.
\end{itemize}
\jump
Las fuentes de MIT Kerberos se pueden descargar de \htmladdnormallink{MIT Kerberos V}{http://web.mit.edu/kerberos/www}, como haremos con todas las fuentes las descomprimiremos en /usr/src y entraremos en /usr/src/krb5-1.X.X y jecutamos \htmladdnormallink{./configure}{http://warping.sourceforge.net/gosa/contrib/es/configure_krb5.sh} con las siguientes opciones:
\jump
\begin{tabular}{|ll|}\hline
--prefix=/usr & $\rightarrow$ Donde vamos a instalarlo\\
--mandir=/usr/share/man & $\rightarrow$ Donde van los manuales\\
--localstatedir=/etc & \\
--enable-shared & $\rightarrow$ Librerias dinamicas, necesarias\\
& $\rightarrow$ para compilar otros programas\\
--with-system-et & $\rightarrow$ Usara la libreria estandar de errores\\
& $\rightarrow$ , libcomerr2, para com\_err.so y compile\_et\\
--with-system-ss & Necesario para que use libss2, una libreria\\
& $\rightarrow$ para la entrada de linea de comandos.\\
--without-tcl & $\rightarrow$ No compilamos el soporte tcl.\\
--enable-dns-for-kdc & $\rightarrow$ Busquedas dns para el kdc\\
\hline \end{tabular}
\jump
Una vez configurado, hacemos:
\jump
\begin{tabular}{|l|}\hline
\#make \&\& make install\\
\hline \end{tabular}
\jump
\subsection{Configuración y funcionamiento}
\subsubsection{Iniciar un dominio}
Antes de iniciar un dominio debemos estar seguros de que la configuración DNS es correcta \ref{dns_kerberos}.
El dominio que vamos a crear es CHAOSDIMENSION.ORG, para ello una vez instalado el programa haremos:
\subsubsection{Añadir usuarios y servicios}
\subsection{Replicación - kprop}
\subsection{Ventajas y desventajas}
\section{El servidor Heimdal Kerberos}
Por culpa de las regulaciones de exportación de los Estados Unidos que prohibian la salida del código del MIT Kerberos porque usaba el algoritmo de encriptación DES con logitud de clave de 56 bit. Se comenzo una implementación nueva en KTH, suecia: Heimdal.
En el 2000 se elimino las restricciones a la exportación y se pudo mejorar la compatibilidad entre ambos servidores.
Aunque GOsa puede usar cualquiera de las dos versiones de Heimdal, desde este manual se recomienda Heimdal, ya que es thread safe (no tiene problemas con los hilos), tiene mejor rendimiento y es el servidor kerberos elegido por el grupo de desarrollo de Samba para su proxima versión 4.
\subsection{Instalación}
\label{down_kerberos_heimdal}
Antes de nada, nos bajaremos una librería de las que depende Heimdal kerberos:
\begin{itemize}
\item[readline]
Se puede descargar de \htmladdnormallink{http://cnswww.cns.cwru.edu/~chet/readline/rltop.html}{http://cnswww.cns.cwru.edu/~chet/readline/rltop.html}. Es una librería que controla el acceso a la linea de comandos.
\end{itemize}
\noindent Heimdal Kerberos se puede descargar de \htmladdnormallink{Heimdal Kerberos}{http://www.pdc.kth.se/heimdal}, las descomprimiremos en /usr/src y entraremos en /usr/src/heimdal-0.6.X.
Ejecutamos \htmladdnormallink{./configure}{http://warping.sourceforge.net/gosa/contrib/es/configure_heimdal.sh} con las siguientes opciones:
\jump
\begin{tabular}{|ll|}\hline
--prefix=/usr & $\rightarrow$ Donde vamos a instalarlo\\
--mandir=/usr/share/man & $\rightarrow$ Donde van los manuales\\
--infodir=/usr/share/info & $\rightarrow$ Donde van los info\\
--libexecdir=/usr/sbin & $\rightarrow$ Donde van los ejecutables de aministrador\\
--with-roken=/usr & $\rightarrow$ Donde van las librerias roken\\
--enable-shared & $\rightarrow$ Librerias dinamicas, necesarias\\
& $\rightarrow$ para compilar otros programas\\
--with-krb4 & $\rightarrow$ Compilar con la versión antigua del protocolo\\
--with-openldap & $\rightarrow$ Soporte openldap \ref{down_ldap}\\
\hline \end{tabular}
\jump
Una vez configurado, hacemos:
\jump
\bbox
\#make \&\& make install\\
\ebox
\jump
\subsection{Configuración y funcionamiento}
La configuración de Heimdal Kerberos se guarda principalmente en estos archivos:\\
\begin{tabular}{|l|l|}\hline
/etc/krb5.conf & Configuración de los dominios Kerberos y de otros parametros.\\
& \\
/var/lib/heimdal-kdc/kdc.conf & Configuración de los parametros del servidor kdc.\\
& \\
/var/lib/heimdal-kdc/kadmind.acl & Configuración de acceso de usuarios y servicios\\
& a la base de datos de Kerberos desde acceso remoto al administrador.\\
& \\
/var/lib/heimdal-kdc/m-key & Clave secreta del servidor Kerberos.\\
& \\
/etc/krb5.keytab & Aqui se guardaran las claves de maquinas y servicios.\\
& \\
\hline \end{tabular}
\jump
Los ejecutables que normalmente vamos a usar son:\\
\begin{tabular}{|l|l|}\hline
kadmin & Aplicación para la administración de los dominios y de los keytab.\\
& Para usarlo en modo local se usara -l.\\
& \\
ktutil & Utilidad mas específica para los keytab.\\
& \\
kinit & Aplicación para iniciar tickets, sirve para probar el servidor.\\
& \\
kpasswd & Utilidad para cambiar las contraseñas de usuarios.\\
& \\
\hline \end{tabular}
\jump
\subsubsection{Iniciar un dominio}
Antes de iniciar un dominio debemos estar seguros de que la configuración DNS es correcta \ref{dns_kerberos}.
\label{heimdal_conf}
El dominio que vamos a crear es CHAOSDIMENSION.ORG, para ello una vez instalado y antes de iniciar heimdal editaremos /etc/krb5.conf:
\jump
\begin{center}
\begin{tabular}{|l|l|}\hline
\verb|[libdefaults]| & $\rightarrow$ Valores por defecto de los dominios\\
\verb| default_realm = CHAOSDIMENSION.ORG| & $\rightarrow$ Dominio por defecto \\
& del servidor si no se pide el dominio\\
\verb| kdc_timesync = true| & $\rightarrow$ Intenta compensar la diferencias de \\
& tiempos entre clientes y servidores\\
\verb| clockskew = 60| & $\rightarrow$ Máxima diferencia de segundos cuando se \\
& comparan tiempos\\
\verb| dns_lookup_kdc = true| & $\rightarrow$ Usar DNS SRV para busquedas \\
& servidores KDC.\\
\verb| dns_lookup_realm = true| & $\rightarrow$ Usar DNS TXT para relacionar \\
& dominios DNS \\
& con dominios Kerberos.\\
\verb| max_retries = 1| & $\rightarrow$ Numero de intentos en la autentificación.\\
\verb| krb4_get_tickets = false| & $\rightarrow$ No Aceptamos tickets de Kerberos v4.\\
& \\
\verb|[realms]| & $\rightarrow$ Definimos los dominios\\
\verb| CHAOSDIMENSION.ORG = {| & $\rightarrow$ \\
\verb| kdc = kdc.chaosdimension.org| & $\rightarrow$ Donde está el KDC.\\
\verb| admin_server = kadmin.chaosdimension.org| & $\rightarrow$ Dondé estará el Kadmind.\\
\verb| kpasswd_server = kpasswd.chaosdimension.org| & $\rightarrow$ Donde está el kpasswd.\\
\verb| }| & \\
& \\
\verb|[domain_realm]| & $\rightarrow$ Mapeo de Dominios.\\
\verb| .chaosdimension.org = CHAOSDIMENSION.ORG| & \\
\verb| chaosdimension.org = CHAOSDIMENSION.ORG| & \\
& \\
\verb|[logging]| & $\rightarrow$ Configuración de registro\\
\verb| kdc = FILE:/var/lib/heimdal-kdc/kdc.log| & \\
\verb| hpropd = FILE:/var/lib/heimdal-kdc/hpropd.log| & \\
\verb| ipropd = FILE:/var/lib/heimdal-kdc/ipropd.log| & \\
\verb| kpasswdd = FILE:/var/lib/heimdal-kdc/kpasswdd.log| & \\
\verb| kadmind = FILE:/var/lib/heimdal-kdc/kadmind.log| & \\
\verb| default = FILE:/var/log/heimdal-kdc.log| & \\
\hline \end{tabular}
\end{center}
\jump
Esta es la configuración mínima para hacer funcionar Heimdal Kerberos, la configuración para GOsa es la indicada en heimdal sobre ldap \ref{heimdal_ldap}, ya que es la que permite mayor control y una replicación mas comoda.
El siguiente paso es crear la clave privada del servidor, para ello ejecutaremos el comando kstah:
\bbox
\verb|\#kstash|\\
\verb|Master key: |\\
\verb|Verifying password - Master key: |\\
\ebox
Iniciamos el dominio CHAOSDIMENSION.ORG:
\bbox
\verb|# kadmin -l|\\
\verb| kadmin> init CHAOSDIMENSION.ORG|\\
\verb| Realm max ticket life [unlimited]:|\\
\verb| Realm max renewable ticket life [unlimited]:|\\
\ebox
\subsubsection{Añadir usuarios y servicios}
Añadir un usuario es sencillo, hacer en la consola de administración (kadmin -l):
\bbox
\verb| kadmin> add usuario|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\verb| Password:|\\
\verb| Verifying password - Password:|\\
\ebox
Para comprobar si funciona:
\bbox
\verb|# kinit usuario@CHAOSDIMENSION.ORG|\\
\verb|# klist|\\
\ebox
Para añadir un servicio necesitamos añadirlo como si fuera un usuario, en este caso la clave sera un valor al azar, ya que no necesita identificarse ante el servidor y por otro lado hay que guardar los datos en el keytab.
Por ejemplo para configurar el servicio ldap tenemos:
\bbox
\verb|# kadmin -l|\\
\verb| kadmin> add --random-key ldap/my.host.name|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\verb| Password:|\\
\verb| Verifying password - Password:|\\
\ebox
Si queremos aceptar todos los servicios de ese servidor tenemos:
\bbox
\verb|# kadmin -l|\\
\verb| kadmin> add --random-key host/my.host.name|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\verb| Password:|\\
\verb| Verifying password - Password:|\\
\ebox
Guardamos entonces el servicio en el keytab.
\bbox
\verb|# kadmin -l|\\
\verb| kadmin> ext host/my.host.name|\\
\verb| kadmin> exit|\\
\verb|# ktutil list|\\
\verb| Version Type Principal|\\
\verb| 1 des-cbc-md5 host/my.host.name@CHAOSDIMENSION.ORG|\\
\verb| 1 des-cbc-md4 host/my.host.name@CHAOSDIMENSION.ORG|\\
\verb| 1 des-cbc-crc host/my.host.name@CHAOSDIMENSION.ORG|\\
\verb| 1 des3-cbc-sha1 host/my.host.name@CHAOSDIMENSION.ORG|\\
\ebox
\subsubsection{Administración Remota}
Para poder administrar de forma remota (lease que no este ejecutandose en la maquina donde estamos o que no seamos root de la maquina donde se está administrando). usaremos kadmin sin la opción -l, en el servidor kerberos debemos tener configurado el usuario de administración remota con los permisos que nosotros querramos. Esto se debe dejar claro en kadmind.acl, por ejemplo si queremos que el usuario admin desde la maquina admin.remote.host pueda tener todos los permisos en el dominio CHAOSDIMENSION.ORG:
\bbox
\verb|admin@CHAOSDIMENSION.ORG all *@CHAOSDIMENSION.ORG|\\
\verb|admin@CHAOSDIMENSION.ORG all */*@CHAOSDIMENSION.ORG|\\
\ebox
\subsection{Replicación - hprop}
Hprop es el servicio de replicación que trae Heimdal Kerberos de serie. No es incremental, se basa en un dump de la base de datos y en la copia de este a los otros servidores.
El servidor hpropd se ejecuta en los esclavos, y el cliente hprop se ejecuta a intervalos regulares en el servidor, cuando hprop es ejecutado intenta una conexión con el puerto 754/TCP del servidor, coge la base de datos del dominio y la envia en un formato que permite al servidor convertirla en la nueva base de datos del cliente.
El servidor maestro debe tener configurado el usuario kadmin/hprop, ya que se crea al inicializar el dominio, si no es asi, haremos:
\bbox
\verb|# kadmin -l|\\
\verb| kadmin> add --random-key kadmin/hprop@CHAOSDIMENSION.ORG|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\ebox
Necesitaremos un usuario administrador, en nuestro caso lo llamaremos admin y le daremos permisos para que tenga administración remota:
\bbox
\verb| kadmin> add admin@CHAOSDIMENSION.ORG|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\verb| Password:|\\
\verb| Verifying password - Password:|\\
\ebox
Editamos el archivo kadmind.acl y añadimos el usuario administrador:
\bbox
\verb| admin@CHAOSDIMENSION.ORG all */*@CHAOSDIMENSION.ORG|\\
\ebox
Tanto en el maestro como en los servidores esclavos, con la configuración dns apuntando como servidor de dominio al servidor maestro, haremos:
\bbox
\verb|# ktutil get -p admin@CHAOSDIMENSION.ORG hprop/esclavo.hostname@CHAOSDIMENSION|\\
\verb|admin@CHAOSDIMENSION's Password:|\\
\ebox
Para hacer una replica del maestro, simplemente ejecutaremos hpropd en el esclavo y en el servidor ejecutaremos:
\bbox
\verb|# hprop --source=heimdal --v5-realm=CHAOSDIMENSION.ORG --encrypt \|\\
\verb| --master-key=/var/lib/heimdal-kdc/m-key esclavo.hostname|\\
\ebox
Para comprobar que la replicación esta bien hecha haremos en el esclavo:
\bbox
\verb|# kadmin -l list *|\\
\ebox
La replicación debe ser controlada desde el maestro, normalmente se ejecutara cada cierto tiempo dependiendo del tamaño de la base de datos. En el esclavo lo normal es que hpropd se ejecute a traves de inetd, aunque puede ejecutarse como demonio.
\subsection{Replicación incremental - iprop}
Iprop es un servicio de replica incremental de la base de datos de Heimdal Kerberos, su idea es sencilla, es un log se van grabando las transacciones de la base de datos, cuando un cliente iprop se conecta se le envian las transacciones que este no haya ejecutado anteriormente.
Necesitaremos un usuario administrador, en nuestro caso lo llamaremos admin y le daremos permisos para que tenga administración remota:
\bbox
\verb| kadmin> add admin@CHAOSDIMENSION.ORG|\\
\verb| Max ticket life [unlimited]:|\\
\verb| Max renewable life [unlimited]:|\\
\verb| Attributes []:|\\
\verb| Password:|\\
\verb| Verifying password - Password:|\\
\ebox
Editamos el archivo kadmind.acl y añadimos el usuario administrador:
\bbox
\verb| admin@CHAOSDIMENSION.ORG all */*@CHAOSDIMENSION.ORG|\\
\ebox
Tanto en el maestro como en los servidores esclavos, con la configuración dns apuntando como servidor de dominio al servidor maestro, haremos:
\bbox
\verb|# ktutil get -p admin@CHAOSDIMENSION.ORG iprop/esclavo.hostname@CHAOSDIMENSION|\\
\verb|admin@CHAOSDIMENSION's Password:|\\
\ebox
Para hacer una replica del maestro, simplemente ejecutaremos \verb| #iprop-master &| en el servidor y en los servidor escalvos ejecutaremos:
\bbox
\verb|# iprop-slave maestro.hostname &|\\
\ebox
Para comprobar que la replicación esta bien hecha haremos en el esclavo:
\bbox
\verb|# kadmin -l list *|\\
\ebox
Esta replicación es incremental lo que significa que cada cambio en el servidor maestro es enviado automaticamente a los esclavos.
\subsection{Heimdal sobre ldap}
Vease en \ref{heimdal_ldap}
\subsection{Ventajas y desventajas}
Heimdal es un desarrollo con mucho futuro, mas aun cuando ha sido elegido como la implementación que llevara el futuro samba4, es thread safe lo que significa menor probabilidad de fallos y mejor rendimiento para aplicaciones que tiren directamente de el, como openLdap o samba4.
La replicacion iprop da numerosos problemas de estabilidad, asi que no es muy recomendada para replicación.
No tiene soporte de politicas de contraseñas, aunque se puede usar cracklib para la seguridad de las contraseñas, esto tiene que añadirse mediante un parche o a traves de aplicaciones externas.
\section{La configuración de clientes MS Windows}
\section{SASL}
\label{down_sasl}
\subsection{La configuración de SASL}
\subsection{Modulos para kerberos}
