Aprenda Linux, 302 (Entornos mixtos)

Integración con Active Directory

Únase e interactúe con un dominio Active Directory

Tracy Bost
Publicado en 16-02-2012

En este artículo, aprenda sobre estos conceptos:

• Entendiendo Active Directory Domain Services (AD DS)
• Entendiendo cómo Samba se comunica con AD DS
• Configurando Samba para que trabaje con AD DS
• Interactuando con AD DS

Este artículo le ayuda a prepararse para el Objetivo 314.3 del Tema 314 del examen (302) sobre la Especialidad de entorno Mixto del Linux Professional Institute (LPI). El objetivo tiene un pese de 2.

Prerrequisitos

Para aprovechar al máximo los artículos de esta serie, usted debe tener conocimientos avanzados sobre Linux y un sistema Linux funcional en el cual pueda practicar los comandos cubiertos en este artículo. En particular, este artículo supone que usted tiene conocimientos prácticos sobre funciones de línea de comandos Linux y al menos un conocimiento general del propósito de Samba, como se cubre en Learn Linux, 302 (Mixed environments): Concepts. Para realizar las acciones descritas en este artículo, usted debe tener instalado el software Samba. Adicionalmente, usted debe tener acceso a una computadora que ejecute un sistema operativo Windows Server configurado para ejecutar AD DS.

Entendiendo el Active Directory

Si usted trabaja en un entorno con gran cantidad de clientes Windows, o uno que ya tenga AD DS en su lugar, usted puede considerar integrar sus servidores Linux hacia el entorno AD. AD ha sido el servicio de autenticación y directorio de Windows desde Microsoft Windows 2000. Un cambio de paradigma significativo desde el controlador de dominio primario y el controlador de dominio de copia de seguridad, AD DS usa controladores de dominio que pueden ser replicados uno en el otro.

Aunque hay otros métodos disponibles para integración con sus servidores Linux en el dominio AD DS, Samba puede ayudar a facilitar la administración y la configuración sin requerir ninguna modificación de sistema en AD DS ni en ninguna otra instalación de software en la computadora de Servidor Windows. Un servidor Samba no se puede convertir en un controlador de dominio dentro de un dominio AD DS, pero puede unirse como servidor miembro e interactuar con servicios AD DS.

AD DS tiene sus fundamentos en los mismos estándares de Internet:

• Domain Name System (DNS) para resolución de nombre
• Kerberos versión 5 para autenticación de usuario
• Lightweight Directory Access Protocol (LDAP) versión 3 para servicios de directorio

LDAP 3

LDAP se originó de la necesidad de un servicio de directorio más liviano que su predecesor, el protocolo X.500. LDAP ha evolucionado hasta ser una buena opción desde su release en 1993. Actualmente es el estándar de Internet de facto para servicios de directorio.

Microsoft reclama cumplimiento LDAP en el núcleo. La Tabla 1 muestra las Requests for Comments (RFCs) proporcionando soporte adicional para leer y efectuar operaciones en LDAP.

Tabla 1. Soporte RFC de Microsoft para LDAP

Kerberos 5

Kerberos fue desarrollado por el Instituto de Tecnología de Massachusetts para que fuera un protocolo de autenticación de red en un momento en el que la seguridad en Internet y las redes internas pasó al frente. Este protocolo proporciona una fuerte criptografía, la cual permite a un cliente probar su identidad a un servidor; de igual forma, un servidor puede probar su identidad para el cliente. Esta operación usa tiquetes y autenticadores.

AD DS usa Kerberos versión 5 para autenticación de usuario. En AD DS, un controlador de dominio actúa como un Kerberos Key Distribution Center para autenticación de cliente.

DNS

AD DS se integra estrechamente con DNS y lo utiliza para:

• Ubicar controladores de dominio AD DS
• Expresar la estructura organizacional en los nombres de sus dominios de una forma jerárquica
• Proporcionar un servicio de solución de nombre para ubicación de controlador de dominio y dominios AD DS

Tenga presente que AD DS en sí no es un servidor DNS y que no reemplaza las tareas que típicamente realiza DNS. Como regla general, un servidor DNS almacena registros de zonas y recursos, mientras que AD DS utiliza el mismo espacio de nombre para almacenar los dominios y sus objetos. La Tabla 2 compara roles típicos DNS y AD DS.

Tabla 2. Roles DNS y AD DS

Un registro de servicio (registro SRV) es una especificación de datos en DNS que define la ubicación de servidores para servicios especificados. Para que AD DS funcione adecuadamente, los servidores DNS deben proporcionar soporte para registros de recursos (RR) de ubicación de servicios. Los RR de SRV correlacionan el nombre de un servicio con el nombre de un servidor que ofrece ese servicio. Los clientes AD DS y controladores de dominio usan registros SRV para determinar las direcciones IP de los controladores de dominio.

Configurando Samba para soporte AD DS

Antes de que su servidor Linux pueda interactuar con AD DS, usted debe verificar que su instalación Samba pueda soportar LDAP y Kerberos. Si usted está usando la versión compilada previamente de Samba, es posible que su instalación soporte tanto Kerberos 5 como LDAP. Si usted compila Samba desde la fuente, asegúrese de incluir soporte para bibliotecas kbr5 y ldap . En principio, esto incluye un cambio para incluir un cambio al archivo de encabezado include/config.h entes de ejecutar el comando make :

#define HAVE_KRB5 1
#define HAVE_LDAP 1

Los nombres de las bibliotecas pueden variar, dependiendo de su computadora Linux.

Cuando Samba está instalado en su computadora Linux, usted puede usar el daemon de servicio Samba smbd para descubrir lo que soporta su instalación Samba (vea el Listado 1).

Listado 1. Mostrando un listado parcial de soporte Kerberos 5 en Samba

[tbost@samba3 ~]$ smbd -b | grep KRB
   HAVE_KRB5_H
   HAVE_KRB5_LOCATE_PLUGIN_H
   HAVE_ADDRTYPE_IN_KRB5_ADDRESS
   HAVE_DECL_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
   HAVE_DECL_KRB5_GET_CREDENTIALS_FOR_USER
   HAVE_INITIALIZE_KRB5_ERROR_TABLE
   HAVE_KRB5
   HAVE_KRB5_AUTH_CON_SETUSERUSERKEY
   HAVE_KRB5_AUTH_CON_SET_REQ_CKSUMTYPE
   HAVE_KRB5_C_ENCTYPE_COMPARE
   HAVE_KRB5_C_VERIFY_CHECKSUM
   HAVE_KRB5_DEPRECATED_WITH_IDENTIFIER
   HAVE_KRB5_ENCRYPT_BLOCK
   HAVE_KRB5_ENCRYPT_DATA
   HAVE_KRB5_ENCTYPE_TO_STRING
.....

[tbost@samba3 ~]$smbd -b | grep LDAP
   HAVE_LDAP_H
   HAVE_LDAP
   HAVE_LDAP_ADD_RESULT_ENTRY
   HAVE_LDAP_INIT
   HAVE_LDAP_INITIALIZE
   HAVE_LDAP_SASL_WRAPPING
   HAVE_LDAP_SET_REBIND_PROC
   HAVE_LIBLDAP
   LDAP_SET_REBIND_PROC_ARGS

El Listado 1 muestra el soporte para las bibliotecas krb5 y ldap , respectivamente, en una distribución Fedora. Su resultado puede diferir dependiendo de la distribución. Aún así, verifique que el resultado de su comando muestre HAVE_KRB5_H y HAVE_LDAP_H como mínimo.

Samba y Kerberos

Samba puede usar Kerberos como una forma de autenticar usuarios en un dominio AD DS. Para configurar Samba, ubique el archivo krb5.conf en el directorio /etc, porque usted necesita realizar algunas modificaciones a la configuración de archivo predeterminada. Como mínimo, usted debe especificar el nombre de dominio en la sección realms del archivo junto con el nombre de dominio completamente calificado del servidor de dominio que efectúa la autenticación para AD DS (vea el Listado 2).

Listado 2. Configurando el archivo krb5.conf

[realms]

	LPIC302.LOCAL= {
		kdc = wins3.lpic302.local 
		admin_server =wins3.lpic302.local
		default_domain = LPIC302.LOCAL
	
	}

El Listado 2 muestra un ejemplo de una configuración simple usando LPIC302.LOCAL como el nombre de dominio AD DS. Asegúrese de ingresar su dominio todo en mayúsculas, o Kerberos no se conectará. La directiva kdc especifica el controlador AD DS con nombre de host wins3.lpic302.local. Adicionalmente, el admin_server es especificado como el controlador de dominio. El parámetro default_domain es útil si usted desea que Kerberos asuma su nombre de dominio cuando el usuario no expresa ninguno.

El daemon Winbind

El daemon Winbind facilita la autenticación para usuarios para el dominio AD DS. Como mucho, usted deberá configurar los Pluggable Authentication Modules (PAM) para que usen el módulo pam_winbind , como se muestra en el Listado 3.

Listado 3. Configurando PAM para usar pam_winbind

auth        sufficient   pam_winbind.so
auth        sufficient   pam_unix.so use_first_pass
auth        required     pam_stack.so service=system-auth
auth        required     pam_nologin.so
account     sufficient   pam_winbind.so
account     required     pam_stack.so service=system-auth
password    required     pam_stack.so service=system-auth
session     required     pam_stack.so service=system-auth
session     optional     pam_console.so

El Listado 3 muestra el archivo modificado de autoridad de sistema en el directorio /etc/pam.d en una distribución basada en Fedora. Dependiendo de su distribución Linux, el nombre del archivo de autenticación puede variar. Normalmente, el nombre de archivo será services o login.

La ubicación de pam_winbind.so es importante. Si usted espera que sus usuarios principalmente vayan a autenticar desde sus cuantas AD DS, de forma opuesta al archivo passwd local, pam_winbind.so debe ingresarse primero. En caso contrario usted podrá encontrar a sus archivos auth.log llenándose demasiado rápido con intentos fallidos de inicio de sesión local.

El Name Service Switch

El Name Service Switch proporciona un mecanismo estándar mediante el cual su computadora Linux puede interactuar con servicios comunes. Su computadora Linux consultará al archivo /etc/nsswitch.conf cuando se estén usando estos servicios. Modifique este archivo como sigue para permitir a su computadora Linux usar Winbind para autenticación de usuario.

El siguiente código resalta el proceso para añadir soporte Winbind para permitir que los usuarios se autentiquen contra una base de datos AD DS Kerberos 5 usando Winbind:

passwd: files winbind
group:	 files winbind

smb.conf

No es de sorprender que el archivo smb.conf necesite un cambio de configuración para que Samba pueda trabajar dentro del dominio AD DS. Al nivel más básico, establezca los parámetros para el dominio y la security, como se muestra en el Listado 4.

Listado 4. Configurando el archivo /etc/nssswitch.conf

[global]
realm = lpic302.LOCAL
security = ADS
password server = wins.lpic302.local
workgroup = lpic302
winbind use default domain = yes
idmap uid = 10000-20000
idmap gid = 10000-20000
winbind enum users = yes
winbind enum groups = yes

La configuración del Listado 4 establece el dominio para el nombre de dominio, lpic302.local. El parámetro de seguridad se establece como ADS. ADS indica que Samba operará en modo de seguridad de Servicio AD DS. Usted puede establecer la líneawindbind use default domain = yes para eliminar la necesidad de calificar nombres de usuario y otros recursos con el nombre de dominio cuando se acceda a los recursos. Por ejemplo, en lugar de autenticar con LPIC302.LOCAL/tbost, Winbind asume el dominio LPIC302.LOCAL cuando el nombre de usuario tbost es especificado.

Interactuando con AD DS

Cuando se completa la configuración, Samba se haya reiniciado y el daemon Winbind esté en ejecución, usted podrá interactuar con AD DS.

Usando el comando net

La herramienta net es una extremadamente útil para administradores Samba. S i usted tiene experiencia con el comando net de Windows, se verá familiarizado con muchas de sus opciones y funcionalidad. El comando net ADS es el que usted usa cuando trabaja con AD DS. Una de las primeras cosas por hacer es unirse a un dominio:

[tbost@samba3 ~]$ sudo net ADS join -U Administrator%password
[tbost@samba3 ~]$ sudo net ADS testjoin
[tbost@samba3 ~]$ sudo net ADS join Computers\OrganizationalUnit\Accounting\Servers

Este código utiliza el comando net para unirse al dominio. De forma alternativa, usted puede omitir %password e ingresar la contraseña de cuenta Windows Administrator cuando se le requiera. El segundo comando verifica que el servidor se haya unido al dominio. El paso final del fragmento crea una cuenta de computadora para el servidor Samba en AD DS bajo Computers\OrganizationalUnit\Accounting\Servers. Si usted necesita más información sobre el comando net , su página man page online proporciona gran cantidad de información útil. Adicionalmente, usted puede emitir el comando net help ADS, como se muestra en el Listado 5.

Listado 5. Listando usuarios y grupos en un dominio AD DS

[tbost@samba3 ~]$ net help ADS
Usage:
net ads info
    Display details on remote ADS server
net ads join
    Join the local machine to ADS realm
net ads testjoin
    Validate machine account
net ads leave
    Remove the local machine from ADS
net ads status
    Display machine account details
net ads user
    List/modify users
net ads group
    List/modify groups
net ads dns
    Issue dynamic DNS update
net ads password
    Change user passwords
net ads changetrustpw
    Change trust account password
net ads printer
    List/modify printer entries
net ads search
    Issue LDAP search using filter
net ads dn
    Issue LDAP search by DN
net ads sid
    Issue LDAP search by SID
net ads workgroup
    Display the workgroup name
net ads lookup
    Find the ADS DC using CLDAP lookups
net ads keytab
    Manage local keytab file
net ads gpo
    Manage group policy objects
net ads kerberos
    Manage kerberos keytab

Interactuando con wbinfo

Luego usted usa la herramienta wbinfo , proporcionada por el daemon Winbind, para consultar recursos AD DS:

[tbost@samba3 ~]$  wbinfo -p
[tbost@samba3 ~]$  wbinfo -u 
[tbost@samba3 ~]$  wbinfo -g

Este snippet usa wbinfo para descubrir información sobre el dominio. El comando wbinfo -p hace ping al daemon Winbind para verificar que se esté ejecutando. El comando wbinfo -u retorna un listado de todos los usuarios en el dominio, mientras que wbinfo -g retorna todos los grupos en el dominio. Consulte el manual wbinfo para más opciones de herramienta y funcionalidad.

Administrando listas de control de acceso con smbcacls

Si usted está familiarizado(a) con los comandos setfacl y getfacl , no tendrá muchos problemas para aprender el comando smbcacls que proporciona la suite del cliente Samba. Usted puede usar la herramienta smbcacls para cambiar propiedad de grupo y de usuario o para administrar permisos de lista de control de acceso en intercambios proporcionados por una máquina Windows Server en un Dominio:

[tbost@samba3 ~]$sudo smbcacls -G LPIC302.LOCAL\accounting \
//wins2.lpic302.local/budget private.doc

Este código utiliza el comando smbcacls para cambiar los permisos de grupo en el private.doc por el grupo accounting en el directorio compartido budget de una máquina Windows Server hacia el grupo de contabilidad dentro del dominio AD DS. El comando smbcacls --help muestra las opciones disponibles para las diferentes funcionalidades de la herramienta.

Recursos para Descargar

• PDF de este contenido

Temas relacionados

• Aprenda más sobre integrating Samba, Active Directory & LDAP del manual Samba 3.x.
• Comprenda cómo Samba uses DNS with AD DS del manual Samba.
• Aprenda cómo configurar Samba para Autenticación AD DS.
• Aprenda cómo Winbind interacts with AD DS en el manual Samba.
• Aprenda más sobre LDAPv3 del grupo de trabajo LDAPv3.
• En el sitio LPIC Program , encuentre objetivos detallados, listas de tareas y preguntas de muestra para los tres niveles de la certificación de administración de sistemas Linux de LPI. Particularmente, observe los objetivos detallados LPI-302.
• Revise toda la serie de preparación para el examen LPI en developerWorks para aprender fundamentos Linux y prepararse para la certificación de administrador de sistemas con base en los objetivos para el examen LPI anteriores a abril del 2009.
• En la zona Linux de developerWorks, encontrará cientos de artículos "cómo hacer" y tutoriales así como descargas, foros de discusión y una riqueza de otros recursos para desarrolladores y administradores Linux.
• Siga a DeveloperWorks en Twitter, o suscríbase al feed de tweets Linux en developerWorks.