En la “Implementación de un dominio Linux con OpenLDAP” se explica cómo es posible configurar un sistema Linux como cliente LDAP. Esta sección recuerda los princpales conceptos relacionados e introduce las peculiaridades que aparecen cuando el sistema Linux debe ser cliente de un servidor LDAP Windows (es decir, de un servicio de Directorio Activo).
En general, Linux separa el acceso interno a las cuentas de usuario/grupo y la autentificación de usuarios en dos bibliotecas diferentes, denominadas respectivamente NSS y PAM. En ambos casos, estas bibliotecas pueden configurarse dinámicamente para obtener sus datos de múltiples fuentes alternativas (ficheros locales, servidores NIS, servidores LDAP, etc.). Si deseamos configurar el sistema Linux como cliente LDAP, debemos establecer que, para ambas bibliotecas, la fuente de información debe ser un servidor LDAP.
Si el cliente es un sistema Linux basado en RedHat, y el servidor
es otro sistema Linux ejecutando OpenLDAP, la configuración es
realmente sencilla: primero hay que asegurarse que está instalado
el paquete RPM nss_ldap (que contiene los
módulos LDAP para PAM y NSS) y posteriormente debemos ejecutar la
herramienta authconfig (también puede invocarse
su versión en modo gráfico,
redhat-config-authentication). En dicha
herramienta hay que activar la recepción de información de cuentas
y la autentificación de tipo LDAP, indicando en ambos casos la
dirección del servidor y la base o sufijo
LDAP. Internamente, esta herramienta modifica principalmente los
siguientes ficheros:
/etc/nsswitch.conf. Contiene la
configuración del cliente NSS del sistema Linux. En nuestro
caso, hay que comprobar que las líneas que configuran de dónde
hay que leer la información de usuarios, contraseñas
shadow y grupos incluyan la
opción ldap:
passwd: files ldap shadow: files ldap group: files ldap
/etc/pam.d/system-auth. Contiene la
configuración básica de autentificación del sistema Linux
mediante PAM. La herramienta authconfig
configura automáticamente los cuatro tipos de módulos
(auth, account,
password, y session) para
que utilicen LDAP como alternativa:
auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so password required /lib/security/$ISA/pam_cracklib.so retry=3 type= password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_ldap.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so
/etc/ldap.conf. Contiene la configuración
del cliente LDAP, independiente de su utilización por las
bibliotecas NSS o PAM. Si el servidor es un servicio OpenLDAP,
la herramienta authconfig realiza
automáticamente todos los cambios necesarios en este fichero.
Si el servicio LDAP contra el que el sistema Linux debe actuar es un Directorio Activo de Windows Server 2003, la configuración es similar a la explicada en la sección anterior, con las siguientes salvedades:
Aunque este no va a ser nuestro
caso, si la versión del paquete nss_ldap que
incorpora su distribución de Linux es antigua, es posible que
sus módulos no sean directamente utilizables y sea necesario
recompilarlos. Si fuera así, habría que seguir los siguientes
pasos:
Instalar el RPM que contiene los fuentes de
nss_ldap, es decir, el paquete
nss_ldap-207-11.src.rpm (donde "207-11"
corresponde con el número de versión concreta del paquete
contenido en la distribución, y es posible que en su caso sean
distintos).
Editar el fichero
/usr/src/redhat/SPECS/nss_ldap.spec y
comprobar si en la línea que comienza con
%configure está incluida la opción:
--enable-schema-mapping. En caso contrario,
debemos añadir esa opción e incrementar en uno el número de
versión del paquete (en la opción %Release
al principio del fichero, si por ejemplo era igual a "11"
ahora habrá que cambiarlo por un "12").
Si no ha sido necesaria la modificación del fichero, ya hemos acabado. En caso contrario, necesitaremos recompilarlo:
bash# cd /usr/src/redhat/SPECS bash# rpmbuild -ba --clean nss_ldap.spec
e instalarlo:
bash# rpm -Uhv usr/src/redhat/RPMS/i386/nss_ldap-207-12.i386.rpm
Igual que en el caso de OpenLDAP, se debe ejecutar authconfig para configurar automáticamente el cliente LDAP y los módulos NSS y PAM.
Sin embargo, en este caso, tras la ejecución de dicha
herramienta hay que modificar manualmente
el fichero /etc/ldap.conf. En concreto,
debemos conseguir que al final el conjunto de líneas útiles (no
comentadas) sea el siguiente, suponiendo que el dominio Windows
se denomina admon.lab:
host DC_DEL_DOMINIO base dc=admon,dc=lab deref never referrals no ldap_version 3 nss_base_passwd cn=Users,dc=admon,dc=lab?sub nss_base_group cn=Users,dc=admon,dc=lab?sub nss_map_objectclass posixAccount User nss_map_objectclass shadowAccount User nss_map_attribute uid sAMAccountName nss_map_attribute uniqueMember member nss_map_attribute homeDirectory msSFUHomeDirectory nss_map_objectclass posixGroup Group pam_login_attribute sAMAccountName pam_filter objectclass=user pam_password md5 ssl no
Las líneas nss_base_* especifican en qué
contenedores se ubican las cuentas de usuario y grupo, mientras
que las líneas nss_map_* asocian
adecuadamente los atributos de las cuentas de usuario y grupo a
sus correspondientes del Directorio Activo. Finalmente, las
líneas que comienzan por pam_* configuran PAM
para que sea compatible con dicho servicio de directorio.
Existe un ligero problema relativo a la exploración anónima del
directorio que debemos resolver: por defecto, el Directorio
Activo no permite realizar búsquedas anónimas (de usuarios no
autentificados) en la base de datos del directorio. Como la
biblioteca NSS de Linux realiza ese tipo de búsquedas, esto
puede ocasionar algunos problemas a la hora de visualizar los
nombres de usuarios y grupos (por ejemplo, en el
prompt del intérprete de órdenes
o al realizar un ls -l). Para solucionarlo
tenemos dos alternativas: configurar el Directorio Activo para
que permita las consultas anónimas o configurar el cliente LDAP
de Linux para que haga todas las consultas como un usuario
conocido por el dominio Windows (ya que por defecto, el grupo
Usuarios Autentificados tiene permisos de
lectura en todo el directorio).
Ambas alternativas tienen sus problemas de seguridad. En el
primer caso, admitir consultas anónimas en el Directorio Activo
no es buena idea si el DC es accesible por red desde el exterior
de la organización, puesto que el contenido del directorio
quedaría público a todo el mundo. En el segundo caso, el
usuario como el que se realizarían las consultas desde el
cliente Linux debe tener sus credenciales (usuario y contraseña)
en texto claro (sin cifrar) en el fichero
/etc/ldap.conf, que posee permisos de
lectura para cualquier usuario conectado localmente al sistema
Linux.
Quizás la opción menos comprometida sería la segunda, pero
utilizando además un usuario especial que sólo sirviera para ese
fin, y que no pudiera luego utilizarse para iniciar sesión en
los sistemas Linux o Windows del dominio. Si nos decantamos por
esta alternativa, se crearía primero un usuario global en el
Directorio Activo (por ejemplo, lectorlinux,
con contraseña xxxxxx) y incluiríamos las dos
líneas siguientes en el fichero
/etc/ldap.conf:
binddn cn=lectorlinux,cn=Users,dc=admon,dc=lab> bindpw xxxxxx
Posteriormente, podemos impedir que dicho usuario inicie sesión
en los sistemas Windows mediante la directiva de seguridad
Denegar incio de sesión local y en los
sistemas Linux poniendo como
shell en sus atributos UNIX el
fichero /bin/false.
Finalmente, hay algunos detalles menores que debemos considerar
para conseguir una configuración más efectiva: algunas de las
opciones de NSS pueden plantear problemas cuando el sistema LDAP
al que le preguntamos es un Directorio Activo. Este es el caso
de la opción automount, que produce un
bloqueo en el arranque del sistema Linux hasta que se produce un
timeout. Como de todas maneras no
vamos a incluir este tipo de opciones en el directorio, podemos
editar el fichero
/etc/nsswitch.conf y, en la línea
"automount: ...", eliminar la opción
ldap.
Hasta ahora hemos visto las posibilidades y características que ofrece un software como SAMBA para conseguir que diferentes clientes linux se integren en un dominio Windows. El métodfo empleado no es en si complicado pero requiere de una serie de conocimientos por parte del administrador. Este ha sido capaz de alterar el esquema del Directorio Activo para que soporte todas las características necesariás para que los clietnes linux se autentifiquen en un dominio Windows.
Pero los desarrolladores de SAMBA pretenden ofrecer una suite completa e indepemdiente que ofrezca las capacidades de integración requeridas sin tener que modificar ningún aspecto del Directorio Activo. Para ello han desarrollado winbind, un componente de SAMBA que permite solventar el problema de la autenticación unificada.
Winbind utiliza una implementación UNIX de las llamadas RPC de Microsoft, PAM (Pluggable Authentication Modules) y NSS (Name Service Switch) para permitir que los usuarios de un dominio Windows se muestren y actúen como usuarios Linux en máquinas Linux.
Winbind proporciona tres funciones independientes:
Autenticación de las credenciales de usuario via PAM. Como ya se vio, podremos ingresar en un sistema linux utilizando las cuentas de usuario y grupo de un dominio Windows (NT4, Active Directory o SAMBA).
Resolución de nombres de usuario y grupo via NSS.
Winbind mantiene una base de datos denominada winbind_idmap.tdb en la cual se almacenan los mapeos entre los UIDs y GIDs de Linux y los SIDs de NT. Este mapeo se utiliza solamente para usuarios y grupos que no tienen un UID/GID local. Si la opción idmap backend ha sido definida, entonces en vez de utilizar el mapeo local, winbind obtendrá dicha información del repositorio de base de datos pertinente que puede ser un servidor LDAP, un fichero XML ...
Winbind permite unificar la administración de cuentas UNIX y Microsoft Windows al permitir a una máquina Linux ser un miembro (completo) de un dominio Windows. Una vez dado este paso, la máquina linux reconocerá a los usuarios Windows como si fueran usuarios linxu nativos, de la misma manera que se utiliza NIS o LDAP en un entorno puramente Linux, gracias a que Winbind se enlaza con la libreria de resolución de nombres (NSS) del sistema Linux. El resultado final es que cualquier programa de la máquina Linux que pregunte al Sistema Operativo por un nombre de usuario o grupo, este le preguntará al controlador de dominio Windows. La única característica especial a considerar cuando se utiliza Winbind como método de resolución de usuarios y grupos es que los nombres de usuarios y grupos vienen precedidos por el nombre del dominio Windows al que pertenecen: DOMAIN\user. Esto es necesario, ya que permite a Winbind determinar que controlador de dominio tiene que utilizar para resolver el nombre de usuario o grupo en un entrono de red donde existen relaciones de confianza entre diferentes dominios. Además, Winbind proporciona un servicio de autenticación via PAM que proporciona la autenticación contra un dominio Windows de cualquier aplicación del sistema compatible con PAM.
Los pasos para configurar un cliente linux como miembro
nativo de un dominio Windows, se vieron en el apartado “Configuración de Samba en el nivel domain
”. Por tanto la configuración
necesaria es una pequeña variación del caso anterior con las
modificaciones siguientes:
Configuración del fichero /etc/samba/smb.conf.
Se necesita añadir varios parámetros al fichero smb.conf para controlar el comportamiento del servicio que implementa winbind (winbindd). El fichero de configuración que se muestra a continuación incluye las entradas necesarias en la sección [global].
[global] # separate domain and username with '\', like DOMAIN\username winbind separator = \ # use uids from 10000 to 20000 for domain users idmap uid = 10000-20000 # use gids from 10000 to 20000 for domain groups idmap gid = 10000-20000 # allow enumeration of winbind users and groups winbind enum users = yes winbind enum groups = yes # give winbind users a real shell template homedir = /home/winnt/%D/%U template shell = /bin/bash
Unir el cliente Linux al dominio Windows.
Todas las máquinas que desean participar en un dominio de seguridad necesitan ser miembros del dominio, incluidos los controladores de dominio (DCs). Para lograr este objetivo en un cliente Linux, tenemos que utilizar el comando net.
root# net rpc join -S PDC -U Administrador
Este comando permite comunicar con un controlador de dominio via llamadas RPC, para ello es necesario que el servicio smbd este corriendo. La respuesta sera "Joined the domain DOMAIN"
Ejecutar el servicio winbindd.
Winbind es un demonio (servicio) independiente de la suite SAMBA (smbd, nmbd). El comando que lo implementa se denomina winbindd. Para lanzarlo, teclearíamos en la shell lo siguiente:
root# /usr/sbin/winbindd
Para comprobar que dicho servicio resuelve los usuarios y grupos del dominio, podemos emplear la utilidad wbinfo.
root# wbinfo -u CEO\Administrator CEO\burdell CEO\Guest CEO\jt-ad CEO\krbtgt CEO\TsInternetUser root# wbinfo -g CEO\Domain Admins CEO\Domain Users CEO\Domain Guests CEO\Domain Computers CEO\Domain Controllers CEO\Cert Publishers CEO\Schema Admins CEO\Enterprise Admins CEO\Group Policy Creator Owners
Configuración de la resolución de nombres (NSS).
Una vez estamos seguros que el servicio winbind resuelve los nombres de usuarios y grupos, hay que conseguir que cualquier aplicación del sistema sea capaz de resolverlos tambien. En un sistema Linux se utiliza la libreria NSS para resolver el nombre de los diferentes objetos del sistema. El fichero de configuración que nos permite definir las fuentes de datos de NSS es /etc/nsswitch.conf.
passwd: files winbind shadow: files winbind group: files winbind
Una vez salvado el fichero comprobaremos que el sitema resuelve los mismos usuarios y grupos que resuelve winbind.
root# getent passwd CEO\burdell:15000:15003:Mary Orville:/home/winnt/CEO/burdell:/bin/bash
Configuración de la autenticación (PAM).
La libreria PAM utiliza una interfaz de modulos apilables que permiten cambiar su comportamiento y definir las fuentes de información de autenticación. En un sistema CentOS Linux, el funcionamiento de la libreria PAM se centraliza en un único fichero denominado /etc/pam.d/system-auth.
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required /lib/security/$ISA/pam_env.so auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account required /lib/security/$ISA/pam_unix.so broken_shadow account sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 quiet account [default=bad success=ok user_unknown=ignore] /lib/security/ $ISA/pam_winbind.so account required /lib/security/$ISA/pam_permit.so password requisite /lib/security/$ISA/pam_cracklib.so retry=3 password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/$ISA/pam_winbind.so use_authtok password required /lib/security/$ISA/pam_deny.so session required /lib/security/$ISA/pam_limits.so session required /lib/security/$ISA/pam_unix.so
system-config-authentication.
Los sistemas CentOS Linux vienen provistos con una herramienta de administración gráfica que permite configurar fácilmente los procesos de resolución y autenticacion de usuarios y grupos en un sitema Linux.
Identity Mapping (IDMAP).
Un aspecto de la configuración de winbind que hay que destacar es la forma en que este realiza la asociacion de identificadores de usuarios windows (SIDs) a identificadores de usuarios Linux (UIDs/GIDs).
Un sistema Linux necesita conocer los identificadores de usuario para funcionar. Winbind se encarga de ello automáticamente transformando el RID del usuario Windows en un UID para Linux. Pero esta información se almacena localmente en una base de datos. Por tanto cuando existen varios clientes Linux integrándose en un dominio Windows, necesitamos habilitar algún mecanismo central para albergar dicha información.
Winbind implementa una facilidad denominada IDMAP_RID que permite que todos los clientes generen el mismo par UID/GID para un mismo RID. IDMAP_RID no funciona en un dominio con relaciones de confianza.
[global] workgroup = DSIC2 netbios name = groucho realm = DSIC2.LOCAL server string = Office Server security = ADS allow trusted domains = No idmap backend = idmap_rid:DSIC2=500-100000000 idmap uid = 500-100000000 idmap gid = 500-100000000 template shell = /bin/bash winbind use default domain = Yes winbind enum users = No winbind enum groups = No winbind nested groups = Yes printer admin = "Domain Admins"