LinuxParty

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.

Ratio: 3 / 5

Inicio activadoInicio activadoInicio activadoInicio desactivadoInicio desactivado
 

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”:

Atributos de Grupo UNIX

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

Atributos de usuario UNIX

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.
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 …

Referencias

Arthur de Jong – nss pam ldapd

Pin It

Escribir un comentario


Código de seguridad
Refescar



Redes:



 

Suscribete / Newsletter

Suscribete a nuestras Newsletter y periódicamente recibirás un resumen de las noticias publicadas.

Donar a LinuxParty

Probablemente te niegues, pero.. ¿Podrías ayudarnos con una donación?


Tutorial de Linux

Filtro por Categorías