Aprenda Linux, 302 (Entornos mixtos)
Integración con Active Directory
Únase e interactúe con un dominio Active Directory
Contenido de la serie:
Este contenido es la parte # de # de la serie: Aprenda Linux, 302 (Entornos mixtos)
Este contenido es parte de la serie:Aprenda Linux, 302 (Entornos mixtos)
Manténgase en contacto por contenidos adicionales de esta serie.
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
RFC | Soporte | |
---|---|---|
2251 | LDAP v3 | Desde Windows 2000 |
2252 | Definiciones de Sintaxis de Atributo | Desde Windows 2000 |
2253 | Representación en Cadena de 8 UTF de nombres Distinguidos | Desde Windows 2000 |
2254 | Filtros de Búsqueda LDAP Usando Secuencias | Desde Windows 2000 |
2255 | El Formato LDAP URL | Desde Windows 2000 |
2256 | El Esquema de Usuario X.500 para uso con LDAPv3 | Desde Windows 2000 |
2829 | Métodos de Autenticación para LDAP | Desde Windows 2000 |
2830 | Extensión para Seguridad de Capa de Transporte | Desde Windows 2000 |
2589 | Extensiones para Servicios de Directorio Dinámico | Desde Windows Server 2003 |
2798 | Define la Clase de Objeto inetOrgPerson LDAP | Desde Windows Server 2003 |
2831 | Usando Autenticación Digest como un Mecanismo SASL | Desde Windows Server 2003 |
2891 | Extensión de Control LDAP para clasificación del lado del servidor de los resultados de búsqueda | Desde Windows Server 2003 |
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
DNS | AD DS |
---|---|
Correlaciona nombres de dominio con registros de recursos | Almacena nombres DNS como objetos
(dnsZone ) |
Correlaciona nombres de computadora con registros de recursos | Almacena nombres de computadora como registros de objetos |
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
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.