Autenticación de usuarios Linux en un Directorio Activo (Active Directory)

NUESTRO SITIO necesita la publicidad para costear hosting y el dominio. Por favor considera deshabilitar tu AdBlock en nuestro sitio. También puedes hacernos una donación entrando en linuxparty.es, en la columna de la derecha.

Autenticación de usuarios Linux en un Directorio Activo (Active Directory)

Publicado: 25 Mayo 2012 | Correo electrónico | Visto: 17150

Ratio: 3 / 5

Si tienes experiencia con Directorio Activo de Windows y autenticación en sistemas GNU/Linux esta entrada puede resultarte interesante, pero no está pensada para gente que está empezando con estos temas porque se dan por sabidos conceptos de Kerberos, LDAP, nss y PAM.

Esta entrada tiene dos objetivos, el principal es utilizar un Directorio Activo montado sobre un equipo con Windows 2008R2 como mecanismo de autenticación válido para usuarios de un equipo GNU/Linux, pero la forma de hacerlo será paso a paso y sin utilizar Samba; quizás no sea la forma más sencilla de hacerlo, pero sí la que cumple mejor con el segundo objetivo que no es otro que comprender de forma precisa todos los componentes implicados. La parte de la centralización de las cuentas de usuario, bien por el protocolo CIFS (SMB), bien por NFS se deja para una entrada posterior.

Como equipo cliente se utilizará Debian Squeeze y como ya se ha mencionado como servidor se utilizará Windows Server 2008R2, es importante tener en cuenta la versión de Windows server porque el esquema LDAP para UNIX de que se incluye cada versión de Windows Server es diferente, por lo que aquí se explica no sirve para versiones anteriores de Windows Server.

Equipos para el montaje

Nombre del Dominio: casa.local
Nombre del servidor: calamardo (calamardo.casa.local)
Dirección IP del servidor: 10.0.0.3
Nombre del cliente: patricio (patricio.casa.local)
Dirección IP del cliente: 10.0.0.2

Nota: Los nombres no están al azar, son los elegidos para los servidores del prácticas por los alumnos de 2º de ASIR de este curso ;).

Elementos de la configuración

Aunque un Directorio Activo se configure en los sistemas Windows Server como si se tratara de una sola cosa, realmente es un conjunto de servicios y conexiones entre ellos configurado para trabajar de forma coordinada. Los servicios más relevantes del Directorio Activo son un servidor LDAP para almacenar toda la información de los objetos del dominio (equipos, usuarios, grupos, etc.) y un servidor Kerberos para autenticar cada uno de ellos. Además de estos dos servicios, es necesario que exista un servidor DNS configurado completamente en el que estén incluídos todos los equipos del Dominio. Además se suele utilizar el protocolo NTP, para asegurar que todos los equipos del dominio tienen sus relojes coordinados; paso que obviaremos en esta configuración por una simple sincronización manual de los relojes de los dos equipos utilizados.

En nuestro caso, partimos de un Directorio Activo ya configurado sobre la base LDAP “dc=casa,dc=local”, que adaptaremos para que permita conexiones desde equipos GNU/Linux y en el equipo cliente configuraremos los siguientes componentes:

Cliente DNS
Cliente nss-ldap
Cliente Kerberos
Cliente PAM para Kerberos

Consideraciones previas sobre LDAP

El directorio Activo está configurado inicialmente sólo para albergar información de usuarios de sistemas Windows, no de usuarios de un equipo GNU/Linux o en general de cualquier UNIX. De forma más precisa esto significa que el Directorio Activo por defecto no incluye ningún objeto (objectClass) con los atributos necesarios para albergar la información de usuarios de UNIX.

Un objeto de LDAP con los atributos mínimos necesarios para almacenar información de usuarios UNIX (conforme a la RFC 2307) sería:

01

dn: uid=usuario,ou=People,dc=casa,dc=local

02
objectClass: account

03
objectClass: posixAccount

04
objectClass: top

05
uid: usuario

06
cn: Nombre Apellido1 Apellido2

07
loginShell: /bin/bash

08
uidNumber: 2001

09
gidNumber: 2001

10
homeDirectory: /home/usuario

Lo que necesitamos es que el Directorio Activo tenga objetos con atributos en los que guardar exactamente la misma información, aunque los atributos tengan otros nombres. En el caso del Directorio Activo de Windows 2008R2, Un objeto de LDAP destinado a almacenar información de usuarios sería algo como:

01
dn: CN=Nombre Apellido1 Apellido2,CN=Users,DC=casa,DC=local

02
objectClass: top

03
objectClass: person

04
objectClass: organizationalPerson

05
objectClass: user

06
cn: Nombre Apellido1 Apellido2

07
sn: Apellido1 Apellido2

08
givenName: Nombre

09
distinguishedName: CN=Nombre Apellido1 Apellido2,CN=Users,DC=casa,DC=local

10
instanceType: 4

11
whenCreated: 20120211185610.0Z

12
whenChanged: 20120211185610.0Z

13
displayName: Nombre Apellido1 Apellido2

14
uSNCreated: 65578

15
uSNChanged: 65583

16
name: Nombre Apellido1 Apellido2

17
objectGUID:: lBMijOgChUWibgWekXtVfQ==

18
userAccountControl: 512

19
badPwdCount: 0

20
codePage: 0

21
countryCode: 0

22
badPasswordTime: 0

23
lastLogoff: 0

24
lastLogon: 0

25
pwdLastSet: 129734601707528000

26
primaryGroupID: 513

27
objectSid:: AQUAAAAAAAUVAAAA+nllo3NnxVVOoZfVWAQAAA==

28
accountExpires: 9223372036854775807

29
logonCount: 0

30
sAMAccountName: usuario

31
sAMAccountType: 805306368

32
userPrincipalName: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

33
objectCategory: CN=Person,CN=Schema,CN=Configuration,DC=casa,DC=local

34
dSCorePropagationData: 16010101000000.0Z

Hay varias cosas que podemos deducir de lo anterior:

El ObjectClass utilizado por Active Directory para almacenar información de usuarios es “user” en lugar de “posixAccout”
El atributo que define el nombre de usuario es “sAMAccountName” en lugar de “uid” en sistemas GNU/Linux
El atributo que define el nombre completo del usuario es en ambos casos cn.
El atributo que define el nombre de usuario no se utiliza como rdn, en su lugar se utiliza el nombre completo del usuario (atributo cn).

En el caso de los grupos la cosa es más sencilla, pero vamos a ver la diferencia entre un objeto con los atributos mínimos para almacenar información de grupos UNIX (RFC 2307) y un grupo del Directorio Activo. El primero sería algo como:

1
dn: cn=grupo1,ou=Group,dc=casa,dc=local

2
objectClass: posixGroup

3
objectClass: top

4
cn: grupo1

5
gidNumber: 2001

Mientras que un grupo típico en AD es:

01
dn: CN=grupo1,CN=Users,DC=casa,DC=local

02
objectClass: top

03
objectClass: group

04
cn: grupo1

05
distinguishedName: CN=grupo1,CN=Users,DC=casa,DC=local

06
instanceType: 4

07
whenCreated: 20120211191507.0Z

08
whenChanged: 20120211191507.0Z

09
uSNCreated: 65585

10
uSNChanged: 65585

11
name: grupo1

12
objectGUID:: SHTAgQ8Q5UmYgpCnJOvpog==

13
objectSid:: AQUAAAAAAAUVAAAA+nllo3NnxVVOoZfVWQQAAA==

14
sAMAccountName: grupo1

15
sAMAccountType: 268435456

16
groupType: -2147483646

17
objectCategory: CN=Group,CN=Schema,CN=Configuration,DC=casa,DC=local

18
dSCorePropagationData: 16010101000000.0Z

Este caso es más sencillo, porque lo único que nos hace falta es incluir un atributo en el que almacenar el GID del grupo (gidNumber en RFC 2307).

Configuración del servidor

Configuración del DNS

En el caso de que el equipo cliente no estuviera en la zona DNS, se incluye mediante la Consola de Administración de DNS

Configuración del LDAP

Accedemos a la herramienta “Administración del Servidor” > Roles > Servicios de dominio de Directorio Activo y agregamos el servicio del Rol “Administración de Identidades para UNIX”, para que el directorio Activo pueda contener objetos con Atributos para UNIX. Una vez reiniciado el servidor, el Directorio Activo será capaz de almacenar información de usuarios y grupos UNIX.

Para añadir los atributos necesarios para almacenar información de usuarios y grupos UNIX, seleccionamos las propiedades de un grupo cualquiera en la consola “Usuarios y Equipos del Active Directory” y veremos la nueva pestaña “UNIX attributes”:

Y de forma análoga, seleccionamos un usuario y rellenamos las casillas de la pestaña “UNIX Attributes”:

Esos atributos son los realmente los mínimos necesarios para almacenar la información de usuarios y grupos UNIX, pero el problema es que Microsoft va siempre a su aire y los nombres de esos atributos en el LDAP no siguen la RFC 2307, por lo que tendremos que averiguar qué nombres se utilizan y ajustar el cliente GNU/Linux para esos atributos. Para ver qué nombres se han utilizado para los atributos, lo mejor es hacer una consula LDAP desde el equipo cliente:

1
patricio:~$
 ldapsearch -x -LLL -D "cn=Administrador,cn=Users,dc=casa,dc=local" -W 
-h 10.0.0.3 -b dc=casa,dc=local "sAMAccountName=usuario"

en la que aparecen los siguientes atributos nuevos:

1
unixUserPassword: ABCD!efgh12345$67890

2
uid: usuario

3
msSFU30Name: usuario

4
msSFU30NisDomain: casa

5
uidNumber: 2001

6
gidNumber: 2001

7
unixHomeDirectory: /home/usuario

8
loginShell: /bin/bash

Donde tenemos todos los atributos necesarios para la cuenta del usuario UNIX, además en esta versión de Active Directory los nombres de los atributos son los esperados, salvo homeDirectory que aparece como unixHomeDirectory-

Configuración del cliente

Configuración del DNS

Editamos el fichero /etc/resolv.conf:

1
domain casa.local

2
nameserver 10.0.0.3

Configuración del cliente nss-ldap

Para que un sistema GNU/Linux pueda obtener la información de las cuentas de los usuarios de un servidor LDAP, hay que instalar en el sistema alguna de las bibliotecas de nss para ldap. Hay dos paquetes en Debian squeeze que proveen estas bibliotecas, nos decantamos por libnss-ldapd porque permite una mejor depuración de la consulta LDAP. Además es habitual instalar las bibliotecas nss de ldap junto con las de autenticación LDAP (libpam-ldap), pero como en esta ocasión la autenticación será vía Kerberos, por lo que instalamos el paquete libnss-ldapd sin los paquetes que recomienda:

1
# apt-get --no-install-recommends install libnss-ldapd

En la instalación se nos piden los parámetros de la configuración, que podemos ignorar o poner los parámetros por defecto porque hay que realizar en cualquier caso una configuración manual, por lo que editamos el fichero /etc/nslcd.conf y dejamos el siguiente contenido:

01
# The user and group nslcd should run as.

02
uid nslcd

03
gid nslcd

04
 
05
# The location at which the LDAP server(s) should be reachable.

06
uri ldap://calamardo.casa.local

07
 
08
# The search base that will be used for all queries.

09
base dc=casa,dc=local

10
 
11
# The LDAP protocol version to use.

12
ldap_version 3

13
 
14
# The DN to bind with for normal lookups.

15
binddn cn=usuario,cn=Users,dc=casa,dc=local

16
bindpw asd-123

17
 
18
# The search scope.

19
scope sub

20
 
21
# Objeto que contiene los usuarios (por defecto es posixAccount)

22
filter passwd (objectClass=User)

23
 
24
# Objeto que contiene los grupos (por defecto es posixGroup) 

25
filter group (objectClass=Group)

26
 
27
# Mapeo de los atributos que no son los esperados por RFC2703

28
map passwd homeDirectory unixHomeDirectory

29
map passwd gecos name

30
map group memberUid member

Donde hay que comentar que a diferencia de la configuración estándar de OpenLDAP, en Active Directory no se permiten consultas de LDAP anónimas, por lo que hay que incluir el dn de un usuario y su contraseña en claro (no hay ni que decir que ese usuario debería tener permisos muy restringidos en el Directorio Activo). Reiniciamos el servicio nslcd y podemos comprobar cómo nuestro sistema GNU/Linux puede identificar los usuarios del directorio activo que tengan atributos UNIX, como usuarios propios:

1
# /etc/init.d/nslcd restart

2
# getent passwd usuario

3
usuario:*:2001:2001:Nombre Apellido1 Apellido2:/home/usuario:/bin/bash

O si con getent no nos queda claro, podemos probar lo siguiente:

1
root@patricio:~# touch /tmp/prueba.txt

2
root@patricio:~# chown 2001:2001 /tmp/prueba.txt 

3
root@patricio:~# ls -l /tmp/prueba.txt 

4
-rw-r--r-- 1 usuario grupo1 0 feb 11 23:32 /tmp/prueba.txt

Configuración de Kerberos

Los datos de la cuenta se obtienen de una consulta LDAP, pero la autenticación se realiza con Kerberos, por lo que instalamos el cliente de Kerberos del MIT:

1
# aptitude install krb5-config krb5-user

Y modificamos los siguientes parámetros del fichero /etc/krb5.conf:

1
[libdefaults]

2
        default_realm = CASA.LOCAL

3
...

4
[realms]

5
        CASA.LOCAL = {

6
             kdc = calamardo.casa.local

7
             admin_server = calamardo.casa.local

8
        }

Simplemente con esta configuración, se puede probar la autenticación de algún usuario del directorio activo con Kerberos:

1
root@patricio:~# kinit usuario

2
Password for Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.: (se introduce la contraseña)

3
root@patricio:~# klist 

4
Ticket cache: FILE:/tmp/krb5cc_0

5
Default principal: Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

6
 
7
Valid starting     Expires            Service principal

8
02/11/12 23:54:11  02/12/12 09:54:19  krbtgt/Esta dirección de correo electrónico está siendo protegida contra los robots de spam. Necesita tener JavaScript habilitado para poder verlo.

9
    renew until 02/12/12 23:54:11

Configuración del cliente PAM Kerberos

Ahora sólo falta que el sistema utilice el servidor Kerberos del Directorio Activo para autenticar los usuarios, para lo que instalamos el paquete libpam-krb5:

1
# aptitude install libpam-krb5

Ahora los usuarios del directorio activo que tengan atributos UNIX, se pueden utilizar como usuarios del sistema y podemos comprobarlo con el programa login:

01
root@patricio:~# login

02
patricio nombre: usuario

03
Password: 

04
Linux patricio 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64

05
 
06
The programs included with the Debian GNU/Linux system are free software;

07
the exact distribution terms for each program are described in the

08
individual files in /usr/share/doc/*/copyright.

09
 
10
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

11
permitted by applicable law.

12
Sin directorio, entrando con HOME=/

El último mensaje nos advierte que el home que tiene definido el usuario en el directorio LDAP no existe en patricio, por lo que utiliza como directorio HOME el directorio raíz. Hay dos soluciones para esto, lo que en terminología del directorio activo se conoce como perfil fijo o perfil móvil, es decir que el usuario tenga sus documentos en el equipo local o los tenga centralizados en algún recurso de la red.

Aquí presentamos la configuración más sencilla, que es crear el directorio home de forma automática en local la primera vez que entra el usuario, para lo que editamos el fichero /etc/pam.d/common-session y añadimos la línea:

1
session     optional      pam_mkhomedir.so

Si volvemos a entrar ahora con el mismo usuario, obtendremos:

01
root@patricio:~# login

02
patricio nombre: usuario

03
Password: 

04
Último inicio de sesión:sáb feb 11 23:59:03 CET 2012en pts/0

05
Linux patricio 2.6.32-5-amd64 #1 SMP Fri Sep 9 20:23:16 UTC 2011 x86_64

06
 
07
The programs included with the Debian GNU/Linux system are free software;

08
the exact distribution terms for each program are described in the

09
individual files in /usr/share/doc/*/copyright.

10
 
11
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent

12
permitted by applicable law.

13
Creando directorio '/home/usuario'.

Nuestro equipo GNU/Linux ya es capaz de utilizar sin problemas los usuarios del directorio activo como usuarios propios, que pueden crear una sesión en el sistema y si su directorio home no existe, se crea al vuelo la primera vez que se entra.

Comprender bien los elementos que intervienen en esta configuración es básico si uno se quiere enfrentar a la configuración de sistemas heterogéneos de cuentas centralizadas y precisamente por eso en este caso hemos preferido obviar samba, que es más sencillo de configurar para unirse a un dominio Windows a través de winbind, pero que a la vez es más opaco. El siguiente paso en la configuración sería conseguir perfiles móviles, pero es mejor tratarlo por separado porque esta entrada ya se hace demasiado larga …