Última revisión de 10:49 2 ago 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.

<actualizacion> Al final el fichero de configuración ha quedado de la siguente forma

#**************************************************************
# Configuracion de Prisa Digital
# Pedro Miguel Blanco
# 30/07/2012
#**************************************************************

# Configuracion de LDAP seguro SSL
TLSCACertificateFile /etc/openldap/cacerts/pdsub.pem
TLSCertificateFile /etc/openldap/ldap.pem
TLSCertificateKeyFile /etc/openldap/ldapkey.pem


# Nivel de log (supuestamente con any se loga todo)
loglevel        any

# Definicion de metadirectorio
database        meta
suffix          "dc=local"
rootdn          "cn=manager,dc=local"
rootpw          "manager"
lastmod         off

# Conexion contra PRISADIGITAL para usuarios (conexion segura)
uri             ldaps://sdc3w2k8.prisadigital.int:636/ou=prisadigital,ou=usuarios,dc=local ldaps://sdc4w2k8.prisadigital.int:636
suffixmassage   "ou=prisadigital,ou=usuarios,dc=local" "ou=usuarios,dc=prisadigital,dc=int"
idassert-bind   bindmethod=simple binddn="cn=ldapuser,cn=users,dc=prisadigital,dc=int" credentials="K3alpc.-"

# Conexion contra PRISADIGITAL para grupos (conexion segura)
uri             ldaps://sdc3w2k8.prisadigital.int:636/ou=prisadigital,ou=grupos,dc=local ldaps://sdc4w2k8.prisadigital.int:636
suffixmassage   "ou=prisadigital,ou=grupos,dc=local" "ou=grupos,dc=prisadigital,dc=int"
idassert-bind   bindmethod=simple binddn="cn=ldapuser,cn=users,dc=prisadigital,dc=int" credentials="K3alpc.-"


#Mapeo de attributos y clases
overlay rwm
rwm-map         objectClass posixGroup group
rwm-map         objectClass posixAccount user
rwm-map         attribute uid SAMACCOUNTNAME
rwm-map         attribute HomeDirectory UNIXHOMEDIRECTORY

He dejado los rwm-map ya que no ha funcionado bien el map sencillo.

También se han agrupado los usurios y los grupos en dos OU separadas, en cada OU habrá otra para organización. De esta forma en los ficheros cliente podemos filtrar mejor cuando buscamos usuarios y grupos.

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, creando el fichero /etc/openldap/ms.schema

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

Configuración de cliente

Para que un cliente pueda ver los usuarios de este ldap tendremos que configurar el fichero ldap.conf de la siguiente forma:

uri                     ldap://sds01
base                    dc=local
scope                   sub
ldap_version            3
binddn                  cn=manager,dc=local
bindpw                  ******
nss_map_objectclass     shadowAccount User
nss_map_attribute       uid sAMAccountName

pam_password    md5
ssl     no
bind_policy soft
timelimit 120
bind_timelimit 5

Si en un cliente queremos que ciertos usuarios no sean consultados en ldap, y solo se consulten en la base de datos local tendremos que añadir la siguiente linea:

nss_initgroups_ignoreusers root,ldap,...

con la lista de usuarios que queremos que se ignoren en la consulta a ldap

Configuración con ldaps

Par que las conexiones sean seguras podemos usar este ejemplo:

uri                     ldaps://pxldap1.prisadigital.int
port                    636
ldap_version            3
base                    dc=local
binddn                  cn=manager,dc=local
bindpw                  manager

nss_base_passwd         ou=usuarios,?sub
nss_base_shadow         ou=usuarios,?sub
nss_base_group          ou=grupos,?sub
timelimit               120
bind_timelimit          5

nss_initgroups_ignoreusers root,ldap

Ademas en este ejemplo ya vemos como hemos desglosado las consultas para usuarios y para grupos con las líneas nss_base_passwd, etc.

Para que funcione la verificación de certificados hemos modificado el fichero /etc/openldap/ldap.conf para que tenga la siguiente línea:

TLS_CACERTDIR /etc/openldap/cacerts

y en ese directorio hemos puesto el subca y el rootca del emisor de nuestro certificado (el de prisa digital en mi caso)

PAM ldap

referencia

Para la configuración de PAM por ldap podemos seguir las instrucciones que vienen en esta página

Configuracion

Editamos el fichero ldap.conf para añadir las siguientes líneas:

#Configuracion PAM
pam_login_attribute     sAMAccountName
pam_filter              objectclass=User
pam_password            ad
pam_member_attribute    uniquemember
pam_groupdn             ou=grupos,dc=local?sub

de esta forma le estamos diciendo a LDAP como consulta la contraseña.

Ahora toca cambiar la configuración del PAM, para ello tenemos que editar el fichero /etc/pam.d/system-auth. Tendremos que añadir en la parte de auth el parámetro para que tire de ldap a la hora de buscar la contraseña. De paso añadimos tambien en la parte de session el pam_mkhomedir para que cree el directorio del usuario en caso de que no exista. Nuestro fichero queda de la siguiente forma:

auth        required      pam_env.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        sufficient    pam_ldap.so use_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session     required      pam_unix.so
session     required      pam_mkhomedir.so umask=0022 skel=/etc/skel

Logs slapd

Se puede configurar los logs de slapd en el fichero de configuración para que archiven diferentes tipos de mensajes:

1 trace function calls
2 debug packet handling
4 heavy trace debugging
8 connection management
16 print out packets sent and received
32 search filter processing
64 configuration file processing
128 access control list processing
256 stats log connections/operations/results
512 stats log entries sent
1024 print communication with shell backends
2048 print entry parsing debugging

Simplemente hay que añadir la suma de los valores que queremos que se archiven en el parámetro logleve de slapd.conf.

Estos logs se archivan a través de syslogd, si queremos almacenarlos en un fichero a parte tendremos que modificar el fichero de configuración de /etc/syslog.conf y añadir unas líneas como las siguientes:

# logs para ldap
local4.debug                                            /var/log/slapd.log

... sin olvidar reinicar el servicio syslogd

Pruebas con conexiones seguras

Desde el proxy a los backends

En las pruebas que he hecho para que los datos vayan en seguro desde el proxy al AD solo he tenido que cambiar en el fichero de configuración para que la conexión vaya por ldaps. Es decir, que en el parametro uri aparece algo así:

uri     ldaps://sdc3w2k8:636/ou=usuarios,ou=prisadigital,dc=local

El resto de configuraciones es igual.

Desde los clientes al proxyldap

(ejemplos en un sistema Centos)

Para la conexión segura a proxy tendremos que generar un certificado para el ldaps. En nuestro caso hemos generado una nueva llave:

# openssl genrsa –out ldapkey.pem 2048

Y hemos hecho una solicitud de certificado:

# openssl req –new –key ldapkey.pem –out ldap.csr 

Importante en este punto poner en el CN (common name) el nombre con el que vamos a hacer la consulta ldap.

El resultado de ese fichero lo hemos usado para hacer la petición en nuestra PKI de Windows, lo cual nos ha devuelto un certificado. De la entidad certificadora hemos sacado la llave pública del CA root y de la CA Subordinada y la hemos pasado al almacén de CA de confianza de Centos:

# Openssl x509 –in pdroot.pem –text >> /etc/pki/tls/certs.pem
# Openssl x509 –in pdsub.pem –text >> /etc/pki/tls/certs.pem

También las hemos puesto en el directorio /etc/openldap/cacerts En el fichero de configuración de slapd.conf hemos añadido las siguientes líneas:

# Configuracion de LDAP seguro SSL
TLSCACertificateFile /etc/openldap/cacerts/pdsub.pem
TLSCertificateFile /etc/openldap/ldap.pem
TLSCertificateKeyFile /etc/openldap/ldapkey.pem

Desactivar las consultas NO seguras

Si queremos que solo se hagan cosultas a traves del puerto ldaps tendremos que cambiar (en CENTOS) el fichero de configuración /etc/sysconfig/ldap.

SLAPD_LDAP=no
SLAPD_LDAPS=yes
SLAPD_LDAPI=no