Se explica en este articulo la implementación de una base de datos de usuarios centralizada mediante OpenLDAP, la implementación de un Controlador Primario de Dominio (PDC) mediante Samba, el cual utilizará la información del directorio LDAP para autenticar y asignar privilegios y restricciones, y la autenticación de usuarios desde terminales Linux/Unix mediante PAM/NSS
Si tiene la intención de realizar una implementación de pruebas previa a la implementación final se recomienda:
La implementación se llevará a cabo sobre un Sistema Operativo Debian GNU/Linux.
El software a utilizar será:
Se instalará todo el software de una vez, los paquetes de configuración de los diferentes servicios nos solicitarán cierta información, por ahora responderemos con cualquier dato ya que mas adelante reconfiguraremos los paquetes y la información será solicitada de nuevo. Puede, si quiere, responder con datos reales si cree conocer cuales son pero en este punto no es importante.
Para que ldap sea el soporte para samba debemos incorporarle la estructura de grupos y usuarios que samba necesita, esa estructura debe contar con ciertos atributos y esos atributos se definen en un schema, pero antes de incorporar esos atributos deberemos hacer una copia de nuestra base de datos.
La herramienta slapcat nos permite volcar el contenido de una base de datos ldap a un archivo de texto ldif (LDAP Directory Interchange Format). Hacemos un backup de la base de datos ahora:
Un schema (esquema) define el tipo de objetos que podemos manejar en nuestro arbol de directorio, sus atributos y sus reglas de sintaxis.
Slapd incluye por defecto los esquemas necesarios para almacenar informacion de cuentas Unix/Posix pero no incorpora soporte para el esquema de samba, afortunadamente el paquete samba-doc nos proveerá de uno. Simplemente haremos:
Es el archivo principal de configuración del servidor slapd. Hagamos una copia de respaldo del mismo antes de modificar el original:
Para generar el password utilizaremos la herramienta slappasswd, la clave que utilizaremos es la misma que la que se ingresó cuando se configuró slapd: ldapadmin.
No es requerimiento que sea la misma clave, pero utilizaremos la misma para evitar confusiones
La salida de slappasswd se utilizará como valor del parámetro rootpw en el archivo /etc/ldap/slapd.conf. Este parametro se establece para hacer posible la replicacion mediante syncrepl
Ahora reemplacemos el contenido del archivo /etc/ldap/slapd.conf con lo siguiete (no olvide de reemplazar el valor del parámetro rootpw con su hash):
# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options. #######################################################################
# Global Directives:
# Features to permit
#allow bind_v2
# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/samba.schema
# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile /var/run/slapd/slapd.pid
# List of arguments that were passed to the server
argsfile /var/run/slapd/slapd.args
# Read slapd.conf(5) for possible values
loglevel none
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_hdb
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu’s that is used
# for indexing.
tool-threads 1
#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# ‘backend’ directive occurs
backend hdb
#######################################################################
# Specific Backend Directives for ‘other’:
# Backend specific directives apply to this backend until another
# ‘backend’ directive occurs
#backend
#######################################################################
# Specific Directives for database #1, of type hdb:
# Database specific directives apply to this databasse until another
# ‘database’ directive occurs
database hdb
# The base of your directory in database #1
suffix «dc=esdebian,dc=org»
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn «cn=admin,dc=esdebian,dc=org»
rootpw {MD5}TmZgZ01/Z0/29bOPByMr4A==
# Where the database file are physically stored for database #1
directory «/var/lib/ldap»
# The dbconfig settings are used to generate a DB_CONFIG file the first
# time slapd starts. They do NOT override existing an existing DB_CONFIG
# file. You should therefore change these settings in DB_CONFIG directly
# or remove DB_CONFIG and restart slapd for changes to take effect.
# For the Debian package we use 2MB as default but be sure to update this
# value if you have plenty of RAM
dbconfig set_cachesize 0 2097152 0
# Sven Hartge reported that he had to set this value incredibly high
# to get slapd running at all. See http://bugs.debian.org/303057 for more
# information.
# Number of objects that can be locked at the same time.
dbconfig set_lk_max_objects 1500
# Number of locks (both requested and granted)
dbconfig set_lk_max_locks 1500
# Number of lockers
dbconfig set_lk_max_lockers 1500
# Indices to maintain for this database
index objectClass eq,pres
index ou,cn,sn,mail,givenname eq,pres,sub
index uidNumber,gidNumber,memberUid eq,pres
index loginShell eq,pres
## required to support pdb_getsampwnam
index uid pres,sub,eq
## required to support pdb_getsambapwrid()
index displayName pres,sub,eq
index nisMapName,nisMapEntry eq,pres,sub
index sambaSID eq
index sambaPrimaryGroupSID eq
index sambaDomainName eq
index default sub
index uniqueMember eq
index sambaGroupType eq
index sambaSIDList eq
# Save the time that the entry gets modified, for database #1
lastmod on
# Checkpoint the BerkeleyDB database periodically in case of system
# failure and to speed slapd shutdown.
checkpoint 512 30
# Where to store the replica logs for database #1
# replogfile /var/lib/ldap/replog
# users can authenticate and change their password
access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdMustChange,sambaPwdLastSet
by self write
by anonymous auth
by * none
# those 2 parameters must be world readable for password aging to work correctly
# (or use a priviledge account in /etc/ldap.conf to bind to the directory)
access to attrs=shadowLastChange,shadowMax
by self write
by * read
# all others attributes are readable to everybody
access to *
by * read
# For Netscape Roaming support, each user gets a roaming
# profile for which they have write access to
#access to dn=».*,ou=Roaming,o=morsnet»
# by dn=»cn=admin,dc=example,dc=com» write
# by dnattr=owner write
#######################################################################
# Specific Directives for database #2, of type ‘other’ (can be hdb too):
# Database specific directives apply to this databasse until another
# ‘database’ directive occurs
#database
# The base of your directory for database #2
#suffix «dc=debian,dc=org»
Como el archivo es muy extenso solo analizaremos las diferencias entre el archivo original y el nuevo, nos valdremos para eso de diff, si no conoce como funciona esta herramienta le bastará con saber que una linea que comienza con un + significa que ha sido agregada en el archivo nuevo y una que comienza con un – significa que la linea ha sido quitada, una linea sin nada significa que la linea permanece en ambos archivos.Por partes:
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
+include /etc/ldap/schema/samba.schema
Se ha agregado el esquema samba.schema para que sea incluido
-suffix «dc=example,dc=com»
+suffix «dc=esdebian,dc=org»
Se ha modificado el sufijo de la base de datos a esdebian.org
+rootdn «cn=admin,dc=esdebian,dc=org»
+rootpw {MD5}SCBBhdOlfHozkVbuKGZt5w==
Se han agregado las lineas que establecen el nombre (admin) y el password del administrador de la base de datos.
-index objectClass eq
+index objectClass eq,pres
+index ou,cn,sn,mail,givenname eq,pres,sub
+index uidNumber,gidNumber,memberUid eq,pres
+index loginShell eq,pres
+index uid pres,sub,eq
+index displayName pres,sub,eq
+index nisMapName,nisMapEntry eq,pres,sub
+index sambaSID eq
+index sambaPrimaryGroupSID eq
+index sambaDomainName eq
+index default sub
+index uniqueMember eq
+index sambaGroupType eq
+index sambaSIDList eq
Se ha agregado una gran cantidad de definiciones de índices. Al ser una base de datos, el incorporar índices acelerará las búsquedas lo cual es muy importante en un servidor atareado.
-access to attrs=userPassword,shadowLastChange
– by dn=»cn=admin,dc=example,dc=com» write
– by anonymous auth
+access to attrs=userPassword,sambaNTPassword,sambaLMPassword,sambaPwdMustChange,sambaPwdLastSet
by self write
+ by anonymous auth
by * none
-access to dn.base=»» by * read
+access to attrs=shadowLastChange,shadowMax
+ by self write
+ by * read
access to *
– by dn=»cn=admin,dc=example,dc=com» write
by * read
Se otorgan permisos a los usuarios para acceder y modificar sus passwords, entre otras cosas.
Para verificar la correctitud del archivo de configuración ejecutamos la herramienta slaptest:
# slaptest -v -u
config file testing succeeded
Y ya podemos reiniciar el servido slapd
# /etc/init.d/slapd restart
Contenidos
4.3- Pruebas Preliminares de servidor ldap
Hagamos una consulta al servidor LDAP para ver si responde correctamente. Con el comando ldapsearch consultaremos el namingContexts
:~ # ldapsearch -x -b » -s base ‘(objectclass=*)’ namingContexts # extended LDIF
#
# LDAPv3
# base with scope baseObject
# filter: (objectclass=*)
# requesting: namingContexts
#
#
dn:
namingContexts: dc=esdebian,dc=org
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Ahora haremos una busqueda en el directorio LDAP autenticado como el usuario admin del LDAP y haremos la buqueda usando como base dc=esdebian,dc=org, esto es para comprobar que la autenticación y nuestras ACLs funcionen correctamente, además de comprobar que el directorio se haya incializado con la estrucutra básica..
# requesting: ALL
# # esdebian.org
dn: dc=esdebian,dc=org
objectClass: top
objectClass: dcObject
objectClass: organization
o: esdebian.org
dc: esdebian
# admin, esdebian.org
dn: cn=admin,dc=esdebian,dc=org
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e2NyeXB0fWRuZ2QvVWtZMEdzbGc=
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2
4.4- La herramienta phpldapadmin
Esta es una herramienta alternativa que puede utilizar para gestionar el directorio LDAP. Resulta muy útil pero no es necesaria para realizar la configuración que se plantea en este artículo.
Si desea utilizar esta herramienta basta con instalarla:
# aptitude install phpldapadmin
Lo cual instalará una gran cantidad de software como dependencias, entre ellos apache2 y php5.
Una vez instalado el software ya puede acceder desde cualquier navegador mediante:
http://ip_del_servidor/phpldapadmin
Ingrese el nombre de usuario, en este caso cn=admin,dc=esdebian,dc=org, y la clave del mismo, en nuestro caso ldapadmin
Nota: si cuando definio rootpw en /etc/ldap/slapd.conf utilizo otro password en lugar de ldapadmin podra ingresar como cn=admin,dc=esdebian,dc=org utilizando cualquiera de los dos passwords
5- Configuración de Samba
5.1- El archivo /etc/samba/smb.conf
Abrir el archivo y modificar/Agregar los siguientes parametros:
# Archivo principal de configuración de Samba [global]
# Juego de caractreres para archivos dos y unix
dos charset = 850
Unix charset = ISO8859-1
# Nombre de dominio y nombre netBIOS
workgroup = ESDEBIAN
realm = esdebian.org
# Cadena con la cual se identifica al servidor
server string = %h server
# Comportamiento frente a usuarios inexistentes
map to guest = Bad User
# Archivo de mapeo de nombres de usuarios, este archivo no existe, por lo que debe crearse
# El contenido es de la forma usuario = alias
# Es util para mapear por ejemplo la cuenta de root con Administrator, la cuenta de
# administrador en sistemas windows
username map = /etc/samba/smbusers
# Informacion para la utilizacion del directorio LDAP como base de datos de usuarios
passdb backend = ldapsam:ldap://127.0.0.1/
ldap admin dn = cn=admin,dc=esdebian,dc=org
ldap delete dn = Yes
ldap group suffix = ou=group
ldap idmap suffix = ou=idmap
ldap machine suffix = ou=computer
ldap suffix = dc=esdebian,dc=org
ldap ssl = no
ldap user suffix = ou=people
add user script = /usr/sbin/smbldap-useradd -m %u
delete user script = /usr/sbin/smbldap-userdel %u
add group script = /usr/sbin/smbldap-groupadd -p %g
delete group script = /usr/sbin/smbldap-groupdel %g
add user to group script = /usr/sbin/smbldap-groupmod -m %u %g
delete user from group script = /usr/sbin/smbldap-groupmod -x %u %g
set primary group script = /usr/sbin/smbldap-usermod -g %g %u
add machine script = /usr/sbin/smbldap-useradd -w %u
# Informacion relacionada con la red (adaptar a sus necesidades)
socket options = TCP_NODELAY SO_RCVBUF=8192 SO_SNDBUF=8192
interfaces = eth0 lo
hosts allow = 127.0.0.1, 192.168.1.0/24
hosts deny = 0.0.0.0
smb ports = 139 445
bind interfaces only = Yes
name resolve order = wins hosts lmhosts bcast
remote announce = 192.168.1.255
# Cambio de contraseñas y otras opciones de PDC
pam password change = Yes
passwd program = /usr/sbin/smbldap-passwd -u %u
passwd chat = *New*password* %nn *Retype*new*password* %nn *all*authentication*tokens*updated*
# Script de inicio de sesion
logon script = ‘logon.bat %U’
# Esto hace que los usuarios posean perfiles movibles. Un perfil móvil implica
# que gran volumen de información se transmite a través de la red cada vez que
# un usuario inicia sesión. Para desactivar los perfiles móviles se debe dejar
# el parámetro con un valor vacío, como sigue: logon path = «»
# En este ejemplo se permiten perfiles móviles
logon path = \%Nprofiles%U
logon drive = U:
domain logons = Yes
os level = 65
preferred master = Yes
domain master = Yes
dns proxy = No
wins support = Yes
panic action = /usr/share/samba/panic-action %d
map acl inherit = Yes
case sensitive = No
hide unreadable = Yes
# Sincronizar password UNIX con passwords del dominio
unix password sync = Yes
# Loggiging
syslog = 0
log file = /var/log/samba/log.%m
max log size = 1000
#
# Sincroonizar la hora con el servidor PDC
time server = Yes
#
# Mapear atributos de archivo de Unix a Windows
# Estas opciones requieren que los parametros create mask y directory mask
# tenga activo el bit de ejecucion para «grupo» y «otros»
map hidden = Yes
map system = Yes
# Recursos compartidos
[homes]
comment = Home Directories
valid users = %S
read only = No
create mask = 0611
directory mask = 0711
browseable = No
path = /var/spool/samba
create mask = 0611
directory mask = 0711
printable = Yes
browseable = No [print$] comment = Printer Drivers
path = /var/lib/samba/printers
create mask = 0611
directory mask = 0711 [netlogon] path = /var/lib/samba/netlogon
browseable = No
create mask = 0611
directory mask = 0711 [profiles] path = /var/lib/samba/profiles
force user = %U
read only = No
create mask = 0611
directory mask = 0711
guest ok = Yes
profile acls = Yes
browseable = No
csc policy = disable [public] path = /tmp
read only = No
guest ok = Yes
create mask = 0611
directory mask = 0711
Se han incluido una seride de explicaicones dentro del archivo a modo de comentario. Seria mas que conveniente que no se limite a copiar el archivo, sino que lea los comentarios.
El archivo /etc/samba/smbusers
Preste atencion al parametro username map = /etc/samba/smbusers, que indica el archivo de mapeo de nombres de usuarios.
Este archivo no existe por lo que debe crearse, el contenido es de la forma usuario = alias y es util para mapear por ejemplo la cuenta de root con Administrator, la cuenta de administrador en sistemas windows
El contenido de /etc/samba/smbusers podria ser
# Archivo de mapeo de usuarios
# Formato: Unix_ID = Windows_ID
#
# Ejemplo:
# root = Administrator
# pepe = «Pepe Parada»
#
root = Administrator
root = Administrador
5.2- Crear los directorios netlogon y profiles
Creamos los directorios especiales netlogon y profile y le asignamos los permisos adecuados
# mkdir -p /var/lib/samba/netlogon /var/lib/samba/profiles
# chown -Rf root:root /var/lib/samba/netlogon /var/lib/samba/profiles
# chmod 1777 /var/lib/samba/profiles
5.2.1- Crear scripts de inicio de sesión
Un script de inicio de sesión Windows es un archivo bat con comandos que se ejecutarán del lado del cliente cuando un usuario inicie sesión. El script a utilizarse está definido por el parámetro logon script en la sección [global] de /etc/samba/smb.conf
Nosotros definimos el paramatro de la siguiente manera
logon script = ‘logon.bat %U’
Lo que indica al cliente que debe buscarse el archivo logon.bat en el directorio compartido netlogon.
Nosotros además hemos incluido %U en la definición, %U se reemplazará por el nombre de usuario y éste se pasará por parametro al script. Eso nos permitirá personalizar la acción dependiendo del usuario que inicia sesión.
Un script de inicio de sesión es utilizado frecuentemente para tareas como:
- Sincronizar la hora con el servidor
- Conectar unidades de red
- Vaciar directorios temporales
Un ejemplo de script de inicio de sesión podría ser:
@echo off
net time \debian-pdc /set /yes IF %1 == Administrador net use p: \debian-pdcroot
IF %1 == guest net use p: \debian-pdcpublico
5.2.2- Implementar Politicas de Sistema
A grandes rasgos, Políticas de Sistema es un mecanismo que se emplea en sistemas Microsoft Windows para esablecer ciertas condiciones que se imponen a los usuarios y procesos del equipo.
Cada equipo Windows define su “Políticas de Sistema” local. Cuando un usuario inicia sesión en un equipo que pertenece a un dominio, éste además descarga del servidor, si está disponible, el archivo de políticas Globales y las hace efectivas en el cliente. “Políticas de Sistema” cuenta con una jerarquía, la definición de una política local gobierna a una política global, mientras que una política globál solo se hará efectiva si no está definida esa política localmente.
No es la finalidad de este artículo dar una explicación detallada de Políticas de Sistema, simplemente se dará una breve explicación de como implementarlas en un dominio Samba.
En un entorno de Dominio las Políticas se materializan en un único archivo de nombre NTConfig.POL que se almacenará en el directorio compartido netlogon, de modo que los clientes acceden a este archivo a través de la ruta \debian-pdcnetlogonNTConfig.POL
Entonces implementar las políticas es muy simple, la complejidad radica en crear el archivo NTConfig.POL y ajustarlo a nuestras necesidades.
Para esto debemos obtener el software poledit.exe, lo que hacemos es, desde un equipo Windows NT compatible:
- Nos dirigimos al sitio de descargas de Microsoft Windows 2000: http://www.microsoft.com/windows2000/
- Descargamos el archivo “Windows 2000 Service Pack 4 Network Install for IT Professionals” (W2kSP4_EN.EXE)
- Descomprimimos el paquete con “W2kSP4_EN.EXE /x”
- Ejecutamos el archivo “adminpack.msi” para instalar las herramientas
- Corremos “poledit.exe”
Ya obtenido el software se puede crear un arhivo de Politicas de manera Standard, se asume que para implementar “Politias de Sistema” usted sabe que son y como se configuran.
Una vez ajustadas las politicas a nuestras necesidades simplemente debemos guardar el archivo como NTConfig.POL y copiarlo al servidor en el directorio compartido netlogon, en nuestro caso /var/lib/samba/netlogon
En http://www.pcc-services.com/custom_poledit.html se explica como configurar políticas de modo mas detallado y además se ofrecen plantillas personalizadas que usted puede utilizar.
NOTA: Esta configuración no es compatible para clientes Windows 98, cuyo archivo de políticas se denomina Config.POL y su estructura es diferente e incompatible. No se tratará en este artículo el caso de clientes Windows 98.
5.3- Comprobando la configuración e iniciando el servicio
Para comprobar la configuración de samba basta con ejecutar:
# testparm
Si todo es correcto ya podemas reiniciar el servicio:
# /etc/init.d/samba restart
Y ahora le indicamos a samba la clave de nuestro usuario admin especificado en smb.conf para que pueda así acceder y modificar nuestro directorio ldap, en nuestro caso la clave que utilizamos es ldapadmin
# smbpasswd -W
Setting stored password for «cn=admin,dc=esdebian,dc=org» in secrets.tdb
New SMB password: ldapadmin
Retype new SMB password: ldapadmin
La clave se almacenará en /var/lib/samba/secrets.tdb, asegurémonos que los permisos de dicho archivo sean los adecuados
# ls -l /var/lib/samba/secrets.tdb
-rw——- 1 root root 8192 2008-06-18 23:29 /var/lib/samba/secrets.tdb
5.4- La herramienta SWAT (Samba Web Administration Tool)
Esta herramienta resulta muy útil para configurar un servidor samba, cuenta con una interfaz a la cual se accede a través de un navegador web y permite modificar todos los parametros de smb.conf a la vez que cuenta con toda la información de las paginas man para cada parámetro de configuración.
Al igual que cuando se describió la herramienta phpldapadmin, esta herramienta tampoco es necesaria para la configuración que se propone en este articulo.
Para instalar swat, simplemente hacer:
# aptitude install swat
El servicio Swat corre bajo el superserver inetd, por lo que debemos decirle a inetd que active el servicio
# update-inetd –enable ‘swat’
Ahora ya podemos acceder desde cualquier navegador ingresando en la barra de direcciones
http://ip_del_servidor:901
6- Configuración de smbldap-tools
El archivo de configuración de smbldap-tools es /etc/smbldap-tools/smbldap.conf, en dicho archivo se definen los parámetros básicos como servidor ldap, servidor samba, tipo de comunicación (cifrada o en claro), dominio, SID, etc.
Además necesita contar con el archivo smbldap_bind.conf, en dicho archivo se almacenará en claro la información necesaria para la conexión con el servidor ldap
6.1- Obteniendo los archivos de configuración
Si ingresamos al directorio /etc/smbldap-tools/ nos encontraremos con que está vacío, Afortunadamente podemos obtener los archivos de configuración desde los archivos de ejemplo de smbldap-tools
# zcat /usr/share/doc/smbldap-tools/examples/smbldap.conf.gz > /etc/smbldap-tools/smbldap.conf
# cp /usr/share/doc/smbldap-tools/examples/smbldap_bind.conf /etc/smbldap-tools/smbldap_bind.conf
Los permisos de /etc/smbldap-tools/smbldap.conf y /etc/smbldap-tools/smbldap_bind.conf deberian ser 640, propiedad de root y grupo openldap.
# chmod 640 /etc/smbldap-tools/smbldap.conf /etc/smbldap-tools/smbldap_bind.conf
# chown root:openldap /etc/smbldap-tools/smbldap.conf /etc/smbldap-tools/smbldap_bind.conf
6.2- Obteniendo el SID
El SID (security identifiers) es un identificador único asignado desde su creación a cada objeto dentro de un dominio. Todo objeto en el dominio tiene un SID y, claro, el controlador de dominio también tiene uno.
Para obtener nuestro SID hacemos:
# net getlocalsid
SID for domain DEBIAN-PDC is: S-1-5-21-3991131808-1853181808-1058153799
Guardemos el SID, ya que lo necesitaremos cuando configuremos /etc/smbldap-tools/smbldap.conf
NOTA: Probablemente nos encontremos con algun mensaje de error cuando ejecutamos net getlocalsid, eso se debe a que el paquete smbldap-tools aún no esta configurado. Sin embargo el SID nos será mostrado correctamente
6.3- El archivo /etc/smbldap-tools/smbldap.conf
Antes de modificar el archivo original hagamos una copia de respaldo mismo
cp /etc/smbldap-tools/smbldap.conf{,.original}
Ahora modifiquemos los siquientes parametros, no olvidar reemplazar el SID por el obtenido con net getlocalsid
# El sid obtenido mediante net getlocalsid
SID=»S-1-5-21-669132894-2586221759-3914214969″ # Nuestro dominio netBIOS
sambaDomain=»ESDEBIAN»
# Informacion del servidor LDAP primario y esclavo
slaveLDAP=»127.0.0.1″
slavePort=»389″
masterLDAP=»127.0.0.1″
masterPort=»389″
# No utilizar conexión cifrada
ldapTLS=»0″
# Sin importancia ya que no se utiliza TLS
verify=»require»
cafile=»/etc/smbldap-tools/ca.pem»
clientcert=»/etc/smbldap-tools/smbldap-tools.pem»
clientkey=»/etc/smbldap-tools/smbldap-tools.key»
# Sufijo LDAP
suffix=»dc=esdebian,dc=org»
# Donde se almacenan los usuarios, grupos, computadoras y idmapdn
usersdn=»ou=people,${suffix}»
computersdn=»ou=computer,${suffix}»
groupsdn=»ou=group,${suffix}»
idmapdn=»ou=idmap,${suffix}»
sambaUnixIdPooldn=»sambaDomainName=${sambaDomain},${suffix}»
# Default scope
scope=»sub»
# Tipo de cifrado UNIX (CRYPT, MD5, SMD5, SSHA, SHA, CLEARTEXT)
hash_encrypt=»CRYPT»
crypt_salt_format=»%s»
# Especifico para cuentas UNIX, shell, ruta al home y demás
userLoginShell=»/bin/bash»
userHome=»/home/%U»
userHomeDirectoryMode=»700″
userGecos=»System User»
defaultUserGid=»513″
defaultComputerGid=»515″
skeletonDir=»/etc/skel»
defaultMaxPasswordAge=»365″
# Configuración especifica para cuentas SAMBA
userSmbHome=»\debian-pdc%U»
userProfile=»\debian-pdcprofiles%U»
userHomeDrive=»U:»
userScript=»logon.bat %U»
mailDomain=»esdebian.org»
# Especifico de smbldap-tools
with_smbpasswd=»0″
smbpasswd=»/usr/bin/smbpasswd»
with_slappasswd=»0″
slappasswd=»/usr/sbin/slappasswd»
6.4- El archivo /etc/smbldap-tools/smbldap_bind.conf
/etc/smbldap-tools/smbldap_bind.conf es el archivo de credenciales, en el se almacenará en claro la clave de administrador del servidor ldap. El contenido deberia ser:
slaveDN=»cn=admin,dc=esdebian,dc=org»
slavePw=»ldapadmin»
masterDN=»cn=admin,dc=esdebian,dc=org»
masterPw=»ldapadmin»
Se puede definir un servidor LDAP esclavo, el cual solo se utilizará para consultas, y un servidor primario, el cual se utilizará para escrituras. En nuestro caso, y por el momento, utilizaremos el mismo servidor.
Está de mas decir que si se utilizan dos servidores LDAP, estos deben estar sincronizados.
6.5- Poblando el directorio LDAP con el Schema Samba – La herramienta smbldap-populate
Una vez configuradas las herramientas smbldap-tools, podemos inicializar nuestro dominio esdebian.org
La herramienta smbldap-populate poblará nuestro directorio LDAP con:
- Base DN: dc=esdebian,dc=org
- Unidad Organizativa people(ou=people) para las cuentas Unix/Samba: se crearán por defecto los usuarios root y nobody los cuales serán mapeados al usuarios Administrador y Guest Samba respectivamente.
- Unidad Organizativa Groups (ou=Groups) para los Grupos Unix/Samba: se crearán por defecto los Grupos Predeterminados de un dominio Samba: Domain Admins, Domain Users, Domain Guests, Domain Computers
- Unidad Organizativa Computers (ou=Computers) para las cuentas de Computadoras Windows
- Unidad Organizativa Idmap (ou=Idmap) para los mapeos de Cuentas Unix a Cuentas Samba/Windows (Relaciones UID SID)
Tambien se nos solicitará que asignemos una contraseña al usuario root del dominio, le pondrémos la clave dominioadmin
Corramos el comando smbldap-populate
# smbldap-populate
Populating LDAP directory for domain ESDEBIAN (S-1-5-21-669132894-2586221759-3914214969)
(using builtin directory structure) entry dc=esdebian,dc=org already exist.
adding new entry: ou=people,dc=esdebian,dc=org
adding new entry: ou=group,dc=esdebian,dc=org
adding new entry: ou=computer,dc=esdebian,dc=org
adding new entry: ou=idmap,dc=esdebian,dc=org
adding new entry: uid=root,ou=people,dc=esdebian,dc=org
adding new entry: uid=nobody,ou=people,dc=esdebian,dc=org
adding new entry: cn=Domain Admins,ou=group,dc=esdebian,dc=org
adding new entry: cn=Domain Users,ou=group,dc=esdebian,dc=org
adding new entry: cn=Domain Guests,ou=group,dc=esdebian,dc=org
adding new entry: cn=Domain Computers,ou=group,dc=esdebian,dc=org
adding new entry: cn=Administrators,ou=group,dc=esdebian,dc=org
adding new entry: cn=Account Operators,ou=group,dc=esdebian,dc=org
adding new entry: cn=Print Operators,ou=group,dc=esdebian,dc=org
adding new entry: cn=Backup Operators,ou=group,dc=esdebian,dc=org
adding new entry: cn=Replicators,ou=group,dc=esdebian,dc=org
entry sambaDomainName=ESDEBIAN,dc=esdebian,dc=org already exist. Updating it…
Please provide a password for the domain root:
Changing UNIX and samba passwords for root
New password: dominioadmin
Retype new password: dominioadmin
La clave solicitada, dominioadmin, es la clave de nuestro usuario Administrador, el administrador del dominio que está mapeado a la cuenta root. Es la clave que debemos utilizar para, por ejemplo, agregar un equipo al dominio.
6.6- Testeando la configuración de Samba y ldap
Mediante la herramienta pdbedit testearemos que el servidor ldap se comporta como nosostros esperamos, listemos los usuarios del directorio
# pdbedit -L
root:0:root
nobody:65534:nobody
Veamos la información de nuestro usuario root
# pdbedit -Lv root
Unix username: root
NT username: root
Account Flags: [U ]
User SID: S-1-5-21-669132894-2586221759-3914214969-500
Primary Group SID: S-1-5-21-669132894-2586221759-3914214969-513
Full Name: root
Home Directory: \debian-pdcroot
HomeDir Drive: U:
Logon Script: ‘logon.bat root’
Profile Path: \debian-pdcprofilesroot
Domain: ESDEBIAN
Account desc:
Workstations:
Munged dial:
Logon time: 0
Logoff time: never
Kickoff time: never
Password last set: lun, 18 ene 2010 09:07:47 ART
Password can change: lun, 18 ene 2010 09:07:47 ART
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
La cuenta root que se creo en el directorio LDAP, es la que se usará como usuario root local y como administrador de dominio, asignemosle un home y un shell:
# smbldap-usermod -d /root -s /bin/bash root
Probemos ahora conectarnos mediante smbclient:
# smbclient //localhost/netlogon -U root
Enter root’s password: dominioadmin
Domain=[ESDEBIAN] OS=[Unix] Server=[Samba 3.2.5]
smb: >
Podemos testear el funcionamiento de los alias de root que definimos antes en el archivo /etc/samba/smbusers, Administrador y Administrator
~# smbclient //localhost/netlogon -U administrador
Enter administrador’s password: dominioadmin
Domain=[ESDEBIAN] OS=[Unix] Server=[Samba 3.2.5]
smb: > quit
~# smbclient //localhost/netlogon -U administrator
Enter administrator’s password: dominioadmin
Domain=[ESDEBIAN] OS=[Unix] Server=[Samba 3.2.5]
smb: > quit
~#
7- Configuración de PAM/NSS
El servicio NSS (Name Service Switch) provee una interface para configurar y acceder a diferentes bases de datos de cuentas de usuarios, la forma mas básica y conocida es acceder a la información de los usuarios locales mediante los archivos /etc/passwd y /etc/shadow, /etc/group, /etc/hosts, etc. Sin embargo se pueden implementar otros mecanismos para ello.
PAM (Pluggable Authentication Modules) es un mecanismo de autenticación flexible que permite abstraer las aplicaciones y otro software del proceso de identificación. El módulo PAM, según como se haya configurado, accederá a la información y determinará su identidad, autenticidad, privilegios y limitaciones entre otras cosas.
Entonces, la combinación PAM/NSS nos provee una capa de abstracción que nos permite obtener la información de usuarios y su identidad sin importar que dicha información sea almacenada en un simple archivo de texto plano (/etc/passwd) o un complejo directorio ldap.
Nos daremos cuenta luego que, al acceder tanto PAM como NSS a la misma base de datos, la configuración de ambos es la misma.
7.1- Configuración de libnss-ldap
El paquete libnss-ldap es el nexo que permitirá el servicio NSS acceder y utilizar la información en el directorio LDAP. Reconfiguremos el paquete mediante:
# dpkg-reconfigure libnss-ldap
Y respondamos a las siguientes preguntas:
- Identificador de recursos para el servidor LDAP: ldap://127.0.0.1/
- El nombre distintivo (DN) de la base de búsquedas: dc=esdebian,dc=org
- Versión de LDAP a utilizar: 3
- ¿Hace falta un usuario para acceder a la base de datos LDAP?: No
- ¿Dar privilegios especiales de LDAP para root?: Sí
- ¿Desea hacer que la configuración sólo la pueda leer o escribir el propietario? Sí
- Cuenta LDAP para root: cn=admin,dc=esdebian,dc=org
- Contraseña para la cuenta LDAP de root: ldapadmin
El demonio nscd (Name Service Cache Daemon) es una caché de nombres para el servicio NSS. Acelera de forma significativa las consultas pero puede hacernos pasar malos ratos durante la configuración. Detengamos el servicio por ahora
# /etc/init.d/nscd stop
7.1.1- El archivo /etc/libnss-ldap.conf
/etc/libnss-ldap.conf es el archivo de configuración de libnss-ldap. Allí se podrían almacenar en claro alguna clave, no en nuestro caso pero debe igualmente asegurarse que los permisos son restrictivos. Propietario root, grupo root y permisos 600.
Busque y reemplace el contenido de las siguientes lineas:
base dc=esdebian,dc=org
uri ldap://127.0.0.1/
ldap_version 3
rootbinddn cn=admin,dc=esdebian,dc=org
bind_policy soft
pam_password crypt
nss_base_passwd dc=esdebian,dc=org?sub
nss_base_shadow dc=esdebian,dc=org?sub
nss_base_group ou=group,dc=esdebian,dc=org?one
7.1.2- El archivo /etc/libnss-ldap.secret
/etc/libnss-ldap.secret es el archivo de credenciales. Allí se almacena en claro la clave de root del servidor ldap, asegúrese de que los permisos son restrictivos
Propietario root, grupo root y permisos 600
Verifique el contenido del archivo:
# cat /etc/libnss-ldap.secret
ldapadmin
7.2- Configurando el paquete libpam-ldap
Reconfiguremos el paquete libpam-ldap
# dpkg-reconfigure libpam-ldap
La configuración es similar a libnss-ldap, respondamos a las siguientes preguntas:
- Identificador de recursos para el servidor LDAP: ldap://127.0.0.1/
- El nombre distintivo (DN) de la base de búsquedas: dc=esdebian,dc=org
- Versión de LDAP a utilizar: 3
- Crear un administrador de la base de datos local: Sí
- ¿Hace falta un usuario para acceder a la base de datos LDAP?: No
- Cuenta LDAP para root: cn=admin,dc=esdebian,dc=org
- Contraseña para la cuenta LDAP de root: ldapadmin
- Cifrado local a utilizar cuando se cambian las contraseñas: crypt
7.2.1- El archivo /etc/pam_ldap.conf
/etc/pam_ldap.conf es el archivo de configuración de libpam-ldap.
Busque y reemplace el contenido de las siguientes lineas:
base dc=esdebian,dc=org
uri ldap://127.0.0.1/
ldap_version 3
rootbinddn cn=admin,dc=esdebian,dc=org
bind_policy soft
pam_password crypt
nss_base_passwd dc=esdebian,dc=org?sub
nss_base_shadow dc=esdebian,dc=org?sub
nss_base_group ou=group,dc=esdebian,dc=org?one
7.2.2- El archivo /etc/pam_ldap.secret
/etc/pam_ldap.secret es el archivo de credenciales. Allí se almacena en claro la clave de root del servidor ldap, asegúrese de que los permisos son restrictivos
Propietario root, grupo root y permisos 600
Verifique el contenido del archivo:
# cat /etc/pam_ldap.secret
ldapadmin
7.3- El archivo /etc/nsswitch.conf
/etc/nsswitch.conf es el archivo de configuración del servicio NSS, él determina cuales son los orígenes que se utilizarán para obtener la información. Teniendo ya configurado libnss-ldap solo modifiquemos las siguientes lineas agregando el origen ldap:
passwd: files ldap
group: files ldap
shadow: files ldap
Esto le indica al servicio NSS que debe utilizar el origen files (/etc/passwd, /etc/group y /etc/shadow respectivamente) y el origen ldap (mediante el modulo libnss-ldap)
Ya teniendo samba configurado como servidor de nombres wins podemos agregar también el soporte para resolucion de nombres de hosts mediante ese servicio
hosts: files wins dns
Aqui el orden es mas importante, esto indica que deben resolverse nombre de host mediante files (/etc/hosts), luego se utilizará wins (samba) y finalmente mediante el DNS resolver
Con esta configuración ya debemos estar en condiciones de obtener información de los usuarios desde todos los orígenes configurados, no está de mas recordar que debe detener o al menos reiniciar el servicio nscd.
Comprobemos que nuestro usuario root pertenece al grupo Domain Admins:
# id root
uid=0(root) gid=0(root) grupos=0(root),512(Domain Admins)
Comprobemos las dos entradas para nuestro usuario root, la de /etc/passwd y la de ldap
# getent passwd | grep root
root:x:0:0:root:/root:/bin/bash
root:x:0:0:Netbios Domain Administrator:/home/root:/bin/bash
Comprobemos los grupos del dominio
# getent group | grep -E ‘root|Domain’
root:x:0:
Domain Admins:*:512:root
Domain Users:*:513:
Domain Guests:*:514:
Domain Computers:*:515:
Una cosa interesante que pasa cuando nuestro servidor tiene más servicios que prestar como bases de datos, web, etc; es que cuando se reinicia la PC nos sale un error como el siguiente:
nss_ldap: failed to bind to LDAP server ldap://127.0.0.1/: Can’t contact LDAP server
Ese es uno de los muchos errores que aparecerán, pero no afecta en nada el funcionamiento del PDC, aunque para solucionar esto y todo se vea bien durante el reinicio del servidor se deben agregar los siguietes grupos y usarios en la consola:
addgroup –system nvram
addgroup –system rdma
addgroup –system fuse
addgroup –system kvm
addgroup –system scanner
adduser –system –group –shell /usr/sbin/nologin –home /var/lib/tpm tss
7.4- Configurando PAM
Ahora configuremos el módulo PAM para poder acceder localmente con usuarios del Dominio
Antes de modificar nada, seria buena idea respaldar la configuración de pam
# cp -a /etc/pam.d /etc/pam.d.ORIGINAL
7.4.1- El archivo /etc/pam.d/common-auth
# Lo que denominarías el bloque primario, si cualquiera de los dos módulos tiene
# exito se salta la ejecucion del modulo pam_deny.so
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass # Si no se salta este punto la autenticacion falla siempre
auth requisite pam_deny.so
# aún cuando la autenticacion tubiera éxito los modulos del bloque
# primario podrian no retornar un código positivo, esto soluciona eso
# asegurando un valor positivo si no lo era antes
auth required pam_permit.so
7.4.2- El archivo /etc/pam.d/common-account
# Lo que denominarias el bloque primario, si cualquiera de los dos módulos tiene
# exito se salta la ejecucion del modulo pam_deny.so
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so # Si no se salta este punto la autenticacion falla siempre
account requisite pam_deny.so
# aún cuando la autenticacion tubiera éxito los modulos del bloque
# primario podrian no retornar un código positivo, esto soluciona eso
# asegurando un valor positivo si no lo era antes
account required pam_permit.so
7.4.3- El archivo /etc/pam.d/common-password
# Es buena idea que se tenga restriciones sobre los passwords
# cracklib permite controlar longitudes minimas y fortaleza de la clave
# ante ataques de diccionario
# Solo no debe ovidarse instalar cracklib, simplemente aptitude install libpam-cracklib
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 # Lo que denominarias el bloque primario, si cualquiera de los dos módulos tiene
# exito se salta la ejecucion del modulo pam_deny.so
password [success=2 default=ignore] pam_unix.so obscure crypt
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
# Si no se salta este punto la autenticacion falla siempre
password requisite pam_deny.so
# aún cuando la autenticacion tubiera éxito los modulos del bloque
# primario podrian no retornar un código positivo, esto soluciona eso
# asegurando un valor positivo si no lo era antes
password required pam_permit.so
7.4.4- El archivo /etc/pam.d/common-session
# Lo que denominarias el bloque primario, si el usuario está correctamente autenticado
# se salta la ejecucion del modulo pam_deny.so (recordar que este es un apartado de
# sesion, por lo tanto lo que se controla no es el acceso sino los privilegios efectivos
# de un usuario ya autenticado)
session [default=1] pam_permit.so # Si no se salta este punto la autenticacion falla siempre
session requisite pam_deny.so
# aún cuando la autenticacion tubiera éxito los modulos del bloque
# primario podrian no retornar un código positivo, esto soluciona eso
# asegurando un valor positivo si no lo era antes
session required pam_permit.so
# Se chequean los privilegios y restricciones
session required pam_unix.so
session optional pam_ldap.so
8- Creación de usuarios y grupos en el directorio LDAP mediante smbldap-tools
Llegado a este punto ya se debería estar en condiciones de ingresar al servidor mediante usuarios del Dominio, los cuales autenticarán mediante PAM, accediendo éste a la información almacenada en nuestro directorio LDAP.
Pero para probar si es posible ingresar al sistema local con un usuario del dominio primero debemos crear uno
8.1- Crear usuarios del dominio
Para esto nos valdremos de las herramientas provistas por smbldap-tools.
Mediante la herramienta smbldap-useradd crearemos agregamos al usuario pepe al dominio
# smbldap-useradd -a -m -P pepe
Cannot confirm uidNumber 1000 is free: checking for the next one
Changing UNIX and samba passwords for pepe
New password: 123456
Retype new password: 123456
- La opción -a indica que es un usuario Windows
- La opción -m indica que debe crearse el home del usuario e inicializarlo con el contenido de /etc/skel que es el comportamiento standard para la creación de una cuenta UNIX. Esta opción no siempre es necesario incluirla ya puede pasar que no todos los usuarios del dominio necesiten un HOME en el servidor
- La opción -P indica que se solicitará y establecerá un password al usuario
man smbldap-useradd para mas información acerca de las opciones del comando
La contraseña de pepe es 123456, es una contraseña muy simple que el sistema nos ha dejado crear porque somos root, si pepe desea en el futuro cambiar su contraseña deberá cumplir las especificaciones del archivo /etc/pam.d/common-password impuestas por el módulo pam_cracklib
También vemos el mensaje “Cannot confirm uidNumber 1000 is free: checking for the next one”. Ese mensaje solo aparecerá ésta primera vez, de ahora en más el último UID se almacenará en sambaUnixIdPooldn como lo establece el archivo /etc/smbldap-tools/smbldap.conf y el siguiente UID libre se determinará en base a eso. Cuando se agrege el primer grupo sucederá lo mismo.
Podemos verificar que el usuario se ha creado pero no existe localmente:
:~# cat /etc/passwd | grep pepe
:~# getent passwd | grep pepe
pepe:x:1003:513:System User:/home/pepe:/bin/bash
:~#
El paquete libpam-dotfile nos provee la herramienta pamtest que nos permite verificar el funcionamiento de los mecanismos de autenticación. Probemos con nuestro usuario pepe
:~# pamtest passwd pepe
Trying to authenticate for service .
Password: 123456
Authentication successful.
Los mecanismos de autenticación funcionan correctamente, accedamos al sistema con el usuario pepe:
debian-pdc login: pepe
Password: 123456
Linux debian-pdc 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686 The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
I have no name!@debian-pdc:~$
Y pudimos acceder al equipo mediante una cuenta ldap. Nos llama la atencion ese “I have no name!” en el prompt, si hacemos
$ whoami
whoami: cannot find name for user ID 1001
Por algún motivo y aún con el demonio nscd detenido pasa esto, pero si reiniciemos el demonio
# /etc/init.d/nscd restart
ahora si
$ whoami
pepe
8.2- Crear un usuario administrador del dominio
A diferencia de los sistemas Linux/Unix, donde el administrador del dominio es root y su UID es 0, en un Dominio Windows para ser administrador del dominio basta con pertenecer al grupo Domain Admins, cuyo GID es 512.
Por lo tanto, para crear un usuario administrador del dominio, basta con indicarle a smbldap-adduser que lo incluya en el grupo 512
# smbldap-useradd -a -m -G 512 -P adminnuevo
Changing UNIX and samba passwords for adminnuevo
New password: adminnuevo
Retype new password: adminnuevo
También podemos ingresar al sistema mediante éste usuario, y podremos comprobar que es solo un administrador del dominio pero no tiene permisos de root (su prompt no es #)
$ id adminnuevo
uid=1002(adminnuevo) gid=513(Domain Users) grupos=512(Domain Admins),513(Domain Users)
8.3- Crear un Grupo en el dominio
Simplemente haciendo:
:~# smbldap-groupadd -a «Grupo Nuevo»
Cannot confirm gidNumber 1000 is free: checking for the next one
Cannot confirm gidNumber 1001 is free: checking for the next one
Cannot confirm gidNumber 1002 is free: checking for the next one
:~#
Podemos verificar que el grupo existe, pero no localmente
:~# cat /etc/group | grep «Grupo Nuevo»
:~# getent group | grep «Grupo Nuevo»
Grupo Nuevo:*:1003:
:~#
8.4- Eliminar usuarios y grupos del dominio
Probemos eliminar el grupo recién creado:
:~# smbldap-groupdel «Grupo Nuevo»
:~#
Y el grupo ya no existe
:~# getent group | grep «Grupo Nuevo»
:~#
Eliminemos el usuario pepe que creamos anteriormente
:~# smbldap-userdel -r pepe
:~#
La opción -r indica que debe eliminarse el home del usuario
Podemos verificar que el usuario ya no existe
:~# getent passwd | grep pepe
:~#
9- Agregar los usuarios y grupos Linux/Unix locales al directorio LDAP
Para la migracion de usuarios y grupos Unix al ldap se utilizarán herramientas provistas por el paquete smbldap-tools
Dichas herramientas no son provistas como parte del paquete de software sino en la parte de documentación. Las herramientas se encuentran en los archivos:
/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-accounts.gz
/usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-groups.gz
Debemos descomprimir estos archivos y hacerlos ejecutables. Los copiaremos a alguna ubicación que figure en nuestro path como ser /usr/sbin
# zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-accounts.gz > /usr/sbin/smbldap-migrate-unix-accounts
# zcat /usr/share/doc/smbldap-tools/examples/migration_scripts/smbldap-migrate-unix-groups.gz > /usr/sbin/smbldap-migrate-unix-groups
# chmod 755 /usr/sbin/smbldap-migrate-unix-accounts /usr/sbin/smbldap-migrate-unix-groups
Migrando usuarios locales al directorio LDAP
El script smbldap-migrate-unix-accounts está preparado para recibir como parametro el archivo /etc/passwd y /etc/shadow, sin embargo nosotros no deseamos exportar todos los usuarios.
Usuarios como backup, bin o daemon no nos son necesarios en nuestro directorio ldap, tampoco podemos migrar root y nobody porque esos usuarios ya existen el el directorio.
Solo migraremos los usuarios necesarios, copiemos /etc/passwd y /etc/shadow a una ubicaion temporal:
# cp /etc/passwd /etc/shadow /tmp/
Quitemos de estos archivos temporales los usuarios que no deseamos migrar y entonces si corramos la herramienta de migración:
# smbldap-migrate-unix-accounts -a -P /tmp/passwd -S /tmp/shadow
Migrando grupos locales al directorio LDAP
Nuevamente copiemos /etc/group a una ubicacion temporal:
# cp /etc/group /tmp/
Editemos el archivo dejando los grupos que deseamos migrar (podria no migrar los grupos root, bin y daemon) y entonces si corramos la herramienta de migración:
# smbldap-migrate-unix-groups -a -G /tmp/group
Seguramente querremos que los usuarios Samba pertenezcan a ciertos grupos Unix, por ejemplo los grupos audio, video, cdrom, plugdev, floppy, etc. para tener esos privilegios cuando accedan desde terminales Linux/Unix. No tenemos mas que agregarlos a dichos grupos, por ejemplo al usuario adminnuevo:
# smbldap-usermod –group audio,video,floppy,cdrom,plugdev,»Domain Admins»,»Domain Users» adminnuevo
y podemos ver que adminnuevo ya es miembro de esos grupos:
# id adminnuevo
uid=1002(adminnuevo) gid=513(Domain Users) grupos=513(Domain Users),512(Domain Admins),24(cdrom),25(floppy),29(audio),44(video),46(plugdev)
NOTA: Recuerde detener el demonio nscd para hacer estas pruebas
10- Agregar equipos Windows al Dominio
Hemos terminado las configuraciones, nuestro servidor se comporta ahora como un controlador de Dominio NT, ya nos debería ser posible unir terminales Windows a nuestro Dominio.
10.1- Requisitos del sistema Windows
El sistema a agregar al dominio será un Windows XP Professional.
Antes que nada se debe estar consiente que nuestro PDC no es un Dominio Active Directory, por lo que:
- No se utiliza el mecanismo de autenticación MIT Kerberos: samba puede ser cliente en un dominio Active Directory y utilizar Kerberos para la autenticación, pero no puede utilizar este mecanismo cuando es un PDC.
- No incorpora un servidor DNS: a diferencia de un dominio NT, donde los nombres se resuelven mediante wins, un dominio Active Directory es gobernado por una implementación DNS. Si bien Active Directory soporta wins (no por defecto, debe instalarse) se basa en DNS para ubicar objetos en la red y esto requiere que los clientes tengan al controlador de dominio como servidor DNS primario.
El no utilizar Kerberos no es un problema, los clientes se autenticarán mediante NTLM, un protocolo lo suficientemente seguro.
El no ser un servidor DNS resulta para nosotros en una mínima configuración más, al no contar con un servidor DNS el dominio esdebian.org no se resuelve con la IP del servidor.
Esto no supone un problema, simplemente debemos utilizar nombres NetBIOS en lugar de nombres DNS, por lo tanto los clientes no podrán agregarse al dominio esdebian.org sino que deberán hacerlo al dominio NetBIOS ESDEBIAN.
Deberemos configurar a nuestros clientes para que utilicen nuestro Samba como servidor de nombres WINS.
NOTA: hacer que nuestro servidor sea tambien un servidor DNS no es nada complicado, pero esa configuración no se tratará en este articulo.
Configuración de red
Asignemos al cliente una dirección IP dentro del segmento de red de nuestro servidor y configuremos para que el servidor wins sea nuestro servidor Samba. Debemos habilitar también NetBIOS sobre TCP/IP:
10.2- Unir el equipo con Windows XP Professional al dominio Samba
Agregaremos el equipo al dominio de manera standard. Se utiliza la cuenta de root, cuyo password era dominioadmin
Y deberíamos recibir el mensaje de bienvenida al Dominio ESDEBIAN
10.3- Eliminar el equipo del dominio
Un equipo dentro del dominio es un usuario dentro de la ou=Computers, el nombre de usuario esel nombre del equipo con la diferencia que su nombre finaliza con un $
Podemos verlo con
# getent passwd | grep Computer
pc-win$:*:1004:515:Computer:/dev/null:/bin/false
Mas información con:
:~# pdbedit -Lv pc-win$
Unix username: pc-win$
NT username: pc-win$
Account Flags: [W ]
User SID: S-1-5-21-669132894-2586221759-3914214969-1001
Primary Group SID: S-1-5-21-669132894-2586221759-3914214969-515
Full Name: PC-WIN$
Home Directory: \debian-pdcpc-win_
HomeDir Drive: U:
Logon Script: ‘logon.bat pc-win_’
Profile Path: \debian-pdcprofilespc-win_
Domain: ESDEBIAN
Account desc: Computer
Workstations:
Munged dial:
Logon time: 0
Logoff time: never
Kickoff time: never
Password last set: mar, 19 ene 2010 07:30:23 ART
Password can change: mar, 19 ene 2010 07:30:23 ART
Password must change: never
Last bad password : 0
Bad password count : 0
Logon hours : FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Por lo tanto eliminar un equipo del dominio es lo mismo que eliminar un usuario, se lo hace mediante la herramienta smbldap-userdel
:~# smbldap-userdel pc-win$
10.4- Notas para equipos con Windows 7
Para unir equipos con windows 7 al dominio hay que hacer unos cambios en el registro de los clientes, así como actualizar samba a la versión 3.4 de Debian-backports. Para ello añadimos la siguiente linea al archivo sources.list:
deb http://backports.debian.org/debian-backports lenny-backports main
Hacemos un update e instalamos samba:
aptitude -t lenny-backports install samba
Nos instalará los paquetes actualizados y nos desinstalará smbfs (no problem).
A continuación debemos crear dos claves de registro en las máquinas con Windows 7 que se unirán al dominio:
HKLMSystemCCSServicesLanmanWorkstationParameters
DWORD DomainCompatibilityMode = 1
DWORD DNSNameResolutionRequired = 0
Ahora ya podemos unir las máquinas al dominio y abrir sesión en el mismo.
11- Configurando PAM/NSS de clientes Linux/Unix para que utilicen la Autenticación centralizada.
Una vez que hicimos login en nuestro equipo cliente Linux/Unix estamos listos para configurar PAM/NSS para hacer que dicho equipo utilice nuestro servidor PDC para la autenticación y manejo de permisos.
Para el ejemplo utilizaremos Debian/GNU Linux 5.0 como Sistema Operativo para el equipo cliente pero cualquier cliente Linux/Unix debe porder ser configurado. La única diferencia destacable en la configuracion es que en sistemas no Debian el archivo /etc/libnss-ldap.conf suele llamarse simplemente /etc/ldap.conf
Instalemos en el cliente el software necesario:
# aptitude install libnss-ldap libpam-ldap libpam-cracklib
y respondamos a las siguientes preguntas:
Configuración de libnss-ldap:
- Identificador de recursos para el servidor LDAP: ldap://192.168.1.200/
- El nombre distintivo (DN) de la base de búsquedas: dc=esdebian,dc=org
- Versión de LDAP a utilizar: 3
- Cuenta LDAP para root: cn=admin,dc=esdebian,dc=org
- Contraseña para la cuenta LDAP de root: dejar vacío
Configuración de libpam-ldap:
- Crear un administrador de la base de datos local: No
- ¿Hace falta un usuario para acceder a la base de datos LDAP? : No
No olvidemos la seguridad
Es importante destacar que cuando se nos preguntó “Contraseña para la cuenta LDAP de root:” durante la configuración de libnss-ldap no se respondió nada.
La contraseña de root para la cuenta ldap es la que definimos en el servidor, en nuestro caso era ldapadmin, y la utiliza entre otras cosas samba para modificar la base de datos agregando usuarios y demás. Sin embargo nuestro servidor ldap es accesible desde toda la red y una red con cientos de clientes Linux/Unix que tengan almacenada la contraseña de root para acceder al servidor ldap no parece muy inteligente.
Cualquier equipo que se vea comprometido tendrá la posibilidad de acceder y modificar sin restricciones nuestra base de datos.
El parámetro “Cuenta LDAP para root:” también lo hemos establecido pero no tiene sentido alguno, cuando revisemos los archivos de configuración comentaremos la linea.
Los archivos de configuración de PAM y NSS
PAM y NSS utilizarán la misma base de datos ldap, por la tanto su configuración es igual.
Editamos los archivos /etc/libnss-ldap.conf y /etc/pam_ldap.conf, y reemplazamos con lo siguiente (la configuración es muy similar a la del servidor):
# DN base
base dc=esdebian,dc=org # URI del servidor ldap, en nuestro caso es 192.168.1.200
uri ldap://192.168.1.200/
# Version de ldap a utilizar
ldap_version 3
# Cuenta de root ldap
# Esta linea no es necesaria, la comentamos o borramos
# rootbinddn cn=admin,dc=esdebian,dc=org
bind_policy soft
pam_password crypt
nss_base_passwd dc=esdebian,dc=org?sub
nss_base_shadow dc=esdebian,dc=org?sub
nss_base_group ou=group,dc=esdebian,dc=org?one
Modificamos /etc/nsswitch.conf agregando ldap para las búsquedas y wins para resolver nombres:
passwd: files ldap
group: files ldap
shadow: files ldap
hosts: files wins dns
Hacemos un backup de la configuración de PAM
# cp -a /etc/pam.d{,.ORIGINAL}
Y modificamos los archivos de configuración de PAM:
/etc/pam.d/common-auth
auth [success=2 default=ignore] pam_unix.so nullok_secure
auth [success=1 default=ignore] pam_ldap.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so
/etc/pam.d/common-account
account [success=2 new_authtok_reqd=done default=ignore] pam_unix.so
account [success=1 default=ignore] pam_ldap.so
account requisite pam_deny.so
account required pam_permit.so
/etc/pam.d/common-password
password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3
password [success=2 default=ignore] pam_unix.so obscure crypt
password [success=1 user_unknown=ignore default=die] pam_ldap.so use_authtok try_first_pass
password requisite pam_deny.so
password required pam_permit.so
/etc/pam.d/common-session
La configuración de este archivo difiere de la del servidor PDC.
En el servidor podemos crear las cuentas de usuario mediante smbldap-useradd agregando la opción -m de modo que el home de cada usuario se crea junto con el usuario.
En los clientes el home de cada usuario no existe, por lo que se utiliza el módulo pam_mkhomedir.so para crear el home del usuario en caso que no exista. Eso es lo que motiva agregar la primer linea del archivo
session required pam_mkhomedir.so
session [default=1] pam_permit.so
session requisite pam_deny.so
session required pam_permit.so
session required pam_unix.so
session optional pam_ldap.so
Probando la configuración
Primero que nada, detengamos el demonio nscd
# /etc/init.d/nscd stop
Ahora ya podemos hacer login en los clientes Linux/Unix con algún usuario del dominio Samba, utilizemos la cuenta de adminnuevo que creamos anteriormente:
debian-cli login: adminnuevo
Password: Linux debian-cli 2.6.26-2-686 #1 SMP Wed Nov 4 20:45:37 UTC 2009 i686
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Creating directory ‘/home/adminnuevo’
adminnuevo@debian-cli:~$
Y hemos logrado hacer login con un usuario del dominio
Vemos también como el módulo pam_mkhomedir.so definido en /etc/pam.d/common-session ha creado el home del usuario en el equipo local. Esto solo sucede para el primer login
Referencia:
Original: http://www.esdebian.org/wiki/controlador-primario-dominio-pdc-debian-lenny-50-mediante-samba-pamnss-openldap
Otros Link de Ayuda!:
http://www.howtoforge.com/openldap-samba-domain-controller-ubuntu7.10
http://jroliva.wordpress.com/samba-ldap-debian-40-etch/
http://edin.no-ip.com/content/ldap-samba-pdc-pamnss-debian-lenny-howto
http://tuxjm.net/docs/Configurar_Servidor_Controlador_de_Dominio_con_Sam…
http://wiki.debian.org/LDAP/NSS
