Revisión de 18:22 23 jul 2012

Introducción

Se busca un sistema en el que las máquinas linux se validen con usurios gestionados en Active Directory de Microsoft. Además es un ambiente en el que habrá varios dominios, y en ambos dominios habrá usuarios que necesiten validarse en estas máquinas. (Administración de servidores compartida por dos dominios)

Que se necesita

• Sistema único de validación de usuarios en ssh
• Validación de aplicaciones web
• Multidominio

Algunas ideas

• Winbind
• LDAP proxy
  • producto de novel:https://www.netiq.com/documentation/ldapproxy/
  • posibiliad con slapd: http://linux.die.net/man/5/slapd-ldap
• Wikipedia sobre ldap: http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol#Extended_operations
• Referals: Son entradas de un LDAP que indican que el objeto que se está buscando está en otro servidor de directorio.

Pruebas con winbind

Para hacer estas pruebas he cogido un CENTOS 5.7. Este servidor esta en una red en la que existen dos dominios de windows:

• prisacomlab.lab
• intlab.prisadigital.lab

Estos dos dominios son una simulación de migración de usuarios de un dominio a otro. Para nuestra prueba es perfecto puesto que ya existe una relación de confianza entre ambos dominios.

La idea es ligar la máquina SDS02.intlab.prisadigital.lab (la máquina linux) contra el dominio intlab.prisadigital.lab, y ver si podemos validarnos con winbind y además usar usuarios del otro dominio con el que tenemos relación de confianza.

Instalación de paquetes inicial

Para empezar hemos instalado los siguientes paquetes:

• yum install samba-common
• yum install pam_krb5
• yum install sudo
• yum install authconfig

Hemos configurado el winbind para que arranque automáticamente:

• chkconfig winbind on

Y hemos comprobado que con hostname -f nos devuelve el fqdn completo del dominio en el que queremos validar la máqiuna:

# hostname -f
sds02.intlab.prisadigital.lab

Configuración de autenticación

Para hacer la configuración de los diferentes ficheros de configuración para la validación se puede usar el ejecutable authconf

# authconfig --disablecache --enablewinbind --enablewinbindauth --smbsecurity=ads --smbworkgroup=WORKGROUP --smbrealm=intlab.prisadigital.lab --enablewinbindusedefaultdomain --winbindtemplatehomedir=/home/EXAMPLE/%u --winbindtemplateshell=/bin/bash --enablekrb5 --enablekrb5kdcdns --enablekrb5realmdns --enablelocauthorize --enablemkhomedir --enablepamaccess --updateall

Este comando, tras su ejecución, debería reiniciar el servicio winbind. Si no es así lo lanzamos a mano:

# service winbind restart

Se habrán modificado varios ficheros con el authconf, entre los que se encuentran:

• /etc/nsswitch.conf
• /etc/krb5.conf
• /etc/samba/smb.conf
• /etc/pam.d/system-auth
• (...) seguro que alguno más

Metiendo linux en dominio

Ahora podemos poner el linux en dominio, para ello tendremos que usar el comando de samba net

# net ads join -U <usuario>

Ponemos la contraseña del usuario con privilegios de domain admin del dominino y automáticamente la máquina se añadirá. Nos sugiere que cambiemos el workgroup del fichero de configuración /etc/samba/smb.conf para que coincida con el de nuestro dominio. (en mi caso el doiminio es intlab.prisadigial.lab y el dominio es INTLABPDIGITAL

Fichero de configuración de samba

Mi fichero de configuración de Samba ha quedado como sigue a continuación:

 workgroup = INTLABPDIGITAL
   realm = INTLAB.PRISADIGITAL.LAB
   security = ads

   idmap domains = INTLABPDIGITAL PRISACOMLAB
   idmap config INTLABPDIGITAL:backend = rid
   idmap config INTLABPDIGITAL:default = yes
   idmap config INTLABPDIGITAL:range = 500 - 50000

   idmap config PRISACOMLAB:backend = rid
   idmap config PRISACOMLAB:default = no
   idmap config PRISACOMLAB:range = 50001 - 100000

#   idmap uid = 16777216-33554431
#   idmap gid = 16777216-33554431
   template homedir = /home/EXAMPLE/%u
   template shell = /bin/bash
#   winbind use default domain = true
   winbind offline logon = false
   winbind trusted domains = yes
   winbind trusted domains only = false

Mapeo de usuarios para el ID

Para cada uno de los dominios que hemos configurado le hemos dado un rango en el que se van a encontrar sus objetos, tanto usuarios como grupos.

Sospecho que al poner en el parámetro backend el valor RID lo que hace es coger el valor del ObjectSid único de cada objeto. En concreto coge el último de los valores.

Si hemos puesto un rango, por ejemplo de 50001 a 100000 lo que va a hacer es sumar el rango inferior (50000) a la ultima cifra del objectSid

Ejemplo. Mi usuario en el dominio PRISACOMLAB tiene el objectid:

S-1-5-21-2900016387-2670582172-2881881166-1970

y como en el dominio le hemos puesto el rango 50001, pues el ID de mi usuario PRISACOMLAB\pmblanco será el 51971

Añadiendo dominios de confianza

Si lanzamos el comando # wbinfo -u nos devuelve una lista de los usuarios que del dominio, y además de cualquier otro dominio con el que haya relación de confianza. Pero si queremos que esos usuarios sean tenidos en cuenta vamos a tener que especificarlo en el fichero smb.conf. Exactamente con el parámetro idmap domains, y además tendremos que añadir algunas entradas idmap config para especificar el rango en el que se van a mover los id's de los objetos del dominio, si es el dominio por defecto, etc.

Comunicaciones

Despues de analizar el tráfico que hay en la máquina cliente para poder recoger todos los datos de cada usuario del dominio PRISACOMLAB, me encuentro que las consultas no se hacen a través del controlador del dominio INTLABPDIGITAL (en el que está metido el samba de esta máquina) sinó que para consultar los datos de un usuario del dominio de confianza tiene que tener conectividad con el controlador de dominio de confianza...

Para probar que de verdad es así he filtrado el acceso a los controladores de dominio PRISACOMLAB con:

iptables -A OUTPUT -d 10.90.3.111 -j DROP
iptables -A OUTPUT -d 10.90.3.112 -j DROP

y efectivamente he dejado de poder consultar los usuarios del dominio PRISACOMLAB. De hecho con el comando wbinfo -u ya solo aparecen los usuarios del dominio INTLABPDIGITAL.

NOTA! Al perder la conectividad contra el DC del domino PRISACOMLAB, y después recuperarla, no podía consultar datos de los usuarios del dominio PRISACOMLAB. He esperado unos dos minutos y no había manera. Solo ha vuelto a funcionar reiniciando el servicio winbind. Aunque los usuarios sobre los que ya había realizado alguna consulta si que respondían, porque hay un cache el servicio WINBIND.

Pruebas con Referencias

Pasos iniciales

En Active Directory se pueden configurar Referals, que es básicamente como un enlace a otro servidor LDAP con el que extender las búsquedas. Esto se define en el RFC2251: El cliente al encontrarse con una de estas entradas podrá progresar en la petición buscando en el servidor al que hace referencia. OJO, esto debe estar configurado en la parte cliente, que cuando haga búsquedas ha de seguir en enlace. En el caso del cliente ldp de windows hay que indicar en la búsqueda que quieres "Chase Referrals" para seguir los enlaces externos.

Se puede encontrar una guía en ingles de los diferentes clases de referals que nos podemos encontrar en Active Directory y como crearlos:

Prueba en AD de laboratorio

Con el ADSI desde el servidor intlabdc01 abrimos la base de datos de configuraciones.

Dentro de las ocnfiguraciónes vamos a la parte de CN=Partitions y le damos a nevo.

For Select a class , you can create objects of only class crossRef , which is already selected. Click Next .

For the cn attribute, in the Value box, type a name that describes the location, and then click Next .

For the nCName attribute, in the Value box, type the distinguished name for the external domain, and then click Next .

For the dnsHostname attribute, in the Value box, type a DNS name for the server that hosts the domain directory partition, or type the domain name.

When you are sure that your entries are correct, click Finish .

Pruebas con SLAPD Proxy

Pasos iniciales

Antes de nada hay que informarse bien de que es SLAPD, en esta pagina explican bastante bien, aunque es de un manual de la universidad de Michigan muy antiguo (1996). Algo más actualizado nos lo podemos encontrar en guia de administracion de OpenLDAP (Feb 2012)

Con SLAPD seguimos con la filosofía de los referals, pero en este caso, SLAPD tiene un un "backend" que no envia los referals a los clientes, sinó que los resuelve el mismo antes de enviar la respuesta. Se detalla este tipo de configuración en la guia de administración en la parte de ldap backend

Configuración de OpenLDAP

para empezar instalamos en nuestro Centos 5.7 el openldap de paquetería:

# yum install openldap openldap-servers

Después hacemos una configuración básica de conexión contra un ldap. En nuestro caso vamos a conectar contra el servidor controlador del dominio intlab.prisadigital.lab (intlapdigital) intlabdc01.intlab.prisadigital.lab.

Esta configuración es muy básica:

database        ldap
suffix          ""
uri             ldap://intlabdc01.intlab.prisadigital.lab
lastmod         off

Para las pruebas, he creado un usuario para consultas en el dominio intlabpdigital, este usuario es cn=ldapuser,cn=users,dc=intlab,dc=prisadigital,dc=lab

Antes de hacer una consulta en local, vamos a probar que esa consulta funciona contra el servidor de dominio, para ello usamos el ldapsearch:

# ldapsearch -x -H "ldap://intlabdc01.intlab.prisadigital.lab" -D "cn=ldapuser,cn=users,dc=intlab,dc=prisadigital,dc=lab" -W

Esta ejecución nos devuelve los objetos del AD. Ahora toca aplicar la configuración que hemos indicado antes en nuestro fichero slapd.conf y al probar el mismo ldapsarch contra ldap://localhost tambien nos devuelve datos.

Como lo que vamos a intentar es juntar las consultas a dos DA diferentes, tendremos que hacer que la validación contra cada uno de ellos sea diferente. Para ello tendremos que añadir el siguiente parámetro a cada database:

database        ldap
suffix          "ou=usuarios,dc=intlab,dc=prisadigital,dc=lab"
uri             ldap://intlabdc01.intlab.prisadigital.lab
lastmod         off
acl-bind        bindmethod=simple binddn="cn=ldapuser,cn=users,dc=intlab,dc=prisadigital,dc=lab" credentials="********"

Después de estudiar un poco más veo que hay un backend especial para juntar varios servidores ldap en uno solo, que se llama meta (de metadirectorio). En el incluso se pude indicar que rama del meta directorio tiene los datos de cada servidor. Una configuración podría ser esta:

loglevel        256

access to dn.base="" by * read
access to dn.base="cn=Subschema" by * read
access to *
 by self write
 by users read
 by anonymous auth


database        meta
suffix          "dc=local"
rootdn          "cn=manager,dc=local"
rootpw          "manager"

#conexion contra INTLAPDIGITAL
uri             ldap://intlabdc01.intlab.prisadigital.lab/ou=ldap1,dc=local
suffixmassage   "ou=ldap1,dc=local" "ou=usuarios,dc=intlab,dc=prisadigital,dc=lab"
lastmod         off
idassert-bind   bindmethod=simple binddn="cn=ldapuser,cn=users,dc=intlab,dc=prisadigital,dc=lab" credentials="K3alpc.-"

#conexion contra PRISACOMLAB
uri             ldap://pcomlabdc01.prisacomlab.lab/ou=ldap2,dc=local
suffixmassage   "ou=ldap2,dc=local" "ou=PRISACOM usuarios,dc=prisacomlab,dc=lab"
lastmod         off
idassert-bind   bindmethotd=simple binddn="cn=ldapuser,cn=users,dc=prisacomlab,dc=lab" credentials="K3alpc.-"

Pero además podemos ya incluso cambiar los nombres de los campos para que sean apropiados para usar en linux. Para ello añadimos lo siguiente al final:

overlay rwm
rwm-map objectClass posixGroup group
rwm-map objectClass posixAccount user

Y en la parte de carga de módulos tenemos que cargar el módulo correspondiente a rewrite engine

# Modules available in openldap-servers-overlays RPM package
# Module syncprov.la is now statically linked with slapd and there
# is no need to load it here

moduleload /usr/lib/openldap/rwm.la

OJO, con la versión 2.3 que viene con centos no hace falta cargar ese modulo, ya que viene la misma funcionalidad en el core de slapd. No cargamos módulo, no hace falta poner overlay rwm, y la instrucción es map en vez de rwm-map. La estructura es la misma.

Añadido al esquema

Al arrancar el servicio ldap con esta configuración nos dará un aviso de advertencia porque no existe el objectclass "user". Y bien advertido porque en la versión que hemos probado nosotros de LDAP si no existe este objectclass en el esquema no podremos usar filtros con ese objeto.

En nuestro caso no funcionaba el hacer búsquedas con el filtro (objectclass=user). Se veía en el log de slapd que este era sustituido en la consulta por un (?=undefined), y no devolvía resultados.

Hemos intentando añadir un esquema que hemos encontrado por internet, que hacía referencia a ser el esquema de directorio activo, pero al cargarlo en el ficheor de configuración de slapd.conf nos daba un error al arrancar, porque había referencias a attributos que no existían.

Pero hemos hecho nuestra propia miniampliación al esquema:

objectclass ( 1.2.840.113556.1.5.9
        NAME 'user'
        SUP organizationalPerson
        STRUCTURAL )

objectclass ( 1.2.840.113556.1.5.8
        NAME 'group'
        SUP top
        STRUCTURAL )

y la hemos cargado en un include en el slapd.conf:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/ms.schema