Ver el código de «Red Hat Directory Server»

== Documentación ==


Guia de administracion RH Directory Server 8.2:
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/index.html

==Antes de la instalación==

El nombre de la máquina ha de estar en el DNS para poder acceder a la administración WEB del servicio, así que lo añadimos

Los nombres DNS que vamos a usar son sds01.prisacom.int y sds02.prisacom.int

==Instalación CENTOS DIRECTORY SERVER==

Referencias:

http://wiki.neddix.com/How_to_setup_the_CentOS_Directory_Server_(389_Directory_Server)

Siguiendo las instrucciones de esa página hacemos lo siguiente:

Desde centos 5.7 es una instalación sencilla del servicio, gracias al comando yum:

<pre>
yum install centos-ds
</pre>
 

Antes de hacer la instalación vamos a realizar algunos pasos necesarios para que funicone bien el ds

Creamos el usuario con el que se va a ejecutar el servicio:

<pre>
[root@sds01 ~]# useradd centos-ds
[root@sds01 ~]# id centos-ds
uid=500(centos-ds) gid=500(centos-ds) grupos=500(centos-ds)
</pre>

y comprobamos que hacer ping a localhost como al nombre del servidor, en este caso sds01, funciona bien

También hay que aumentar el numero de descriptores, o ficheros abiertos, de la siguiente forma:

<pre>
ulimit -n 8192
echo "* soft nofile 8192" >> /etc/security/limits.conf
echo "* hard nofile 8192" >> /etc/security/limits.conf
echo "ulimit -n 8192" >> /etc/profile
</pre>
 
Aconsejable es instalar el cliente de ldap
 
<pre>
yum install openldap-clients
</pre>
 
Después ya podemos hacer la instalación con el yum y ejecutar el script de configuración inicial del directory server:

<pre>
# setup-ds-admin.pl
</pre>
 
Continuamos la instalacion según las intrucciones que nos van apareciendo. Para empezar hacemos una instalación típica.

El usuario que hemos puesto para la administración del directory server es admin con password sistemas.

El dominio de administración que hemos usado es test.prisacom.int
 
Usamos el puerto 389, el dominio será dc=test,dc=prisacom,dc=int y el usuario de administración del ldap será cn=Directory Manager. El puerto de administración es el 9830

Una vez terminada la configuración aparece el siguiente mensaje:

</pre>
Creating directory server . . .
Your new DS instance 'sds01' was successfully created.
Creating the configuration directory server . . .
Beginning Admin Server creation . . .
Creating Admin Server files and directories . . .
Updating adm.conf . . .
Updating admpw . . .
Registering admin server with the configuration directory server . . .
Updating adm.conf with information from configuration directory server . . .
Updating the configuration for the httpd engine . . .
Starting admin server . . .
The admin server was successfully started.
Admin server was successfully created, configured, and started.
Exiting . . .
Log file is '/tmp/setupo5jSNl.log'
</pre>

Ahora que ya tenemos activo el servidor podemos editar el fichero /etc/sysconfig/dirsrv para descomentar el ulimit -n 8192
y tambien tenemos que añadir esto a los parametros de configuración dentro del ldap.

<pre>
echo -e "dn: cn=config\nnsslapd-maxdescriptors: 8192\n"|ldapmodify -x -h localhost -D "cn=Directory Manager" -W
</pre>
 
y reiniciar el servicio

<pre>
service dirsrv restart
</pre>

==Cliente para Windows ==

Si se quiere administrar el servicio de directorio desde windows se puede descargar un cliente desde la página: 

* http://directory.fedoraproject.org/wiki/Download

Para que este cliente funcione parece ser que hace falta tener instalado el jdk. Desués funciona como el cliente local centos-idm-admin


==Instálación de directorio activo==

Sin entrar en muchos detalles, se ha instalado el servidor sdc1w2k8, al que se le ha configurado el rol de servicios de directorio y se ha ejectuado un DCPROMO para crear el directorio activo psdtest.int

Además se ha quitado de la política global del domino la complejidad de contraseñas para facilitar las pruebas.

A su vez se ha creado una OU=test dentro de dc=psdtest,dc=int con una estructura de pruebas (tecnología y rrhh), y se han introducido tres usuarios.

(mas adelante se podría intentar hacer una sincronización de usuarios desde el directorio activo de prisacom para hacer pruebas más en real)

==Replicación multi-master==

Lo ideal para nuestro escenario es tener dos servidores sirviendo los usuarios, para tener capacidad de fail-over. Por ello vamos a investigar primero la capacidad de multi-master del ds.

Información detallada aqui:

http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Configuring_Multi_Master_Replication.html

Para cualquier tipo de replicación lo primero que hay que hacer es crear el usuario con el que se van a hacer las replicas.Esto se hace parando el servicio dirsrv y añadiendo al fichero /etc/dse.ldif esto al final... (por ejemplo)

<pre>
dn: cn=replication manager,cn=config
objectClass: inetorgperson
objectClass: person
objectClass: top
cn: replication manager
sn: RM
userPassword: password
passwordExpirationTime: 20380119031407Z
nsIdleTimeout: 0
</pre>

NOTAS: El passwordExpirationTime que se ha expecificado en el ejemplo es el dato para que no expire la contraseña

Una vez reiniciado el servicio ya tenemos creado el usuario cn=replication manager, cn=config

Resumiendo, estos son los pasos que hay que seguir para configurar la replicacion multi-master:

Vamos al nodo 1 y en la pestaña de configuración pinchamos sobre la carpeta replicación, y en la pestaña de Supplier Settings habilitamos el checkbox de Changelog, podemos usar el botón de fichero por defecto y podemos configurar un de las opciones de autolimpieza de log

Después seleccionamos dentro de la carpeta de replication la base de datos que queremos replicar, en nuestro caso la userRoot, que es donde está nuestro suffix dc=test,dc=prisacom,dc=int. Y ahí seleccionamos el habilitar la replica, en modo multiple Master. Mas abajo aparece la opción de id de replica, que tendrá que ser único, nosotros ponemos el 1 para el nodo sds01. También aparece el purge del log para hacer la limpieza del log, lo hemos configurado a 7 días. Más abajo aparece un dato importante, que es el Supplier DNs, donde especificaremos el usuario que hemos creado para replicas.

Repetimos estas operaciones para el nodo 2, especificando un Id diferente, en nuestro caso el 2

Volvemos al nodo1 y configuraremos nuestro primero Acuerdo de replicación, pinchando con el botón derecho sobre la base de datos que estamos replicando le decimos que queremos un nuevo acuerdo de replicación. Le ponemos nombre (Acuerdo MM) y una descripcion. Después especificamos el modo de comunicación entre los dos nodos, en nuestro caso, para las primeras pruebas hemos puesto que usaremos conexion LDAP normal, y le diremos que el modo de autenticación será la simple, especificando el usaurio de replicacon que hemos creado.

A continuación podemos filtrar campos, pero añadimos todos, y depués configuramos que la replicación no se haga preogramada si no que se haga continuamente. Al final le dcimos que haga la replicación inicial en ese momento.

De esta forma tenemos ya configurada la replicación en una dirección, para que sea multi-master tendremos que configurar el acuerdo de replicación en el sentido contrario, exactamente igual a como hemos configurado antes, e incluso iniciando la replica de nuevo en sentido contrario. (esto seguro que se puede omitir, pero no lo he probado)

==Sincronización con directorio activo==

Documentación sobre esto en la siguiente URL:
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Windows_Sync.html

Varias consideraciones que hay que tener en cuenta antes de ponerse con esto:

Para que se sincronizen las password hay que instalar un servicio en cada uno de los controladores del dominio.
La sincronización solo puede ir por SSL/TLS, así que hay que jugar con certificados.
Mas adelante explico como configurar esta sincronización.

==Servidor CA en windows==

He tenido que parar un poco para hacer la investigación sobre un CA para la nueva plataforma. Seguramente vamos a tener muchas más neceisdades de certificados, así que voy a proponer el poner un servidor de certificados internos para nuestros directorios activos.

Para la instalación del certificado solamente he añadido el Rol de Active Directory Certificate Services. lo que he creado ha sido un root CA y le he llamado psdtestCA.

==Habilitando comunicación SSL==

Referencia a la documentación de Directory Server:
http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_SSL.html

Aprovechando que la sincronización de contraseñas solo funciona si la comunicación se hace a través de SSL voy a terminar de configurar bien los Directory server bien para que admitan la comunicación encriptada.

Para ello, desde el administrador del directory server, en las "tasks", está la opción de administrar los certificados.

Si pinchamos en él nos aparecerá una venana de administración con las pestañas para añadir certificados de servidor y certificados raiz CA. La primera vez que entramos en ese administrador de certificados nos pedirá una contraseña para almacenar las claves privadas.

==Creando peticion de certificado==

En la pestaña de "server certs" podremos crear una solicitud de certificado, que después aplicaremos en nuestro servidor CA para generar el certificado que usaremos para las comunicaciones SSL. Al pulsar en Request tendremos que rellenar manualmente los datos de la petición (hay que rellenar todos los campos), y generaremos el DN de petición como este: CN="sds02.prisacom.int", OU="Sistemas", O="Prisa Digital", L="Madrid", C="ES"

Insertaremos la petición en nuestro almacen de claves privadas, y después guardaremos el fichero resultante para pasarselo a nuestro CA.

==Solicitando el certificado==

Ahora nuestra petición se la pasaremos a nuestro CA. En nuestro caso, cuando creamos la entidad certificadora, también añadimos soporte web para poder hacer las gestiones más fácilmente. http://10.90.3.68/certsrv/

Vamos a la opción "Request a certificate", y desde ahí a "advanced certificate request". En la siguiente opción elegimos la opción en la que ya facilitamos nosotros la petición, no tenemos que crearla. Vemos el contenido del fichero que hemos generado desde el administrador de certificados, y encontraremos la cadena de peitición que es algo así:

<pre>
-----BEGIN NEW CERTIFICATE REQUEST-----
MIIBpjCCAQ8CAQAwZjELMAkGA1UEBhMCRVMxDzANBgNVBAcTBk1hZHJpZDEWMBQG
(...)

PFZspTpgKq7f169HUnfaeRSmxLJ096bIdSOyAYWzTqTuOjjZSPQCGqHw
-----END NEW CERTIFICATE REQUEST-----
</pre>

La copiamos dentro del recuadro de "saved request" y le decimos que queremos un certificado de servidor Web... (el de usaurio no sirve)

Pinchamos en el botón de generar certificado y después le diremos que queremos descargar nuestro fichero de certificado en formato Base 64 encoded.

==Instalando certificado==

Ahora que ya tenemos el certificado lo podemos instalar, desde la pestaña de "Server certs" del adminstrador de certificados del directory server donde estábamos antes. Pulisamos el botón "install" y elegimos el fichero que nos hemos descargado antes desde el servidor de certificados de windows. Verificamos los datos y aceptamos. Damos un nombre a nuestro certificado "sds02-server-cert", y después, una vez puesta la contraseña de nuestro almacen de claves privadas, ya tenemos el certificado en nuestra lista.

==Añadiendo Certificado de entidad certificadora (CA)==

Para que la entidad certificadora con la que hemos creado nuestro certificado sea válida en nuestro directory server tendremos que descargarnos el certificado de nuestro CA de la web http://10.90.3.68/certsrv/, con el formato Base 64 encoded y la tendremos que instalar desde la pestaña CA Certs de nuestro administrador de certificados del directory server. Durante la instalación le diremos que sea válido tanto para aceptar conexiones desde los clientes como para hacer conexiones con otros servidores.


==Activación de la encriptación SSL==

Ahora que ya tenemos nuestro certificado podremos usarlo para las comunicaciones encriptadas. Desde el administrador de nuestro directory server, en la pestaña de "configuracion", pulsamos sobre el servidor y en la parte de la derecha, pulsamos en la pestaña de encriptación. 

Ahí tendremos la opción de habilitar el SSL para este servidor , y además tendremos que marcar el check de "Use this cipher family: RSA" donde veremos que está el certificado que hemos añadido antes. En la parte de Client Authentication dejaremos la opción de "Allow client authentication".


NO MARCAMOS LA OPCIÓN DE SSL IN CONSOLE TODAVÍA.


Grabamos los cambios que hemos hecho y tendremos que reinicar el servidor desde consola.

<pre>
# service dirsrv restart
</pre>
 
Nos pedirá la contraseña de la base de datos de claves privadas que hemos dado antes. (Hay forma de hacer que no la pida en cada reinicio)

==Configuración del admin server para que use conexión segura consultando directory server==

Para que la comunicación entre el servidor de adminstración y el propio ldap sea por conexión segura tendremos que editar las propiedades de este. Para ello, entrando en la configuracion del admin server tendremos que acceder a la administración de certificados (si es la primera vez nos pedirá que le demos una contraseña), y para que el admin server confíe en el certificado firmado por nuestra CA tendremos que añadirsela en la pestaña CA Certs, igual que hicimos para directory server.

Después, volviendo hacia atrás, vamos a la configuración del administration server y en la pestaña configuracion DS le decimos que queremos consultar el directory server usando conexión segura.

Una vez hecho esto tenemos que reinicar el dirsrv-admin desde la consola

 

==Añadiendo debug al log de errores==

Para subir el nivel de debug en el error log hay que tocar el parámetro nsslapd-errorlog-level de cn=config. Para saber que cifra hay que poner, dependiendo de que queramos hacer debug, podemos mirar la siguiente lista:

<pre>
1 — Trace function calls. Logs a message when the server enters and exits a function. 
2 — Debug packet handling. 
4 — Heavy trace output debugging. 
8 — Connection management. 
16 — Print out packets sent/received. 
32 — Search filter processing. 
64 — Config file processing. 
128 — Access control list processing. 
1024 — Log communications with shell databases. 
2048 — Log entry parsing debugging. 
4096 — Housekeeping thread debugging. 
8192 — Replication debugging. 
16384 — Default level of logging used for critical errors and other messages that are always written to the error log; for example, server startup messages. Messages at this level are always included in the error log, regardless of the log level setting. 
32768 — Database cache debugging. 
65536 — Server plug-in debugging. It writes an entry to the log file when a server plug-in calls slapi-log-error. 
131072 — Microsecond resolution for timestamps instead of the default seconds. 
262144 — Access control summary information, much less verbose than level 128. This value is recommended for use when a summary of access control processing is needed. Use 128 for very detailed processing messages. 
</pre>

más en:

http://docs.redhat.com/docs/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Configuring_Logs.html