Validación LDAP
Configuración de Samba
Otra de las piezas fundamentales es el servicio de samba para validación y compartir recursos en la red local. Vamos a preparar Samba para que mantenga su base de datos de usuarios en el directorio LDAP.
smb.conf para PDC con ldap
Primero necesitamos un controlador primario de dominio. Esta máquina será la que va a permitir iniciar sesiones de trabajo tanto en máquinas Linux como en máquinas Windows.
El primer paso para crear un PDC funcional en Samba es entender qué parámetros son necesarios en el fichero smb.conf. En el siguiente ejemplo podemos encontrar un caso de smb.conf para actuar como PDC. Lo ponemos primero para los impacientes y más tarde se describen algunos los parámetros. Puede encotrar detalles adicionales sobre la configuración de Samba como PDC (Controlador Primario de Dominio) en http://dns.bdat.net/documentos/samba/samba_pdc/.
[global] unix charset = LOCALE workgroup = BEZMILIANA netbios name = SAMBA1 interfaces = eth1, lo bind interfaces only = Yes # passdb backend = ldapsam:ldap://samba1.bez.ies passdb backend = ldapsam:ldap://localhost username map = /etc/samba/smbusers |
log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 50 |
smb ports = 139 445 name resolve order = wins bcast hosts time server = Yes printcap name = CUPS printing = cups show add printer wizard = No lpq command = lpstat -o %p lprm command = cancel %p-%j printer admin = Administrador, root, jose |
add user script = /usr/sbin/smbldap-useradd.pl -a -m '%u' delete user script = /usr/sbin/smbldap-userdel.pl '%u' add group script = /usr/sbin/smbldap-groupadd.pl -p '%g' delete group script = /usr/sbin/smbldap-groupdel.pl '%g' add user to group script = /usr/sbin/smbldap-groupmod.pl -m '%u' '%g' delete user from group script = /usr/sbin/smbldap-groupmod.pl -x '%u' '%g' set primary group script = /usr/sbin/smbldap-usermod.pl -g '%g' '%u' add machine script = /usr/sbin/smbldap-useradd.pl -w '%u' |
logon script = scripts\%u.bat logon drive = X: logon home = \\%N\%U\profile logon path = |
security = user
domain logons = Yes
preferred master = Yes |
domain master = Yes
os level =33
wins support = Yes |
ldap suffix = dc=bezmi,dc=es ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap admin dn = cn=rootr,dc=bezmi,dc=es ldap filter = (&(uid=%u)(objectclass=sambaSamAccount)) ldap ssl = off ldap passwd sync = Yes |
idmap backend = ldap:ldap://samba1.bez.ies idmap uid = 10000-20000 idmap gid = 10000-20000 |
map acl inherit = Yes [netlogon] path = /var/samba/netlogon read only = yes write list = root browseable=no [profiles] path = /home/%U/profile read only = no create mask = 0600 directory mask = 0700 |
El resto sería la descripción de los servicios que queremos que comparta el servidor.
A continuación vamos a describir las opciones fundamentales mostradas en este ejemplo:
passdb backend
passdb backend = ldapsam:ldap://localhost |
Aquí indicamos que tipo de base de datos tiene que usar Samba para guardar las datos de los usuarios y los grupos. Hemos puesto ldapsam y la dirección donde se encuentran el servidor para tener los datos en un directorio LDAP. Si vamos a usar Contoladores Secundarios de Dominio (BDC), la única elección lógica es usar LDAP para que el passdb backend se pueda distribuir.
Es posible indicar una lista de valores para este parámetro, por ejemplo:
passdb backend = tdbsam:/etc/samba/private/passdb.tdb smbpasswd:/etc/samba/smbpasswd |
Si ponemos varias bases de datos, estas se consultan en el mismo orden en el que se especifican, pero tenemos que tener en cuenta que los nuevos usuarios siempre se añaden a la primera base de datos especificada.
Parámetros de control del dominio
Los parámetros os level, preferred master, domain master, security, encrypt passwords y domain logons juegan un papel central para asegurar el control del dominio y las sesiones de red.
El parámetro os level tiene que tomar un valor superior a 32. Un controlador de dominio tiene que ser el examinador principal. El valor de parámetro controla el nivel en que se anuncia samba a si mismo para la elección de examinador.
Un controlador de dominio tiene que tener el modo de seguridad como user, tiene que admitir contraseñas cifradas compatibles con Microsoft y tiene que proporcionar el servicio de sesiones del dominio (domain logons). La contraseñas cifradas tienen que estar activadas.
Parámetros de entorno
Los parámetros logon path, logon home, logon drive y logon script definen los valores que determinan el entorno que ayudan a facilitar las operaciones de sesión y de control automático y de red.
logon path indica el directorio home donde se guardan los ficheros de perfiles (NTuser.dat para windows NT). A diferencia de versiones previas, no influye en los perfiels de W9X. Para gestionar los perfieles en Win 9X tenemos que usar logon home.
Esta opción toma las sustituciones estándar, por ejemplo %u para el nombe de usuari o %m para el nambre de máquina cliente, lo que permite tener script de conexión para cada usuario o máquina. También especifica el directorio desde el cual se cargan los contenidos de las carpetas "escritorio", "menú inicio", "programas" y "entorno de red" tal y como queremos que se muestren en los clientes Windows NT.
El usuario debe poder leer el servicio y la ruta para que las preferencias y los directorios se carguen en los clientes Windows NT. El recurso tiene que tener permiso de escritura, al menos la primera vez que el usuario se conecta, para que los clientes Windows NT puedan crear el fichero user.dat y otros directorios. Los directorio y cualquiera de los contenidos, pueden, si es necesario en nuestro caso, ponerse como sólo lectura. No es conveniente que el fichero NTuser.dat se haga de sólo lectura, renómbrelo como NTuser.man para llevar a cabo los efectos deseados ( MANdatory profile que impide su escritura).
logon home especifica la ubicación del directorio home cuando se conectan estaciones Win95/98 a un PDC Samba. Esto le permite hacer:
C:\>NET USE H: /HOME |
desde la línea de órdenes, o desde un script albergado en el servidor para poder montar en la máquina cliente el directorio personal que tiene el usuario en el servidor, por ejemplo.
Esta opción, al igual que vimos en el anterior parámetro, toma las sustituciones normales, permitiendole tener scripts distintos por usuario o máquina.
Este parámetro se puede usar con Win9X para asegurarse que los perfiles se almacenan en un subdirectorio del directorio personal del usuario. Esto se hace de la siguiente forma:
logon home = \\servidor\%u\perfil |
Tenga en cuenta que esta opción sólo es válida si Samba está configurado como logon server.
logon drive especifica la ruta local al cual se conectarán los directorios home las estaciones de trabajo NT. Tenga en cuenta que esta opción sólo es válida si Samba está configurado como logon server.
logon script especifica el fichero de lotes (.bat) o fichero de comandos NT (.cmd) que el cliente tiene que cargar y ejecutar cuando se conecta correctamente al dominio. El fichero debe tener el estilo de fin de línea de DOS (cr/lf). Se recomienda usar un editor estilo DOS para crear este fichero. El script debe ser relativo al path del servicio [netlogon]. Si el servicio [netlogon] especifica un path de /var/samba/netlogon y logon script = CONEX.BAT, entonces el fichero que se carga será:
/var/samba/netlogon/CONEX.BAT |
El contenido del fichero está enteramente a disposición del administrador. Se puede poner NET TIME \\SERVIDOR /SET /YES, para forzar a cada máquina que sincronice su reloj con el del servidor. Otro que se podría añadir sería NET USE U: \\SERVER\PROGRAMAS para las utilidades de uso común. Observe que es particularmente importante no permitir acceso de escritura al servicio [netlogon] o de escritura sobre los ficheros de lotes, o le permite a los usuarios modificar arbitrariamente los ficheros batch y comprometer la seguridad. Esta opción también toma las sustitucions estándar, permitiéndole tener scritps de logon separados para cada usuario o máquina.
Gestión de cuentas
Parte de la gestión del controlador del dominio se puede realizar de forma remota. Hay situaciones en las que el PDC tiene que añadir una cuenta de usuario grupo nueva y tenemos que enseñarle a hacerlo. Por ejemplo, cada máquina que se agrega al dominio necesita una cuenta de máquina en el servidor y lo ideal es que se cree automáticamente. También es posible, desde un cliente NT, añadir o eliminar grupos o usuarios. Los siguientes parámetros facilitan el desarrollo de todas estas acciones indicando el script que realiza la tarea.
add user script: Esta opción permite a Samba crear los usuarios UNIX requeridos bajo demanda cuando, porejemlo, un usuario del dominio que no está dado de alta en el servidor SAMBA accede al servidor Samba. Por ejemplo, podríamos poner:
add user script = /usr/sbin/smbldap-useradd.pl -a -m '%u' |
add machine script: Esta opción se ejecutará cuando agregue una máquina a su dominio. Los nombres de máquina terminan en "$". Por ejemplo, nos podría servir:
dd machine script = /usr/sbin/smbldap-useradd.pl -w '%u'
El resto de los parámetros tienen una características similares:
delete user script = /usr/sbin/smbldap-userdel.pl '%u' add group script = /usr/sbin/smbldap-groupadd.pl -p '%g' delete group script = /usr/sbin/smbldap-groupdel.pl '%g' add user to group script = /usr/sbin/smbldap-groupmod.pl -m '%u' '%g' delete user from group script = /usr/sbin/smbldap-groupmod.pl -x '%u' '%g' set primary group script = /usr/sbin/smbldap-usermod.pl -g '%g' '%u' |
El recurso NETLOGON
El recurso NETLOGON, como ya hemos visto en la descripción de los parámetros de configuración del PDC. Juega un papel central en las sesiones de dominio y en el soporte de la pertenencia al dominio. Este recurso está presente en todos los controladores de dominio Microsof. Se usa para proporcionar guiones o scripts de conexión, almacenar ficheros de políticas de grupo (NTConfig.POL) y otras herramientas que pueden ser necesarias para procesar las sesiones. Es un recuros esencial en un controlador de dominio.
Recurso PROFILES
Este recurso se usa para guardar los periles del escritorio. Cada usuario tiene que tener un directorio en la raíz de este recurso. Este directorio tiene que tener permiso de escritura para el usuario y tiene que tener permiso de lectura global.
Acceso a ldap
Samba tiene que comunicarse con el servidor LDAP con privilegios administrativos, pero como el fichero smb.conf tiene permoso de lectura es necesario guardar la clave de acceso en un fichero alternativo y accesible por samba, secrets.tdb. Para suministrar esta clave ejecutanmos:
smbpasswd -w clave |
y nos debe responder
Setting stored password for "cn=root,dc=bezmi,dc=es" in secrets.tdb |
Gestión de los usuarios del dominio
Podemos obtener información más detallada sobre gestión de usuarios en http://dns.bdat.net/documentos/usuarios/. Prácticamente todo lo que indica ese documento es aplicable cuando utilizamos LDAP como base de datos de usuarios.
Añadir un grupo
Para crear un grupo Samba utilizamos la interfaz de smbldaptools:
smbldap-groupadd samba |
Esta orden dispone de las mismas opciones que la orden groupadd y alguna adicional para utilzar con samba.
Añadir un grupo a Samba
Para crear un grupo Samba utilizamos la interfaz de smbldaptools:
smbldap-groupadd -a samba |
Con esto hemos creado un grupo llamado samba. La opción -a le añade al grupo creado las características de una cuenta de grupo Samba.
Añadir un usuario
Para añadir un usuario ejecutamos:
smbldap-useradd usuario |
Igual que antes con los grupos, conviene consultar el uso de useradd.
Añadir un usuario a Samba
Ahora tenemos que agregar los usuarios al dominio en la máquina con samba. En primer lugar, para Samba es necesario que cada usuario tenga una correspondencia con un usuario Unix, pero no tenemos de qué preocuparnos, nuestro script se encarga de ello:
smbldap-useradd -s /bin/false -g samba -a usuario |
La opción -a al igual que ocurría con los grupos significa que el usuario también incorpora las características de una cuenta samba de usuario. Si el usuario tuviera que hacer ciertas operaciones con el servidor podríamos asignarle otra shell, es decir cambiamos /bin/false por /bin/bash o indicar cual es el directorio personal, etc. Todos estos valores predeterminados que se asignan a los nuevos usuarios se definen al configurar smbldap-tools.
El resto de las operaciones se efectuarían de la misma forma con el script correspondiente.
Samba como BDC
Cliente ldap
En primer lugar tenemos que configurar /etc/nsswitch.conf y /etc/pam.d/ para que esta máquina se comunique con la base de datos LDAP del servidor.
Después tenemos que permitir los acceso administrativos al servidor LDAP. Como vimos en el caso del PDC:
root# smbpasswd -w clave Setting stored password for "cn=root,dc=bezmi,dc=es" in secrets.tdb |
Establecer el SID
Ahora establecemos el Idendificadorde Seguridad (SID) del PDC y guardarlo en el fichero secrets.tdb. En nuestro caso no es necesario, porque al usar una base de datos subyacente de tipo LDAP la máquina BDC tomael SID directamente del objeto sambaDomain y lo guarda. Parahacerlo explícityamente y almacenar en si en secrets.tdb ejecutamos :
net rpc getsid BEZMILIANA Storing SID=S-1-5-21-3251624699-4073233138-3422219849 for Domain BEZMILIANA in secrets.tdb |
Unirse al dominio
Cuando configuramos Samba como BDC basado en LDAP no es necesariohacer nada de particular para unirse al dominio, pero como winbind se comunica con el controlador de dominio de la máquina local y tiene que poder validarse, sí necesita que el BDC se una al dominio. El proceso de unión crea las cuentas necesarias.
Para unir el BDC Samba el dominio ejecutamos :
root# net rpc join -U root%claveroot Joined domain BEZMILIANA. |
Verificación de cuentas
Para comprobar que las cuentas de usuario y grupo estan disponibles para la gestión ejecutamos:
pdbedit -L |
y deberemos de obtener la lista de usuarios del dominio. E igualmente si ejecutamos
net groupmap list |
obtendremos una lista de cuentas de grupo samba con su SID y el correspondiente grupo UNIX asociado.
Fichero smb.conf para BDC
[global] unix charset = LOCALE workgroup = BEZMILIANA netbios name = BDC passdb backend = ldapsam:ldap://samba1.bezmi.ies username map = /etc/samba/smbusers |
log level = 1 syslog = 0 log file = /var/log/samba/%m max log size = 50 smb ports = 139 445 name resolve order = wins bcast hosts printcap name = CUPS show add printer wizard = No printing = cups printer admin = Administrador, root, pedro logon script = scripts\%u.bat logon path = \\%L\profiles\%U logon drive = X: domain logons = Yes domain master = No wins server = 172.16.0.1 ldap suffix = dc=bezmi,dc=es ldap machine suffix = ou=People ldap user suffix = ou=People ldap group suffix = ou=Groups ldap idmap suffix = ou=Idmap ldap admin dn = cn=root,dc=bezmi,dc=es idmap backend = ldap:ldap://samba1.bezmi.ies idmap uid = 10000-20000 idmap gid = 10000-20000 |
Samba cliente winbind
Ahora queremos que configurar el cliente para que realice búsquedas de usuarios en otro servidor y lo trate como un usuario local. Esta configuración consta de varios pasos, configurar samba y winbind, agregar el cliente al dominio, configurar la búsqueda de usuarios y configurar el sistema de validación.
Configuración Samba del cliente winbind
La configuración mínima del cliente sería, en smb.conf:
workgroup = BEZMILIANA security = domain winbind separator = + idmap uid = 10000-20000 idmap gid = 10000-20000 winbind enum users = yes winbind enum groups = yes template homedir = /home/samba/%D/%U template shell = /bin/bash winbind use default domain = no |
En primer lugar usamos el mismo grupo de trabajo o dominio y decimos que la validación de los usuario depende del controlador de dominio que es nuestro Samba.
Los parámetros "idmap" indican un rango de identificadores, uid y gid, para asignar en esta máquina a los usario remotos. Estos valores se recuerdan, es decir que una vez que winbind asigna un uid y un gid a un usuario, volverá a asignar el mismo en sucesivas conexiones. Los parámetros "enum" permiten la enumeración de usuarios. Es conveniente añadirla.
Los parámetros "template" indican qué valores asignará winbind a los usuarios como shell y directorio personal cuando el usuario del dominio haga un "login" en esta máquina cliente.
Por último "winbind use default domain" decide la forma de los nombres de usuarios. En nuestro caso, los nombres de usuarios serán BEZMILIANA+usuario, es decir, el nombre de usuario se construye usando el nombre del dominio, el signo "+" definido en "winbind separator" y por último el nombre del usuario del dominio.
Unir la máquina al dominio
Para unir la máquina al dominio ejecutamos:
root# net join -S BEZMILIANA -Uroot%claveroorpassword |
teniendo en cuenta que root tiene que ser usuario de samba en el servidor, y por supuesto, la contraseña también tiene que ser la contraseña samba de root en el servidor.
Aquí los problemas pueden surgir si el parámetro "add machine script" está mal configurado. Tras unir la máquina al dominio en el servidor se ha creado una cuenta con el nombre del cliente terminado en $.
Búsqueda de usuarios
Ahora hay que enseñar al linux cliente a que busque usuarios tambien en la red además de los que tenga definidos en su fichero /etc/passwd. Como vimos en la configuración de LDAP, esto se hace en el fichero /etc/nsswitch.conf. Lo editamos y modificamos para que las líneas correspondientes queden como:
passwd: files ldap winbind shadow: files ldap winbind group: files ldap winbind |
Cuando esta máquina busque un usuario primero lo hará en los ficheros locales, posteriormente busca en un directorio LDAP y por último pregunda a un servidor de dominio Samba/NT/200x en la red a través de winbind.
Configuración de PAM
Ahora tenemos que indicar como buscar las contraseñas para validar a los usuarios, esto se hace a través de pam. Vamos al directorio /etc/pam.d y buscamos el fichero de configuración de validación. En las distribuciones de Fedora por ejemplo editamos el fichero system-auth y lo dejamos como:
#%PAM-1.0 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 sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth sufficient /lib/security/$ISA/pam_smb_auth.so use_first_pass nolocal auth required /lib/security/$ISA/pam_deny.so account sufficient /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 account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_winbind.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 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 optional /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so session optional /lib/security/$ISA/pam_winbind.so |
Iniciar los servicios
Ahora reiniciamos Samba y winbind en el cliente:
/etc/init.d/smb restart /etc/init.d/winbind restart |
Si todo se ha configurado correctamente ya podemos usar en esta máquina los usuarios que hay en el servidor, pero primero algunas comprobaciones.
Ejecutamos:
wbinfo -u wbinfo -g |
Si no aparece algún error de validación ejecutamos:
wbinfo -a root%claveroot |
y volvemos a ejecutar las órdenes anteriores; nos deben aparecer los usuarios del dominio.
Ahora entramos en una consola y cuando apareca login: respondemos:
login BEZMILIANA+usuario password: contraseña_de_ususario |
y habremos iniciado una sesión local como un usuario remoto. Si no hemos creado el directorio /home/samba/usuario y no tenemos la línea
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 |
en el fichero /etc/pam.d/system-aut el sistema se queja pero inicia la sesión.
Migración de cuentas
Si cambiamos la ubicación de las cuentas del sistema también tendremos que disponer de las utilidades necesarias que sepan manipular los datos almacenados en el nuevo formato. En algunos casos sólo tendremos que instruir al sistema sobre como tiene que hacer las cosas ahora pero en otros casos tendremos que instalar nuevas herramientas que sepan entender el nuevo formato. Por ejemplo, para que el sistema busque un nombre de usuario sólo hay que decirle "busca también en tal sitio". Sin embargo, para cambiar un contraseña necesitamos una utilidad que sepa escribir en el sitio adecuado la nueva contraseña.
Para la migración de cuentas vamos a utilizar un script que viene con el paquete smbldap-tools que tendremos que tener instalado.
Sistema de nombres NSS
El sistema de nombres es una interfaz abstracta que permite seleccionar entre distintas fuentes para seleccionar un nombre en el sistema. Esta interfaz supone una gran versatilidad a la hora de seleccionar el origen de las cuentas de usuario. Podremos indicar que tome los datos de los ficheros locales, como /etc/passwd, que los tome de un servicio NIS, LDAP, de un DC Samba, etc.
Fichero /etc/nsswitch.conf
En este fichero sólo tenemos que indicar los sistemas subyacentes admitidos por cada base de datos de nombres y el orden en el que se deben hacer las consultas.
La parte del fichero que nos interesa debería quedar como:
passwd: files ldap shadow: files ldap group: files ldap |
Y con esto la búsqueda de nombres de usuarios primero se realizaría en los ficheros locales y después en el servidor LDAP. Si tuviéramos configurado winbind para buscar cuentas en servidores Samba/NT/200x remotos entonces también se podría añadir al fichero nsswitch.conf ese sistema de búsquedas:
passwd: files ldap winbind shadow: files ldap winbind group: files ldap winbind |
Sistema de validación PAM
El sistema PAM se utiliza para comprobar si unas credenciales son correctas. Puedes encontrar más detalles sobre la configuración de PAM en http://dns.bdat.net/documentos/samba/html/pam.html.Aquí sólo vamos a presentar los cambios necesarios.
Fichero /etc/pam.d/system-auth
Para que el sistema admita la validación de contraseñas contra una base de datos LDAP necesitamos configurar PAM
#%PAM-1.0 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 sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100 account required /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so password requisite /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 |
Podemos observar como añadimos las líneas que incluyen pam_ldap.so. Si quisiéramos que también se utilizara winbind como alternativa a la validación del sistema utilizaríamos:
#%PAM-1.0 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 sufficient /lib/security/$ISA/pam_winbind.so use_first_pass auth required /lib/security/$ISA/pam_deny.so account sufficient /lib/security/$ISA/pam_unix.so account [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_ldap.so account [default=bad success=ok user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/$ISA/pam_winbind.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 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 optional /lib/security/$ISA/pam_unix.so session optional /lib/security/$ISA/pam_ldap.so session optional /lib/security/$ISA/pam_winbind.so |
Creación de directorios personales
También podemos añadir al fichero system-auth la línea:
session optional pam_mkhomedir.so skel=/etc/skel/ umask=0022 |
para crear los directorios personales bajo demanda cuando iniciamos una sesión de trabajo.
configuración de smbldap-tools
Fichero /etc/smbldap-tools/smbldap.conf
No voy a copiar todo el fichero, pero conviene un correcta configuración, sobre todo en los valores predeterminados para los usuarios samba. Los parámetros imprescindibles para configurar son:
SID, que define el SID del dominio. Para averiguar su valor ejecutamos:
net getlocalsid |
y en el fichero tendremos algo como:
SID="S-1-5-21-3251624699-4073233138-3422219849" |
Para definir la conexión utilizamos:
masterLDAP="127.0.0.1" masterPort="389" |
donde deberemos poner los valores adecuados.
Y por último para indicar la raíz del árbol ldap con la que tiene que trabajar:
suffix="dc=bezmi,dc=es" |
El resto de los parámetros también se pueden modificar, por ejemplo si vamos a cambiar los nombres de alguna unidad organizativa o bien para modificar ciertos valores predeterminados para la creación de usuarios como son el shell que utiliza, el directorio personal, etc.
Fichero /etc/smbldap-tools/smbldap_bind.conf
Este fichero contiene las credenciales para realizar operaciones de escritura en el servidor ldap. Tiene que tener permisos 600 para evitar su lectura pública, contiene la contraseña de administración del árbol ldap:
############################ # Credential Configuration # ############################ # Notes: you can specify two differents configuration if you use a # master ldap for writing access and a slave ldap server for reading access # By default, we will use the same DN (so it will work for standard Samba # release) slaveDN="cn=root,dc=bezmi,dc=es" slavePw="clave" masterDN="cn=root,dc=bezmi,dc=es" masterPw="clave" |
Rellenar las cuentas LDAP
Una vez configurado el paquete smbldap-tools vamos a utilizar los scripts para duplicar todos los datos necesarios del sistema en el árbol ldap. Tendremos todas las cuentas del sistema repetidas, pero eso es inconveniente para un sistema Unix.
Para rellenar la base de datos ldap, ejecutamos:
smbldap-populate.pl |
Esta utilidad también crea en LDAP los usuarios samba existentes en el sistema.
Ahora unas pequeñas comprobaciones para asegurarnos que el servidor ldap está activo y contiene los datos necesarios.
Primero ejectamos:
slapcat |
para consultar directamente la base de datos. Nos debe de aparecer en plantalla la información de todas las cuentas del sistema.
Ahora realizamos unas consultas a la base de datos:
ldapsearch -x -b "dc=bezmi,dc=es" "(ObjectClass=*)" ldapsearch -x -W -D "cn=proxyuser,dc=bezmi,dc=es" -b "dc=bezmi,dc=es" "(ObjectClass=*)" ldapsearch -x -b "dc=bezmi,dc=es" "(ObjectClass=sambaSAMAccount)" ldapsearch -x -W -D "cn=proxyuser,dc=bezmi,dc=es" -b "dc=bezmi,dc=es" "(ObjectClass=account)" |
que deben mostrar los contenidos solicitados de la base de datos.
Para introducir datos iniciales en LDAP, también tenemos:
smbldap-migrate-accounts smbldap-migrate-groups |
para introducir sólo cuentas o grupos, además del ya citado
smbldap-populate |
Gestión de usuarios LDAP
Muy bien, ya tenemos todos los usuario del sistema integrados en la base de datos LDAP, pero ¿como los gestiono? ¿Donde están ahora useradd o passwd?¿Sirven estas utilidades?
Lamentablemente las utilidades clásicas de gestión de usuarios actúan sobre los ficheros del sistema, pero al tener ahora las cuentas de usuario integradas en la base de datos LDAP necesitamos unas herramientas específicas que sepan dialogar con LDAP.
No hay problema, smbldap-tools proporcionan esta interfaz con las utilidades:
smbldap-useradd smbldap-groupadd smbldap-userdel smbldap-groupdel smbldap-usermod smbldap-groupmod smbldap-usershow smbldap-groupshow smbldap-passwd |
que nos deben resultar familiares. Hay que resaltar que las opciones que admiten en la ejecución estas utilidades son las mismas que incluyen sus correspondientes utilidades clásicas. Además estas nuevas utilidades permiten la gestión de usuarios y grupos Samba.
Configuración LDAP
Cada elemento del árbol ldap tiene sus propiedades y una serie de valores asociados a las propiedades. Además estas propiedades son extensibles, es decir podemos agregar nuevas propiedades al servidor LDAP para adecuarse a nuestras necesidades. A estos conjuntos de propiedades los vamos a llamar esquema. En nuestro caso, además de los esquemas predeterminados, vamos a necesitar que el servidor LDAP almacene cuentas Samba, por lo que tendremos que asegurarnos que LDAP conoce la estructura y los datos necesarios de una cuenta Samba mediante la inclusión del correspondiente fichero de esquema. En el fichero /etc/openldap/spald.conf deberemos tener algo similar a:
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/samba.schema |