Interoperabilidad

Autenticar los clientes de Linux con Active Directory

Gil Kirkpatrick

 

En resumen:

• Cómo funciona la autenticación en Windows y Linux
• Utilizar Samba y Winbind
• Las estrategias de implementación
• Recorrido a través de la integrationItem de Linux a Active Directory

Contenido

Autenticación de Windows
Autenticación de Linux
SAMBA y Winbind
Tres estrategias de autenticación
Nuestro plan de implementación
Buscar el software derecho
SAMBA de creación
Configuración de red Linux
Configurar la sincronización de hora de Linux
Configurar PAM y NSS
Instalar y configurar Samba
El problema de asignación de ID.
Unirse el dominio y registro en
¿Qué ocurre si se no trabajar?
Ahora que funciona, ¿qué tiene?
Soluciones de terceros

Republicans y Democrats. Zumo toothpaste y naranja. Linux y Windows. ¿Algunas cosas sólo don’t mezclar, derecha? Cada tienda de TI alguna vez ha implicado en se ha dividido en dos grupos: el equipo de Windows y el equipo de Linux. Realmente don’t competir entre sí, pero que asegurarse de que no colaborar cualquiera. De hecho, algunos lugares incluso Ir hasta el momento como al colocar una línea de color amarilla en los planos inferior sólo para no asegurarse absolutamente que no existe ningún fraternization inadecuado entre los dos grupos.

Estoy un chico de Windows y ha poked ciertamente diversión en Mis compañeros Linux-orientado a, pero todos tenemos el mismo objetivo de proporcionar servicios de TI de alta calidad y rentables para la organización. Una forma podemos hacer que consiste en compartir la infraestructura central de software como Active Directory. QUE casi todas las organizaciones han liquidado en Active Directory para proporcionar servicios de autenticación a sus escritorios de Windows y servidores. ¿En lugar de mantener una infraestructura de autenticación diferentes para el entorno de Linux (junto con un conjunto independiente de los nombres de usuario y contraseñas), sería mejor si los equipos de Linux utilizan Active Directory así? CREO que lo haría, y le mostraremos cómo hacerlo en este artículo.

Autenticación de Windows

Windows se envió con una autenticación de red integrado y el sistema de inicio de sesión único bastante algún tiempo ahora. Antes de Windows 2000, Windows controladores de NT de dominio (DC) proporcionan servicios de autenticación para clientes de Windows mediante el protocolo de NT LAN Manager (NTLM). Aunque NTLM no era tan seguro como se originalmente considerar, es muy útil porque se claramente resuelto el problema de la necesidad de mantener cuentas de usuario duplicados en múltiples servidores de la red.

A partir de Windows 2000, Microsoft mover de NTLM a Active Directory y sus servicios integrados de autenticación Kerberos. Kerberos era mucho más seguro que NTLM, y escala mejor, demasiado. Y Kerberos era un estándar del sector ya utiliza sistemas Linux y UNIX, que abre la puerta a integrar esas plataformas Windows.

Autenticación de Linux

Originalmente, Linux (y las GNU herramientas y las bibliotecas que se ejecutarán en él) no se creó con un mecanismo de autenticación único en mente. Como consecuencia de esto, los programadores de aplicaciones de Linux suelen tardó en crear su propio esquema de autenticación. Administra para ello por buscar los nombres y algoritmos hash de contraseña en/etc / passwd (las texto tradicional archivo contenedor Linux credenciales de usuario) o proporcionar un mecanismo totalmente diferente (e independiente).

La gran cantidad resultante de mecanismos de autenticación era difícil de administrar. En 1995, Sun propone un mecanismo denominado módulos de autenticación conectable (PAM). PAM proporciona un conjunto común de autenticación de las API que podría utilizar todos los desarrolladores de aplicaciones, junto con un servidor configurado por el administrador acabar que permitido para varios esquemas de autenticación "conectable y". Mediante las API PAM para la autenticación y el nombre de servidor cambiar (NSS) las API para buscar información del usuario, los programadores de aplicaciones de Linux podría escribir menos código y los administradores de Linux podría tener un único lugar para configurar y administrar el proceso de autenticación.

La mayoría de los distribuciones de Linux se suministran con varios módulos de autenticación PAM, incluidos los módulos que admiten la autenticación a un directorio LDAP y la autenticación mediante Kerberos. Puede utilizar estos módulos para autenticarse en Active Directory, pero hay algunas limitaciones importantes, como explicará más adelante en este artículo.

SAMBA y Winbind

SAMBAes un proyecto de código abierto que pretende proporcionar integración entre entornos de Windows y Linux. SAMBA contiene componentes que otorgar acceso de equipos de Linux a archivo de Windows y servicios de impresión, así como proporcionan servicios de en función de Linux que emulan los controladores de dominio de Windows NT 4.0. Mediante los componentes de cliente Samba, Linux equipos pueden sacar partido de servicios de autenticación de Windows proporcionados por Windows NT y controladores de dominio Active Directory.

La parte concreta de Samba que resulte más interesante que nos para este proyecto se denomina Winbind. Winbind es un demonio (servicio en la terminología de Windows) que se ejecuta en los clientes de Samba y actúa como un proxy para la comunicación entre PAM y NSS ejecutando en el equipo de Linux y que se ejecutan en un controlador de dominio de Active Directory. En concreto, Winbind utiliza Kerberos para autenticarse con Active Directory y LDAP para recuperar información de usuario y de grupo. Winbind también proporciona servicios adicionales, como la capacidad de ubicar controladores de dominio mediante un algoritmo similar a la DCLOCATOR en Active Directory y la capacidad de restablecer las contraseñas de Active Directory con la comunicación con un controlador de dominio mediante RPC.

Winbind resuelve unos pocos problemas que simplemente mediante Kerberos con PAM no. En concreto, en lugar de difícil de codificar un controlador de dominio para autenticarse en la forma que hace el módulo Kerberos PAM, Winbind selecciona un controlador de dominio al buscar los registros de ubicador DNS similar a la forma en que el módulo de UBICADOR de controlador de dominio de Microsoft.

Tres estrategias de autenticación

Dada la disponibilidad de LDAP, Kerberos y Winbind en equipos de Linux, hay tres estrategias de implementación diferente que se pueden emplear para permitir que nuestro equipo Linux utilizar Active Directory para la autenticación.

utilizar la autenticación LDAP La forma más sencilla, pero menos satisfactoria de usar Active Directory para la autenticación es configurar PAM va a utilizar la autenticación LDAP, como se muestra en la figura 1 . Aunque Active Directory es un servicio de LDAPv3, los clientes de Windows utilice Kerberos (con la recuperación tras error en NTLM), no LDAP, para propósitos de autenticación.

La autenticación LDAP (denominada enlace LDAP) pasa el nombre de usuario y la contraseña en texto sin cifrar a través de la red. Esto es inseguro y inaceptable para la mayoría de los propósitos.

La figura 1 Authenticating a Active Directory mediante LDAP (haga clic en la imagen de una vista más grande)

La única forma mitigar este riesgo de pasar las credenciales en el cifrado es cifrar el canal de comunicación de Active Directory cliente con algo como SSL. Aunque esto es sin duda es factible, impone la carga adicional de administración de los certificados SSL en el controlador de dominio y en el equipo de Linux. Además, mediante el LDAP PAM módulo no es compatible con cambiar restablece o había caducado la contraseña.

con LDAP y Kerberos Otra estrategia para aprovechar Active Directory para la autenticación de Linux consiste en configurar PAM para utilizar la autenticación Kerberos y NSS utilizar LDAP para buscar el usuario e información de grupo, tal como se muestra en la figura 2 . Este esquema tiene la ventaja de ser relativamente más seguro, y aprovecha las funciones "en el de cuadro" de Linux. Pero no aprovechar los registros de ubicación DNS de servicio (SRV) que publicar controladores de dominio Active Directory, por lo que están obligados a seleccionar un conjunto específico de controladores de dominio para autenticar. También no proporcionan una forma muy intuitiva de administración de caducidad de contraseñas de Active Directory o, hasta hace poco tiempo, para las búsquedas de pertenencia al grupo adecuado.

La Figura 2 Authenticating a Active Directory mediante LDAP y Kerberos (haga clic en la imagen de una vista más grande)

utilizar Winbind La tercera forma de usar Active Directory para la autenticación de Linux consiste en configurar PAM y NSS realizar llamadas al demonio Winbind. Winbind se traducen las PAM diferente y NSS solicitudes en las llamadas de Active Directory correspondientes, mediante LDAP, Kerberos o RPC, según con qué es más apropiado. la figura 3 muestra esta estrategia.

La figura 3 Authenticating a Active Directory mediante Winbind (haga clic en la imagen de una vista más grande)

Nuestro plan de implementación

Causa de la integración mejorada con Active Directory, optado por utilizar Winbind en red Hat empresa Linux 5 (RHEL5) para mi proyecto de integración de Linux a Active Directory. RHEL5 es la versión actual de la distribución Red Hat Linux comercial, y es muy popular en centros de datos de empresa.

Obtener RHEL5 para autenticarse en Active Directory básicamente requiere cinco pasos independientes, los siguientes:

1. Busque y descargue el Samba apropiado y otros componentes dependientes.
2. Crear Samba.
3. Instale y configure Samba.
4. Configurar Linux, concretamente PAM y NSS.
5. Configurar Active Directory.

Las secciones de algunas siguientes en este artículo describen estos pasos con más detalle.

Buscar el software derecho

Una de las principales diferencias entre Windows y Linux radica en que Linux se basa en de un kernel de sistema operativo pequeño y una enorme colección de componentes de descargables por separado y instalables. Esto hace posible para crear muy específica Linux configuraciones optimizado para determinadas tareas, pero también pueden realizar configuración y administración de un servidor muy complicado. Distintas distribuciones controlar esto de diferentes maneras. Red Hat (y su primo no comerciales Fedora) utilice el administrador de red de paquete Hat (RPM) para instalar y administrar estos componentes.

Los componentes de Linux para red Hat proceder de dos maneras. Archivos RPM contienen archivos binarios que han sido precompilados y creado para una combinación específica de versión del componente, distribución de Linux y arquitectura de CPU. Por lo que puede descargar y instalar, por ejemplo, la versión 1.3.8-5 del Common UNIX impresión del sistema (CUPS) creado para Fedora versión 10 que se ejecutan en una arquitectura de Intel x 86 CPU. Dado que hay una docena diferentes arquitecturas de CPU, más de 100 las distribuciones de Linux y miles de paquetes y las versiones, puede ver que hay un número increíble de RPMs binarias entre los que elegir.

Archivos RPM del origen, por otro lado, contienen el código fuente real para un determinado paquete. La expectativa es que se descargue y instalar las fuentes, configurar las opciones de generación y compilar y vincular los archivos binarios. La idea de crear sus propios componentes del sistema operativo es complicada para un chico de Windows utilizado para instalar lo que Microsoft proporciona en el CD de instalación de Windows, pero el administrador de paquete simplifica el proceso bastante sencillo y confiable es sorprendente. El grupo Samba libera actualizaciones y revisiones de seguridad a un ritmo furious; en julio y agosto de 2008 por sí solos, hay cuatro versiones de Samba 3.2, con un total de más de 100 correcciones de errores y seguridad. Para este proyecto, descargan los orígenes de la última versión estable de Samba, versión 3.0.31.

¿Por qué se ha descargar los orígenes de Samba en lugar de un conjunto precompilado de archivos binarios? Ciertamente, eso fue lo que intentó hacer en primer lugar. Lo que descubren después de muchas horas con un depurador era que no se han creado los archivos binarios que descargan con las opciones correctas para admitir la autenticación de Active Directory. En concreto, el código que admite la asignación de ID de Linux en Active Directory se ha desactivado en las generaciones predeterminada; por lo que tuve que reconstruir Samba con las opciones de generación correspondiente. Hablaré más sobre la asignación de IDENTIFICADOR más adelante en este artículo.

Aunque Linux nativa es un núcleo pequeño, la distribución Red Hat empresarial incluye muchos paquetes preinstalados. Normalmente esto, vida mucho más fácil porque empieza con un sistema de operativo completo de trabajo, pero los paquetes que están preinstalados en ocasiones, en conflicto con software que desea instalar más tarde.

No incluía Samba cuando instaló Red Hat (normalmente Samba se instala de forma predeterminada) ya que quería utilizar una versión más actual. Sin embargo, la versión más reciente de Samba requiere nuevas versiones de varias otras bibliotecas y utilidades que ya se han instalado. Este tipo de problemas de dependencia es bastante molesta, pero se resuelve fácilmente mediante el RPM.

Hay muchos sitios de Web que los paquetes RPM binario de host. El uno que he usado (por ninguna otra razón que era el encontré primero de ellos) se denomina PBONE, ubicado en rpm.pbone. NET. Tiene una forma cómoda de buscar paquetes y tenía todos los archivos binarios que necesitan para la arquitectura de CPU (i386) y distribución de sistema operativo (red Hat empresa Linux 5/Fedora 7 y 8).

Tuve que descargar y actualizar los paquetes listados en la figura 4 para crear e instalar la última versión 3.0 de Samba (no hay un árbol versión 3.2 incluso posterior que no ha intentado). Tenga en cuenta que estos paquetes destino la distribución principales Fedora (fc). Red Hat se basa en los orígenes mismos Fedora utiliza y completamente puede interoperar con él. Los paquetes integrados para Fedora principales 7 y versiones posteriores se ejecutarán en RHEL5 con ninguna modificación. Colocar los archivos RPM descargados en el directorio / usr/src/REDHAT/RPMS.

La figura 4 paquetes necesarios para crear y instalar Samba 3.0.31

SAMBA-3.031-0.fc8.src.rpm	Origen Samba 3.0.31 RPM
gnutls1.6.3-3.fc7.i386	Las bibliotecas de seguridad de nivel de transporte (TLS) GNU
gnutils-devel-1.6.3-3.fc7.i386	Los archivos de desarrollo de GNU TLS
popt-1.12-3.fc8.i386	Argumento de línea de comandos análisis de bibliotecas
popt-devel-1.12-3.fc8.i386	Argumento de línea de comandos analizar los archivos de desarrollo
cups-libs-1.2.12-11.fc7.i386	Bibliotecas de sistema de impresora de UNIX comunes
cups-devel-1.2.12-11.fc7.i386	Archivos comunes de desarrollo del sistema de impresora de UNIX
cups-1.2.12.11.fc7.i386	Binarios del sistema de impresora de UNIX comunes

SAMBA de creación

El primer paso en la creación de Samba es para descargar el origen adecuado RPM. El origen de RPM había descargada para Samba 3.0.31 desde el sitio PBONE. Colocar a continuación, el archivo RPM de código fuente descargados en / usr/src/REDHAT/SRPMS; esto es el directorio estándar de origen RPMs durante el proceso de generación.

Abrir una sesión de terminal (línea de comandos de ventana en la terminología de Windows) y desplazarse a la carpeta SRPMS. Una vez hecho, instale el paquete de origen utilizando el comando, tal como se muestra en la figura 5 .

La figura 5 instalar el origen de Samba RPM (haga clic en la imagen de una vista más grande)

Si aparece la advertencia de error " mockbuild de usuario no existe, el uso de raíz, " no se preocupe. Este error indica que no están instaladas las herramientas de generación de simulacro. El proceso de generación funcionará sin ellos.

A continuación, mueva al directorio / usr/src/REDHAT/ESPECIFICACIONES y editar el archivo SAMBA.SPEC, que contiene las opciones de generación Samba. Busque la línea que empieza con " CFLAGS = " y asegúrese de que la opción "--con-compartido de módulos = idmap_ad, idmap_rid " está presente. Esta opción garantiza que el proceso de generación incluye el código que traduce las UID de Linux (identificadores únicos) correctamente en Active Directory. la figura 6 muestra esta opción.

Figura 6 el con-compartido de módulos crear opción (haga clic en la imagen de una vista más grande)

A continuación, quizás tenga que actualizar algunos de las bibliotecas en el equipo para correctamente crear e instalar Samba; depende de qué versiones de las bibliotecas lo hizo tener instalado. En mi caso, tuve que instalar los paquetes listados en la figura 4 uso el rpm: comando de instalación; en algunos casos había que usar la--opción force que conseguir pasar algunos de los problemas de dependencia.

Para generar Samba, mueva al directorio / usr/src/redhat y ejecute el –bb rpmbuild comando SPECS/samba.spec, tal como se muestra en la figura 7 . El proceso dejar un nuevo archivo RPM de samba-3.0.31-0.i386 en el directorio / usr/src/REDHAT/RPMS. Se instalará este archivo RPM más adelante en el proyecto.

La figura 7 de crear el archivo RPM Samba binario (haga clic en la imagen de una vista más grande)

Configuración de red Linux

Para autenticar con Active Directory, el equipo Linux debe ser capaces de comunicarse con un controlador de dominio. Tiene que configurar tres configuraciones de red para que esto suceda.

En primer lugar, es importante para asegurarse de que la interfaz de red para su equipo Linux está configurada correctamente, ya sea mediante Protocolo de configuración dinámica de host (DHCP) o asignación una dirección IP adecuada y netmask mediante el comando ifconfig. Bajo RHEL5, configurar la red seleccionando red en el sistema | administración de menú, tal como se muestra en la figura 8 .

Figura 8 configuración de la red (haga clic en la imagen de una vista más grande)

A continuación, compruebe que la resolución de DNS para el equipo Linux está establecida para utilizar el mismo servidor de nombre DNS que utilizan los controladores de dominio; en la mayoría de los casos, esto es un controlador de dominio en el dominio al que desea unir el equipo de Linux, suponiendo que estás utilizando DNS Active_Directory-integrated. Configurar la resolución de DNS en la ficha DNS de la misma utilidad de configuración de red que utiliza para configurar la red, como se muestra en la figura 9 .

Figura 9 configuración de la resolución de DNS principal (haga clic en la imagen de una vista más grande)

Por último, una vez que haya completado estos pasos, debe establecer el nombre de host del equipo Linux para reflejar su nombre en el dominio. Aunque puede establecer el nombre de host mediante la aplicación de configuración de red, esto parece no siempre funciona correctamente.

En su lugar, edite el /etc/hosts archivo directamente y agregar una entrada por debajo de la entrada localhost.localdomain que tiene el formato < dirección ip > < nombre de host > <fqdn>. (Un ejemplo sería " 10.7.5.2 rhel5.linuxauth.local linuxauth ".) Tenga en debe cuenta como que error al hacer esto se resultado en la creación de un objeto de equipo incorrecto en el directorio después de unir el equipo Linux al dominio.

Configurar la sincronización de hora de Linux

El protocolo Kerberos es dependiente de los sistemas de autenticación con los relojes que están sincronizados dentro de un valor relativamente pequeño. De forma predeterminada, Active Directory permite un máximo tiempo sesgar de cinco minutos. Para asegurarse de que los sistemas Linux y el sistema de los controladores de su dominio los relojes no mantenerse dentro de este valor, debe configurar sus sistemas Linux para utilizar el servicio Protocolo de tiempo de red (NTP) de un controlador de dominio.

A continuación, en el servidor Linux, ejecute la utilidad de fecha y hora desde el sistema | menú de administración y, a continuación, haz clic en la ficha Protocolo de tiempo de red. Active la casilla Habilitar el protocolo de tiempo de red y, a continuación, agregue la dirección IP del controlador de dominio que desea utilizar como un origen de hora de la red. Observe que normalmente, esto debe ser el controlador de dominio en el dominio que desempeñe la función Flexible Single Master Operations (FSMO) de la emulador de controlador (PDC, Primary Domain Controller) de dominio principal. Figura 10 es un ejemplo de cómo establecer el origen de hora de red Linux.

Figura 10 configuración el protocolo de tiempo de red (haga clic en la imagen de una vista más grande)

Configurar PAM y NSS

PAM y NSS proporcionan el pegado entre una aplicación de Linux, como el escritorio y Winbind. Al igual que muchos servicios de Linux, configurar PAM y la NSS a través de archivos de texto. Veremos configurar PAM primero.

PAM proporciona utilidades de relacionadas con autenticación de cuatro a aplicaciones que la utilizan. La utilidad de autenticación permite que una aplicación determinar quién está utilizando. La función cuenta proporciona cuenta funciones de administración que no están específicamente relacionadas con autenticación, como restricción de tiempo de inicio de sesión. La utilidad de contraseña proporciona mecanismos para solicitar y administración de contraseñas. La utilidad de sesión realiza la configuración del usuario de ­related y tareas tear-abajo para la aplicación, tales como el registro o crear archivos en un directorio específica del usuario.

PAM en red Hat almacena sus archivos de configuración en el directorio /etc/pam.d, que contendrá un archivo de texto para cada aplicación que utiliza PAM para la autenticación. Por ejemplo, la /etc/pam.d/gdm archivo contiene la información de configuración de PAM para Gnome escritorio el administrador (GDM), el entorno de ventana predeterminado de red Hat. Cada archivo de configuración PAM contiene varias líneas, con cada línea de definir algunos aspectos del proceso de autenticación PAM. Figura 11 muestra el contenido de la PAM archivo de configuración para GDM.

Figura 11 PAM archivo de configuración para el administrador de escritorio de Gnome (haga clic en la imagen de una vista más grande)

Cada entrada de un archivo de configuración PAM tiene el formato < grupo de administración > <control> <module> <parameters>, donde < grupo de administración > corresponde a la función de la entrada de configuración pertenece a: autenticación, cuenta, contraseña o sesión. Las palabras clave de control, que se describen en la figura 12 , indican PAM cómo procesar la entrada de configuración. La tercera columna del archivo contiene el nombre de una biblioteca compartida PAM en el directorio /lib/security. Bibliotecas compartidas contienen código ejecutable cargable dinámicamente, la similar a las DLL de Windows. Términos adicionales después del nombre del módulo son parámetros que PAM pasa a la biblioteca compartida.

La figura 12 palabras clave de control PAM

Palabra clave	Descripción
Requerido	Si el módulo se realiza correctamente, PAM continúa evaluando las entradas restantes para el grupo de administración, y los resultados se determinarse por los resultados de los demás módulos. Si falla el módulo, PAM continúa evaluación pero devolverá un error a la aplicación que realiza la llamada.
Necesario	Si se realiza correctamente el módulo, PAM continúa evaluando las entradas de grupo de administración. Si falla el módulo, PAM devuelve en la aplicación realiza la llamada con ningún procesamiento adicional.
Suficiente	Si el módulo se realiza correctamente, PAM devolverá éxito a la aplicación que realiza la llamada. Si falla el módulo, PAM sigue evaluación, pero los resultados vendrá determinados por módulos posteriores.
Opcional	A menos que sea el módulo único especificado para el grupo de administración, PAM omite los resultados del módulo.
Incluir	PAM incluye el contenido del archivo de configuración PAM al que se hace referencia y procesa las entradas que contiene.

Puede ver que cada grupo de administración tiene varias entradas. PAM procesa las entradas en orden mediante una llamada al módulo con nombre. El módulo, a continuación, devuelve éxito o fracaso, y PAM continúa acuerdo con la palabra clave de control.

Observará que el archivo de configuración de PAM de GDM incluye autenticación de sistema en todos sus grupos de administración. Se trata cómo PAM establece el comportamiento de autenticación predeterminado para GDM. Si modifica la autenticación de sistema, puede modificar el comportamiento de autenticación para todas las aplicaciones que incluyen el archivo de la autenticación de sistema en sus configuraciones PAM. En la figura 13 se muestra el archivo de la autenticación de sistema predeterminado.

Figura 13 archivo de sistema de autenticación de PAM (haga clic en la imagen de una vista más grande)

El módulo de nombre de servicio de conmutador (NSS) oculta los detalles del sistema de almacenamiento de datos desde el desarrollador de aplicaciones, en gran parte del mismo modo que PAM oculta los detalles de la autenticación. NSS permite al administrador especificar que se almacenan las bases de datos del sistema de forma. En concreto, el administrador puede especificar cómo se almacena información de nombre de usuario y contraseña. Porque queremos que las aplicaciones para buscar información de usuario en Active Directory mediante Winbind, tenemos que modificar el archivo de configuración de NSS para mostrar.

Red Hat incluye un pequeño subprograma gráfico para configurar PAM y NSS había denominado configuración de sistema de autenticación. Se encarga de más (pero no todas) de los cambios necesita hacer en los archivos de autenticación de sistema y nss.conf.

Ejecutar la aplicación de configuración de sistema de autenticación y verá un cuadro de diálogo como la que se muestra en la figura 14 . Active la opción Winbind en tanto en la ficha información del usuario (que configura el archivo nss.conf) y en la ficha autenticación (que modifica el archivo de sistema de autenticación).

Figura 14 el diálogo de autenticación de systemconfig

Haga clic en el botón Configurar Winbind y verá el cuadro de diálogo en la figura 15 . Especifique el nombre del dominio que desea que los usuarios autenticar en el campo dominio Winbind y seleccione "anuncios" como el modelo de seguridad. Escriba el nombre de dominio DNS del dominio de Active Directory en el campo Winbind ADS territorio. En el campo Winbind los controladores de dominio, escriba el nombre de un controlador de dominio desea autenticar con este sistema de Linux o un asterisco, que indica que Winbind debe seleccionar un controlador de dominio consultando DNS los registros SRV.

Figura 15 configurar Winbind diálogo

Seleccione el shell de comandos predeterminado adecuado que deben tener los usuarios de Active Directory; en este caso, selecciona Bourne-nuevo revestimientos o BASH. No intente el botón combinación dominio en este momento. Se unirán el equipo en el dominio más adelante.

Hay un cambio adicional para realizar en el archivo /etc/pam.d/system-auth después de que haya modificado para admitir Winbind. Cuando un usuario de Linux inicia sesión, el sistema requiere que el usuario tiene un directorio principal. El directorio principal contiene muchos preferencias específicas del usuario y elementos de configuración, al igual que el registro de Windows. El problema es que porque va a crear los usuarios en Active Directory, Linux no se automáticamente Crear directorio particular del usuario. Afortunadamente, puede configurar PAM para hacerlo como parte de su configuración de sesión.

Abra el archivo /etc/pam.d/system-auth, a continuación, desplácese hacia la parte inferior y insertar una línea antes de la última línea en la sección de sesión que se lee " sesión map_mkhomedir.so opcional skel = / etc/skel umask = 0644" (consulte la figura 16 ). Esta línea configura PAM para crear un directorio principal para un usuario si no existe uno. Utilizará el directorio/etc/skel como un "esquema" o la plantilla, y asignará la máscara de permisos 0644 (lectura y escritura para lectura para todos los demás, propietario y de lectura para el grupo primario) a la nueva carpeta.

Figura 16 creación de un directorio principal para los usuarios (haga clic en la imagen de una vista más grande)

Instalar y configurar Samba

Para instalar los archivos binarios de Samba que acaba de crear, cambiar el directorio / usr/src/REDHAT/RPMS. Todos los archivos RPM creados por el comando rpmbuild aparecerán en este directorio. Recuerde que Samba incluye los archivos binarios que permiten un cliente de Linux tener acceso a un recurso compartido de archivos Windows (o Samba), así como código que permita un sistema de Linux para actuar como un servidor de archivos de Windows, un servidor de impresión de Windows y un controlador de Windows NT 4.0 estilo.

No necesitamos todo eso para permitir que Linux para autenticarse en Active Directory; todo lo que necesitamos realmente son los archivos comunes Samba y los binarios de cliente Samba. Estos archivos se dividirán fuera fácilmente en archivos RPM dos: samba-cliente-3.0.31-0.i386.rpm y samba-común de 3.0.31-0.i386.rpm. Instalar los archivos RPM mediante la rpm: comando de instalación. A continuación se muestra un ejemplo: rpm--instalar samba-común de 3.0.31-0.i386.rpm. (Tenga en cuenta que tendrá que instalar primero el archivo RPM –common.)

Una vez que ha instalado los binarios de cliente Samba, debe modificar la configuración de Samba predeterminada para asegurarse de que Winbind controla la autenticación correctamente con Active Directory. Toda la información de configuración Samba (cliente y servidor) puede encontrarse en el archivo de texto smb.conf, que está en el directorio/etc / samba de manera predeterminada. Smb.conf puede contener un número enorme de las opciones de configuración, y una explicación completa de su contenido se sale del ámbito de este artículo. El sitio Web de samba.org y las páginas de tipo " Man " Linux tratan smb.conf en algún detalle.

El primer paso es configurar Winbind para utilizar Active Directory para la autenticación. Debe establecer el modelo de seguridad en smb.conf para "anuncios". La utilidad de configuración de sistema de autenticación debe ha establecer esto para usted ya, pero siempre es conveniente comprobar. Editar el archivo smb.conf y busque la sección Opciones de miembros de dominio con la etiqueta. Busque la línea que comienza con "seguridad" y asegúrese de que se lee " seguridad = anuncios ". El siguiente paso de configuración determina cómo Winbind asignará Windows principales de seguridad, como usuarios y grupos a los identificadores de Linux, y requiere una pequeña explicación más.

El problema de asignación de ID.

Hay un gran problema que he no ha mencionado aún con autenticación de usuarios de Linux con Active Directory y es el problema de las UID de usuarios y grupos. Internamente, ni Linux Windows hacer referencia a los usuarios por su nombre de usuario; en su lugar utilizan un identificador interno único. Windows utiliza el identificador de seguridad o SID, que es una estructura de longitud variable que identifica inequívocamente cada usuario dentro de un dominio de Windows. El SID también contiene un identificador único del dominio, para que Windows pueda distinguir entre los usuarios en diferentes dominios.

Linux tiene una cantidad combinación más sencilla. Cada usuario en un equipo Linux tiene un UID que es simplemente un entero de 32 bits. Pero el ámbito de la UID está limitado en el equipo sí mismo. No hay ninguna garantía de que el usuario con la UID 436 en un equipo Linux es el mismo que el usuario con la UID 436 en otro equipo de Linux. Por lo tanto, un usuario tendrá para iniciar sesión en cada equipo que necesita para tener acceso a, claramente no una situación deseable.

Normalmente, los administradores de red de Linux solucionan este problema proporcionando autenticación de red con el sistema de información de red (NIS) o un directorio compartido de LDAP. El sistema de autenticación de red proporciona la UID para el usuario y todos los equipos Linux que utilizan ese sistema de autenticación compartan el mismo usuario y los identificadores de grupo. En este caso, VOY a utilizar Active Directory para proporcionar el usuario único y los identificadores de grupo.

Hay dos estrategias que puede utilizar para solucionar este problema. La estrategia primer (y también más obvia) es crear un UID para cada usuario y grupo y almacenar ese identificador con el objeto correspondiente en Active Directory. Este modo, cuando un usuario se autentica Winbind, puede buscar la UID para el usuario y proporcionarla a Linux como el identificador del usuario interno. Winbind hace referencia a esta combinación como asignación de ID de Active Directory o idmap_ad. la figura 17 se muestra el proceso de asignación de ID de Active Directory.

En la figura 17 asignación de ID de Active Directory (haga clic en la imagen de una vista más grande)

La desventaja única asignación de ID de Active Directory es que se tiene que proporcionar un mecanismo para garantizar que cada usuario y grupo tiene un identificador y que estos identificadores son todos los únicos en el bosque. Para obtener más información, consulte la barra lateral, "Configuración de Directory Active para Directory Active ID de asignación,".

Afortunadamente, hay otra estrategia de asignación de ID que tiene mucho menos sobrecarga administrativa. Recuerde que el SID de Windows identifica el usuario dentro de un dominio, así como del dominio propiamente dicho. La parte de los SID que identifica el usuario en el dominio se denomina identificador relativo o RID y es en realidad un entero de 32 bits. Por tanto, Winbind puede simplemente extraer el RID el SID cuando el usuario inicie sesión en y a continuación, utilice el RID como la UID interna única. Winbind hace referencia a esta estrategia como asignación de RID o idmap_rid. figura 18 se muestra cómo asignación de RID funciona realmente.

Figura 18 RID asignación (haga clic en la imagen de una vista más grande)

Asignación de RID tiene la ventaja de cero sobrecarga administrativa, pero no puede utilizar en un entorno con varios dominios debido a de la probabilidad de que los usuarios de diferentes dominios tener el mismo valor RID. Pero si tiene un único dominio de Active Directory, asignación de RID es la forma.

Para configurar la estrategia de asignación Winbind ID, modifique el archivo de /etc/samba/smb.conf nuevo y agregue la línea " idmap back-end = ad " utilizar la estrategia de asignación de Active Directory, o " idmap back-end = eliminar " si desea utilizar la estrategia de asignación de RID. Compruebe que no hay otras líneas especificar la estrategia de asignación en el archivo.

Hay un par de otras opciones de configuración que tenemos que agregar al archivo smb.conf para Winbind. Aunque se ha configurado PAM para crear el directorio principal para cada usuario cuando inicien sesión en, necesitamos saber Winbind lo que es el nombre de ese directorio principal. Nos ello, agregue la línea " plantilla homedir = /home/%U " para smb.conf (consulte la figura 19 ). Esto indica Winbind que el directorio principal para cada usuario que autentica mediante Active Directory será /home/ < nombre de usuario >. Asegúrese de crear el /home directorio con antelación.

Figura 19 especificar el nombre del directorio principal (haga clic en la imagen de una vista más grande)

Unirse el dominio y registro en

Ahora que la red, PAM, NSS y Samba Winbind están todos configurados correctamente, es tiempo para unir el equipo Linux al dominio. Esto se hace mediante el comando NET Samba. En un símbolo del sistema de shell, ejecute "NET anuncios combinación –U < nombre del administrador >". Reemplazar < nombre del administrador > con el nombre de una cuenta que tiene suficientes privilegios para unir un equipo al dominio.

El comando net le pedirá la contraseña del usuario. Si todo funciona correctamente, el comando net unir el equipo al dominio. Puede utilizar Active usuarios y equipos de Active para buscar la cuenta de equipo recién creado.

Puede comprobar el estado de la combinación con la herramienta de prueba Winbind denominada wbinfo. Ejecución –t wbinfo probará la relación de confianza entre el equipo y el dominio. Ejecución –u wbinfo muestra todos los usuarios del dominio y wbinfo –g muestra todos los grupos.

Si el equipo de Linux correctamente se une al dominio, el paso siguiente es intentar iniciar sesión con una cuenta de usuario de Active Directory y la contraseña. Cerrar el equipo de Linux, sesión y utilizar un nombre de usuario de Active Directory. Si todo funciona correctamente, podrá iniciar sesión.

Configurar Active Directory para la asignación de ID de Active Directory

Esta información se aplica sólo si está utilizando la asignación de ID de Active Directory. Si se ha decidido utilizar asignación de RID, no dude omitir esta barra lateral.

Antes de empezar a iniciar sesión en el servidor de red Hat utilizando una cuenta de Active Directory, tendrá que realizar algunos cambios en Active Directory. En primer lugar, el esquema de Active Directory tiene que dar cabida a los atributos que Winbind utiliza para almacenar información de usuario. Si está ejecutando Windows Server 2003 R2, el esquema está preparado para ir. Si tiene una versión anterior del esquema de Active Directory, tendrá que ampliar mediante el servicios de Microsoft para UNIX (SFU) de paquete.

Puede encontrar información en Servicios para UNIX en TechNet. SFU también incluye una página de propiedades adicionales para los usuarios de Active Directory y el equipos Microsoft Management Console (MMC) complemento que permite administrar el IDENTIFICADOR de usuario y el información de ID de grupo que precisa de Linux.

Una vez el esquema está configurado correctamente, tiene que proporcionar los identificadores de Linux para todos los usuarios (y los grupos a los que son miembros) que puede iniciar sesión en el equipo de Linux. Esto significa que tendrá que definir valores para los atributos uidNumber y gidNumber de los usuarios y grupos que pueden iniciar sesión en los equipos de Linux. Pero debe tener en cuenta algunos requisitos para estos atributos:

1. Linux requiere un UID para cada usuario que autentica. Porque desea administrar la información de usuario en Active Directory, cada cuenta de usuario que iniciará una sesión en un equipo Linux debe tener un atributo uidNumber único. El valor específico que utilice para un uidNumber no es importante, pero debe ser único entre todos los usuarios pueden iniciar sesión en el equipo de Linux.
2. Cada usuario de Linux también debe tener un identificador de grupo predeterminado, para cada usuario de Active Directory que se iniciará una sesión en un equipo Linux requiere un valor para el atributo gidNumber así. Este valor no tiene que ser único entre los usuarios, pero debe identificar el grupo.
3. Cada grupo en Active Directory debe tener un valor único para el atributo gidNumber. En realidad, es ACEPTAR para grupos de no tiene un valor para el atributo gidNumber, pero Winbind espera, cuando autentica un usuario, que cada grupo al que ese usuario es miembro tendrá un valor único gidNumber. Es probablemente fácil sólo asegúrese de que cada grupo tiene un valor único gidNumber.
4. Winbind espera que cada usuario busca en Active Directory es miembro del grupo Usuarios del dominio, por lo que también espera que el grupo Usuarios del dominio tiene un valor para el atributo gidNumber.

¿Qué ocurre si se no trabajar?

Configurar un equipo Linux para autenticar con Active Directory uso Winbind no es un proyecto trivial. Existen gran cantidad de piezas para configurar y muchas cosas que pueden ir mal. El hecho de que todas las versiones de Linux y cada versión de Samba es un poco diferentes no ayuda temas. Pero hay unas cuantas de lugares que puede buscar para ayudar a determinar lo que ocurre.

En primer lugar, hay el archivo de registro de sistema Linux, que se mantiene en var y registro y los mensajes. SAMBA colocará los mensajes de este archivo de eventos importantes, como los archivos que faltan o configuración incorrecta. En además el archivo de registro del sistema, hay también los archivos de registro para Samba y Winbind. Puede encontrar en var y registro y samba, y se proporcionan, con cierta información adicional.

Se puede aumentar el detalle (y el volumen) de los mensajes del registro emitidos por Winbind mediante la modificación de su secuencia de comandos de inicio para establecer el nivel de depuración. Modifique la secuencia de comandos de shell /etc/init.d/winbind y agregue "-d 5" al comando winbindd. Esto aumentará el nivel de depuración a 5 (valores permitidos son de 1 a 10), que hará que winbind generar mensajes de error más detallados.

Si se obtiene Winbind, hasta como la comunicación con un controlador de dominio, puede ejecutar una utilidad de captura de paquetes de red, como Netmon 3.1. Esto le permite analizar exactamente lo que Winbind está intentando hacer. Y también puede examinar el registro de seguridad de Windows en el controlador de dominio, que se muestran los intentos de autenticación.

Ahora que funciona, ¿qué tiene?

Si se ha logrado obtener todo para trabajar, ahora tiene la capacidad de registrar en el sistema de Linux con las credenciales que se conservan en Active Directory. Esto es una enorme mejora sobre administración de identidades localmente en el equipo de Linux o mediante un sistema no seguro como NIS. Permite centralizar la administración de usuario en almacén de identidades de una: Active Directory.

Pero hay una varias cosas que faltan para hacer que esta solución realmente útil. En primer lugar, obtener soporte técnico es un poco de una operación hit-or-miss. La mayoría de las organizaciones de Linux es un poco en la oscuridad cuando lo que respecta a Active Directory, y la compatibilidad que se puede obtener de la comunidad de Linux depende totalmente que ocurre leer la entrada de blog y cómo siente ese día.

También no hay herramientas de migración o implementación con Samba. Si tiene cuentas existentes de Linux con sus identificadores de usuario asociada y permisos, debe asegurarse manualmente de que mantiene su UID al migrar a Active Directory.

No Finalmente, una de las aplicaciones más importantes de Active Directory, directiva de grupo, está todavía disponible en SAMBA, aunque esté en el funcionamiento. Aunque puede combinar un sistema de Linux con Active Directory con Samba, no puede administrar mediante Directiva de grupo.

Soluciones de terceros

Autenticar equipos de Linux con Active Directory es claramente A Thing válida, pero distribuir su propia solución utilizando Samba Winbind es tedioso si no completamente dolorosa. Se piensa algunos proveedores de software innovadores podrían paso hacia arriba con una solución más fácil de utilizar, y sería derecho.

Hay cuatro proveedores de software comercial que han desarrollado versiones fácil de instalación de y de uso de lo que ha demostrado en este artículo. Ofrecer el código y herramientas de migración para prácticamente cada versión popular de Apple Macintosh, UNIX y Linux, así como compatibilidad para administración de equipos de Linux mediante la directiva de grupo.

Las compañías a las cuatro son Centrify, Software de forma similar, Quest Software y Symark. Todos los proveedores de cuatro proporcionan funcionalidad similar, incluidas la administración de directivas de grupo, a través de una gran variedad de las distribuciones de Linux. Software Likewise recientemente ha originado abierto su implementación, denominado Abrir Asimismo, aunque su componente de directiva de grupo sigue siendo un producto comercial. Del mismo modo abrir estarán disponible con varias distribuciones de Linux principales. (Total revelación: mientras que en el proceso de escritura Quest Software adquirió este artículo, mi compañía, NetPro,.)

¿Sentido para crear su propio sistema de autenticación mediante Samba y Winbind cuando hay comerciales las opciones disponibles? Si spending dinero en integración de software no está en la cotización, a continuación, pasar la ruta de código abierto con Samba tiene la ventaja de estar disponible. También obtendrá todos los el código fuente, que puede ser una ventaja atractiva. Pero migrar Linux existente máquinas y su UID existentes es un problema muy difícil.

Por otro lado, si desea ahorrar tiempo de instalación e implementación, tengan existente Linux que necesita migrar, o en su lugar tendrá alguien llama a para obtener una respuesta autorizada a su pregunta, entonces la desprotección de una de las soluciones comerciales, tiene sentido. Y si necesita administración de directivas de grupo, a continuación, la alternativa comercial es la única opción.

Pero cualquier forma vaya, integrar la autenticación de Linux con Active Directory reduce el esfuerzo dedicado a administrar varias cuentas de usuario, mejora la seguridad del sistema y le proporcionará un almacén de identidades único para administrar y de auditoría. Y éstos son todos los motivos muy atractivas para Anímese a intentarlo.

Gil Kirkpatrick ha diseñado o desarrollado docenas de productos de software comercial con éxito de su carrera de 30 años y es el fundador de la conferencia de expertos en Active (ahora denominadas la conferencia de expertos en). Gil es el autor de Active Directory Programming y es un colaborador frecuente Windows IT Pro y la TechNet Magazine. En su función actual como experto en domicilio NetPro (ahora parte de Quest Software), Gil consulta en diversos seguridad, identidad y proyectos de marketing y ofrece tecnología seminarios y conferencias todo el mundo.