integración-windows-unix-dns

Universidad Politécnica de ValenciaDepartamento de Sistemas Informáticos y Computación

Curso de Integración de SistemasLinux/Windows

Linux CentOS 5 y Windows Server 2003 R2

porFernando Ferrer GarcíaAndrés Terrasa Barrena

Curso Académico 2009/2010Valencia, 21 de mayo de 2010

Curso de Integración de Sistemas Linux/Windows

Indice1. Administración de dominios Windows 2003 ....................................................... 1

1.1. Introducción ............................................................................................ 31.2. El Directorio Activo ................................................................................. 3

1.2.1. Dominios Windows 2003 y el Directorio Activo ............................... 31.2.2. Estándares relacionados ................................................................. 41.2.3. El Directorio Activo y DNS ............................................................ 41.2.4. Estructura lógica ........................................................................... 51.2.5. Estructura física .......................................................................... 12

1.3. Objetos que administra un dominio ........................................................ 151.3.1. Usuarios globales ........................................................................ 161.3.2. Grupos ....................................................................................... 171.3.3. Equipos ...................................................................................... 181.3.4. Unidades Organizativas ............................................................... 19

1.4. Compartición de recursos ....................................................................... 191.4.1. Permisos y derechos .................................................................... 191.4.2. Compartición dentro de un dominio ............................................. 201.4.3. Mandatos Windows 2003 para compartir recursos ......................... 21

1.5. Delegación de la administración ............................................................. 222. Administración de dominios en Linux ............................................................. 23

2.1. Introducción .......................................................................................... 252.2. Concepto de dominio ............................................................................. 252.3. Servicios de directorio y LDAP ............................................................... 252.4. Visión general de la implementación de un dominio Linux con OpenLDAP 282.5. Instalación del servidor OpenLDAP ........................................................ 292.6. Instalación de las herramientas cliente de OpenLDAP .............................. 302.7. Migración de la información del servidor ................................................ 322.8. Autenticación basada en OpenLDAP ....................................................... 342.9. Permisos de acceso ................................................................................. 352.10. Configuración de OpenLDAP con varios servidores ............................... 372.11. Herramientas gráficas de administración ............................................... 38

3. Sistema de Archivos en Red (NFS) ................................................................... 413.1. Introducción .......................................................................................... 433.2. Acceso a directorios remotos mediante NFS ............................................. 433.3. Usos típicos de NFS ............................................................................... 433.4. Funcionamiento de NFS ......................................................................... 443.5. Instalación y configuración del cliente NFS .............................................. 443.6. Instalación y configuración del servidor NFS ........................................... 45

4. Configuración Básica de Samba ....................................................................... 494.1. ¿Qué es Samba? ..................................................................................... 514.2. El protocolo SMB ................................................................................... 524.3. Configuración de Samba ........................................................................ 554.4. Niveles de seguridad ............................................................................. 564.5. Configuración de Samba en el nivel domain ............................................ 57

4.6. Tratamiento de los accesos como invitado ............................................... 584.7. El sistema de ficheros CIFS para Linux .................................................... 594.8. Opciones del servidor Samba .................................................................. 604.9. Opciones del recurso .............................................................................. 61

5. Integración de dominios mediante servidores Windows Server 2003 ................. 635.1. Introducción .......................................................................................... 655.2. Aspectos básicos a considerar ................................................................. 655.3. Integración de clientes Linux mediante Windows Services for UNIX ......... 67

5.3.1. Modificaciones del Directorio Activo ............................................ 675.3.2. Configuración de los clientes Linux .............................................. 69

5.4. Integración de clientes Linux mediante Winbind ...................................... 745.5. Directorios home centralizados ............................................................... 78

5.5.1. Uso de pam_mkhomedir y pam_mount ........................................ 795.5.2. Uso de pam_script ....................................................................... 81

6. Integración de dominios mediante servidores Linux ......................................... 856.1. Introducción .......................................................................................... 876.2. Estructura del Servicio de Directorio ....................................................... 886.3. Instalación del software .......................................................................... 906.4. Configuración del servidor OpenLDAP ................................................... 906.5. Configuración del cliente Linux .............................................................. 936.6. Configuración del servidor Samba .......................................................... 946.7. Configuración del cliente Windows ......................................................... 976.8. Conclusiones ......................................................................................... 986.9. Comandos de referencia ......................................................................... 98

A. Nota Legal .................................................................................................... 101

Curso de Integración de Sistemas Linux/Windows

vi ©A. Terrasa, F. Ferrer

Lista de figuras2.1. Estructura de directorio del dominio admon.com. ............................................ 272.2. Vista de la herramienta phpLDAPadmin ......................................................... 394.1. Protocolos sobre los que puede implementarse SMB. ........................................ 525.1. Pestaña de atributos UNIX en Usuarios y Equipos de Active Directory. ............. 685.2. Configuración de la autenticación Kerberos en Linux. ...................................... 735.3. Configuración de la autenticación Kerberos en Linux. ...................................... 75

Lista de tablas4.1. Resumen de los accesos como invitado en modo "domain" ............................... 584.2. Opciones de montaje del sistema de archivos CIFS ........................................... 604.3. Principales opciones de la sección [global] de Samba ........................................ 604.4. Principales opciones de los recursos en Samba ................................................. 61

1Administración de

dominios Windows 2003

Indice1.1. Introducción .................................................................................................... 31.2. El Directorio Activo ......................................................................................... 3

1.2.1. Dominios Windows 2003 y el Directorio Activo ....................................... 31.2.2. Estándares relacionados ......................................................................... 41.2.3. El Directorio Activo y DNS .................................................................... 41.2.4. Estructura lógica ................................................................................... 51.2.5. Estructura física .................................................................................. 12

1.3. Objetos que administra un dominio ................................................................ 151.3.1. Usuarios globales ................................................................................ 161.3.2. Grupos ............................................................................................... 171.3.3. Equipos .............................................................................................. 181.3.4. Unidades Organizativas ....................................................................... 19

1.4. Compartición de recursos ............................................................................... 191.4.1. Permisos y derechos ............................................................................ 191.4.2. Compartición dentro de un dominio ..................................................... 201.4.3. Mandatos Windows 2003 para compartir recursos ................................. 21

1.5. Delegación de la administración ..................................................................... 22

1.1. IntroducciónEste capítulo introduce los conceptos fundamentales sobre dominios Windows 2003, sufi-cientes para poder unificar y centralizar la administración de conjuntos de sistemas Win-dows 2003 en organizaciones de cualquier tamaño.

En concreto, se explicarán los conceptos fundamentales que soportan el Directorio Activo(Active Directory), así como la administración del mismo, incluyendo los principales objetosque pueden definirseen el mismo, la compartición de recursos entre sistemas de la organiza-ción y la delegación de tareas administrativas dentro de un dominio.

1.2. El Directorio Activo

1.2.1. Dominios Windows 2003 y el Directorio Activo

Hoy en día, los ordenadores existentes en cualquier organización se encuentran formandoparte de redes de ordenadores, de forma que pueden intercambiar información. Desde elpunto de vista de la administración de sistemas, la mejor forma de aprovechar esta caracte-rística es la creación de un dominio de sistemas, en donde la información administrativa y deseguridad se encuentra centralizada en uno o varios servidores, facilitando así la labor del ad-ministrador. Windows 2003 utiliza el concepto de directorio para implementar dominios desistemas Windows 2003.

En el ámbito de las redes de ordenadores, el concepto de directorio (o almacén de datos) esuna estructura jerárquica que almacena información sobre objetos en la red, normalmenteimplementada como una base de datos optimizada para operaciones de lectura y que sopor-ta búsquedas de grandes datos de información y con capacidades de exploración.

Active Directory es el servicio de directorio de una red de Windows 2003. Este serviciode directorio es un servicio de red que almacena información acerca de los recursos de la redy permite el acceso de los usuarios y las aplicaciones a dichos recursos, de forma que se con-vierte en un medio de organizar, controlar y administrar centralizadamente el acceso a los re-cursos de la red.

Como veremos, al instalar el Directorio Activo en uno o varios sistemas Windows 2003(Server) de nuestra red, convertimos a dichos ordenadores en los servidores del dominio, omás correctamente, en los denominados Controladores de Dominio (Domain Controllers) o sim-plemente "DCs". El resto de los equipos de la red pueden convertirse entonces en los clientesde dicho servicio de directorio, con lo que reciben toda la información almacenada en loscontroladores. Esta información incluye no sólo las cuentas de usuario, grupo, equipo, etc.,sino también los perfiles de usuario y equipo, directivas de seguridad, servicios de red, etc.El Directorio Activo se convierte así en la herramienta fundamental de administración de to-da la organización.

Una de las ventajas fundamentales del Directorio Activo es que separa la estructura lógicade la organización (dominios) de la estructura física (topología de red). Ello permite, por una

1.1. Introducción

©A. Terrasa, F. Ferrer 3

parte, independizar la estructuración de dominios de la organización de la topología de la(s)red(es) que interconectan los sistemas; y, por otra parte, permite administrar la estructura fí-sica explícitamente cuando es necesario, de forma independiente de la administración de losdominios. Más adelante en este capítulo se exponen ambas estructuras detalladamente.

1.2.2. Estándares relacionados

A diferencia de su antecesor NT 4.0, Windows 2003 proporciona compatibilidad con un buennúmero de protocolos y estándares existentes, ofreciendo interfaces de programación deaplicaciones que facilitan la comunicación con otros servicios de directorio. Entre ellos, pode-mos destacar los siguientes:

• DHCP (Dynamic Host Configuration Protocol). Protocolo de configuración dinámica de or-denadores, que permite la administración desatendida de direcciones de red.

• DNS (Domain Name System). Servicio de nombres de dominio que permite la administra-ción de los nombres de ordenadores. Este servicio constituye el mecanismo de asignacióny resolución de nombres (traducción de nombres simbólicos a direcciones IP) en Internet.

• SNTP (Simple Network Time Protocol). Protocolo simple de tiempo de red, que permite dis-poner de un servicio de tiempo distribuido.

• LDAP (Lightweight Directory Access Protocol). Protocolo ligero (o compacto) de acceso a di-rectorio. Este es el protocolo mediante el cual las aplicaciones acceden y modifican la in-formación existente en el directorio.

• Kerberos V5. Protocolo utilizado para la autenticación de usuarios y máquinas..

• Certificados X.509. Estándar que permite distribuir información a través de la red de unaforma segura.

De entre todos ellos, es imprescindible que el administrador conozca en detalle la relaciónentre el Directorio Activo y DNS. A continuación se exponen los aspectos fundamentales deesta relación.

1.2.3. El Directorio Activo y DNS

El Directorio Activo y DNS son espacios de nombres. Podemos entender un espacio de nom-bres como un área delimitada en la cual un nombre puede ser resuelto. La resolución denombres es el proceso de traducción de un nombre en un objeto o información que lo repre-senta. Por ejemplo, el sistema de ficheros NTFS puede ser considerado un espacio de nom-bres en cual un fichero puede ser resuelto en el fichero propiamente dicho.

DNS es el sistema de nombres de facto para redes basadas en el protocolo TCP/IP y el ser-vicio de nombres que se usa para localizar equipos en Internet. Windows 2003 utiliza DNSpara localizar equipos y controladores de dominio. Una estación de trabajo o servidor miem-bro busca un controlador de dominio preguntando a DNS.

1.2.2. Estándares relacionados

4 ©A. Terrasa, F. Ferrer

Cada dominio de Windows 2003 se identifica unívocamente mediante un nombre DNS(por ejemplo, miempresa.com) y cada equipo basado en Windows 2003 que forma parte deun dominio tiene un nombre DNS cuyo sufijo es precisamente el nombre DNS de dicho do-minio (siguiendo con el ejemplo, pc0100.miempresa.com). De esta forma vemos que do-minios y equipos se representan como objetos en Active Directory y como nodos en DNS.Por tanto resulta fácil confundir ambos espacios de nombres ya que comparten idénticosnombres de dominio. La diferencia es que aunque comparten la misma estructura, almace-nan información diferente: DNS almacena zonas y registros de recursos y el Directorio Acti-vo guarda dominios y objetos de dominio.

Como conclusión diremos que Directorio Activo utiliza DNS, para tres funciones princi-pales:

1. Resolución de nombres: DNS permite realizar la resolución de nombres al convertir losnombres de host a direcciones IP.

2. Definición del espacio de nombres: Directorio Activo utiliza las convenciones de no-menclatura de DNS para asignar nombre a los dominios.

3. Búsqueda de los componentes físicos de AD: para iniciar una sesión de red y realizarconsultas en Directorio Activo, un equipo con Windows 2003 debe encontrar primeroun controlador de dominio o servidor de catálogo global para procesar la autenticaciónde inicio de sesión o la consulta. La base de datos DNS almacena información acerca dequé equipos realizan estas funciones para que se pueda atender la solicitud adecuada-mente. En concreto, esto se lleva a cabo mediante registros de recursos SRV que especifi-can el servidor (o servidores) del dominio que proporcionan los servicios de directoriocorrespondientes.

1.2.4. Estructura lógica

La estructura lógica del Directorio Activo se centra en la administración de los recursos de lared organizativa, independientemente de la ubicación física de dichos recursos, y de la topo-logía de las redes subyacentes. Como veremos, la estructura lógica de la organización se basaen el concepto de dominio, o unidad mínima de directorio, que internamente contiene infor-mación sobre los recursos (usuarios, grupos, directivas, etc.) disponibles para los ordenado-res que forman parte de dicho dominio. Dentro de un dominio es posible subdividir lógica-mente el directorio mediante el uso de unidades organizativas, que permiten una administra-ción independiente sin la necesidad de crear múltiples dominios. Sin embargo, si la organi-zación desea estructurarse en varios dominios, también puede hacerlo, mediante los concep-tos de árbol y bosque; ambos son jerarquías de dominios a distintos niveles, en función de silos dominios comparten o no un espacio de nombres común. A continuación se presentan to-dos estos conceptos de forma más detallada.

1.2.4.1. Dominios

La unidad central de la estructura lógica del Directorio Activo es el dominio. Un dominio es



un conjunto de equipos que comparten una base de datos de directorio común. Dentro deuna organización, el Directorio Activo se compone de uno o más dominios, cada uno de ellossoportado, al menos, por un controlador de dominio. Como hemos visto, cada dominio seidentifica unívocamente por un nombre de dominio DNS, que debe ser el sufijo DNS princi-pal de todos los ordenadores miembros del dominio, incluyendo el o los controladores.

El uso de dominios permite conseguir los siguientes objetivos:

• Delimitar la seguridad. Un dominio Windows 2003 define un límite de seguridad. Lasdirectivas de seguridad, los derechos administrativos y las listas de control de acceso (Ac-cess Control Lists, ACLs) no se comparten entre los dominios. Active Directory puede in-cluir uno o más dominios, teniendo cada uno sus propias directivas de seguridad.

• Replicar información. Un dominio es una partición del directorio, las cuales son unida-des de replicación. Cada dominio almacena solo la información sobre los objetos localiza-dos en este dominio. Active Directory utiliza un modelo de replicación con varios maes-tros. Todos los controladores de dominio del dominio pueden recibir cambios realizadossobre los objetos, y pueden replicar estos cambios a todos los controladores de dominioen el dominio.

• Aplicar Políticas (o Directivas) de Grupo. Un dominio define un posible ámbito para laspolíticas. Al aplicar un objeto de política de grupo (GPO) al dominio, este establece comolos recursos del dominio se configuran y se usan. Estas políticas se aplican dentro del do-minio y no a través de los dominios.

• Delegar permisos administrativos. En las redes que ejecutan Windows 2003, se puededelegar a medida la autoridad administrativa tanto para unidades organizativas (OUs)individuales como a dominios individuales, lo cual reduce el número de administradoresnecesarios con amplios permisos administrativos. Ya que un dominio representa un lími-te de seguridad, los permisos administrativos se limitan al dominio.

1.2.4.2. Múltiples dominios en la misma organización

Existen muchos casos en los que es interesante disponer de varios dominios de ordenadoresWindows 2003 en la misma organización (distribución geográfica o departamental, distintasempresas, etc.). El Directorio Activo permite almacenar y organizar la información de direc-torio de varios dominios de forma que, aunque la administración de cada uno sea indepen-diente, dicha información esté disponible para todos los dominios.

Según los estándares de nombres DNS, los dominios de Active Directory se crean dentrode una estructura de árbol invertida, con la raíz en la parte superior. Además, esta jerarquíade dominios de Windows 2003 se basa en relaciones de confianza, es decir, los dominios sevinculan por relaciones de confianza entre dominios.

Cuando se instala el primer controlador de dominio en la organización se crea lo que sedenomina el dominio raíz del bosque, el cual contiene la configuración y el esquema del bos-que (compartido por todos los dominios de la organización). Más adelante, podemos agregar



dominios como subdominios de dicha raíz (árbol de dominios) o bien crear otros dominios"hermanos" de la raíz (bosque de dominios), debajo del cual podemos crear subdominios, yasí sucesivamente.

Arbol Un árbol es un conjunto de uno o más dominios que comparten un espacio denombres contiguo. Si existe más de un dominio, estos se disponen en estructu-ras de árbol jerárquicas.

El primer dominio creado es el dominio raíz del primer árbol. Cuando seagrega un dominio a un árbol existente este pasa a ser un dominio secundario(o hijo). Un dominio inmediatamente por arriba de otro dominio en el mismoárbol de dominio es su padre. Todos los dominios que tengan un dominio raízcomún se dice que forman un espacio de nombres contiguo.

Los dominios secundarios (hijos) pueden representar entidades geográficas(valencia, madrid, barcelona), entidades administrativas dentro de la organiza-ción (departamento de ventas, departamento de desarrollo ...), u otras delimita-ciones específicas de una organización, según sus necesidades.

Los dominios que forman un árbol se enlazan mediante relaciones de con-fianza bidireccionales y transitivas. La relación padre-hijo entre dominios en unárbol de dominio es simplemente una relación de confianza. Los administrado-res de un dominio padre no son automáticamente administradores del dominiohijo y el conjunto de políticas de un dominio padre no se aplican automática-mente a los dominios hijo.

Por ejemplo, en la Universidad Politécnica de Valencia cuyo dominio actualde Active Directory es upv.es se crean dos nuevos departamentos: DSIC yDISCA. Con el fin de permitir la administración de los dominios por parte delos técnicos de los respectivos departamentos, se decide agregar dos nuevos do-minios a su árbol de dominios existente en lugar de crear dos unidades organi-zativas en el dominio existente. Los dominios resultantes, dsic.upv.es ydisca.upv.es forman un espacio de nombres contiguo, cuya raíz es upv.es.El administrador del dominio padre (upv.es) puede conceder permisos pararecursos a cuentas de cualquiera de los tres dominios del árbol, pero por defectono los puede administrar.

Bosque Un bosque es un grupo de árboles que no comparten un espacio de nombrescontiguo, conectados a través de relaciones de confianza bidireccionales y tran-sitivas. Un dominio único constituye un árbol de un dominio, y un árbol únicoconstituye un bosque de un árbol. Los árboles de un bosque aunque no formanun espacio de nombres común, es decir, están basados en diferentes nombres dedominio raíz de DNS, comparten una configuración, un esquema de directoriocomún y el denominado catálogo global.

Es importante destacar que, aunque los diferentes árboles de un bosque nocomparten un espacio de nombres contiguo, el bosque tiene siempre un únicodominio raíz, llamado precisamente dominio raíz del bosque; dicho dominio raízserá siempre el primer dominio creado por la organización.



Añadir nuevos dominios a un bosque es fácil. Sin embargo, existen ciertas li-mitaciones que hemos de tener en cuenta al respecto:

• No se pueden mover dominios de Active Directory entre bosques.• Solamente se podrán eliminar dominios de un bosque si este no tiene domi-

nios hijo.• Después de haber establecido el dominio raíz de un árbol, no se pueden aña-

dir dominios con un nombre de nivel superior al bosque.• No se puede crear un dominio padre de un dominio existente.

En general, la implementación de bosques y árboles de dominio permitemantener convenciones de nombres tanto contiguos como discontiguos, lo cualpuede ser útil en organizaciones con divisiones independendientes que quierenmantener sus propios nombres DNS.

Finalmente, debemos relacionar estos conceptos con el procedimiento para crear un do-minio. Esto se hace mediante la ejecución de un asistente denominado dcpromo en el siste-ma Windows 2003 Server que queramos promocionar a controlador de dominio. En concreto,este asistente nos permite elegir entre las siguientes opciones de instalación:

1. DC adicional de un dominio existente o DC para un dominio nuevo (creación de un do-minio).

2. En el segundo caso, el dominio (nuevo) puede ser un dominio secundario de otro domi-nio existente (es decir, un subdominio en un árbol de dominios ya creado), o bien el do-minio principal (raíz) de un nuevo árbol de dominios.

3. En este segundo caso, el dominio raíz puede ser de un bosque existente (agregamos unaraíz nueva a un bosque) o de un nuevo bosque (creación del bosque). Por tanto, el pri-mer dominio que creemos en una organización siempre será un dominio nuevo de unárbol nuevo de un bosque nuevo.

1.2.4.3. Niveles funcionales

La funcionalidad de los dominios de Windows 2003 es diferente de la que tenían sistemasanteriores de la misma familia (Windows NT4 y Windows 2000). Tanto Windows 2000 comoWindows 2003 pueden configurarse en diferentes niveles funcionales ("modos de dominio" enWindows 2000) para que puedan ser compatibles con sistemas anteriores.

En concreto, Windows Server 2003 soporta cuatro niveles funcionales de dominio y tres ni-veles funcionales de bosque, explicados a continuación.

Un dominio Windows 2003 puede estar en cuatro niveles funcionales:

1. Windows 2000 mixto. Este es el nivel funcional por defecto cuando se crea un nuevo do-



minio (o cuando se actualiza de un sistema anterior). En este nivel, los DCs de Windows2003 son compatibles dentro del mismo dominio con DCs Windows NT4 y Windows2000. Por este motivo, un conjunto significativo de opciones de configuración no estándisponibles (como por ejemplo el anidamiento de grupos, el cambio de ámbito de grupoy los grupos universales).

2. Windows 2000 nativo. En este nivel funcional, los DCs de Windows 2003 son compati-bles dentro del mismo dominio con DCs que ejecuten Windows 2000 pero no WindowsNT4. Se tiene una funcionalidad completa del Directorio Activo a nivel de Windows2000, aunque se excluyen las nuevas opciones que Windows 2003 ha introducido en losdominios (entre las cuales destaca la posibilidad de cambiar de nombre a un DC sin ne-cesidad de despromocionarlo previamente).

3. Windows Server 2003 provisional. En este nivel funcional, los DCs de Windows 2003son compatibles dentro del mismo dominio con DCs que ejecuten Windows NT4 perono Windows 2000. Se trata de un nivel funcional reservado únicamente para migracio-nes directas de NT4 a Windows 2003, y se supone que es completamente transitorio.

4. Windows Server 2003. En este nivel funcional, los DCs de Windows 2003 son compati-bles únicamente entre sí (sólo puede configurarse si todos los DCs del dominio son Win-dows Server 2003). Este nivel ofrece la funcionalidad completa de dominios, incluyendotodas las características definidas en Windows 2000 más las nuevas incluidas en Win-dows Server 2003.

Por otro lado, un bosque de dominios Windows 2003 puede estar en tres niveles funciona-les:

• Windows 2000. Este es el nivel por defecto al crear un nuevo bosque (o actualizar desdeun sistema anterior). En este nivel funcional, los DCs de Windows 2003 son compatiblesdentro del bosque con DCs que ejecuten Windows 2000 o Windows NT4. Se tiene unafuncionalidad completa del bosque a nivel de Windows 2000, aunque se excluyen lasnuevas opciones que Windows 2003 ha introducido a este nivel (incluyendo mejoras en lareplicación, las relaciones de confianza entre bosques y la posibilidad de renombrar do-minios en lugar de eliminarlos y volverlos a crear).

• Windows Server 2003 provisional. En este nivel funcional, los DCs de Windows 2003son compatibles dentro del bosque con DCs que ejecuten Windows NT4 pero no Win-dows 2000. Se trata de un nivel funcional reservado únicamente para la migración directade NT4 a Windows 2003 en el primer dominio del bosque, y se supone que es completa-mente transitorio.

• Windows Server 2003. En este nivel funcional, los DCs de Windows 2003 son compati-bles únicamente entre sí (sólo puede configurarse si todos los DCs del bosque son Win-dows Server 2003). Este nivel ofrece la funcionalidad completa para los bosques, inclu-yendo todas las características definidas en Windows 2000 más las nuevas incluidas enWindows Server 2003.



Por tanto, por defecto al crear un nuevo bosque, éste se sitúa en el nivel funcional "Win-dows 2000", y al crear un nuevo dominio, éste se sitúa en el nivel funcional "Windows 2000mixto", manteniendo, en ambos casos, la compatibilidad completa con sistemas anteriores.

Tanto a nivel de dominio como de bosque, la transición entre niveles funcionales sólo esposible elevando el nivel actual, es decir, pasando a un nivel con mayor funcionalidad (a ex-cepción de los niveles provisionales, reservados para casos poco frecuentes). La elevación denivel funcional es, por tanto, un paso irreversible, y sólo debe hacerse cuando se está segurode que no van a añadirse sistemas anteriores como DCs al dominio, o al bosque. La elevacióndel nivel funcional de dominio o de bosque se realiza desde la herramienta "Dominios yConfianzas de Active Directory".

1.2.4.4. Relaciones de confianza

Una relación de confianza es una relación establecida entre dos dominios de forma que per-mite a los usuarios de un dominio ser reconocidos por los DCs de otro dominio. Estas rela-ciones permiten a los usuarios acceder a los recursos de otro dominio y a los administrado-res definir los permisos y derechos de usuario para los usuarios del otro dominio.

Windows Server 2003 soporta varios tipos de relaciones de confianza, que veremos poste-riormente. Al margen de su uso, los diferentes tipos de relaciones se diferencian en funciónde tres rasgos característicos:

• Método de creación: algunos tipos de relaciones de confianza se crean de forma automá-tica (implícita) y otros de forma manual (explícita).

• Dirección: algunos tipos de relaciones son unidireccionales y otros bidireccionales. Si larelación es unidireccional, los usuarios del dominio A (de confianza) pueden utilizar losrecursos del dominio B (que confía), pero no al revés. En una relación bidireccional, am-bas acciones son posibles.

• Transitividad: algunos tipos de relaciones son transitivas y otras no. Una relación de con-fianza transitiva es aquella que permite que si un dominio A confía en otro B, y éste con-fía en un tercero C, entonces de forma automática, A confía en C. En las relaciones notransitivas, la confianza entre A y C tendría que añadirse explícitamente.

Después de ver las características de las relaciones de confianza, se explican a continua-ción los tipos de relaciones de confianza válidos en dominios y bosques Windows Server2003:

• Confianza raíz de árbol. Esta relación se establece de forma automática entre los domi-nios raíz del mismo bosque. Es bidireccional y transitiva.

• Confianza principal-secundario. Esta relación se establece de forma automática entre undominio dado y cada uno de sus subdominios (o dominios secundarios). Es bidireccionaly transitiva.



• Confianza de acceso directo. Este tipo de relación debe establecerse de forma manual, ytiene como objetivo mejorar la eficiencia en los inicios de sesión remotos. Si los usuariosde un dominio A necesitan acceder frecuentemente a los recursos de un dominio B, y am-bos dominios se encuentran "lejos" entre sí (con muchos dominios intermedios), la con-fianza permite una relación directa que acorta el tiempo necesario para la autentificaciónde los usuarios. Es transitiva y unidireccional (si se necesita en ambos sentidos, debencrearse dos relaciones de confianza).

• Confianza externa . Este tipo de relación se crea manualmente y permite a usuarios deun dominio Windows 2003 acceder a recursos ubicados en dominios de otro bosque, obien dominios Windows NT4. Es unidireccional e intransitiva.

• Confianza de bosque . Este tipo de relación debe crearse de forma manual entre los do-minios raíz de dos bosques distintos, y permite a los usuarios de cualquier dominio de unbosque acceder a los recursos de cualquier dominio del otro bosque. Es unidireccional ysólo es transitiva entre dos bosques. Este tipo de relaciones sólo están disponibles si am-bos bosques se sitúan en el nivel funcional "Windows Server 2003".

• Confianza de territorio . Este tipo de relación debe crearse de forma manual entre un do-minio Windows 2003 y un territorio (realm) Kerberos (versión 5) que no sea Windows, ypermite interoperabilidad entre ambos. Es unidireccional y puede ser transitiva o no.

Por tanto, las relaciones de confianza automáticas (implícitas) se crean por defecto al irañadiendo dominios al bosque, y mantienen relacionados todos esos dominios de forma bi-direccional y transitiva. El efecto de estas relaciones es que de forma automática, los usuariosde cualquier dominio del bosque son conocidos (y pueden acceder a los recursos) en todoslos dominios de dicho bosque. Las relaciones de confianza manuales (explícitas) están reser-vadas para casos en donde se busca mejorar la eficiencia o permitir interactuar con otros bos-ques o con dominios que no son Windows 2003.

1.2.4.5. Unidades Organizativas

Una Unidad Organizativa (Organizational Unit, OU) es un objeto del Directorio Activo quepuede contener a otros objetos del directorio. Es decir, es un contenedor de otros objetos, deforma análoga a una carpeta o directorio en un sistema de archivos tradicional. En concreto,dentro de una unidad de este tipo pueden crearse cuentas de usuario, de grupo, de equipo,de recurso compartido, de impresora compartida, etc., además de otras unidades organizati-vas. Es decir, mediante unidades organizativas podemos crear una jerarquía de objetos en eldirectorio (lo cual se asemeja otra vez a un sistema de archivos típico de Windows). Los obje-tos ubicados dentro de una unidad organizativa pueden moverse más tarde a otra, si fueranecesario. Sin embargo, un objeto no puede copiarse: cada objeto es único en el directorio, ysu existencia es independiente de la unidad organizativa a la que pertenece.

Por tanto, el objetivo de las unidades organizativas es estructurar u organizar el conjuntode los objetos del directorio, agrupándolos de foma coherente. En el Directorio Activo, lasunidades organizativas permiten:



1. Delegar la administración. Cada unidad organizativa puede administrarse de forma in-dependiente. En concreto, se puede otorgar la administración total o parcial de una uni-dad organizativa a un usuario o grupo de usuarios cualquiera. Esto permite delegar laadministración de subconjuntos estancos del dominio a ciertos usuarios que posean elnivel de responsabilidad adecuada.

2. Establecer de forma centralizada comportamientos distintos a usuarios y equipos. Acada unidad organizativa pueden vincularse políticas de grupo, que aplican comporta-mientos (generalmente en forma de restricciones) a los usuarios y equipos cuyas cuentasse ubican en dicha unidad. De esta forma, podemos aplicar restricciones distintas a sub-conjuntos de usuarios y equipos del dominio, en función exclusivamente de la unidadorganizativa donde se ubican. Por ejemplo, podemos limitar a los usuarios del departa-mento de contabilidad para que sólo puedan utilizar ciertas aplicaciones, pero que estono se aplique a los usuarios del departamento de informática.

En muchos sentidos, el concepto de unidad organizativa se puede utilizar en Windows2003 de la misma forma que se entendía el concepto de dominio en versiones anteriores deWindows NT, es decir, conjunto de usuarios, equipos y recursos administrados indepen-dientemente. En realidad, en Windows 2003 el concepto de dominio viene más bien asociadoa la distribución de los sitios (topología de red) y a la implementación de DNS que exista (oquiera crearse) en la empresa.

De este modo, en muchas organizaciones de pequeño o medio tamaño resulta más ade-cuado implementar un modelo de dominio único con múltiples unidades organizativas queun modelo de múltiples dominios. Si es necesario, cada unidad puede administrarse inde-pendientemente, con uno o varios administradores delegados y comportamientos (políticas)diferentes.

1.2.5. Estructura física

En Active Directory, la estructura lógica está separada de la estructura física. La estructuralógica se utiliza para organizar los recursos de red mientras que la estructura física se utilizapara configurar y administrar el tráfico de red. En concreto, la estructura física de Active Di-rectory se compone de sitios y controladores de dominio.

La estructura física de Active Directory define dónde y cuándo se producen el tráfico dereplicación y de inicio de sesión. Una buena comprensión de los componentes físicos de Ac-tive Directory permite optimizar el tráfico de red y el proceso de inicio de sesión, así comosolventar problemas de replicación.

1.2.5.1. Sitios

Un sitio es una combinación de una o varias subredes IP que están conectadas por un víncu-lo de alta velocidad. Definir sitios permite configurar la topología de replicación y acceso aActive Directory de forma que Windows 2003 utilice los vínculos y programas más efectivospara el tráfico de inicio de sesión y replicación.



Normalmente los sitios se crean por dos razones principalmente:

• Para optimizar el tráfico de replicación.

• Para permitir que los usuarios se conecten a un controlador de dominio mediante una co-nexión confiable de alta velocidad.

Es decir, los sitios definen la estructura física de la red, mientras que los dominios definenla estructura lógica de la organización.

1.2.5.2. Controladores de dominio

Un controlador de dominio (Domain Controller, DC) es un equipo donde se ejecuta Windows2003 Server y que almacena una replica del directorio. Los controladores de dominio ejecu-tan el servicio KDC, que es responsable de autenticar inicios de sesión de usuario.

La información almacenada en cada controlador de dominio se divide en tres categorías(particiones): dominio, esquema y datos de configuración. Estas particiones del directorioson las unidades de replicación:

1. Partición del directorio de esquema: contiene todos los tipos de objetos y atributos quepueden ser creados en Active Directory. Estos datos son comunes a todos los dominiosen el bosque. Por tanto los datos del esquema se replican a todos los controladores dedominio del bosque.

2. Partición de directorio de configuración: contiene la estructura de los dominios y la to-pología de replicación. Estos datos son comunes a todos los dominios en el bosque, y sereplican a todos los controladores de dominio en el bosque.

3. Partición de directorio de dominio: contiene todos los objetos del directorio para estedominio. Dichos datos se replican a todos los controladores de ese dominio, pero no aotros dominios.

4. Partición de directorio de aplicaciones: contiene datos específicos de aplicación. Estosdatos pueden ser de cualquier tipo excepto principales de seguridad (usuarios, grupos yequipos). En este caso, se tiene un control fino sobre el ámbito de la replicación y la ubi-cación de las réplicas. Este tipo de partición es nuevo de Windows Server 2003.

Además de estas cuatro particiones de directorio de escritura, existe una cuarta categoríade información almacenada en un controlador de dominio: el catálogo global. Un catálogoglobal es un controlador de dominio que almacena las particiones de directorio de escritura,así como copias parciales de sólo lectura de todas las demás particiones de directorio de do-minio del bosque.



1.2.5.3. Funciones de los controladores de dominio

Las versiones anteriores de Windows NT Server usaban múltiples controladores de dominioy sólo se permitía que uno de ellos actualizase la base de datos del directorio. Este esquemade maestro único exigía que todos los cambios se replicasen desde el controlador de dominioprincipal (Primary Domain Controller, PDC) a los controladores de dominio secundarios o dereserva (Backup Domain Controllers, BDCs).

En Windows 2003, todos los controladores de dominio admiten cambios, y estos cambiosse replican a todos los controladores de dominio. Las operaciones de administración deusuarios, grupos y equipos son operaciones típicas de múltiples maestros. Sin embargo no espráctico que algunos cambios se realicen en múltiples maestros debido al tráfico de replica-ción y a los posibles conflictos en las operaciones básicas. Por estas razones, las funciones es-peciales, como la de servidor de catálogo global y operaciones de maestro único, se asignansólo a determinados controladores de dominio. A continuación veremos estas funciones.

1.2.5.4. Servidor de catálogo global

El catálogo global es un depósito de información que contiene un subconjunto de atributos pa-ra todos los objetos de Active Directory (partición de directorio de dominio). Los atributosque se almacenan en el catálogo global son los que se utilizan con más frecuencia en las con-sultas. El catálogo global contiene la información necesaria para determinar la ubicación decualquier objeto del directorio.

Un servidor de catálogo global es un controlador de dominio que almacena una copia delcatálogo y procesa las consultas al mismo. El primer controlador de dominio que se crea enActive Directory es un servidor de catálogo global. Se pueden configurar controladores dedominio adicionales para que sean servidores de catálogo global con el fin de equilibrar eltráfico de autenticación de inicios de sesión y la transferencia de consultas.

El catálogo global cumple dos funciones importantes en el directorio:

• Permite que un usuario inicie una sesión en la red mediante el suministro de la informa-ción de pertenencia a grupos universales a un controlador de dominio cuando inicia unproceso de sesión.

• Permite que un usuario busque información de directorio en todo el bosque, indepen-diente de la ubicación de los datos.

1.2.5.5. Operaciones de maestro único

Un maestro de operaciones es un controlador de dominio al que se le ha asignado una o va-rias funciones de maestro único en un dominio o bosque de Active Directory. Los controla-dores de dominio a los que se les asignan estas funciones realizan operaciones que no pue-den ocurrir simultáneamente en otros controladores de dominio de la red. La propiedad deestas operaciones de maestro único puede ser transferida a otros controladores de dominio.



Todos los bosques de Active Directory deben tener controladores de dominio que cum-plan dos de las cinco funciones de operaciones de maestro único. Las funciones para todo elbosque son:

• Maestro de esquema. El controlador de dominio maestro de esquema controla todas lasactualizaciones y modificaciones del esquema. Para actualizar el esquema de un bosque,debe tener acceso al maestro de esquema.

• Maestro de nombres de dominio. El controlador de dominio maestro de esquema con-trola las operaciones de agregar o quitar dominios del bosque, asegurando que los nom-bres de dominio sean únicos en el bosque.

Todos los dominios de Active Directory deben tener controladores de dominio que cum-plan tres de las cinco funciones de operaciones de maestro único:

• Maestro de identificadores relativos (RID). El controlador de dominio maestro de iden-tificadores relativos (RID) asigna secuencias de identificadores relativos a cada uno de losdistintos controladores de su dominio.

Cuando un controlador de dominio crea un objeto de usuario, grupo o equipo, asignaal objeto un identificador de seguridad único (SID). Este identificador está formado porun identificador de seguridad de dominio, que es el mismo para todos los que se crean enel dominio, y un identificador relativo que es único para cada identificador de seguridadque se crea en el dominio.

• Emulador de controlador de dominio principal (PDC). Para mantener la compatibilidadcon servidores basados en Windows NT que puedan funcionar como controladores dedominio de reserva (BDC) en dominios de Windows 2003 en modo mixto, pero todavíarequieren un controlador principal de dominio (PDC), se asigna a un controlador de do-minio específico basado en Windows 2003, la función de emular a un PDC. A este contro-lador de dominio lo ven los servidores basados en NT como un PDC.

• Maestro de infraestructuras. Cuando los objetos se mueven o se eliminan, un controla-dor de dominio de cada dominio, el maestro de infraestructura, es el responsable de ac-tualizar los identificadores de seguridad y nombres completos en las referencias de obje-tos de dominio cruzado de ese dominio.

1.3. Objetos que administra un dominioEl Directorio Activo, tal como se ha visto en capítulos anteriores, es en realidad una base dedatos jerárquica de objetos, que representan las entidades que pueden administrarse en unared de ordenadores, o, más correctamente en nuestro caso, en un dominio de sistemas Win-dows 2003. Esta base de datos de objetos de administración es compartida, para consulta,por todos los ordenadores miembros del dominio y, para modificación, por todos los contro-ladores del dominio (o DC, Domain Controllers).

1.3. Objetos que administra un dominio


Por tanto, en Windows 2003, la gestión de un dominio puede realizarse de forma centrali-zada, administrando únicamente el Directorio Activo. En este contexto, "administrar" signifi-ca crear y configurar adecuadamente los objetos del directorio que representan a las entida-des o recursos que existen en el dominio (recursos como usuarios, grupos, equipos, etc.).

Este apartado expone con detalle los principales tipos de objetos que pueden crearse en elDirectorio Activo de Windows 2003, planteando en cada caso sus opciones de configuracióny su utilidad dentro de la administración del dominio.

1.3.1. Usuarios globales

En la administración de sistemas Windows 2003 independientes (administración local), secrean en los sistemas cuentas de usuario y de grupo que sirven para:

1. identificar y autentificar a las personas (usuarios) que deben poder acceder al sistema, y

2. administrar los permisos y derechos que permitirán aplicar el control de acceso adecua-do a dichos usuarios en el sistema.

Por lo tanto, utilizando únicamente protección local, si una persona debe trabajar en va-rios ordenadores, necesita poseer una cuenta de usuario en cada uno de ellos. A continua-ción explicaremos una alternativa a esto.

En un dominio Windows 2003, cualquier servidor que actúa como DC puede crear cuen-tas de usuario global. En este caso, el término "global" debe interpretarse como global al domi-nio. Los datos de una cuenta de usuario global se almacenan en el Directorio Activo y portanto son conocidos por todos los ordenadores del dominio (en realidad, por todos los orde-nadores de bosque). Em otras palabras, no es que se cree una cuenta para ese usuario en cadaordenador miembro, sino que existe una única cuenta (con un único SID) que es visible en to-dos los ordenadores del dominio. En este caso, cuando una persona se conecta a cualquierade dichos ordenadores utilizando para ello su cuenta de usuario global, el ordenador encuestión realiza una consulta al Directorio Activo (i.e., a alguno de los DCs) para que se vali-den las credenciales del usuario. El resultado de la validación es enviado al ordenadormiembro (y de éste al usuario), concediendo o rechazando la conexión.

Los ordenadores miembros de un dominio que no sean DCs, además de conocer a losusuarios globales del dominio, pueden crear también sus propios usuarios locales. En este ca-so, estos usuarios son únicamente visibles en el ordenador en el que han sido creados. Cuan-do una persona desea entrar en el sistema utilizando una cuenta local, dicha cuenta se validacontra la base de datos local de ese ordenador. Además, es importante resaltar que a dichousuario local no se le pueden asignar permisos sobre recursos que residan en otro sistemaWindows 2003 (puesto que allí no existe). Por el contrario, a un usuario global se le puedenconceder permisos sobre cualquier recurso (archivo, directorio, impresora, etc.) de cualquierordenador miembro del dominio, puesto que es visible (y posee el mismo SID) en todosellos.

1.3.1. Usuarios globales


1.3.2. Grupos

De forma análoga a los usuarios globales, existen grupos que son almacenados en el Directo-rio Activo y que por tanto son visibles desde todos los ordenadores del dominio (y, en algu-nos casos, también de otros dominios del bosque). En el directorio pueden crearse dos tiposde grupos: grupos de distribución y grupos de seguridad. Los primeros se utilizan exclusiva-mente para crear listas de distribución de correo electrónico, mientras que los segundos sonlos que se utilizan con fines administrativos. Por este motivo, a partir de ahora nos referire-mos exclusivamente a los grupos de seguridad.

En concreto, en dominios Windows 2003 se definen tres clases de grupos de seguridad (o,de forma más precisa, se pueden definir grupos de tres ámbitos distintos):

1. Grupos locales del dominio. En un dominio en nivel funcional Windows 2000 mixto,pueden contener cuentas de usuario y grupo globales de cualquier dominio del bosque.En un dominio en nivel Windows 2000 nativo o Windows Server 2003, pueden contener,además, grupos universales y otros grupos locales del dominio. Sólo son visibles en eldominio en que se crean, y suelen utilizarse para conceder permisos y derechos en cual-quiera de los ordenadores del dominio (nótese que en modo mixto, sólo son visibles porlos DCs del dominio, y por tanto sólo se pueden utilizar para administrar permisos yderechos en esos ordenadores).

2. Grupos globales. En un dominio en nivel funcional Windows 2000 mixto, pueden con-tener cuentas de usuario globales del mismo dominio. En un dominio en nivel Windows2000 nativo o Windows Server 2003, pueden contener, además, otros grupos globalesdel mismo dominio. Son visibles en todos los dominios del bosque, y suelen utilizarsepara clasificar a los usuarios en función de las labores que realizan.

3. Grupos universales. Sólo están disponibles en dominios en nivel funcional Windows2000 nativo o Windows Server 2003 nativo. Pueden contener cuentas de usuario y gru-pos globales, así como otros grupos universales, de cualquier dominio del bosque. Sonvisibles en todo el bosque.

En un ordenador miembro de un dominio también se pueden definir grupos locales. Losgrupos locales pueden estar formados por cuentas de usuario locales y usuarios y gruposglobales de cualquier dominio del bosque (en modo mixto) y además por grupos universales(en modo nativo). Un grupo local no puede ser miembro de otro grupo local. Los grupos lo-cales pueden utilizarse para conceder permisos y derechos en el equipo en que son creados.

Por tanto, la administración de la protección en cada ordenador del dominio puede reali-zarse mediante grupos locales del dominio o grupos locales del equipo en que reside el re-curso a administrar. Por tanto, la recomendación que se hacía en la protección local respectoa la asignación de permisos en base a grupos locales sigue siendo válida. En el caso más ge-neral, la regla que recomienda Windows 2003 es la siguiente:

1. Asignar usuarios globales a grupos globales, según las labores que desempeñen en laorganización.

1.3.2. Grupos


2. Incluir (usuarios y/o) grupos globales en grupos locales (del equipo o del dominio) se-gún el nivel de acceso que vayan a tener.

3. Asignar permisos y derechos únicamente a estos grupos locales (del equipo o del domi-nio).

La utilización de grupos universales tiene sentido sólo cuando un mismo conjunto deusuarios (y/o grupos) de varios dominios deben recibir permisos/derechos en varios domi-nios simultáneamente. En Windows 2000, el uso de este tipo de grupo estaba muy desacon-sejado, por dos motivos: primero, porque estos grupos y sus miembros deben replicarse entodos los catálogos globales del bosque, y segundo, porque cualquier incio de sesión de unusuario debe consultar a un catálogo global para determinar la pertenencia de dicho usuarioa posibles grupos universales. Windows 2003 ha suavizado el primero de los problemas, me-jorado la eficiencia de esa replicación (sólo si el bosque está en nivel funcional Windows Ser-ver 2003), de forma que su uso no está ahora tan desaconsejado como lo estaba en Windows2000. En cualquier caso, el uso de un grupo universal siempre puede simularse con la combi-nación adecuada de grupos globales y locales del dominio. Se recomienda al lector reflexio-nar sobre cómo podría hacerse.

En relación con esto, es importante saber que cuando un ordenador pasa a ser miembrode un dominio, el grupo global Administradores del dominio se incluye automática-mente en el grupo local Administradores de dicho ordenador. De igual forma, el grupoglobal Usuarios del dominio se incluye dentro del grupo local Usuarios. De esta for-ma, los administradores y usuarios normales del dominio tienen en cada miembro los mis-mos derechos y permisos que los que tengan ya definidos los administradores y usuarios lo-cales, respectivamente. El administrador local puede, si lo desea, invalidar esta acción auto-mática, extrayendo posteriormente los grupos globales de los locales.

1.3.3. Equipos

Como hemos visto, en el Directorio Activo de un dominio se conserva toda la informaciónrelativa a cuentas de usuarios y grupos globales. Esta misma base de datos de directoio reco-ge también una cuenta de equipo por cada uno de los ordenadores miembro de un dominio.

Entre otras informaciones, en cada una de estas cuentas se almacena el nombre del orde-nador, así como un identificador único y privado que lo identifica unívocamente. Este identi-ficador es análogo al SID de cada cuenta de usuario o grupo, y sólo lo conocen los DCs y elpropio ordenador miembro. Es por tanto, un dato interno del sistema operativo, y ni siquierael administrador puede cambiarlo. Es precisamente este dato, propio de las cuentas de usua-rio, grupo y equipo, lo que permite asignar permisos y derechos en los sistemas a estos trestipos de cuentas. Por este motivo, se denominan principales de seguridad (security principals).Por tanto, la asignación de derechos y permisos (NTFS) a cuentas de equipo es posible, perose limita a situaciones muy poco frecuentes y está fuera del ámbito de este texto.

Windows 2003 puede utilizar distintos protocolos de comunicaciones seguros entre losordenadores miembro de un dominio y los DCs. Entre ellos los más importantes son NTLM(el protocolo utilizado por versiones anteriores de Windows NT, que se mantiene por com-

1.3.3. Equipos


patibilidad hacia atrás) y Kerberos V5. Kerberos presenta numerosas ventajas respecto aNTLM, pero sólo es viable en la práctica si todas las máquinas del dominio son Windows2000, Windows XP o Windows Server 2003. Estos protocolos se utilizan siempre que infor-mación relativa a aspectos de seguridad se intercambia entre sistemas pertenecientes a algúndominio y, en concreto, para autenticar usuarios (como se ha explicado arriba).

1.3.4. Unidades Organizativas

Como hemos visto en Sección 1.2.4.5, “Unidades Organizativas”, las unidades organizativasson objetos del directorio que a su vez, pueden contener otros objetos. El uso fundamental delas OUs es delegar la administración de sus objetos a otros usuarios distintos del administra-dor del dominio, y personalizar el comportamiento de los usuarios y/o equipos mediante laaplicación de directivas de grupo (GPOs) específicas a la unidad.

1.4. Compartición de recursosCuando un sistema Windows 2003 participa en una red (grupo de trabajo o dominio), puedecompartir sus recursos con el resto de ordenadores. En este contexto, sólo vamos a conside-rar como recursos a compartir las carpetas o directorios que existen en un sistema Windows.La compartición de otros recursos (tales como impresoras, por ejemplo) queda fuera del ám-bito de este texto.

1.4.1. Permisos y derechos

Cualquier sistema Windows 2003 puede compartir carpetas, tanto si es un servidor como sies una estación de trabajo. Para poder compartir una carpeta basta con desplegar su menúcontextual desde una ventana o desde el explorador de archivos, y seleccionar Compar-tir.... En la ventana asociada a esta opción se determina el nombre que tendrá el recurso(que no tiene por qué coincidir con el nombre de la propia carpeta), así como qué usuariosvan a poder acceder al mismo. En relación con esto, existe una gran diferencia entre que eldirectorio resida en una partición FAT y que resida en una NTFS.

Si la carpeta reside en una partición FAT, este filtro de acceso será el único que determinelos usuarios que van a poder acceder al contenido de la carpeta, puesto que no es posible de-terminar permisos sobre la misma o sus archivos. Es decir, el filtro sólo se establece para po-der acceder al recurso. Si un usuario tiene permisos suficientes para conectarse a un recurso,tendrá acceso sobre todos los archivos y subcarpetas del recurso. Concretamente, el tipo deacceso sobre todos ellos será el que le permita el permiso sobre el recurso (Lectura, Es-critura o Control Total).

Por el contrario, si la carpeta se encuentra en una partición NTFS, ésta tendrá unos permi-sos establecidos (así como sus subcarpetas y archivos), al margen de estar o no compartida.En este caso también es posible establecer permisos desde la ventana de Compartir..., pe-ro entonces sólo los usuarios que puedan pasar ambos filtros podrán acceder a la carpetacompartida y a su contenido. En este caso se recomienda dejar Control Total sobre To-dos en los permisos asociados al recurso (opción por defecto), y controlar quién (y cómo)

1.3.4. Unidades Organizativas


puede acceder al recurso y a su contenido mediante los permisos asociados a dicha carpeta(y a sus archivos y subcarpetas). Sin embargo, esta no es la opción por defecto en WindowsServer 2003 (aunque sí lo era en Windows 2000), que sólo concede inicialmente el permiso delectura al grupo Todos al compartir una carpeta.

Esta recomendación es muy útil, si tenemos en cuenta que de esta forma para cada carpe-ta (y archivo) del sistema no utilizamos dos grupos de permisos sino uno solo, independien-temente de que la carpeta sea o no compartida. Este forma de trabajar obliga al administra-dor a asociar los permisos correctos a cada objeto del sistema (aunque no esté compartido),pero por otra parte se unifica la visión de la seguridad de los archivos, con lo que a la largaresulta más segura y más sencilla.

Cuando compartimos recursos a otros usuarios en la red (especialmente en un dominio)hay que tener en cuenta no sólo los permisos del recurso y su contenido, sino también los de-rechos del ordenador que comparte el recurso. En concreto, si un usuario ha iniciado una se-sión interactiva en un ordenador Windows 2003 denominado A, y desea conectarse a un re-curso de red que exporta otro Windows 2003 denominado B, además de poseer suficientespermisos (sobre el recurso, sobre el propio carpeta y sobre su contenido), tiene que tenerconcedido en B el derecho Acceder a este equipo desde la red. De lo contrario, di-cho usuario ni siquiera podrá obtener la lista de los recursos que el ordenador B comparte.

1.4.2. Compartición dentro de un dominio

Cuando la compartición de recursos la realizan equipos que forman parte de un dominioWindows 2003, existen consideraciones que el administración debe conocer.

Primero, una vez se ha compartido físicamente una carpeta en la red (según el procedi-miento descrito arriba), el administrador del dominio puede además publicar este recurso enel directorio. Para ello debe crear un nuevo objeto, en la unidad organizativa adecuada, de ti-po Recurso compartido. A este objeto se le debe asociar un nombre simbólico y el nom-bre de recurso de red que representa (de la forma \\equipo\recurso). Es importante te-ner en cuenta que cuando se publica el recurso de esta forma, no se comprueba si realmenteexiste o no, por lo que es responsabilidad del administrador el haberlo compartido y que sunombre coincida con el de la publicación. Una vez publicado, el recurso puede localizarsemediante búsquedas en el Directorio Activo, como el resto de objetos del mismo. WindowsServer 2003 ha introducido otra forma de publicación: entre las opciones de la pestaña "Com-partir" del explorador de archivos, puede publicarse dicha compartición en el directorio,simplemente asignándole un nombre simbólico. Si se publica de esta forma, el proceso creaautomáticamente el objeto que representa la carpeta compartida en el directorio.

Y segundo, cuando un sistema Windows 2003 se agrega a un dominio, los siguientes re-cursos se comparten de forma automática y por defecto (estas comparticiones no deben mo-dificarse ni prohibirse):

• letra_de_unidad$. Por cada partición existente en el sistema Windows 2003 (C:, D:,etc.) se crea un recurso compartido denominado C$, D$, etc. Los administradores del do-minio, así como los operadores de copia del domino, pueden conectarse por defecto a es-tas unidades.

1.4.2. Compartición dentro de un dominio


• ADMIN$. Es un recurso utilizado por el propio sistema durante la administración remotade un ordenador Windows 2003.

• IPC$. Recurso que agrupa los tubos (colas de mensajes) utilizados por los programas pa-ra comunicarse entre ellos. Se utiliza durante la administración remota de un ordenadorWindows 2003, y cuando se observa los recursos que comparte.

• NETLOGON. Recurso que exporta un DC para proporcionar a los ordenadores miembrosdel dominio el servicio de validación de cuentas globales a través de la red (Net Logon ser-vice).

• SYSVOL. Recurso que exporta cada DC de un dominio. Contiene información del Directo-rio Activo (por ejemplo, de directivas de grupo) que debe replicarse en todos los DCs deldominio.

En relación con los nombres de estos recursos, es interesante saber que añadir el carácter"$" al final de cualquier nombre de recurso tiene un efecto específico: prohibe que dicho re-curso se visualice dentro de la lista de recursos que una máquina exporta al resto. Es decir,convierte un recurso en "invisible" para al resto del mundo. En este caso, un usuario remotosólo podrá conectarse al recurso si conoce su nombre de antemano (y tiene suficientes permi-sos, obviamente).

1.4.3. Mandatos Windows 2003 para compartir recursos

La compartición de recursos en Windows 2003 puede realizarse en línea de órdenes utilizan-do los mandatos net share y net use. La sintaxis de ambos mandatos es la siguiente:

1. Mandato net share: Crea, elimina o muestra recursos compartidos.

net sharenet share recurso_compartidonet share recurso_compartido=unidad:ruta_de_acceso

[/users:número | /unlimited] [/remark:"texto"]net share recurso_compartido [/users:número | unlimited]

[/remark:"texto"]net share {recurso_compartido | unidad:ruta_de_acceso} /delete

2. Mandato net use: Conecta o desconecta un equipo de un recurso compartido o muestrainformación acerca de las conexiones del equipo. También controla las conexiones dered persistentes.

net use [nombre_dispositivo][\\nombre_equipo\recurso_compartido[\volumen]][contraseña | *]] [/user:[nombre_dominio\]nombre_usuario][[/delete] | [/persistent:{yes | no}]]

net use nombre_dispositivo [/home[contraseña | *]][/delete:{yes | no}]

net use [/persistent:{yes | no}]

1.4.3. Mandatos Windows 2003 para compartir recursos


1.5. Delegación de la administraciónPara delegar, total o parcialmente, la administración de una unidad organizativa existe unasistente (wizard) que aparece cuando se selecciona la acción Delegar el control... enel menú contextual de la unidad organizativa. Este asistente pregunta básicamente los dosaspectos propios de la delegación: a quién se delega y qué se delega. La primera pregunta secontesta o bien con un usuario o con un grupo (se recomienda un grupo). Para responder ala segunda pregunta, se puede elegir una tarea predefinida a delegar (de entre una lista de ta-reas frecuentes), o bien podemos optar por construir una tarea personalizada. En este últimocaso, tenemos que especificar la tarea mediante un conjunto de permisos sobre un cierto tipode objetos del directorio. Esto se explica a continuación.

Internamente, los derechos de administración (o control) sobre un dominio o unidad or-ganizativa funcionan de forma muy similar a los permisos sobre una carpeta o archivo: exis-te una DACL propia y otra heredada, que contienen como entradas aquellos usuarios/gru-pos que tienen concedida (o denegada) una cierta acción sobre la unidad organizativa o so-bre su contenido. En este caso, las acciones son las propias de la administración de objetos enel directorio (control total, creación de objetos, modificación de objetos, consulta de objetos,etc.), donde los "objetos" son las entidades que pueden ser creados dentro de la unidad:usuarios, grupos, unidades organizativas, recursos, impresoras, etc.

En resumen, la delegación de control sobre una unidad organizativa puede hacerse deforma completa (ofreciendo el Control Total sobre la unidad) o de forma parcial (permitiendola lectura, modificación y/o borrado de los objetos de la misma). Hay que tener en cuentaque en el caso de la delegación parcial, el número de posibilidades es inmenso: por una par-te, se incluye la posibilidad de establecer el permiso sobre cada atributo de cada tipo de obje-to posible; por otra parte, se puede establecer a qué unidades se va a aplicar la regla (sólo enesa unidad organizativa, en todas las que se sitúan por debajo, en parte de ellas, etc.). Portanto, para una delegación parcial se recomienda el uso del asistente, ya que su lista de dele-gación de tareas más frecuentes (como por ejemplo "Crear, borrar y administrar cuentas deusuario" o "Restablecer contraseñas en cuentas de usuario") resulta muy útil. Sin embargo,cuando la delegación que buscamos no se encuentra en la lista, tendremos que diseñar una amedida, asignando los permisos oportunos sobre los objetos del directorio que sean necesa-rios.

1.5. Delegación de la administración


2Administración dedominios en Linux

Indice2.1. Introducción .................................................................................................. 252.2. Concepto de dominio ..................................................................................... 252.3. Servicios de directorio y LDAP ....................................................................... 252.4. Visión general de la implementación de un dominio Linux con OpenLDAP ....... 282.5. Instalación del servidor OpenLDAP ................................................................ 292.6. Instalación de las herramientas cliente de OpenLDAP ...................................... 302.7. Migración de la información del servidor ........................................................ 322.8. Autenticación basada en OpenLDAP ............................................................... 342.9. Permisos de acceso ......................................................................................... 352.10. Configuración de OpenLDAP con varios servidores ....................................... 372.11. Herramientas gráficas de administración ....................................................... 38

2.1. IntroducciónEn el mundo Linux no existe un concepto de dominio tan elaborado como en el mundo deWindows 2003. Sin embargo, se consigue un efecto similar al activar un servicio en una má-quina Linux (que actuaría como "servidor" de cuentas y grupos) y otro servicio que permitela exportación de directorios a máquinas remotas. En concreto, dichos servicios se denomi-nan LDAP y NFS, respectivamente. Ambos son explicados en este capítulo y en el siguiente,respectivamente.

2.2. Concepto de dominioDesde el punto de vista de la administración de sistemas, suele denominarse dominio a unconjunto de equipos interconectados que comparten información administrativa (usuarios,grupos, contraseñas, etc.) centralizada. Ello requiere fundamentalmente la disponibilidad de(al menos) un ordenador que almacene físicamente dicha información y que la comunique alresto cuando sea necesario, típicamente mediante un esquema cliente-servidor. Por ejemplo,cuando un usuario desea iniciar una conexión interactiva en cualquiera de los ordenadores(clientes) del dominio, dicho ordenador deberá validar las credenciales del usuario en el ser-vidor, y obtener de éste todos los datos necesarios para poder crear el contexto inicial de tra-bajo para el usuario.

En Windows 2003, la implementación del concepto de dominio se realiza mediante el de-nominado Directorio Activo, un servicio de directorio basado en diferentes estándares comoLDAP (Lightweight Directory Access Protocol}) y DNS (Domain Name System). En el mundoUnix, los dominios solían implementarse mediante el famoso Network Information System(NIS), del que existían múltiples variantes. Sin embargo, la integración de servicios de direc-torio en Unix ha posibilitado la incorporación de esta tecnología, mucho más potente y esca-lable que NIS, en la implementación de dominios.

Este capítulo describe cómo una implementación libre del protocolo LDAP para Unix, de-nominada OpenLDAP (www.openldap.org), puede utilizarse para implementar dominiosen Centos Linux.

2.3. Servicios de directorio y LDAPEn el contexto de las redes de ordenadores, se denomina directorio a una base de datos espe-cializada que almacena información sobre los recursos, u "objetos", presentes en la red (talescomo usuarios, ordenadores, impresoras, etc.) y que pone dicha información a disposiciónde los usuarios de la red. Por este motivo, esta base de datos suele estar optimizada paraoperaciones de búsqueda, filtrado y lectura más que para operaciones de inserción o transac-ciones complejas. Existen diferentes estándares que especifican servicios de directorio, sien-do el demominado X.500 tal vez el más conocido.

El estándar X.500 define de forma nativa un protocolo de acceso denominado DAP (Di-rectory Access Protocol) que resulta muy complejo (y computacionalmente pesado) porque es-tá definido sobre la pila completa de niveles OSI. Como alternativa a DAP para acceder a di-

2.1. Introducción


rectorios de tipo X.500, LDAP (Lightweight Directory Access Protocol) ofrece un protocolo "lige-ro" casi equivalente, pero mucho más sencillo y eficiente, diseñado para operar directamentesobre TCP/IP. Actualmente, la mayoría de servidores de directorio X.500 incorporan LDAPcomo uno de sus protocolo de acceso.

LDAP permite el acceso a la información del directorio mediante un esquema cliente-servidor, donde uno o varios servidores mantienen la misma información de directorio(actualizada mediante réplicas) y los clientes realizan consultas a cualquiera de ellos. Anteuna consulta concreta de un cliente, el servidor contesta con la información solicitada y/o conun "puntero" donde conseguir dicha información o datos adicionales (normalmente, el "pun-tero" es otro servidor de directorio).

Internamente, el modelo de datos de LDAP (derivado de X.500, pero algo restringido) de-fine una estructura jerárquica de objetos o entradas en forma de árbol, donde cada objeto oentrada posee un conjunto de atributos. Cada atributo viene identificado mediante un nom-bre o acrónimo significativo, pertenece a un cierto tipo y puede tener uno o varios valores aso-ciados. Toda entrada viene identificada unívocamente en la base de datos del directorio me-diante un atributo especial denominado nombre distinguido o dn (distinguished name). El restode atributos de la entrada depende de qué objeto esté describiendo dicha entrada. Por ejem-plo, las entradas que describen personas suelen tener, entre otros, atributos como cn (com-mon name) para describir su nombre común, sn (surname) para su apellido, mail para su di-rección de correo electrónico, etc. La definición de los posibles tipos de objetos, así como desus atributos (incluyendo su nombre, tipo, valor(es) admitido(s) y restricciones), que puedenser utilizados por el directorio de un servidor de LDAP la realiza el propio servidor median-te el denominado esquema del directorio. Es decir, el esquema contiene las definiciones de losobjetos que pueden darse de alta en el directorio.

El nombre distinguido de cada entrada del directorio es una cadena de caracteres forma-da por pares <tipo_atributo>=<valor> separados por comas, que representa la ruta in-vertida que lleva desde la posición lógica de la entrada en el árbol hasta la raíz del mismo.Puesto que se supone que un directorio almacena información sobre los objetos que existenen una cierta organización, cada directorio posee como raíz (o base, en terminología LDAP)la ubicación de dicha organización, de forma que la base se convierte de forma natural en elsufijo de los nombres distinguidos de todas las entradas que mantiene el directorio. Existendos formas de nombrar, o estructurar, la raíz de un directorio LDAP:

1. Nombrado "tradicional": formado por el país y estado donde se ubica la organización,seguida por el nombre de dicha organización. Por ejemplo, la raíz o base de la Universi-dad Politécnica de Valencia podría ser algo así: "o=UPV, st=Valencia, c=ES".

2. Nombrado basado en nombres de dominio de Internet (es decir, en DNS): este nombra-do utiliza los dominios DNS para nombrar la raíz de la organización. En este caso, la ba-se de la UPV sería: "dc=upv, dc=es". Este es el nombrado que vamos a utilizar puestoque permite localizar a los servidores de LDAP utilizando búsquedas DNS.

A partir de esa base, el árbol se subdivide en los nodos y subnodos que se estime oportu-no para estructurar de forma adecuada los objetos de la organización, objetos que se ubicanfinalmente como las hojas del árbol. De esta forma, el nombre distinguido de cada entrada

2.3. Servicios de directorio y LDAP


describe su posición en el árbol de la organización (y vice-versa), de forma análoga a un sis-tema de archivos típico, en el que el nombre absoluto (unívoco) de cada archivo equivale asu posición en la jerarquía de directorios del sistema, y vice-versa. En la Figura 2.1,“Estructura de directorio del dominio admon.com.” se muestra un ejemplo de un directoriosencillo (dos usuarios y dos equipos) de la organización admon.com.

Figura 2.1. Estructura de directorio del dominio admon.com.

De acuerdo con dicha figura, la entrada correspondiente al usuario "pepe" tendría comonombre distinguido "uid=pepe, ou=People, dc=admon, dc=com". Al margen de eseidentificador único, cada entrada u objeto en el directorio puede tener, como hemos dicho,un conjunto de atributos tan descriptivo como se desee. Cada objeto necesita, al margen desu nombre distinguido, su "clase de objeto", que se especifica mediante el atributo Object-Class (un mismo objeto puede pertenecer a diferentes clases simultáneamente, por lo quepueden existir múltiples atributos de este tipo para un mismo objeto en el directorio). Esteatributo especifica implícitamente el resto de atributos de dicho objeto, de acuerdo con la de-finición establecida en el esquema. Siguiendo con el ejemplo anterior, a continuación semuestra un subconjunto de los atributos del usuario "pepe":

dn: uid=pepe, ou=People, dc=admon, dc=comobjectClass: personcn: Jose Garcíasn: Garcíadescription: alumnomail: [email protected]

El formato en el que se han mostrado los atributos del objeto se denomina LDIF (LDAPData Interchange Format), y resulta útil conocerlo porque es el formato que los servidoresLDAP (y OpenLDAP entre ellos) utilizan por defecto para insertar y extraer información deldirectorio.

Puesto que nosotros vamos a utilizar el directorio con un uso muy específico (centralizarla información administrativa de nuestro dominio para autentificar usuarios de forma glo-

2.3. Servicios de directorio y LDAP


bal) deberíamos asegurarnos que en el esquema de nuestro directorio existen los tipos de ob-jetos (y atributos) adecuados para ello. Afortunadamente, OpenLDAP posee por defecto unesquema suficientemente rico para cubrir este cometido. Por ejemplo, cada usuario puededefinirse mediante un objeto de tipo posixAccount, que posee entre otros atributos paraalmacenar su UID, GID, contraseña, etc. A título de curiosidad, la entrada en el esquema quedefine el atributo para la contraseña (userPassword) se muestra a continuación:

attributetype (2.5.5.35 NAME 'userPassword'EQUALITY octetStringMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128})

2.4. Visión general de la implementación de un dominioLinux con OpenLDAPLa implementación de un dominio Linux utilizando OpenLDAP es una tarea algo complejay requiere realizar varios pasos que se resumen a continuación.

• Instalar el servidor OpenLDAP.

El primer paso consiste en elegir uno de los ordenadores de la red para que actue co-mo servidor OpenLDAP, e instalar y configurar en dicho ordenador este servicio de red,tal como se describe en la sección Sección 2.5, “Instalación del servidor OpenLDAP”. Fi-nalizado este paso se dispone de un directorio operativo pero carente de información.

• Configurar clientes de OpenLDAP.

Antes de pasar a introducir información es conveniente verificar que el directorio esaccesible desde las herramientas cliente de OpenLDAP, tal como se describe en la secciónSección 2.6, “Instalación de las herramientas cliente de OpenLDAP”. Es importante desta-car que este paso sólo configura las herramientas para consultar y modificar la informa-ción del directorio. Configurar Linux para que utilice esta información para autenticarusuarios es una acción diferente que se realiza en el último paso.

• Migrar la información actual de usuarios y grupos.

Una vez se ha comprobado el correcto funcionamiento del directorio LDAP, es el mo-mento de introducir la información administrativa relativa a usuarios y grupos. Si esta in-formación ya existe y está almacenada en los ficheros locales del ordenador donde se eje-cuta el servicio OpenLDAP, es posible "copiarla" al directorio mediante las acciones quese describen en la sección Sección 2.7, “Migración de la información del servidor”.

• Configurar la autenticación basada en OpenLDAP.

Finalmente, una vez se dispone de un directorio LDAP en el que reside la informaciónnecesaria relativa a usuarios y grupos (UIDs, GIDs, contraseñas, etc.), podemos configu-rar Linux para que utilice esta información para autenticar usuarios. Estas acciones estándescritas en la sección Sección 2.8, “Autenticación basada en OpenLDAP”.

2.4. Visión general de la implementación de un dominio Linux con OpenL-DAP


Otros aspectos interesantes a considerar en la configuración de OpenLDAP son la asigna-ción de permisos y la utilización de varios servidores, descritos respectivamente en las sec-ciones Sección 2.9, “Permisos de acceso” y Sección 2.10, “Configuración de OpenLDAP convarios servidores”.

Es importante resaltar que buena parte de la configuración que se describe a continuaciónes dependiente del software de LDAP concreto que se va a utilizar (en este caso, OpenLDAP)y de la versión de UNIX utilizada (Centos Linux). La configuración de otros servidores deLDAP, en la misma u otras versiones de Linux, puede ser distinta a la que aquí se va a expo-ner.

2.5. Instalación del servidor OpenLDAPEl paquete que incorpora el servidor de OpenLDAP se denomina openldap-servers ypuede instalarse utilizando:

yum install openldap-servers

Una vez instalado, este paquete instala los ficheros de configuración por defecto bajo eldirectorio /etc/openldap, crea un directorio vacío denominado /var/lib/ldap para al-bergar la base de datos con la información del directorio y sus índices, y finalmente incorpo-ra el servicio o "demonio" de LDAP, denominado slapd. Al igual que sucede con la mayoríade servicios, sladp puede iniciarse y detenerse utilizando el mandado service:

service ldap start | stop | restart

y puede ser configurado para activarse cuando se inicia el sistema utilizando la ordenchkconfig:

bash# chkconfig --level 35 ldap on

La configuración del servicio slapd se realiza en /etc/openldap/slapd.conf funda-mentalmente. Este fichero contiene referencias a los demás ficheros necesarios para el servi-cio slapd (como por ejemplo, las definiciones del esquema), y un conjunto de seccionesdonde se describen los directorios de los que se mantiene información. Es incluso posible al-macenar los directorios en bases de datos de distintos formatos internos y definir opcionesespecíficas diferentes para cada una. En el caso más sencillo, sin embargo, tendremos un úni-co directorio almacenado en una base de datos en el formato por defecto (lbdm), cuyas op-ciones no modificaremos.

De hecho, de los numerosos parámetros que pueden configurarse en este fichero, sólo va-mos a comentar los estrictamente necesarios para configurar un servidor básico de LDAPque luego haga de servidor de un dominio Linux. Para configurar cualquier otro parámetroavanzado, se recomienda la lectura previa del documento "OpenLDAP Administrator's Guide"[http://www.openldap.org/doc/admin22/].

2.5. Instalación del servidor OpenLDAP


http://www.openldap.org/doc/admin22/

En definitiva, los tres parámetros fundamentales que es necesario configurar son los si-guientes (el resto pueden dejarse con sus opciones por defecto):

1. Sufijo. Este es el sufijo de las entradas del directorio, es decir, lo que hemos denomina-do base o raíz del directorio. Por ejemplo, para el dominio "admon.com" deberíamosconfigurar:

suffix "dc=admon, dc=com"

2. Cuenta del administrador (del directorio). Esta es la cuenta del usuario administradordel directorio, lógicamente en formato de LDAP. Las credenciales que se sitúan en estaopción (y la siguiente) tienen validez independientemente de que este usuario existarealmente en la base de datos del directorio o no. El nombre por defecto es "manager",pero si queremos lo podemos cambiar por "root" (a la UNIX):

rootdn "cn=root, dc=admon, dc=com"

3. Contraseña del administrador. Cuando las operaciones a realizar en la base de datos nopermitan una conexión anónima (sin acreditarse), y en concreto, cuando necesiten delusuario "administrador del directorio" definido arriba, dichas operaciones deben acom-pañarse de la contraseña de esta cuenta, que se especifica en la siguiente opción:

rootpw <CONTRASEÑA>

Hay que tener en cuenta que la contraseña que pongamos aquí será visible por cual-quier usuario que pueda leer el fichero (aunque por defecto, éste es un permiso sólo deroot). Por tanto, es conveniente ponerla cifrada. Para ello, podemos crear una contraseñanueva mediante la orden:

slappasswd -h {MD5}

Esta orden nos pide una contraseña y nos la muestra cifrada. Luego simplementesustitiumos <CONTRASEÑA> por el resultado de dicha orden. Como ejemplo, la sen-tencia rootpw quedaría como sigue:

rootpw {MD5}EDtdFIXDSXRdagNOPSXPvcTBbA==

2.6. Instalación de las herramientas cliente de OpenLDAPOpenLDAP incluye varias utilidades a nivel de cliente que permiten acceder a la informa-ción que almacenan los servidores LDAP. Entre estas utilidades se encuentran, por ejemplo,mandatos tales como ldapsearch, ldapadd y ldapmodify, que consultan, crean y modi-fican dicha información. El paquete que incorpora las herramientas cliente de OpenLDAP se

2.6. Instalación de las herramientas cliente de OpenLDAP


denomina openldap-clients y puede instalarse utilizando:

yum install openldap-clients

Para que estos mandatos funcionen correctamente es necesario configurar en el fichero /etc/openldap/ldap.conf dos opciones que describen el ordenador donde se encuentrainstalado el directorio LDAP así como el sufijo común para las entradas de dicho directorio.

BASE dc=admon,dc=comHOST adlin.admon.com

Es importante hacer notar que OpenLDAP aún no soporta la localización del servidor ba-sada en registros de servicio de DNS (como es el caso del Directorio Activo de Windows2003). Por tanto, en la opción HOST es necesario especificar o bien una dirección IP o bien unnombre de ordenador que pueda resolverse correctamente sin utilizar el propio directorio(por ejemplo, que esté dado de alta en el fichero /etc/hosts del ordenador cliente, o quepueda resolverse correctamente mediante una consulta DNS).

Una vez realizada la configuración del apartado anterior, ya estamos en condiciones decomprobar que, de momento, todo funciona correctamente.

Si el servicio ha arrancado correctamente, y a pesar de que actualmente el directorio estávacío, deberíamos ser capaces de preguntar al menos por un tipo de atributo denominado"namingContexts". Para ello, utilizamos la orden ldapsearch:

bash# ldapsearch -x -b '' -s base namingContexts

Si todo funciona bien, el resultado debería ser algo así:

# filter: (objectclass=*)# requesting: namingContexts#dn:namingContexts: dc=admon,dc=com

# search resultsearch: 2result: 0 Success

Es imprescindible que en la salida por pantalla aparezca el sufijo del dominio(dc=admon,dc=com en el ejemplo).

También puede resultar útil comprobar si se ha configurado correctamente el "administra-dor" del directorio y su contraseña. Para ello puede ejecutarse la orden anterior acreditándo-se como el administrador utilizando las opciones -D dn (acreditarse como) y -W (solititarcontraseña):

bash# ldapsearch -D "cn=root,dc=admon,dc=com" -W -x -b '' -s base \namingContexts

2.7. Migración de la información del servidor


2.7. Migración de la información del servidorEste paso consiste en añadir al directorio, que aún está vacío, toda la información presenteen el ordenador que está haciendo de servidor. Esto incluye todos los recursos dados de altaen sus ficheros de configuración, tales como cuentas de usuarios, grupos, ordenadores, etc.,así como diferentes "contenedores" o "unidades organizativas" (OrganizationalUnits) que dis-tribuyen los objetos de forma racional.

Para ello, OpenLDAP incorpora un conjunto de herramientas que pueden utilizarse pararealizar esta migración de forma automática. El paso previo para ello es editar el fichero /usr/share/openldap/migration/migrate_common.ph. En concreto, tenemos queeditar las dos directivas siguientes:

$DEFAULT_MAIL_DOMAIN = "admon.com";$DEFAULT_BASE = "dc=admon,dc=com";

Una vez modificadas ambas, tenemos diferentes opciones para incorporar la informacióndel sistema al directorio. Entre ellas, la más recomendable es realizar la migración por partes,añadiendo primero la "base" (es decir, las entradas correspondientes a la organización y susunidades organizativas por defecto) y posteriormente migrando los usuarios, grupos, hosts,etc., que se ubicarán dentro de dichas unidades.

Para todo ello existen scripts de Perl en el directorio mencionado arriba (donde se ubicamigrate_common.ph), que podemos utilizar de la siguiente forma (en todo el proceso, elservicio ldap debe estar ejecutándose):

• Para la migración de la base, se exporta primero sus objetos a un fichero, en formatoLDIF, y luego se insertan en el directorio mediante la orden ldapadd:

bash# ./migrate_base.pl > /root/base.ldifbash# ldapadd -x -c -D "cn=root,dc=admon,dc=com" -W -f /root/base.ldif

Nótese que con la opción -D estamos acreditándonos, para la operación, como elusuario "administrador del directorio", y con la opción -W le decimos a la orden que nospida la contraseña de dicho usuario de forma interactiva. La opción -c consigue que lda-padd siga insertando registros a pesar de que se produzcan errores en alguna inserción(cosa que suele ocurrir con el primer registro).

• Para la migración de los usuarios:

bash# ./migrate_passwd.pl /etc/passwd > /root/usus.ldif

Una vez copiados todos los usuarios en format LDIF, tenemos que editar el ficherousuarios.ldif y eliminar todos los registros que hacen referencia a usuarios especia-les de Linux, incluyendo a "root" (no se recomienda en general exportar la cuenta de"root" mediante LDAP, por cuestiones de seguridad). En definitiva, sólo deberían quedaren el fichero los registros asociados a los usuarios comunes que hemos añadido al siste-ma. Una vez editado el fichero, añadimos los registros al directorio:

2.7. Migración de la información del servidor


bash# ldapadd -x -c -D "cn=root,dc=admon,dc=com" -W -f /root/usus.ldif

• Para la migración de los grupos:

bash# ./migrate_group.pl /etc/group > /root/grupos.ldif

Como con los usuarios, eliminamos del fichero grupos.ldif los grupos especiales, ydejamos sólo los grupos privados de los usuarios comunes que hemos añadido al siste-ma. Tras la modificación, añadimos esos grupos al directorio:

bash# ldapadd -x -c -D "cn=root,dc=admon,dc=com" -W -f /root/grupos.ldif

• Y así sucesivament con hosts, servicios, etc. De todas formas, para nuestros propósitos deuso del directorio, con la migración hecha hasta aquí resultaría suficiente.

A partir de este momento, pueden utilizarse las utiliadades ldapadd para añadir entra-das, ldapmodify y ldapmodrdn para modificar entradas o nombres relativos de entrada (elnombre distinguido relativo de una entrada es el primer campo del nombre distinguido dedicha entrada), ldapdelete para eliminar entradas, ldappasswd para modificar la contraseñade una entrada y la ya mencionada ldapsearch para buscar entradas, desde cualquiera de losclientes. Se recomienda visitar las páginas de manual correspondientes para más informa-ción.

Es importante recordar que las órdenes de añadir y modificar entradas esperan recibir lainformación en formato LDIF. Por ejemplo, para añadir una entrada de grupo denominada"alumnos" con GID 1000 deberíamos crear primeramente un archivo (alumnos.ldif) conel siguiente contenido (y al menos una línea en blanco al final):

dn: cn=alumnos,ou=Group,dc=admon,dc=comobjectclass: posixGroupobjectclass: topcn: alumnosuserPassword: {crypt}xgidNumber: 1000

Y posteriormente añadirlo al directorio mediante la orden:

bash# ldapadd -x -D "cn=root,dc=admon,dc=com" -W -f alumnos.ldif

Evidentemente, esto resulta muy tedioso y es fácil equivocarse. Por este motivo, se reco-mienda la utilización de herramientas gráficas que faciliten la labor de crear, modificar y bo-rrar entradas en el directorio. En Sección 2.11, “Herramientas gráficas de administración” seamplía este aspecto.

2.8. Autenticación basada en OpenLDAP


2.8. Autenticación basada en OpenLDAPUna vez configurado el servidor de LDAP para almacenar la información del directorio, ylos clientes de LDAP para poder preguntar por ella, el siguiente y último paso para organi-zar un dominio Linux con LDAP es conseguir que el directorio sea utilizado por todos los or-denadores (servidores y clientes) como fuente de información administrativa, añadida a lospropios ficheros de configuración locales presentes en cada ordenador.

En principio, la información administrativa que tiene sentido centralizar en un dominioLinux se reduce prácticamente a cuentas de usuario (incluyendo contraseñas) y cuentas degrupo (las cuentas de ordenadores del directorio, es decir, la centralización del fichero /etc/hosts del servidor LDAP, pueden obviarse si ya disponemos de resolución de nom-bres basada en DNS, por ejemplo). En conjunto, la información almacenada en ambos tiposde cuentas permite autentificar a un usuario cuando éste desea iniciar una sesión interactivaen un sistema Linux y, en el caso de que la autentificación sea positiva, crear el contexto detrabajo inicial (es decir, el proceso shell inicial) para ese usuario. Manteniendo ambos tipos decuentas en el directorio permitiría una gestión completamente centralizada de los usuariosdel dominio.

Internamente, este proceso de autentificación y creación del contexto inicial que Linux lle-va a cabo cuando un usuario desea iniciar una sesión interactiva utiliza dos bibliotecas dis-tintas:

1. PAM (Pluggable Authentication Module) es una biblioteca de autentificación genérica quecualquier aplicación puede utilizar para validar usuarios, utilizando por debajo múlti-ples esquemas de autentificación alternativos (ficheros locales, Kerberos, LDAP, etc.).Esta biblioteca es utilizada por el proceso de "login" para averiguar si las credenciales te-cleadas por el usuario (nombre y contraseña) son correctas.

2. NSS (Name Service Switch) presenta una interfaz genérica para averiguar los parámetrosde una cuenta (como su UID, GID, shell inicial, directorio de conexión, etc.), y es utiliza-da por el proceso de "login" para crear el proceso de atención inicial del usuario.

La ventaja fundamental de ambas bibliotecas consiste en que pueden reconfigurarse diná-micamente mediante ficheros, sin necesidad de recompilar las aplicaciones que las utilizan.Por tanto, lo único que necesitamos es reconfigurar ambas para que utilicen el servidorLDAP además de los ficheros locales (/etc/passwd, etc.) de cada ordenador.

En CentOS Linux, esta configuración es muy sencilla. Primero instalamos (si no lo estáya) un paquete denominado nss_ldap, que contiene los módulos de LDAP para PAM yNSS. A partir de ahí, ejecutamos la herramienta de configuración system-con-fig-authentication, que configura automáticamente los ficheros de PAM y NSS con los meca-nismos de autentificación disponibles. En nuestro caso, basta habilitar el soporte LDAP enlos paneles "Información del usuario" y "Autenticación", configurando LDAP indicando ladirección IP del servidor y el sufijo del directorio (en formato LDAP, claro). En principio, nodebemos activar la casilla de "Utilizar TLS" (que activaría conexiones seguras) ya que no he-mos activado este tipo de conexiones en el servidor.

2.8. Autenticación basada en OpenLDAP


Es importante recordar que debemos realizar esta configuración en todos los clientes pri-mero, y sólo iniciarla en el servidor cuando hayamos asegurado que todo funciona correcta-mente. En cualquier caso, no resulta imprescindible configurar el servidor como cliente, sisiempre incluimos los usuarios y grupos nuevos tanto en el directorio como en los ficheroslocales del mismo (o bien si dichos usuarios nunca van a trabajar en el servidor).

La comprobación desde cualquier cliente que el dominio funciona es muy sencilla. Sim-plemente ejecutamos:

bash# getent passwdbash# getent group

Y comprobamos que nos devuelven, respectivamente, la lista completa de usuarios y gru-pos del servidor. En realidad, esta forma comprobaría únicamente el funcionamiento correc-to de NSS sobre LDAP. Para una comprobación completa (PAM+NSS), la manera más efecti-va es intentar iniciar una sesión en un cliente con un usuario que sólo esté definido en el ser-vidor. Hay que recordar que el directorio de conexión del usuario (home)debe existir en el or-denador cliente (localmente, o bien montado por NFS).

2.9. Permisos de accesoEn OpenLDAP es posible establecer permisos de acceso, e indicar así quién puede leer, bus-car, comparar, modificar, etc., la información almacenada en el directorio. Estos permisos seexpresan en el fichero de configuración /etc/openldap/slapd.conf mediante una listade sentencias de acceso. La sintaxis que utilizan estas sentencias es relativamente compleja yestá descrita con detalle en la página de manual slapd.access. A continuación se describela sintáxis de las formas más usuales de estas sentencias.

access to <what> [by <who> <acess_control>]+

donde:

• <what> es una expresión que especifica a qué entradas del directorio se aplica la regla.Existen varias opciones, siendo las más comunes las siguientes: (1) puede indicarse todoel directorio mediante un asterisco (*), (2) una entrada del directorio (por ejemplo,dn="cn=jero,ou=people,dc=admon, dc=com" y (3) un subarbol de entradas deldirectorio (por ejemplo, dn.subtree="ou=ventas,dc=admon, dc=com"). Por defec-to, los permisos se aplican a todos los atributos de las entradas especificadas, pero es po-sible seleccionar qué atributos que se verán afectados utilizando la opción attrs (porejemplo, dn.subtree="ou=People, dc=admon, dc=com"attrs=userPassword).

• <who> indica a quién (a qué usuario(s)) se especifica la regla. Puede tomar diferentes va-lores, siendo los más comunes los siguientes: self (el propietario de la entrada),dn="..." (el usuario representado por el nombre distinguido), users (cualquier usua-rio acreditado), anomymous (cualquier usuarios no acreditado) y * (cualquier usuario).

2.9. Permisos de acceso


• <access_control> indica qué operación concede la regla: none (sin acceso), auth(utilizar la entrada para validarse), compare (comparar), search (búsqueda), read(lectura), y write (modificación).

Para entender correctamente la semántica de las reglas de control de acceso, es imprescin-dible conocer el método que sigue slapd para evaluarlas, cada vez que recibe una peticiónpor parte de un cliente: primero se busca, secuencialmente, la primera regla cuya expresión<what> incluye la entrada, o entradas, afectadas por la petición. Dentro de ella, se busca se-cuencialmente la primera expresión <who> que incluye al usuario que ha realizado la peti-ción desde el cliente. Una vez encontrado, si el nivel de acceso expresado por<access_control> es mayor o igual al requerido por la petición, entonces ésta se concede,y en caso contrario se deniega. Si no existe ninguna expresión <who> que incluya al usuario,o bien no existe ninguna regla cuya expresión <what> incluya la información afectada por lapetición, se deniega la petición.

Por tanto, el orden en que aparecen las reglas en el fichero, y el orden interno de las cláu-sulas "by" dentro de cada regla, es relevante: si varias reglas afectan a los mismos objetos, lasreglas más específicas deberían ubicarse antes en el fichero; y, dentro de una regla, si inclui-mos varias cláusulas by, también debemos situar las más específicas primero.

Es importante tener en cuenta que el administrador del directorio siempre tiene asignadoel permiso de escritura y, por defecto, el resto de usuarios tienen permiso de lectura. Unejemplo de reglas de acceso que modifica levemente el comportamiento por defecto podríaser el siguiente:

access to dn.subtree="ou=People,dc=admon,dc=com" attrs=userPasswordby self writeby dn="cn=root,dc=admon,dc=com" writeby * auth

access to *by dn="cn=root,dc=admon,dc=com" writeby * read

En este ejemplo, la primera regla de acceso permite a cada usuario a cambiarse su propiacontraseña (la contraseña es el atributo userPassword en los objetos de tipo usuario, que sesitúan por defecto dentro de la unidad organizativa "People"), al administrador cambiar lade cualquier usuario y al resto de usuarios sólo pueden utilizar este campo para autentificar-se. De esta forma se consigue que un usuario no pueda leer las contraseñas cifradas de otrosusuarios. La segunda regla de acceso permite al administrador cambiar cualquier entradadel directorio y al resto de usuarios sólo leerlas, lo que corresponde realmente con el com-portamiento por defecto excepto para el atributo userPassword.

Finalmente, es importante destacar que las reglas de acceso también permiten delegar laadministración de parte (o todo) el directorio a ciertos usuarios, de forma análoga a la dele-gación de control en el Directorio Activo de Windows Server (ver Sección 1.5, “Delegaciónde la administración”). En este caso, la delegación se traduce habitualmente en conceder per-misos de escritura sobre los objetos situados en una cierta unidad organizativa, bien sea so-bre todos los atributos de dichos objetos, o bien sobre alguno(s) en concreto.

2.9. Permisos de acceso


Por ejemplo, supongamos que queremos modificar el comportamiento de las reglas deacceso anteriores para conseguir que sobre la unidad organizativa People, el usuario ja-vier tenga capacidad administrativa completa, mientras que el usuario jose pueda modifi-car únicamente las contraseñas de sus usuarios. Para ello debemos modificar las reglas ante-riores de forma que queden como se muestra a continuación:

access to dn.subtree="ou=People,dc=admon,dc=com" attrs=userPasswordby dn="cn=javier,ou=People,dc=admon,dc=com" writeby dn="cn=jose,ou=People,dc=admon,dc=com" writeby self writeby dn="cn=root,dc=admon,dc=com" writeby * auth

access to dn.subtree="ou=People,dc=admon,dc=com"by dn="cn=javier,ou=People,dc=admon,dc=com" writeby dn="cn=root,dc=admon,dc=com" writeby * read

access to *by dn="cn=root,dc=admon,dc=com" writeby * read

Esta forma de construir las reglas viene determinada por la manera particular en queOpenLDAP las evalúa, tal como se ha descrito arriba. En concreto, la primera regla del ejem-plo permite que tanto javier como jose modifiquen las contraseñas de los usuarios dePeople, mientras que la segunda permite que javier tenga permisos de modificación so-bre el resto de los atributos de los usuarios de People.

2.10. Configuración de OpenLDAP con varios servidoresSi las necesidades de nuestra red y/o de nuestro directorio hacen aconsejable mantener másde un servidor LDAP (por ejemplo, para poder equilibrar la carga de las consultas, y por as-pectos de tolerancia a fallos) podemos configurar varios servidores LDAP que mantenganimágenes sincronizadas de la información del directorio.

Para mantener el directorio replicado en diferentes servidores, OpenLDAP propone unesquema de maestro único y múltiples esclavos. Este esquema funciona de la siguiente for-ma: cada vez que se produce un cambio en el directorio del servidor maestro, el servicioslapd escribe dicho cambio, en formato LDIF, en un fichero local de registro (es decir, log fi-le o cuaderno de bitácora). El servidor maestro inicia otro servicio denominado slurpd que,cada cierto tiempo se activa, lee dichos cambios e invoca las operaciones de modificación co-rrespondientes en todos los esclavos. En cambio, si un esclavo recibe una operación de modi-ficación directa por parte de un cliente, ésta debe redirigirse automáticamente al servidormaestro.

Evidentemente, este esquema sólo funciona si todos los servidores (maestro y esclavos)parten de un estado del directorio común. Por ese motivo, es necesario copiar manualmentela base de datos del directorio (es decir, el contenido del directorio /var/lib/ldap del ser-vidor maestro) a cada esclavo, estando los servicios slapd parados en todos ellos, por su-puesto.

2.10. Configuración de OpenLDAP con varios servidores


La configuración del servidor maestro y de cada esclavo sería la siguiente:

1. Servidor maestro. En el archivo de configuración /etc/openldap/slapd.conf hayque añadir las siguientes líneas por cada servidor esclavo:

replica host=esclavo.admon.com:389binddn="cn=Replicator,dc=admon,dc=com"bindmethod=simplecredentials=CONTRASEÑA_PLANA

Y además hay que decirle a slapd en qué fichero de registro tiene que escribir loscambios:

replogfile /var/lib/ldap/master-slapd.replog

2. Servidor esclavo. Por una parte, en el servidor esclavo hay que configurar el archivo /etc/openldap/slapd.conf de la misma forma que en el maestro (ver Sección 2.5,“Instalación del servidor OpenLDAP”), exceptuando las líneas expuestas en el apartadoanterior, que sólo corresponden al maestro.

Por otra parte, hay que incluir en dicho fichero las siguientes opciones:

rootdn "cn=Replicator,dc=admon,dc=com"updatedn "cn=Replicator,dc=admon,dc=com"updateref ldap://maestro.admon.com

La opción updatedn indica la cuenta con la que el servicio slurpd del servidormaestro va a realizar las modificaciones en la réplica del esclavo. Como puede compro-barse, hemos establecido que esta cuenta sea también el "rootdn" del servidor esclavo.Esa es la forma más sencilla de asegurar que este usuario tendrá permisos para modifi-car el directorio en este servidor (si no fuera así, deberíamos asegurarnos que esta cuen-ta tuviera concedido permiso de escritura en el directorio del servidor esclavo, en direc-tiva "access" correspondiente). Por su parte, updateref indica al servidor esclavo quecualquier petición directa de modificación que venga de un cliente debe ser redireccio-nada al servidor maestro del directorio.

2.11. Herramientas gráficas de administraciónEntre las diferentes herramientas gráficas con las que se puede manipular un directorio de ti-po LDAP en Linux, hemos elegido una denominada "phpLDAPadmin"[http://phpldapadmin.sourceforge.net] por su sencillez y comodidad.

Esta herramienta se ejecuta de forma indirecta a través de un servidor Web, Apache nor-malmente. Una muestra de su interfaz la tenemos en la Figura 2.2, “Vista de la herramientaphpLDAPadmin”.

2.11. Herramientas gráficas de administración


http://phpldapadmin.sourceforge.net

A partir de ese momento, ya estamos en condiciones de añadir, modificar y borrar usua-rios y grupos del directorio, mediante una simple interacción con la herramienta. Si esta he-rramienta se convierte en la herramienta fundamental de gestión de usuarios y grupos en eldominio Linux, necesitamos tener en mente un par de precauciones: en primer lugar, si de-seamos mantener la filosofía de grupos privados, debemos crear el grupo privado de unusuario antes que el propio usuario, ya que en este último paso sólo podemos seleccionar sugrupo primario. Y en segundo lugar, tendremos que gestionar manualmente los directoriosde conexión de los usuarios que creemos.

Figura 2.2. Vista de la herramienta phpLDAPadmin

2.11. Herramientas gráficas de administración


3Sistema de Archivos en

Red (NFS)

Indice3.1. Introducción .................................................................................................. 433.2. Acceso a directorios remotos mediante NFS ..................................................... 433.3. Usos típicos de NFS ....................................................................................... 433.4. Funcionamiento de NFS ................................................................................. 443.5. Instalación y configuración del cliente NFS ...................................................... 443.6. Instalación y configuración del servidor NFS ................................................... 45

3.1. IntroducciónComo es bien sabido por cualquier usuario de Linux, un sistema Linux puede trabajar única-mente con una jerarquía de directorios, de tal forma que si se desea acceder a distintos siste-mas de archivos (particiones de discos, cd-roms, disquetes, etc.), todos ellos deben montarseprimero en algún punto de dicha jerarquía única.

Siguiendo la misma filosofía, Network File System (NFS) es un servicio de red que permitea un ordenador cliente montar y acceder a un sistema de archivos (en concreto, un directorio)remoto, exportado por otro ordenador servidor. Este capítulo explica las bases de cómo ex-portar directorios por NFS desde un sistema Linux y cómo acceder a ellos desde otros siste-mas a través de la red.

3.2. Acceso a directorios remotos mediante NFSComenzaremos esta sección con un ejemplo. Supóngase que una máquina denominadafaemino desea acceder al directorio home/ftp/pub/ de la máquina cansado. Para ello,debería invocarse el siguiente mandato (en faemino):

bash# mount -t nfs cansado:/home/ftp/pub /mnt

Este mandato indica que el directorio /home/ftp/pub/, que debe ser exportado por elordenador cansado, va a montarse el directorio local /mnt/ de faemino. Es importante te-ner en cuenta que este directorio local debe existir previamente para que el montaje puedarealizarse. La opción -t nfs indica a mount el tipo de sistema de archivos que va a montar,aunque en este caso podría omitirse, ya que mount detecta por el carácter que se trata de unmontaje remoto (por NFS) gracias al carácter ':' en la especificación del "origen" ("cansa-do:/home/ftp/pub").

Una vez el montaje se ha realizado, cualquier acceso a archivos o directorios dentro de /mnt (lectura, escritura, cambio de directorio, etc.) se traduce de forma transparente a peticio-nes al ordenador servidor (cansado), que las resolverá y devolverá su respuesta al cliente,todo a través de la red. Es decir, el montaje de directorios mediante NFS permite trabajar conarchivos remotos exactamente igual que si fueran locales, aunque lógicamente con una me-nor velocidad de respuesta.

3.3. Usos típicos de NFSEn general, NFS es muy flexible, y admite las siguientes posibilidades (o escenarios):

• Un servidor NFS puede exportar más de un directorio y atender simultáneamente a va-rios clientes.

• Un cliente NFS puede montar directorios remotos exportados por diferentes servidores.

3.1. Introducción


• Cualquier sistema UNIX puede ser a la vez cliente y servidor NFS.

Teniendo esto en cuenta, existen varios usos típicos de NFS donde este servicio muestrasu utilidad (entre otros):

1. Directorios de conexión (home) centralizados. Cuando en una red local de máquinasLinux se desea que los usuarios puedan trabajar indistintamente en cualquiera de ellas,es apropiado ubicar los directorios de conexión de todos ellos en una misma máquina yhacer que las demás monten esos directorios mediante NFS.

2. Compartición de directorios de uso común. Si varios usuarios (desde distintas máqui-nas) trabajan con los mismos archivos (de un proyecto común, por ejemplo) también re-sulta útil compartir (exportar+montar) los directorios donde se ubican dichos archivos.

3. Ubicar software en un solo ordenador de la red. Es posible instalar software en un di-rectorio del servidor NFS y compartir dicho directorio vía NFS. Configurando los clien-tes NFS para que monten dicho directorio remoto en un directorio local, este softwareestará disponible para todos los ordenadores de la red.

3.4. Funcionamiento de NFSEn el sistema cliente, el funcionamiento de NFS está basado en la capacidad de traducir losaccesos de las aplicaciones a un sistema de archivos en peticiones al servidor correspondien-te a través de la red. Esta funcionalidad del cliente se encuentra normalmente programadaen el núcleo de Linux, por lo que no necesita ningún tipo de configuración.

Respecto al servidor, NFS se implementa mediante dos servicios de red, denominadosmountd y nfsd. Veamos qué acciones controlan cada uno de ellos:

1. El servicio mountd se encarga de atender las peticiones remotas de montaje, realizadaspor la orden mount del cliente. Entre otras cosas, este servicio se encarga de comprobarsi la petición de montaje es válida y de controlar bajo qué condiciones se va a acceder aldirectorio exportado (sólo lectura, lectura/escritura, etc.). Una petición se considera váli-da cuando el directorio solicitado ha sido explícitamente exportado y el cliente tienepermisos suficientes para montar dicho directorio. Esto se detalla más adelante en el do-cumento.

2. Por su parte, y una vez un directorio remoto ha sido montado con éxito, el servicio nfsdse dedica a atender y resolver las peticiones de acceso del cliente a archivos situados enel directorio.

3.5. Instalación y configuración del cliente NFSComo se ha expresado anteriormente, el cliente NFS no requiere ni instalación ni configura-

3.4. Funcionamiento de NFS


ción. Los directorios remotos pueden importarse utilizando el mandato mount y el ficheroasociado /etc/fstab

En este sentido, recuérdese que en cada invocación al mandato mount (y/o en cada líneadel fichero /etc/fstab) se pueden establecer opciones de montaje. En ellas se particularizael comportamiento que tendrá el sistema de archivos una vez se haya montado en el directo-rio correspondiente. En el caso de NFS, las opciones más importantes son las que gobiernanel modo de fallo de las peticiones remotas, es decir, cómo se comporta el cliente cuando elservidor no responde:

1. soft. Con esta opción, cuando una petición no tiene respuesta del servidor el clientedevuelve un código de error al proceso que realizó la petición. El problema es que muypocas aplicaciones esperan este comportamiento y ello puede provocar situaciones enlas que se pierda información. Por tanto, no es aconsejable.

2. hard. Mediante esta opción, cuando el servidor no responde el proceso que realizó lapetición en el cliente se queda suspendido indefinidamente. Esta es la opción que se re-comienda normalmente, por ser la que esperan las aplicaciones, y por tanto más seguradesde el punto de vista de los datos.

Esta opción se puede combinar con la opción intr, que permite matar el procesomediante el envío de una señal (de la forma tradicional en Linux).

A continuación se muestra un ejemplo, en el que se presenta la línea del archivo /etc/fstab(de la máquina faemino) relacionada con el ejemplo de la Sección 3.2, “Acceso adirectorios remotos mediante NFS”:

#device mountpoint fs-type options dump fsckorder...cansado:/home/ftp/pub /mnt nfs defaults 0 0

3.6. Instalación y configuración del servidor NFSEl servidor necesita, además de los dos servicios mountd y nfsd (ambos se aúnan en el servi-cio común demominado nfs), uno más denominado portmap (del inglés portmapper), sobreel cual ambos basan su funcionamiento. Por tanto, la configuración de un servidor NFS nece-sita únicamente tener disponibles dichos servicios e iniciarlos en el nivel de ejecución 3 (o 5,o ambos) de la máquina.

Una vez activos los servicios NFS, el servidor tiene que indicar explícitamente qué direc-torios desea que se exporten, a qué máquinas y con qué opciones. Para ello existe un ficherode configuración denominado /etc/exports. A continuación se muestra uno de ejemplo,sobre el que se explican las características más relevantes:

# Directory Clients and (options)/tmp pc02??.dsic.upv.es(rw) *.disca.upv.es()/home/ftp/pub 158.42.54.1(rw,root_squash)

3.6. Instalación y configuración del servidor NFS


/ mio.dsic.upv.es(rw,no_root_squash)/pub (rw,all_squash,anonuid=501,anongid=601)/pub/nopublic (noaccess)

Cada línea especifica un directorio que se va a exportar, junto con una lista de autoriza-ciones, es decir, qué ordenadores podrán montar dicho directorio y con qué opciones (desdeel punto de vista del servidor). Cada elemento de la lista de ordenadores puede especificarun solo ordenador (mediante nombre simbólico o dirección IP) o un grupo de ordenadores(mediante el uso de caracteres comodín como `*' ó `?'). Cuando el ordendor/rango no se espe-cifica (por ejemplo, en las últimas dos líneas), esto significa que el directorio correspondientese exporta a todos los ordenadores del mundo (conectados a Internet). Por su parte, de entrelas posibles opciones de montaje que, entre paréntesis, pueden especificarse para cada orde-nador/grupo, las más importantes se resumen a continuación:

() Esta opción establece las opciones que NFS asume por defecto.

ro El directorio se exporta como un sistema de archivos de sólo lectu-ra (opción por defecto).

rw El directorio se exporta como un sistema de archivos de lectura/escritura.

root_squash Los accesos desde el cliente con UID=0 (root) se convierten en elservidor en accesos con UID de un usuario anónimo (opción pordefecto)

no_root_squash Se permite el acceso desde un UID = 0 sin conversión. Es decir, losaccesos de root en el cliente se convierten en accesos de root en elservidor.

all_squash Todos los accesos desde el cliente (con cualquier UID) se transfor-man en accesos de usuario anónimo.

anonuid, anongid Cuando se activa la opción root_squash ó all_squash, los ac-cesos anónimos utilizan normalmente el UID y GID primario delusuario denominado nobody, si éste existe en el servidor (opciónpor defecto). Si se desean utilizar otras credenciales, los parámetrosanonuid y anongid establecen, respectivamente, qué uid y gidtendrá la cuenta anónima que el servidor utilizará para accedercontenido del directorio.

noaccess Impide el acceso al directorio especificado. Esta opción es útil paraimpedir que se acceda a un subdirectorio de un directorio exporta-do.

Es importante destacar que cada vez que se modifica este fichero, para que se activen loscambios, el servidor NFS debe ser actualizado ejecutando el mandato exportfs -ra.

Una lista completa de las opciones de montaje y su significado pueden encontrarse en la



página de manual exports (5) de Linux. La mayoría de estas opciones establecen comoquién se comporta el proceso cliente cuando su petición de acceso llega al servidor. En prin-cipio, cada petición lleva asociada el UID y GID del proceso cliente, es decir, se comporta co-mo sí mismo. No obstante, si está activa la opción all_squash (o bien el UID es cero yroot_squash está activado), entonces el UID/GID se convierten en los del usuario anóni-mo. De todas formas, hay que tener en cuenta que los permisos sobre cada acceso del clientese evalúan mediante los UID/GID que finalmente son válidos en el servidor (es decir, los ori-ginales o los anónimos, según el caso).

Es muy importante resaltar que no existe ningún proceso de acreditación de usuarios enNFS, por lo que el administrador debe decidir con cautela a qué ordenadores exporta un de-terminado directorio. Un directorio sin restricciones es exportado, en principio, a cualquierotro ordenador conectado con el servidor a través de la red (incluida Internet). Si en un orde-nador cliente NFS existe un usuario con un UID igual a "X", este usuario accederá al servidorNFS con los permisos del usuario con el UID igual a "X" del servidor, aunque se trate deusuarios distintos.



4Configuración Básica de

Samba

Indice4.1. ¿Qué es Samba? ............................................................................................. 514.2. El protocolo SMB ........................................................................................... 524.3. Configuración de Samba ................................................................................ 554.4. Niveles de seguridad ..................................................................................... 564.5. Configuración de Samba en el nivel domain .................................................... 574.6. Tratamiento de los accesos como invitado ....................................................... 584.7. El sistema de ficheros CIFS para Linux ............................................................ 594.8. Opciones del servidor Samba .......................................................................... 604.9. Opciones del recurso ...................................................................................... 61

4.1. ¿Qué es Samba?Samba es un producto que se distribuye gratuitamente para varias versiones de UNIX(R), deacuerdo con los términos de la General Public License de GNU, y que básicamente permite alsistema UNIX conversar con sistemas Windows a través de la red de forma nativa. De estaforma, el sistema UNIX aparece en el "Entorno de red", y clientes Windows pueden acceder asus recursos de red e impresoras compartidas como si de otro sistema Windows se tratase.Para ello, Samba implementa los protocolos NetBIOS y SMB. NetBIOS es un protocolo de ni-vel de sesión que permite establecer sesiones entre dos ordenadores. SMB (Server MessageBlock), implementado sobre NetBIOS, es el protocolo que permite a los sistemas Windowscompartir ficheros e impresoras.

Esencialmente, Samba consiste en dos programas, denominados smbd y nmbd. Ambosprogramas utilizan el protocolo NetBIOS para acceder a la red, con lo cual pueden conversarcon ordenadores Windows. Haciendo uso de estos dos programas, Samba ofrece los siguien-tes servicios, todos ellos iguales a los ofrecidos por los sistemas Windows:

• Servicios de acceso remoto a ficheros e impresoras.• Autenticación y autorización.• Resolución de nombres.• Anuncio de servicios.

El programa smbd se encarga de ofrecer los servicios de acceso remoto a ficheros e im-presoras (implementando para ello el protocolo SMB), así como de autenticar y autorizarusuarios. smbd ofrece los dos modos de compartición de recursos existentes en Windows,basado en usuarios o basado en recursos. En el modo basado en usuarios (propio de los do-minios Windows) la autorización de acceso al recurso se realiza en función de nombres deusuarios registrados en un dominio, mientras que en el modo basado en recursos (propio deWindows 3.11/95) a cada recurso se le asigna una contraseña, estando autorizado el accesoen función del conocimiento de dicha contraseña.

El programa nmbd permite que el sistema UNIX participe en los mecanismos de resolu-ción de nombres propios de Windows, lo cual incluye el anuncio en el grupo de trabajo, lagestión de la lista de ordenadores del grupo de trabajo, la contestación a peticiones de reso-lución de nombres y el anuncio de los recursos compartidos. De esta forma, el sistema UNIXaparece en el "Entorno de Red", como cualquier otro sistema Windows, publicando la listade recursos que ofrece al resto de la red.

Adicionalmente a los dos programas anteriores, Samba ofrece varias utilidades. Algunasde las más relevantes son las siguientes:

• smbclient. Una interfaz similar a la utilidad ftp, que permite a un usuario de un sistemaUNIX conectarse a recursos SMB y listar, transferir y enviar ficheros.

• swat (Samba Web Administration Tool). Esta utilidad permite configurar Samba de for-ma local o remota utilizando un navegador de web.

4.1. ¿Qué es Samba?


• smbfs Sistema de ficheros SMB para Linux. Linux puede montar recursos SMB en su je-rarquía, al igual que sucede con directorios compartidos vía NFS.

• winbind. Permite integrar un servidor Samba en un dominio Windows sin necesidad decrear usuarios UNIX en el servidor Samba que correspondan con los usuarios del domi-nio Windows, simplificando así la labor de administración.

4.2. El protocolo SMBPuesto que Samba es, fundamentalmente, una implementación para UNIX del protocoloSMB, quizás la mejor forma de entender Samba es comenzar por describir SMB con un pocomás de detalle. Esta sección realiza una pequeña revisión de este protocolo.

SMB es un protocolo de comunicación de alto nivel que puede implementarse sobre di-versos protocolos como TCP/IP, NetBEUI y IPX/SPX, tal como muestra la Figura 4.1,“Protocolos sobre los que puede implementarse SMB.”, junto con la ubicación de dichos pro-tocolos en los niveles OSI y en la pila TCP/IP. Entre todas esas alternativas, tanto en el casode Samba como de Windows 2000/XP, SMB se implementa habitualmente encima de Net-BIOS sobre TCP/IP (esta alternativa se ha convertido en el estándar de facto para compartirrecursos entre sistemas Windows). Sin embargo, no incidiremos más en los protocolos quesoportan SMB o en su implementación, puesto que todo ello queda fuera del contexto de estetema.

Figura 4.1. Protocolos sobre los que puede implementarse SMB.

Históricamente, este protocolo fue desarrollado inicialmente por IBM como el IBM PCNetwork SMB Protocol o Core Protocol a principios de los años 80. Desde entonces, diversos fa-bricantes (especialmente Microsoft) han ido ampliando su funcionalidad progresivamente,creando diferentes variantes (versiones) de SMB. Desafortunadamente, en ocasiones el cam-bio de versión ha conllevado el rebautizar el propio protocolo. En este sentido, SMB ha reci-bido, entre otros, los siguientes nombres: Core Protocol, DOS Lan Manager, LAN Manager,NTLM (NT Lan Manager), y en los últimos años, CIFS (Common Internet File System). Todos

4.2. El protocolo SMB


ellos, por tanto, hacen referencia a SMB, aunque se diferencien en algunos detalles de su fun-cionalidad y/o implementación.

Si nos fijamos en su interfaz, SMB es un protocolo de tipo cliente/servidor, donde el orde-nador "servidor" ofrece recursos (archivos, impresoras, etc.) que pueden ser utilizados remo-tamente por los ordenadores "cliente" a través de la red. Asimismo, es un protocolo de losdenominados petición/respuesta, indicando que las comunicaciones se inician siempre desdeel cliente como una petición de servicio al servidor (dicha petición se denomina precisamen-te SMB), que la procesa y retorna una respuesta a dicho cliente. (En realidad, existe un casoen que el servidor envía un mensaje al cliente sin haber recibido una petición de éste, pero ladiscusión del protocolo a ese nivel queda fuera del ámbito de este texto). La respuesta delservidor puede ser positiva (con el resultado de procesar la petición del cliente) o negativa(mensaje de error), en función del tipo de petición, la disponibilidad del recurso, el nivel deacceso (permisos) del cliente, etc.

El siguiente aspecto relevante de SMB es saber qué mecanismos de autentificación sopor-ta este protocolo para controlar el acceso del cliente a los recursos compartidos. En concreto,SMB soporta dos modos de autentificación alternativos, denominados share y user:

• Cuando compartimos un recurso en modo share, la protección de dicho recurso recae enuna contraseña que asociamos al mismo, de forma que cualquier usuario de un sistemacliente remoto que conozca dicha palabra de paso podrá acceder sin mayores restriccio-nes al recurso (este es el mecanismo de autentificación por defecto en las implemementa-ciones de SMB para Windows 9X, por ejemplo).

• Sin embargo, en modo user, el servidor recibe inicialmente del sistema cliente unas cre-denciales de usuario (nombre, dominio y contraseña), que debe autentificar para autori-zar el acceso al recurso. Concretamente, si el dominio de las credenciales es conocido, laautentificación se delega a algún controlador de dicho dominio; y en caso contrario, elusuario y la contraseña se autentifican contra la base de datos local del equipo servidor.En cualquier caso, en modo user, el control de acceso sobre el recurso se realiza en fun-ción de qué permisos posee sobre dicho recurso el usuario cuyas credenciales se han en-viado desde el cliente. En otras palabras, una vez el sistema servidor ha identificado y au-tentificado al usuario que desea conectarse al recurso, este sistema dispone ya de un SIDválido con el que puede contrastar los permisos que dicho SID posee sobre el recurso. Esconveniente recordar en este punto que si el recurso en cuestión es una carpeta comparti-da, se tienen en cuenta tanto los permisos del recurso, como los permisos NTFS de la car-peta y sus archivos. El modo user es el mecanismo de autentificación por defecto en lasversiones de SMB de sistemas Windows NT y posteriores.

Finalmente, revisaremos brevemente el funcionamiento interno del protocolo SMB, utili-zando para ello un ejemplo concreto. Supongamos que un sistema cliente desea acceder auna carpeta compartida que exporta el servidor (en modo user). En este escenario, se produ-ciría el siguiente intercambio de mensajes entre ellos:

1. Petición: Sesión NetBIOS. El objetivo de este mensaje es establecer una sesión fiable pa-ra subsiguientes mensajes entre los ordenadores cliente y servidor. Es imprescindible

4.2. El protocolo SMB


que el cliente conozca el nombre NetBIOS del servidor para poder alcanzarlo; el nombreNetBIOS del cliente es parte del mensaje, por lo que ambos saben quién es el otro.

2. Respuesta: Sesión NetBIOS. Si no hay error en el mensaje anterior, el servidor envía unmensaje de reconocimiento (ACK), aceptando la conexión.

3. Petición: Dialecto SMB. El cliente envía en este mensaje una lista con los dialectos o va-riantes de SMB que soporta, puesto que es habitual que un sistema Windows soportevarias versiones de SMB simultáneamente.

4. Respuesta: Dialecto SMB. El servidor contesta con el dialecto que prefiere para la co-municación subsiguiente, o un código de error si no soporta ninguna de las alternativasofrecidas por el cliente.

5. Petición: Inicio de sesión. El cliente envía las credenciales de usuario (usuario, dominio,contraseña) con las que éste desea conectarse al servidor. Recuérdese que por defecto, seemplean las credenciales con las que el usuario se conectó interactivamente al sistemacliente, pero se pueden especificar otras explícitamente.

6. Respuesta: Inicio de sesión. El servidor autentifica las credenciales de usuario (ver mo-do user descrito arriba). Si las credenciales son buenas, el servidor posee ya un SID váli-do que le permite, antes que nada, comprobar si el usuario posee el derecho de conectar-se al servidor (directiva "tener acceso a este equipo desde la red"). En caso afirmativo, seacepta la conexión y el servidor construye un identificador numérico particular para esaconexión (denominado User ID o UID) que devuelve al cliente. Los UIDs pueden serreutilizados durante la vida del sistema, pero son únicos para todas las conexiones si-multáneas que mantiene el servidor en un momento dado, por lo que identifican unívo-camente una conexión (aceptada). Todos los mensajes posteriores del cliente deben con-tener este identificador para ser aceptados por el servidor.

Por otro lado, si las credenciales estaban mal (o si los derechos eran insuficientes), elservidor envía un código de error en lugar del UID.

7. Petición: Conexión a un recurso concreto. El cliente envía entonces un mensaje quecontiene una cadena que identifica el recurso al que desea acceder (por ejemplo,\\pc01\impresora o \\pc01\carpeta).

8. Respuesta: Conexión a un recurso concreto. Si el recurso solicitado por el cliente existe(y el SID asociado a la conexión posee suficientes permisos), el servidor construye unidentificador denominado Tree ID o TID, que será utilizado por el cliente para hacer re-ferencia a dicho recurso en posteriores mensajes de esa conexión.

Tras esta secuencia típica de conexión al recurso (carpeta compartida), y si todo ha fun-cionado correctamente, el sistema cliente ya está en condiciones de acceder a la carpeta. Me-diante el envío de los SMBs correspondientes, el cliente ya puede abrir archivos, leerlos, mo-dificarlos, etc., utilizando siempre los identificadores (UID y TID) que el servidor ha cons-truido durante el intercambio de mensajes inicial.

4.3. Configuración de Samba


4.3. Configuración de SambaLa configuración de Samba se realiza en el fichero /etc/samba/smb.conf. En este ficherose establecen las características del servidor Samba, así como los recursos que serán compar-tidos en la red. La utilización de este fichero es bastante sencilla, ya que aunque existe ungran número de opciones, muchas de ellas pueden obviarse dado que siempre existe una va-lor por defecto para cada opción, que suele ser apropiado. A título de ejemplo, a continua-ción se muestra un fichero de configuración simple, que exporta el directorio de conexión decada usuario como un recurso de red distinto, y el directorio /espacio/pub como el recur-so de red pub:

[global][homes]

comment = Home Directories[pub]

path = /espacio/pub

Como se ve en el ejemplo, el fichero /etc/samba/smb.conf se encuentra divido en sec-ciones, encabezados por una palabra entre corchetes. Dentro de cada sección figuran opcio-nes de configuración, de la forma etiqueta = valor, que determinan las característicasdel recurso exportado por la sección. Al final del capítulo (Sección 4.8, “Opciones del servi-dor Samba” y Sección 4.9, “Opciones del recurso”) del presente documento se citan las op-ciones más importantes que se pueden establecer en cada sección.

Existen tres secciones predefinidas, denominadas global, homes y printers, y tantassecciones adicionales como recursos extra se quieran compartir. El cometido de dichas sec-ciones predefinidas se describe brevemente a continuación:

[global] Define los parámetros de Samba a nivel global del servidor, así como losparámetros que se establecerán por defecto en el resto de las secciones.

[homes] Define automáticamente un recurso de red por cada usuario conocidopor Samba. Este recurso, por defecto, está asociado al directorio de cone-xión de cada usuario en el ordenador en el que Samba está instalado.

[printers] Define un recurso compartido por cada nombre de impresora conocidapor Samba.

Para cualquier otro recurso (directorio o impresora) que se quiera compartir hay que defi-nir una sección adicional en el fichero de configuración. El encabezamiento de dicha sección(pub en el ejemplo anterior) corresponderá al nombre que el recurso tendrá en la red.

Por otra parte, Samba ofrece una interfaz de edición de este fichero basada en web deno-minada swat. Esta herramienta permite configurar Samba utilizando un navegador de red,tanto de forma local como remota. Para ello, basta con acceder a la direciónhttp://nombre_de_ordenador_samba:901/ mediante cualquier navegador.

4.4. Niveles de seguridad


4.4. Niveles de seguridadUna de las consideraciones más importantes a la hora de configurar Samba es la seleccióndel nivel de seguridad.

Desde la perspectiva de un cliente, Samba ofrece dos modos de seguridad, denominadosshare y user, emulando exactamente las dos opciones de SMB que veíamos en la Sección 4.2,“El protocolo SMB”:

1. Modo Share. En modo share, cada vez que un cliente quiere utilizar un recurso ofrecidopor Samba, debe suministrar una contraseña de acceso asociada a dicho recurso.

2. Modo User. En modo user, el cliente debe establecer en primer lugar una sesión con elservidor Samba, para lo cual le suministra un nombre de usuario y una contraseña. Unavez Samba valida al usuario, el cliente obtiene permiso para acceder a los recursos ofre-cidos por Samba.

En cualquiera de ambos, Samba tiene que asociar un usuario del sistema UNIX en el quese ejecuta Samba con la conexión realizada por el cliente. Este usuario es el utilizado a la ho-ra de comprobar los permisos de acceso a los ficheros y directorios que el sistema UNIX/Samba comparte en la red.

La selección del nivel de seguridad se realiza con la opción security, la cual pertenece ala sección [global]. Sus alternativas son las siguientes:

security = share | user | server | domain

Desde la perspectiva del cliente, el nivel share corresponde al modo de seguridad sharey los niveles user, server y domain corresponden todos ellos al modo de seguridad user.A continuación se describen someramente los cuatro niveles.

El nivel share es utilizado normalmente en entornos en los cuales no existe un dominioWindows. En este caso, se asocia una contraseña por cada recurso, que debe proporcionarsecorrectamente desde el cliente cuando se pide la conexión.

En el nivel user, el encargado de validar al usuario es el sistema UNIX donde Samba seejecuta. La validación es idéntica a la que se realizaría si el usuario iniciase una sesión localen el ordenador UNIX. Para que este método sea aplicable, es necesario que existan los mis-mos usuarios y con idénticas contraseñas en los sistemas Windows y en el sistema UNIXdonde Samba se ejecuta.

Desde la aparición de sistemas Windows como Windows 98, Windows NT 4.0 (a partirdel Service Pack 3), Windows 2000 y posteriores, la utilización de este nivel se ha vuelto com-plicada, ya que dichos sistemas Windows transmiten las contraseñas cifradas por la red.Puesto que Samba no posee acceso a las contraseñas cifradas por Windows, el sistema UNIXya no puede realizar la validación. Existen dos métodos para resolver este problema. El pri-mero consiste en modificar el registro del sistema Windows para permitir la transferencia decontraseñas sin cifrar por la red. El segundo método obliga a utilizar una tabla de contrase-

4.4. Niveles de seguridad


ñas adicional en el sistema UNIX, en la cual se almacenan las contraseñas cifradas de losusuarios Windows.

En el nivel server, Samba delega la validación del usuario en otro ordenador, normal-mente un sistema Windows. Cuando un cliente intenta iniciar una sesión con Samba, éste úl-timo intenta iniciar una sesión en el ordenador en el cual ha delegado la validación con lamisma acreditación (usuario+contraseña) recibidos del cliente. Si la sesión realizada porSamba es satisfactoria, entonces la solicitud del cliente es aceptada. Este método aporta laventaja de no necesitar que las contraseñas se mantengan sincronizadas entre los sistemasWindows y UNIX, ya que la contraseña UNIX no es utilizada en el proceso de validación.Adicionalmente, no hay inconveniente en utilizar contraseñas cifradas, ya que la validaciónla realiza un sistema Windows.

Por último, existe la posibilidad de utilizar el nivel domain. Este nivel es similar al nivelserver, aunque en este caso el ordenador en el que se delega la validación debe ser un DC,o una lista de DCs. La ventaja de este método estriba en que el ordenador Samba pasa a serun verdadero miembro del dominio Windows, lo que implica, por ejemplo, que puedan uti-lizarse las relaciones de confianza en las que participa el dominio Windows. Esto significa,en pocas palabras, que usuarios pertenecientes a otros dominios en los que los DCs confíanson conocidos por Samba.

Dadas las ventajas del nivel domain, este documento se centra fundamentalmente en estemétodo. Para detalles específicos de los otros niveles, se recomienda la consulta de la docu-mentación original de Samba.

4.5. Configuración de Samba en el nivel domainLos pasos a seguir para configurar Samba con el nivel de seguridad domain son los siguien-tes:

1. Desde alguno de los DCs del dominio, dar de alta el sistema UNIX donde se ejecutaSamba en el dominio (si en dicho dominio ya existía una cuenta de máquina con el mis-mo nombre, hay que borrar dicha cuenta y volver a crearla).

2. Detener el servidor Samba. Para ello:

bash# service smb stop

3. Utilizando swat, o editando manualmente el fichero de configuración /etc/samba/smb.conf, configurar Samba en modo domain. En concreto, en la sección[global] hay que establecer las siguientes opciones:

security = domainworkgroup = DOMINIOencrypt passwords = yespassword server = DC1_DEL_DOMINIO, DC2_DEL_DOMINIO, ...

En esta configuración, la última línea hace referencia a los ordenadores que realiza-

4.5. Configuración de Samba en el nivel domain


rán la autenticación de los usuarios. Esta línea se puede simplificar, y sustituir por:password server = *

4. Agregar el sistema UNIX al dominio:

bash# net rpc join member -U administrador -W "DOMINIO" -S "DC"

5. Iniciar el servidor Samba:

bash# service smb start

4.6. Tratamiento de los accesos como invitadoCuando se utiliza el nivel de seguridad domain, el tratamiento de los accesos como usuarioinvitado requiere algunas consideraciones. En particular, hay que tener en cuenta tres facto-res:

1. Si el usuario que accede ha sido acreditado por el dominio Windows al cual pertenece elservidor Samba.

2. Si el usuario que accede existe, como usuario UNIX, en el servidor Samba.

3. El valor que tenga actualmente asignado la opción global de Samba map to guest.

La Tabla 4.1, “Resumen de los accesos como invitado en modo "domain"” a continuaciónindica, en función de los tres factores anteriores, si Samba permite o no el acceso y, en casode permitirlo, si al usuario que accede se le considera como él mismo o como invitado.

Tabla 4.1. Resumen de los accesos como invitado en modo "domain"

MAP TO GUEST = NEVER

En Windows...

En Samba... Acreditado No acreditado

Existe Mismo usuario No permitido

No Existe No permitido No permitido

MAP TO GUEST = BAD USER

En Windows...


Existe Mismo usuario No permitido

No Existe Invitado Invitado

4.6. Tratamiento de los accesos como invitado


MAP TO GUEST = BAD PASSWORD

En Windows...


Existe Mismo usuario Invitado

No Existe Invitado Invitado

En cualquier caso, para que el usuario "invitado" pueda acceder a un recurso compartido,este acceso tiene que permitirse expresamente para el recurso con la opción guest ok (cuyovalor por defecto es no).

4.7. El sistema de ficheros CIFS para LinuxLinux dispone de soporte para montar recursos SMB. En concreto, los sistemas Linux actua-les son capaces de montar recursos compatibles con la nueva especificación del protocoloSMB, denominada CIFS (Common Internet File System). De esta forma, Linux, al igual quepuede montar en un directorio local un directorio exportado vía NFS, puede montar un re-curso SMB/CIFS ofrecido por un servidor SMB (un sistema Windows o un servidor Samba,por ejemplo).

No obstante, existe una diferencia significativa entre NFS y CIFS. En NFS no se requiereautenticar al usuario que realiza la conexión; el servidor NFS utiliza el UID del usuario delordenador cliente para acceder a los ficheros y directorios exportados. Un servidor SMB, porcontra, requiere autenticar al usuario, para lo que necesita un nombre de usuario y una con-traseña. Por ello, para montar un recurso SMB/CIFS se utiliza el mandato mount indicándoleun tipo de sistema de archivos específico, denominado cifs:

bash# mount -t cifs -o user=USUARIO,password=CONTRASEÑA,domain=DOMINIO//ORDENADOR/RECURSO /PUNTO/DE/MONTAJE

Si se omite la opción password, el sistema solicita al usuario que introduzca una contra-seña. Si el servidor SMB valida al usuario, a partir del directorio /PUNTO/DE/MONTAJE seconsigue el acceso al recurso //ORDENADOR/RECURSO.

Como de costumbre en los montajes de sistemas de archivos, podemos optar por registrarel montaje en el fichero /etc/fstab. Sin embargo, dicho registro presenta un problema enel caso del sistema de archivos cifs, puesto que el montaje siempre supone la petición deuna contraseña, bien escrita en las opciones de montaje, bien solicitada por teclado en el mo-mento de realizar dicho montaje. Obviamente, esto dificulta el montaje automático en tiem-po de inicio, a menos que escribamos la contraseña en el fichero fstab, lo cual no resultamuy buena idea por motivos de seguridad (dicho archivo puede ser leido por cualquierusuario). La alternativa consiste en utilizar un fichero de credenciales (opción de montajecredentials=FICHERO), donde escribimos el nombre del usuario y su contraseña. A pesarde que la contraseña en dicho fichero también se escribe en texto plano, resulta suficienteque dicho fichero pueda ser leído por el usuario que realiza el montaje (por ejemplo, root, sies un montaje automático durante el inicio), lo cual permite un nivel de seguridad un pocomayor. Se recomienda consultar la página de manual mount.cifs(8) para obtener detalles

4.7. El sistema de ficheros CIFS para Linux


sobre esta opción.

A continuación se muestra una tabla con las principales opciones de montaje del sistemade archivos CIFS:

Tabla 4.2. Opciones de montaje del sistema de archivos CIFS

Opción Descripción

user Usuario con el que se realiza la conexión al ordenadorremoto

password Contraseña del usuario

domain Dominio al que pertenece el usuario

uid Nombre del usuario linux que será el propietario del di-rectorio donde se ha montado el recurso de red

gid Nombre del grupo linux que será el grupo propietariodel directorio donde se ha montado el recurso de red

dir_mode Bits de premiso de los directorios

file_mode Bits de permiso de los ficheros

4.8. Opciones del servidor SambaEn la Tabla 4.3, “Principales opciones de la sección [global] de Samba” se describen algunasopciones del servidor Samba. Estas opciones tan sólo son aplicables a la sección [global].

Tabla 4.3. Principales opciones de la sección [global] de Samba

Opción Significado Valor por defecto

netbios name Nombre (NetBIOS) del ordenador Samba. Primer componente delnombre DNS del ordena-dor.

workgroup Nombre del dominio (o grupo de trabajo) alque pertenece Samba.

nulo

security Nivel de seguridad (share, user, ser-ver, domain).

user

encrypt passwords Utilizar contraseñas cifradas de Windows (enmodo domain, sí deben utilizarse).

no

password server Ordenador Windows utilizado para la autenti-ficación. En modo domain, debe ser una lis-ta de los DCs del dominio.

nulo

map to guest Establece en qué condiciones un acceso aSamba debe considerarse en modo invitado(en el nivel domain, este parámetro afectasólo cuando el acceso no ha sido acreditadopor el DC del dominio).

never

log level Nivel de detalle en la auditoría de Samba. Esun número que indica la cantidad de infor-mación a auditar. A mayor valor, más canti-dad de información.

Se establece en el scriptque inicia el servicio Sam-ba.

4.8. Opciones del servidor Samba



log file Nombre del fichero donde se almacenanmensajes de auditoría de Samba.

Se establece en el scriptque inicia el servicio Sam-ba.

4.9. Opciones del recursoEn la Tabla 4.4, “Principales opciones de los recursos en Samba” se describen algunas opcio-nes aplicables a cada recurso compartido. Pueden establecerse también en la sección global,siendo en este caso utilizadas como valores por defecto para cada recurso compartido.

Tabla 4.4. Principales opciones de los recursos en Samba


read only ({yes/no}) Recurso exportado como sólo lectura. yes

browseable({yes/no})

El servicio aparece en la lista de recursoscompartidos al explorar el ordenador Sambadesde el Entorno de Red Windows.

yes

path Ruta absoluta al directorio compartido por elrecurso.

nulo

comment Descripción del servicio (cadena de caracte-res).

nulo

guest ok ({yes/no}) Permitir accesos como invitado al recurso. no

guest account Si un acceso se realiza como invitado, se uti-liza el usuario indicado para representar laconexión.

nobody

guest only({yes/no})

Todos los accesos se aceptan en modo invi-tado.

no

copy Duplica otro recurso existente. nulo

force user Los accesos al recurso se realizan como siel usuario que accede es el usuario indicado.

nulo (se utiliza el mismousuario que ha realizado laconexión).

force group Los accesos al recurso se realizan como siel usuario que accede pertenece al grupo in-dicado.

nulo (se utiliza el grupo pri-mario del usuario que harealizado la conexión).

hosts allow Lista ordenadores desde los que se permiteacceder al recurso

lista vacía (i.e., todos losordenadores).

hosts deny Lista ordenadores desde los que no se per-mite acceder al recurso. En caso de conflic-to, prevalece lo indicado en hosts allow.

lista vacía (ningún ordena-dor).

valid users Lista de usuarios que pueden acceder al re-curso.

lista vacía (i.e., todos losusuarios).

follow symlinks({yes/no})

Permitir el seguimiento de los enlaces sim-bólicos que contenga el recurso.

yes.

inherit permissions({yes/no})

Al crear ficheros y subdirectorios nuevos, es-tos heredan los permisos UNIX de la carpetadonde se crean.

no.

4.9. Opciones del recurso


5Integración de dominios

mediante servidoresWindows Server 2003

Indice5.1. Introducción .................................................................................................. 655.2. Aspectos básicos a considerar ......................................................................... 655.3. Integración de clientes Linux mediante Windows Services for UNIX ................. 67

5.3.1. Modificaciones del Directorio Activo .................................................... 675.3.2. Configuración de los clientes Linux ...................................................... 69

5.4. Integración de clientes Linux mediante Winbind .............................................. 745.5. Directorios home centralizados ....................................................................... 78

5.5.1. Uso de pam_mkhomedir y pam_mount ................................................ 795.5.2. Uso de pam_script ............................................................................... 81

5.1. IntroducciónCuando una organización posee múltiples ordenadores en los que hay instalado el mismosistema operativo, la opción de administración más adecuada suele ser la creación de un do-minio o conjunto lógico de sistemas que admite gestionarse de forma centralizada, típica-mente mediante un esquema cliente/servidor. Para ello, es imprescindible que en dicho siste-ma operativo exista alguna tecnología que permita esa centralización de aspectos comocuentas de usuarios/grupos, autentificación, políticas de seguridad, etc. En la actualidad,tanto en el caso de Windows Server 2003 como el de Linux, esta tecnología existe y está basa-da en un servicio de directorio compatible con el estándar LDAP.

Sin embargo, es cada vez más habitual que las organizaciones posean simultáenamentesistemas de diferentes tipos. En este tipo de escenarios, la opción más sencilla (y a menudo laúnica posible) consiste en gestionar los sistemas de cada tipo de forma independiente, utili-zando las herramientas administrativas que cada fabricante proporciona. En el caso más fa-vorable, podemos crear un dominio que integre los sistemas de cada tipo (un dominio de sis-temas Linux, un dominio de sistemas Windows (NT, 2000, 2004, XP), etc.), de forma que lagestión está centralizada en cada dominio. Pero obviamente, eso aún supone la repetición deacciones de administración en cada dominio: creación de los mismos usuarios y grupos, con-figuración de permisos y políticas de seguridad, administración de recursos compartidos en-tre sistemas, etc.

Es evidente que la opción más coherente en este tipo de entornos mixtos sería la creaciónde un dominio heterogéneo (o multi-plataforma), que agrupara todos los sistemas de la organiza-ción en una única administración centralizada. Lamentablemente, esta alternativa no es sen-cilla, ya que los diferentes fabricantes de sistemas no suelen diseñarlos para que sean compa-tibles entre sí (especialmente cuando el fabricante es una empresa que defiende un productocomercial). Incluso en el caso de sistemas que basan sus tecnologías en estándares (como he-mos dicho, Windows Server 2003 y Linux implementan sus dominios mediante LDAP), estaintegración no resulta trivial. Ello es debido fundamentalmente a diferencias de diseño entrelos sistemas y a que normalmente ningún sistema implementa los estándares de forma com-pleta y correcta hasta el último detalle.

Este capítulo se centra en cómo conseguir un dominio heterogéneo de sistemas Windowsy Linux mediante una gestión centralizada en servidores Windows Server 2003 (o más co-rrectamente, controladores de dominio). En concreto, se pretende abordar la labor fundamentalen la integración de sistemas: la centralización de usuarios (y grupos) de ambos sistemas enuna única base de datos, en este caso el Directorio Activo de Windows Server 2003.

5.2. Aspectos básicos a considerarGlobalmente, lo que se pretende conseguir es centralizar la administración de cuentas deusuario y grupo mediante un dominio Windows 2003 de tal forma que sistemas Linux pue-dan ser clientes de dicho dominio igual que si fueran sistemas Windows miembros del domi-nio. El resultado final de la configuración será una única base de datos de usuarios/gruposalmacenada en el Directorio Activo de Windows y la posibilidad de que dichos usuariospuedan iniciar una sesión en cualquiera de los sistemas cliente (Windows o Linux), sin nece-

5.1. Introducción


sitar cuentas de usuario locales en ese sistema.

Para el caso de clientes Linux, este objetivo global supone la necesidad de ofrecerles tantoun mecanismo de autentificación que puedan utilizar como el conjunto de atributos de usua-rio (o "atributos UNIX") necesario para que los usuarios puedan iniciar sesión satisfactoria-mente (incluyendo el UID, GID, directorio de conexión o home, shell inicial, etc.). El sistemade autentificación por defecto ofrecido por los dominios Windows (basado en Kerberos) esdirectamente utilizable por los sistemas Linux. Sin embargo, en el caso de los atributos UNIXes necesario realizar configuraciones adicionales. A pesar de que es factible configurar a losclientes Linux para que consulten un directorio LDAP como el Directorio Activo de Win-dows, éste último no incluye por defecto ningún atributo de tipo UNIX.

Para que estos atributos UNIX estén disponibles en los clientes Linux, tenemos dos alter-nativas posibles de partida. En la primera alternativa, los atributos UNIX se almacenan en elDirectorio Activo junto con el resto de información de usuario y de grupo, y son proporcio-nadas a los clientes Linux cuando es necesario. En este caso, se requiere realizar las siguien-tes configuraciones tanto en el servicio de directorio Windows como en los sistemas Linuxcliente:

A. En el Directorio Activo. Puesto que en esta alternativa los atributos UNIX se almacenanen el Directorio Activo, es necesario modificar dicho directorio para que se almacene lainformación que Linux necesita para cada usuario y cada grupo. Como veremos, seránecesario modificar el esquema del Directorio Activo para que las cuentas de usuario ygrupo incorporen estos nuevos atributos.

B. En los clientes Linux. Las modificaciones a realizar permitirán, por un lado, que los sis-temas Linux puedan acceder al Directorio Activo de los controladores Windows paraconsultar las listas de usuarios y grupos del dominio; y por otro lado, que los sistemasLinux sean capaces de autentificar los inicios de sesión de dichos usuarios contra losDCs Windows.

En la segunda alternativa, tanto la autentificación como la obtención de atributos UNIXpara los usuarios se realiza desde el propio cliente Linux, sin involucrar al Directorio Activo.Para ello se instala un servicio en el cliente Linux, denominado winbind, que integra a dichocliente en el dominio Windows como cualquier otro miembro. Una vez integrado, el serviciowinbind autentifica a los usuarios contra el Directorio Activo y obtiene de él aquellos atribu-tos de usuarios y grupos que son comunes a ambos tipos de sistemas (como el nombre deusuario o grupo, o la lista de miembros de un grupo, por ejemplo). Para los atributos UNIX,que no existen en el Directorio Activo, el servicio winbind incorpora un mecanismo que losgenera dinámicamente cuando el sistema cliente los requiere.

Las dos siguientes secciones se centran en discutir las configuraciones exactas que hayque realizar para permitir la integración bajo cada una de ambas alternativas.

5.2. Aspectos básicos a considerar


5.3. Integración de clientes Linux mediante Windows Ser-vices for UNIX

5.3.1. Modificaciones del Directorio Activo

Para conseguir que un sistema Linux vea como cuentas de usuario los usuarios globales quedefinidos en el Directorio Activo, es imprescindible conseguir que la definición de un usua-rio global Windows incluya los atributos que definen a un usuario en Linux. Y exactamenteigual ocurre con las cuentas de grupo. En concreto, los sistemas Linux necesitan, al menos, lossiguientes atributos:

1. Para cada usuario:

• Un nombre de usuario (login name).

• Una contraseña (cifrada).

• Un identificador numérico de usuario (UID).

• Un identificador numérico de grupo primario (GID).

• Un directorio de conexión inicial (home).

• Un programa de atención al usuario (shell).

2. Para cada grupo:

• Un nombre de grupo.

• Un identificador numérico de grupo (GID).

• Una lista de los nombres de de usuario que pertenecen a ese grupo.

Como es lógico, algunos de los atributos que el Directorio Activo almacena por defectopara un usuario y grupo "Windows" pueden servir también para el caso de clientes Linux (esel caso del nombre del usuario o del grupo y de la contraseña). Sin embargo, hay atributoscomo el UID, GID, directorio home, etc., que no existen en el Directorio Activo simplementeporque Windows no los utiliza. Por ello, si queremos ofrecérselos a los clientes Linux, necesi-taremos incorporarlos primero al Directorio Activo. Esto puede conseguirse mediante la mo-dificación del esquema del directorio. Una vez añadidos los nuevos atributos a los objetos detipo usuario y grupo, ya pueden crearse cuentas que contengan todos los datos necesariospara clientes tanto Windows como Linux.

Hasta la primera versión de Windows Sever 2003, existían dos formas de realizar la mo-

5.3. Integración de clientes Linux mediante Windows Services for UNIX


dificación del esquema del Directorio Activo para añadir los "atributos UNIX" a los objetosde tipo usuario y grupo: un parche de libre distribución denominado MKS AD4Unix y unasuite de utilidades de Microsoft denominadas genéricamente Windows Services for UNIX (oSFU). En el primer caso, el parche realizaba la modificación del esquema y de la herramientaUsuarios y Equipos de Active Directory para incluir dichos atributos UNIX. En el caso de lasSFU, además, se incluía un conjunto de servicios tales como cliente y servidor de NIS, NFS yTelnet, varios shells, utilidades comunes en UNIX, etc.

A partir de Windows Server 2003 R2, las SFU vienen de serie en el sistema en lugar de enun paquete aparte. Por tanto, no resulta necesario modificar el esquema del Directorio Acti-vo para disponer de los atributos UNIX. Sin embargo, para poder acceder a esta funcionali-dad, sí es necesario instalar el "servidor NIS", que incluye la pestaña "Atributos UNIX" parausuarios y grupos en la herramienta Usuarios y Equipos de Active Directory. Esto se realizainstalando un componente de Windows (desde el Panel de Control) denominado "IdentityManagement for UNIX" dentro de los "Servicios de Active Directory". En la figura Figura 5.1,“Pestaña de atributos UNIX en Usuarios y Equipos de Active Directory.” se muestran loselementos de esta pestaña. Para poder acceder a los atributos es necesario seleccionar el "do-minio NIS" (que coincide por defecto con el nombre NetBIOS del dominio), y ya se está encondiciones de rellenar el resto de los atributos del usuario: UID, shell, directorio home y gru-po primario (GID).

Figura 5.1. Pestaña de atributos UNIX en Usuarios y Equipos de Active Directory.

Como puede verse en la figura, la elección del grupo no es un número o identificador quepueda teclearse, sino un desplegable de los grupos para los que previamente hemos activado

5.3.1. Modificaciones del Directorio Activo


sus atributos UNIX. Esto obliga a activar primero los atributos UNIX de los grupos (que que-ramos sean visibles desde UNIX) y luego hacer lo propio con los usuarios. A este respecto, esimportante destacar que en el Directorio Activo existe una limitación que impide a un grupollamarse igual que un usuario en el mismo dominio (aunque residan en unidades organizati-vas distintas). Esto dificulta la implementación de la estrategia de grupos privados que man-tienen los sistemas Linux basados en RedHat (en el ejemplo, el grupo primario del usuario"andres" se ha denominado "g-andres" por este motivo).

5.3.2. Configuración de los clientes Linux

En la Sección 2.8, “Autenticación basada en OpenLDAP” se explica cómo es posible configu-rar un sistema Linux como cliente LDAP. Esta sección recuerda los princpales conceptos re-lacionados e introduce las peculiaridades que aparecen cuando el sistema Linux debe sercliente de un servidor LDAP Windows (es decir, de un servicio de Directorio Activo).

5.3.2.1. Linux como cliente de OpenLDAP

En general, Linux separa el acceso interno a las cuentas de usuario/grupo y la autentificaciónde usuarios en dos bibliotecas diferentes, denominadas respectivamente NSS y PAM . En am-bos casos, estas bibliotecas pueden configurarse dinámicamente para obtener sus datos demúltiples fuentes alternativas (ficheros locales, servidores NIS, servidores LDAP, etc.). Si de-seamos configurar el sistema Linux como cliente LDAP, debemos establecer que, para ambasbibliotecas, la fuente de información debe ser un servidor LDAP.

Si el cliente es un sistema Linux basado en RedHat, y el servidor es otro sistema Linuxejecutando OpenLDAP, la configuración es realmente sencilla: primero hay que asegurarseque está instalado el paquete RPM nss_ldap (que contiene los módulos LDAP para PAM yNSS) y posteriormente debemos ejecutar la herramienta authconfig (también puede invocar-se su versión en modo gráfico, system-config-authentication). En dicha herramienta hayque activar la recepción de información de cuentas y la autentificación de tipo LDAP, indi-cando en ambos casos la dirección del servidor y la base o sufijo LDAP. Internamente, estaherramienta modifica principalmente los siguientes ficheros:

• /etc/nsswitch.conf. Contiene la configuración del cliente NSS del sistema Linux. Ennuestro caso, hay que comprobar que las líneas que configuran de dónde hay que leer lainformación de usuarios, contraseñas shadow y grupos incluyan la opción ldap:

passwd: files ldapshadow: files ldapgroup: files ldap

• /etc/pam.d/system-auth. Contiene la configuración básica de autentificación del sis-tema Linux mediante PAM. La herramienta authconfig configura automáticamente loscuatro tipos de módulos (auth, account, password, y session) para que utilicenLDAP como alternativa:



auth required /lib/security/$ISA/pam_env.soauth sufficient /lib/security/$ISA/pam_unix.so likeauth nullokauth sufficient /lib/security/$ISA/pam_ldap.so use_first_passauth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.soaccount [default=bad success=ok user_unknown=ignore service_err=ignoresystem_err=ignore] /lib/security/$ISA/pam_ldap.so

password required /lib/security/$ISA/pam_cracklib.so retry=3 type=password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtokmd5 shadowpassword sufficient /lib/security/$ISA/pam_ldap.so use_authtokpassword required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.sosession required /lib/security/$ISA/pam_unix.sosession optional /lib/security/$ISA/pam_ldap.so

• /etc/ldap.conf. Contiene la configuración de las bibliotecas NSS y PAM cuando seutilizan contra un servidor LDAP. Si el servidor en cuestión es OpenLDAP, el fichero yaestá preparado para interpretar adecuadamente los atributos LDAP de los objetos "usua-rio" y "grupo" del directorio como los atributos UNIX necesarios (UID, GID, contraseña,etc.), con lo que no es necesaria ninguna modificación de posterior.

5.3.2.2. Linux como cliente del Directorio Activo

Si el servicio LDAP contra el que el sistema Linux debe actuar es un Directorio Activo deWindows Server 2003, la configuración es similar a la explicada en la sección anterior, aun-que existen un par de salvedades importantes que hay que considerar: en primer lugar, el fi-chero /etc/ldap.conf no es el adecuado y resulta necesario modificar su configuración, yen segundo el Directorio Activo no permite por defecto las consultas anónimas (que hacenlos clientes LDAP Linux normalmente). A continuación se expone cómo solucionar ambosproblemas. Por último, al final de la sección, se incluye un apartado donde se comenta lasdos posibilidades de configurar el cliente de autenticación en el sistema Linux (bibliotecaPAM): LDAP y Kerberos.

Tras la ejecución de la herramienta authconfig (igual que en la sección anterior), es nece-sario modificar manualmente el fichero /etc/ldap.conf, ya que no está preparado para in-terpretar correctamente los atributos de los objetos del directorio como los atributos UNIXque necesitan NSS y PAM. En particular, debemos asegurarnos que el fichero incluye las si-guientes líneas (suponiendo que el dominio Windows en cuestión se denomina "ad-mon.lab"):

# Your LDAP server.host 158.42.170.14

# The distinguished name of the search base.base dc=admon,dc=lab

# The distinguished name to bind to the server with.# Optional: default is to bind anonymously.binddn cn=linux,ou=special-users,dc=admon,dc=lab



# The credentials to bind with.# Optional: default is no credential.bindpw -Admon-

# Base searchnss_base_passwd dc=admon,dc=lab?subnss_base_shadow dc=admon,dc=lab?subnss_base_group dc=admon,dc=lab?sub

# Services for UNIX 3.5 mappingsnss_map_objectclass posixAccount Usernss_map_objectclass shadowAccount Usernss_map_objectclass posixGroup Groupnss_map_attribute uid sAMAccountNamenss_map_attribute uidNumber uidNumbernss_map_attribute gidNumber gidNumbernss_map_attribute loginShell loginShellnss_map_attribute uniqueMember membernss_map_attribute homeDirectory unixHomeDirectory

# pam configurationpam_login_attribute msSFU30Namepam_filter objectclass=Userssl nopam_password md5

En el fichero anterior, las líneas nss_base_* especifican en qué contenedores se ubicanlas cuentas de usuario y grupo, mientras que las líneas nss_map_* asocian adecuadamentelos atributos de las cuentas de usuario y grupo a sus correspondientes del Directorio Activo.Finalmente, las líneas que comienzan por pam_* configuran PAM para que sea compatiblecon dicho servicio de directorio.

Para comprobar que efectivamente la asociación entre los atributos de los objetos del Di-rectorio Activo y los atributos UNIX correspondientes es la adecuada, a continuación semuestran los atributos del usuario del Directorio Activo "andres", correspondientes al usua-rio de la figura Figura 5.1, “Pestaña de atributos UNIX en Usuarios y Equipos de Active Di-rectory.”.

# andres, Desarrollo, admon.labdn: CN=andres,OU=Desarrollo,DC=admon,DC=labobjectClass: topobjectClass: personobjectClass: organizationalPersonobjectClass: usercn: andresgivenName: andresdistinguishedName: CN=andres,OU=Desarrollo,DC=admon,DC=labinstanceType: 4whenCreated: 20070531144519.0ZwhenChanged: 20070601104631.0ZdisplayName: andresuSNCreated: 16398memberOf: CN=proy1,OU=Desarrollo,DC=admon,DC=labmemberOf: CN=g-andres,OU=Desarrollo,DC=admon,DC=labuSNChanged: 28711name: andresobjectGUID:: GwlsqoY+Ykm5wZZFVtIKew==userAccountControl: 512badPwdCount: 0codePage: 0countryCode: 0badPasswordTime: 128251773380156250



lastLogoff: 0lastLogon: 128251789138750000pwdLastSet: 128250963195312500primaryGroupID: 513objectSid:: AQUAAAAAAAUVAAAAHCoq2isuNW66PFYOUgQAAA==accountExpires: 9223372036854775807logonCount: 8sAMAccountName: andressAMAccountType: 805306368userPrincipalName: [email protected]: CN=Person,CN=Schema,CN=Configuration,DC=admon,DC=labdSCorePropagationData: 20070531144632.0ZdSCorePropagationData: 20070531144632.0ZdSCorePropagationData: 20070531144632.0ZdSCorePropagationData: 16010108151056.0Zuid: andresmsSFU30Name: andresmsSFU30NisDomain: admonuidNumber: 10000gidNumber: 10000unixHomeDirectory: /home/andresloginShell: /bin/bash

Por otro lado, existe un ligero problema relativo a la exploración anónima del directorioque debemos resolver: por defecto, el Directorio Activo no permite realizar búsquedas anó-nimas (de usuarios no autentificados) en la base de datos del directorio. Como la bibliotecaNSS de Linux realiza ese tipo de búsquedas, esto puede ocasionar algunos problemas a lahora de visualizar los nombres de usuarios y grupos (por ejemplo, en el prompt del intérpretede órdenes o al realizar un ls -l). Para solucionarlo tenemos dos alternativas: configurar elDirectorio Activo para que permita las consultas anónimas o configurar el cliente LDAP deLinux para que haga todas las consultas como un usuario conocido por el dominio Windows(ya que por defecto, el grupo Usuarios Autentificados tiene permisos de lectura en to-do el directorio).

Ambas alternativas tienen sus problemas de seguridad. En el primer caso, admitir consul-tas anónimas en el Directorio Activo no es buena idea si el DC es accesible por red desde elexterior de la organización, puesto que el contenido del directorio quedaría público a todo elmundo. En el segundo caso, el usuario como el que se realizarían las consultas desde elcliente Linux debe tener sus credenciales (usuario y contraseña) en texto claro (sin cifrar) enel fichero /etc/ldap.conf, que posee permisos de lectura para cualquier usuario conecta-do localmente al sistema Linux.

Quizás la opción menos comprometida sería la segunda, pero utilizando además unusuario especial que sólo sirviera para ese fin, y cuya funcionalidad en los sistemas Linux/Windows del dominio estuviera restringida. Para ello es necesario crear un usuario en el Di-rectorio Activo (no hace falta activar sus atributos UNIX) y especificar dicho usuario y sucontraseña en el fichero /etc/ldap.conf, en las líneas binddn y bindpw, respectivamen-te. En el ejemplo de arriba, se ha utilizado un usuario denomindo "linux" (dentro de la uni-dad organizativa "special-users") cuya contraseña es "-Admon-".

Posteriormente, podemos restringir las acciones que dicho usuario pueda realizar en lossistemas Windows del dominio (mediante directivas de seguridad o GPOs) y en los sistemasLinux, especificando el fichero /bin/false como shell en sus atributos UNIX.



5.3.2.2.1. Autenticación LDAP vs. Kerberos

En la configuración de Linux como cliente de un dominio Windows descrita arriba, el siste-ma Linux se configura como cliente de cuentas (bibilioteca NSS) y de autenticación(biblioteca PAM) de los controladores del dominio a través del protocolo LDAP. Sin embar-go, la forma nativa en que los sistemas Windows pertenecientes a un dominio realizan la au-tenticación es mediante el protocolo Kerberos. En el dominio, los DCs son servidores de Ker-beros y todos los miembros de dicho dominio autentican los inicios de sesión utilizando di-cho protocolo.

En los sistemas Linux, es posible configurar la biblioteca PAM para que utilice Kerberos yrealice la autenticación de usuarios mediante este protocolo en los inicios de sesión. Paraello, se puede utilizar la misma herramienta de configuración descrita arriba (system-con-fig-authentication), pero en la pestaña de autenticación debe seleccionarse la habilitación delprotocolo Kerberos en lugar de LDAP. La configuración de Kerberos tiene básicamente tresapartados: el entorno o realm, el servidor KDC (Kerberos Distribution Center) y el servidor deadministración. En el primer caso, debe teclearse el nombre completo (DNS) del dominioWindows pero en mayúsculas, y en los otros dos casos, el nombre completo o la dirección IPde uno de los servidores (DCs) del dominio. La Figura 5.2, “Configuración de la autentica-ción Kerberos en Linux.” muestra cómo realizar esta configuración para el dominio Win-dows "admon.lab".

Figura 5.2. Configuración de la autenticación Kerberos en Linux.

La configuración de la biblioteca PAM a través de Kerberos respecto a LDAP tiene dosventajas fundamentales: en primer lugar, el cliente Linux se comporta exactamente igual queun sistema Windows miembro del dominio respecto a la autenticación. Y en segundo lugar,



no resulta necesario configurar ningún mecanismo especial en el sistema Linux para encrip-tar las comunicaciones (mediante certificados), ya que el propio protocolo Kerberos garanti-za la confidencialidad en la manipulación de las contraseñas utilizadas en la autenticación.

5.4. Integración de clientes Linux mediante WinbindHasta ahora hemos visto las posibilidades y características que ofrece un software como SFUpara conseguir que diferentes clientes linux se integren en un dominio Windows. El métodoempleado no es en sí complicado pero requiere de una serie de conocimientos por parte deladministrador. Este ha sido capaz de alterar el esquema del Directorio Activo para que so-porte todas las características necesarias para que los clientes Linux se autentifiquen en undominio Windows.

En esta sección se plantea una alternativa de integración que no requiere modificar nin-gún aspecto del Directorio Activo. Se trata de un servicio incluido en la suite Samba, deno-minado winbind, y que permite solventar el problema de la autenticación unificada.

Winbind utiliza una implementación UNIX de las llamadas RPC de Microsoft, PAM(Pluggable Authentication Modules) y NSS (Name Service Switch) para permitir que losusuarios de un dominio Windows se muestren y actúen como usuarios Linux en sistemas Li-nux.

Winbind proporciona tres funciones independientes:

• Autenticación de las credenciales de usuario vía PAM. Esta funcionalidad permite auten-tificar usuarios Windows, almacenados en el Directorio Activo, desde el sistema Linuxcliente (de forma idéntica a cómo se describía en la Sección 5.3.2.2, “Linux como clientedel Directorio Activo”).

• Resolución de nombres de usuario y grupo via NSS. Esta funcionalidad permite al siste-ma Linux utilizar de forma natural su biblioteca NSS para resolver nombres de usuario yde grupo contra el Directorio Activo

• Asociación dinámica entre SIDs de Windows y UID/GIDs de Linux. Por defecto, Winbindmantiene una base de datos local denominada winbind_idmap.tdb, en la que se almacenanlas asociaciones entre los UIDs y GIDs de Linux y los SIDs de Windows. En particular,cuando un usuario no tiene un UID/GID local (es decir, cuando es un usuario almacena-do en el Directorio Activo), Winbind genera automáticamente un nuevo UID/GID paraeste usuario, y almacena la asociación entre esos atributos UNIX y el SID del usuario enesta base de datos. Así, siempre que el usuario inicie sesión en el futuro en el sistema Li-nux, Winbind le asignará el mismo UID/GID (ya que el SID siempre es único), mante-niendo la consistencia en el acceso al sistema de archivos. Como alternativa a este alma-cenamiento local, winbind puede también recuperar esta información de un repositoriode base de datos mediante la opción idmap backend. De esta manera, las asociaciones sepueden guardar de múltiples formas alternativas (en un servidor LDAP, en un ficheroXML, etc.)

5.4. Integración de clientes Linux mediante Winbind


El funcionamiento de Winbind le permite unificar la administración de cuentas UNIX yWindows al permitir a un sistema Linux ser un miembro completo de un dominio Windows.Una vez dado este paso, el sistema Linux reconocerá a los usuarios Windows como si fueranusuarios Linux nativos, de la misma manera que se utiliza NIS o LDAP en un entorno pura-mente Linux, gracias a que Winbind se enlaza con la biblioteca de resolución de nombres(NSS) del sistema Linux. El resultado final es que cualquier programa de Linux que pregun-te al sistema operativo por un nombre de usuario o grupo, este le preguntará al controladorde dominio Windows. La única característica especial a considerar cuando se utiliza Win-bind como método de resolución de usuarios y grupos es que los nombres de usuarios y gru-pos vienen precedidos por el nombre del dominio Windows al que pertenecen: DO-MAIN\user. Esto es necesario, ya que permite a Winbind determinar qué controlador de do-minio tiene que utilizar para resolver el nombre de usuario o grupo en un entrono de reddonde existen relaciones de confianza entre diferentes dominios. Además, Winbind propor-ciona un servicio de autenticación via PAM que proporciona la autenticación contra un do-minio Windows de cualquier aplicación del sistema compatible con PAM .

Figura 5.3. Configuración de la autenticación Kerberos en Linux.

En distribuciones basadas en RedHat (como CentOS), la configuración del sistema Linuxcomo cliente del Directorio Activo mediante Winbind puede realizarse casi por completomediante la herramienta gráfica de configuración de la autenticación (authconfig), tal comomuestra la Figura 5.3, “Configuración de la autenticación Kerberos en Linux.”. Alternativa-mente, se puede configurar siguiendo los pasos siguientes:



1. Configuración del fichero /etc/samba/smb.conf.

Se necesita añadir varios parámetros al fichero smb.conf para controlar el comporta-miento del servicio que implementa winbind (winbindd). El fichero de configuraciónque se muestra a continuación incluye las entradas necesarias en la sección [global].

[global]# separate domain and username with '\', like DOMAIN\usernamewinbind separator = \# use uids from 10000 to 20000 for domain usersidmap uid = 10000-20000# use gids from 10000 to 20000 for domain groupsidmap gid = 10000-20000# allow enumeration of winbind users and groupswinbind enum users = yeswinbind enum groups = yes# give winbind users a real shelltemplate homedir = /home/winnt/%D/%Utemplate shell = /bin/bash

2. Unir el cliente Linux al dominio Windows.

Todas las máquinas que desean participar en un dominio de seguridad necesitan sermiembros del dominio, incluidos los controladores de dominio (DCs). Para lograr esteobjetivo en un cliente Linux, tenemos que utilizar el comando net.

root# net rpc join -S PDC -U Administrador

Este comando permite comunicar con un controlador de dominio via llamadas RPC,para ello es necesario que el servicio smbd este corriendo. La respuesta sera "Joined thedomain DOMAIN"

3. Ejecutar el servicio winbindd.

Winbind es un demonio (servicio) independiente de la suite SAMBA (smbd, nmbd). Elcomando que lo implementa se denomina winbindd. Para lanzarlo, teclearíamos en lashell lo siguiente:

root# /usr/sbin/winbindd

Para comprobar que dicho servicio resuelve los usuarios y grupos del dominio, po-demos emplear la utilidad wbinfo.

root# wbinfo -uCEO\AdministratorCEO\burdellCEO\GuestCEO\jt-adCEO\krbtgtCEO\TsInternetUser

root# wbinfo -gCEO\Domain AdminsCEO\Domain UsersCEO\Domain GuestsCEO\Domain ComputersCEO\Domain Controllers



CEO\Cert PublishersCEO\Schema AdminsCEO\Enterprise AdminsCEO\Group Policy Creator Owners

4. Configuración de la resolución de nombres (NSS).

Una vez estamos seguros que el servicio winbind resuelve los nombres de usuarios ygrupos, hay que conseguir que cualquier aplicación del sistema sea capaz de resolverlostambien. En un sistema Linux se utiliza la libreria NSS para resolver el nombre de los di-ferentes objetos del sistema. El fichero de configuración que nos permite definir lasfuentes de datos de NSS es /etc/nsswitch.conf.

passwd: files winbindshadow: files winbindgroup: files winbind

Una vez salvado el fichero comprobaremos que el sitema resuelve los mismos usua-rios y grupos que resuelve winbind.

root# getent passwdCEO\burdell:15000:15003:Mary Orville:/home/winnt/CEO/burdell:/bin/bash

5. Configuración de la autenticación (PAM).

La libreria PAM utiliza una interfaz de modulos apilables que permiten cambiar sucomportamiento y definir las fuentes de información de autenticación. En un sistemaCentOS Linux, el funcionamiento de la libreria PAM se centraliza en un único ficherodenominado /etc/pam.d/system-auth.

#%PAM-1.0# This file is auto-generated.# User changes will be destroyed the next time authconfig is run.auth required /lib/security/$ISA/pam_env.soauth sufficient /lib/security/$ISA/pam_unix.so likeauth nullokauth sufficient /lib/security/$ISA/pam_winbind.so use_first_passauth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so broken_shadowaccount sufficient /lib/security/$ISA/pam_succeed_if.so uid < 100quietaccount [default=bad success=ok user_unknown=ignore] /lib/security/$ISA/pam_winbind.soaccount required /lib/security/$ISA/pam_permit.so

password requisite /lib/security/$ISA/pam_cracklib.so retry=3password sufficient /lib/security/$ISA/pam_unix.so nullokuse_authtok md5 shadowpassword sufficient /lib/security/$ISA/pam_winbind.so use_authtokpassword required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.sosession required /lib/security/$ISA/pam_unix.so

Tras esta configuración básica de Winbind, debemos prestar especial atención a la formaparticular en la que se realiza asociacion de identificadores de usuario Windows (SIDs) a



identificadores de usuarios Linux (UIDs/GIDs), que Winbind denomina identity mapping. Co-mo se ha explicado anteriormente, Winbind dispone de varios mecanismos alternativos pararealizar el almacenamiento de esas asociaciones. En este sentido, si existen varios sistemasLinux que utilicen Winbind, un mismo usuario podría recibir UIDs/GIDs diferente en cadasistema, lo cual puede ocasionar problemas si entre dichos sistemas Linux utilizan aplicacio-nes que confían en la unicidad de UIDs/GIDs, como el protocolo NFS, por ejemplo. Este pro-blema puede resolverse mediante dos configuraciones de identity mapping: almacenar las aso-ciaciones en una base de datos única compartida por todos los sistemas Linux (normalmente,un servidor de tipo LDAP), o bien utilizar una asociación algorítmica, que dado un SID deun usuario o grupo Windows, calcule siempre el mismo UID o GID.

Esta última alternativa se denomina IDMAP_RID, y en realidad lo que permite es que lossistemas Linux cliente generen el mismo UID/GID para un mismo RID, es decir, para la par-te del SID que es única dentro de cada dominio. Por este motivo, IDMAP_RID no funcionacorrectamente cuando hay varios dominios relacionados (por ejemplo, en un bosque), ya queel algoritmo de asignación asignaría el mismo UID/GID a dos usuarios de dominios diferen-tes que tuvieran el mismo RID (aunque obviamente su SID sería distinto). Un ejemplo con-creto de configuración con esta opción se muestra a continuación.

[global]workgroup = ADMONrealm = ADMON.LABsecurity = ADSallow trusted domains = Noidmap backend = rid:ADMON=500-100000000idmap uid = 500-100000000idmap gid = 500-100000000template shell = /bin/bashwinbind use default domain = Yeswinbind enum users = Nowinbind enum groups = Nowinbind nested groups = Yes

5.5. Directorios home centralizadosEn un dominio Linux puro, es habitual centralizar los directorios de conexión (home) de losusuarios en uno de los sistemas del dominio, y compartirlo al resto de sistemas mediante elsistema de archivos en red NFS (ver Capítulo 3, Sistema de Archivos en Red (NFS)). De estaforma, los ficheros de cada usuario se mantienen centralizados y el usuario trabaja siemprecon los mismos datos, independientemente del ordenador en que esté trabajando.

En el caso de un domino heterogéneo de sistemas Linux y Windows, existen numerosasalternativas para conseguir que los usuarios tengan disponibles sus datos de forma centrali-zada: exportar los directorios personales a través de SMB o de NFS, y en ambos casos, expor-tarlos desde un sistema Windows o Linux. En esta sección vamos a comentar estas alternati-vas (aunque algunas con mayor nivel de detalle que otras, por ser su configuración menosautomática).

La primera alternativa sería que los directorios home residieran físicamente en un sistemaLinux, que puede ser cliente de autentificación del dominio Windows, tal como se ha conta-

5.5. Directorios home centralizados


do en este capítulo. En este caso, es necesario crear manualmente los directorios y asignarleslos atributos de protección adecuados (propietario, grupo y permisos). Si lo hacemos así, laconfiguración más fácil es exportar dichos directorios mediante NFS para los demás sistemasLinux, y mediante Samba para que se conviertan en recursos directamente accesibles desdesistemas Windows. En ambos casos (NFS para Linux y SMB para Windows) las configura-ciones pueden automatizarse completamente (en el caso de Windows, mediante scripts deinicio de sesión) para que no necesiten ninguna intervención del usuario. Ambas configura-ciones han sido comentadas respectivamente en el Capítulo 1, Administración de dominiosWindows 2003 y Capítulo 2, Administración de dominios en Linux, respectivamente.

La segunda alternativa sería que los directorios home residieran físicamente en un sistemaWindows miembro del dominio (que puede ser alguno de los DCs, o bien cualquier otromiembro). En este caso, obviamente los directorios se exportarían como recursos SMB parael resto de sistemas Windows del dominio, que podrían acceder al mismo mediante una co-nexión a la unidad de red correspondiente. Respecto a los sistemas Linux que deben serclientes de estos recursos, puede optarse por hacerlo mediante NFS o mediante el propioprotocolo SMB. En el primer caso, es necesario utilizar una suite existente en Windows Ser-ver denominada "Windows Services for UNIX", que incluye entre otros servicios un servidorde NFS. En el segundo caso, es necesario que los clientes Linux sean configurados para ad-mitir como directorios de trabajo de los usuarios los correspondientes recursos de red expor-tados directamente por SMB. El resto de la sección trata de explicar cómo puede hacerse estaconfiguración. En concreto, se comenta primero las configuraciones a realizar en el sistemaWindows que alojará los directorios de los usuarios, y posteriormente se introducen dos al-ternativas para realizar el montaje desde los sistemas Linux: la utilización conjunta depam_mkhomedir y pam_mount y la utilización de pam_script.

Lo primero que hay que configurar es el propio recuro compartido SMB, que puede ex-portar cualquier sistema Windows del dominio o cualquier sistema Linux con Samba correc-tamente configurado. Lo más sencillo resulta exportar un directorio o carpeta por cada usua-rio como un recurso de red que debe denominarse como el propio usuario. Si decidimos uti-lizar para ello un sistema Linux con Samba, sólo debemos activar el recurso denominadohomes. Si lo realizamos desde un sistema Windows, debemos crear y compartir una carpetapersonal por usuario (esta acción puede automatizarse mediante el uso de la pestaña Per-fil del usuario en la herramienta Usuarios y Equipos de Active Directory). Si lo hace-mos así, la conexión de dicho recurso como unidad de red del usuario en cualquier sistemaWindows del dominio ya está resuelto.

5.5.1. Uso de pam_mkhomedir y pam_mount

En el caso de los clientes Linux, puesto que el directorio personal de cada usuario va a resi-dir en un recurso SMB, necesitamos montar dicho recurso mediante el sistema de archivoscifs (ver Sección 4.7, “El sistema de ficheros CIFS para Linux”). En principio, el montaje de-bería hacerse en la ruta de su directorio home según los datos de su cuenta de usuario (estaruta es, habitualmente, /home/nombre_de_usuario). Sin embargo, en el caso de un mon-taje de tipo SMB, esta opción plantea algunos inconvenientes relacionados con los ficheros/directorios de configuración del entorno gráfico que se guardan en el directorio de conexiónde cada usuario. Por tanto, se ha optado por una alternativa un poco distinta: crear el homedel usuario como un directorio local en cada sistema Linux y montar automáticamente su



unidad de red personal Windows en un subdirectorio particular (denominado, por ejemplo,/home/nombre_de_usuario/Personal).

Entre otros motivos, hemos elegido esta alternativa porque puede automatizarse comple-tamente, sin requerir por parte del administrador la creación de los directorios de conexiónlocales en cada sistemas Linux ni el montaje de los recursos SMB de forma manual. Para ellopueden utilizarse dos extensiones de la biblioteca PAM, que se explican a continuación:

A. pam_mkhomedir. Mediante esta extensión (que no es necesario instalar, sino sólo acti-var), si el directorio de conexión de un usuario no existe en el sistema, éste se crea auto-máticamente cuando el usuario inicia sesión por primera vez.

La configuración de esta biblioteca es muy sencilla. Basta añadir la siguiente línea enla sección session del fichero /etc/pam.d/system-auth:

session required /lib/security/$ISA/pam_mkhomedir.so \skel=/etc/skel/ umask=0022

B. pam_mount. Esta extensión viene como un paquete instalable (en formato RPM) con elmismo nombre. Una vez instalado, la configuración se lleva a cabo en dos ficheros: unopara establecer los parámetros del montaje (servidor, recurso, directorio local, etc.), yotro para instruir a PAM sobre cuándo realizar el montaje (cuándo ejecutarpam_mount). A continuación se explican los cambios concretos en ambos ficheros:

En primer lugar, en el fichero /etc/security/pam_mount.conf basta añadir unalínea al final, tomando como plantilla una existente que especifica cómo realizar monta-jes de recursos exportados por sistemas Windows Server 2003 pertenecientes a un domi-nio. Suponiendo que el dominio Windows se denomina ADMON y que el ordendor SER-VIDOR exporta la carpeta personal de cada usuario como un recurso con el nombre deese usuario, la línea quedaría así:

volume * smb SERVIDOR & /home/&/Personal uid=&,gid=&,dmask=0750, \workgroup=ADMON - -

Y en segundo lugar, el fichero /etc/pam.d/system-auth necesita incluir dos lí-neas, una de tipo auth y otra de tipo session incluyendo las llamadas al módulopam_mount. La ubicación de ambas líneas entre las de su tipo es significativa para elcorrecto funcionamiento del módulo. Con todas las modificaciones realizadas, la confi-guración final del fichero system-auth sería:

#%PAM-1.0

auth required /lib/security/$ISA/pam_env.soauth sufficient /lib/security/$ISA/pam_unix.so likeauth nullokauth required /lib/security/$ISA/pam_mount.soauth sufficient /lib/security/$ISA/pam_ldap.so use_first_passauth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.soaccount [default=bad success=ok user_unknown=ignore \service_err=ignore system_err=ignore] /lib/security/$ISA/pam_ldap.so



password required /lib/security/$ISA/pam_cracklib.so retry=3 \type=password sufficient /lib/security/$ISA/pam_unix.so nullok \use_authtok md5 shadowpassword sufficient /lib/security/$ISA/pam_ldap.so use_authtokpassword required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.sosession required /lib/security/$ISA/pam_unix.sosession required /lib/security/$ISA/pam_mkhomedir.so \skel=/etc/skel/ umask=0022session optional /lib/security/$ISA/pam_mount.sosession optional /lib/security/$ISA/pam_ldap.so

De esta forma, la primera vez que un usuario se conecta al sistema Linux, primero se creasu directorio de conexión y posteriormente se monta en un subdirectorio denominado Per-sonal el recurso SMB que contiene su carpeta Windows de uso personal. Cuando el usuariose desconecta del sistema, el directorio permanece, aunque el recurso se desmonta auotmáti-camente.

Por último, debemos tener en cuenta que el uso de estas extensiones de PAM (en especial,pam_mkhomedir) tiene algunos efectos secundarios que debemos considerar:

• Si pensamos permitir el acceso al sistema Linux de forma remota mediante ssh, tenemosque modificar ligeramente la configuración del demonio sshd, debido a una inconsistenciaentre la implementación de este servicio y pam_mkhomedir. Para resolverlo, debemosdescomentar una línea del fichero /etc/ssh/sshd_config (se encuentra casi al final)y configurarla como sigue:

UsePrivilegeSeparation no

• Debido a otra inconsistencia entre pam_mkhomedir y la orden su, esta orden no funcio-nará bien cuando intentemos cambiar de usuario a uno que no tenga aún creado su direc-torio de conexión (es decir, cuando interviene pam_mkhomedir). La causa está en que elUID efectivo del proceso que crea el directorio del usuario no es el de root, y por tantono tiene permisos para crear el directorio en /home/. Este problema puede solucionarseúnicamente mediante permisos de escritura a todos los usuarios en /home/, cosa muypoco sensata en cualquier caso. Por tanto, si ese es el efecto que observa en su sistema Li-nux, no podrá utilizar su - usuario para usuarios que no tengan directorio home ya crea-do.

5.5.2. Uso de pam_script

Como alternativa al uso combinado de las bibliotecas de PAM pam_mkhomedir ypam_mount vistas arriba, esta sección explica otra de estas bibliotecas denominadapam_script, que permite la ejecución de scripts cada vez que un usuario inicia o abandonauna sesión en el sistema Linux. Puesto que los scripts pueden ser libremente escritos por el



administrador, esta opción permite un máximo nivel de flexibilidad en la configuración delentorno de trabajo inicial del usuario, así como de las acciones automáticas que deben ejecu-tarse cuando el usuario finaliza su sesión.

La biblioteca pam_script permite la ejecución automática de un script en tres momentosdiferentes durante el proceso de inicio/fin de sesión de un usuario en el servicio de PAM quese desee (login, ssh, gdm, kdm, etc.):

1. Autenticación. Si dentro del fichero de configuración del servicio PAM establecemos es-te módulo en la sección auth, cada vez que un usuario se autentifique utilizando dichomódulo se ejecutará un script, cuya ubicación por defecto es /etc/security/onauth.

2. Inicio de sesión. Si dentro del fichero de configuración del servicio PAM establecemoseste módulo en la sección session, cada vez que un usuario inicie una sesión utilizan-do dicho módulo se ejecutará un script, cuya ubicación por defecto es /etc/security/onsessionopen.

3. Fin de sesión. Si dentro del fichero de configuración del servicio PAM establecemos estemódulo en la sección session, cada vez que un usuario cierre una sesión utilizando di-cho módulo se ejecutará un script, cuya ubicación por defecto es /etc/security/onsessionclose.

A modo de ejemplo, a continuación se muestra cómo debería quedar el fichero de confi-guración PAM del servicio gdm (pantalla de inicio en modo gráfico del gestor de ventanasGnome) para poder utilizar pam_script en los tres casos descritos arriba. Se ha elegido unservicio específico como gdm en lugar de system-auth porque éste último es invocado desdetodos los servicios que permiten conectarse al sistema (login, gdm, ssh, ftp, etc.) y de estamanera ilustramos que es posible asociar script de inicio con sólo alguna(s) forma(s) de ini-ciar sesión en el sistema. El fichero de configuración de este servicio se denomina /etc/pam.d/gdm, y quedaría así:

#%PAM-1.0auth required pam_env.soauth required pam_stack.so service=system-authauth required pam_script.so expose=1 runas=rootauth required pam_nologin.so

account required pam_stack.so service=system-authpassword required pam_stack.so service=system-authsession required pam_stack.so service=system-authsession required pam_script.so expose=1 runas=rootsession optional pam_console.so

En principio, los scripts se ejecutan con los atributos de protección del usuario implicado,aunque se puede estableer que se ejecuten en el contexto de protección de otro usuario, me-diante la opción runas=usuario. En el caso de gdm de arriba, los tres scripts se ejecutaráncomo root.

Por otro lado, los scripts siempre reciben dos parámetros como argumentos: el primer ar-gumento es el nombre del usuario implicado en la autenticación/sesión, y el segundo argu-mento es el nombre del servicio para el que se está ejecutando el módulo PAM. Además,



existe una variable de entorno denominada PAM_AUTHTOK que contiene la contraseña de di-cho usuario. Esto puede ser útil, por ejemplo, para realizar montajes de recursos SMB, querequieren de dicha contraseña. El valor de retorno del script es significativo: un valor igual acero se entiende como éxito mientras que un valor diferente se supone fallido. Si el móduloPAM es requerido, un módulo que falle supone que el proceso de autenticación o inicio desesión falla para el usuario. Por tanto, también se puede utilizar el script para realizar com-probaciones de cualquier tipo que permitan o impidan al usuario entrar al sistema.

A modo de ejemplo, a continuación se muestra un script simple, vinculado al módulo deautenticación (/etc/security/onauth), que crearía el directorio del usuario en el caso deque no existiera, y posteriormente montaría su directorio personal Windows dentro de dichodirectorio. Este script, por tanto, realizaría las mismas acciones que los módulospam_mkhomedir y pam_mount comentados anteriormente:

USER=$1SERVICE=$2

if [ ! -d /home/$USER ]then

mkdir /home/$USER 2>/dev/nullfind /etc/skel -name ".*" -exec cp -r \{\} /home/$USER/ \;chown -R $USER.g-$USER /home/$USER 2>/dev/null

fi

if [ ! -d /home/$USER/Personal ]then

mkdir /home/$USER/Personal 2>/dev/nullchown $USER.g-$USER /home/$USER/Personal 2>/dev/null

fi

mount -t cifs //dc01/$USER /home/$USER/Personal -o user=$USER, \password=$PAM_AUTHTOK,workgroup=ADMON,uid=$USER,gid=g-$USER 2>/dev/null

exit 0

Para completar la configuración, debería implementarse también el script de cierre de se-sión /etc/security/onsessionclose para desmontar el recurso SMB del directorio delusuario.



6Integración de dominios

mediante servidoresLinux

Indice6.1. Introducción .................................................................................................. 876.2. Estructura del Servicio de Directorio ............................................................... 886.3. Instalación del software .................................................................................. 906.4. Configuración del servidor OpenLDAP ........................................................... 906.5. Configuración del cliente Linux ...................................................................... 936.6. Configuración del servidor Samba .................................................................. 946.7. Configuración del cliente Windows ................................................................. 976.8. Conclusiones ................................................................................................. 986.9. Comandos de referencia ................................................................................. 98

6.1. IntroducciónLa integración de sistemas es la pieza angular que debe afrontar un administrador de siste-mas. Cuando en una organización deben convivir diferentes sistemas operativos, el adminis-trador debe facilitar a los usuarios la forma de acceder a los recursos independientemente dela plataforma que estos decidan utilizar.

Unas credenciales únicas facilitarán al usuario el acceso a la red e implicará una mayorseguridad y control del funcionamiento de la misma. Esto conlleva la creación de un reposi-torio único donde se almacena la información de cada elemento de la red. Máquinas, usua-rios y servicios podrán ser fácilmente creados, modificados y eliminados si disponemos deun único punto de administración.

La implantación de un dominio de red que nos permita implementar los objetivos ante-riores, obliga a que el administrador tenga que escoger las herramientas software que seancapaces de llevar dicho reto a cabo. La elección del software condicionara el modelo de do-minio que se pueda ofrecer.

Desde el punto de vista de la administración de sistemas, suele denominarse dominio aun conjunto de equipos interconectados que comparten información administrativa(usuarios, grupos, contraseñas, etc.) centralizada. Ello requiere fundamentalmente la dispo-nibilidad de (al menos) un ordenador que almacene físicamente dicha información y que lacomunique al resto cuando sea necesario, típicamente mediante un esquema cliente-servi-dor. Por ejemplo, cuando un usuario desea iniciar una conexión interactiva en cualquiera delos ordenadores (clientes) del dominio, dicho ordenador deberá validar las credenciales delusuario en el servidor, y obtener de éste todos los datos necesarios para poder crear el con-texto inicial de trabajo para el usuario. En Windows 2000, la implementación del concepto dedominio se realiza mediante el denominado Directorio Activo, un servicio de directorio ba-sado en diferentes estándares como LDAP (Lightweight Directory Access Protocol}) y DNS(Domain Name System). En el mundo Linux, los dominios solían implementarse mediante elfamoso Network Information System (NIS), del que existían múltiples variantes. Sin embar-go, la integración de servicios de directorio en Linux ha posibilitado la incorporación de estatecnología, mucho más potente y escalable que NIS, en la implementación de dominios.

La elección está hecha y en este capítulo veremos la implantación de un dominio que decabida tanto a plataformas Linux como Microsoft Windows. Para implementar todos los ser-vicios que deben ofrecerse (DNS, DHCP, LDAP, SMB, HTTP, SMTP) se ha elegido el SistemaOperativo Linux, corriendo sobre diferentes paquetes de software libre (Bind, OpenLDAP,Samba, NFS, Apache).

La pareja OpenLDAP-Samba nos permitirá crear un dominio de red donde tanto losclientes Linux como Microsoft Windows podrán acceder y compartir información facilitandoal usuario la tarea de tener que buscar dicha información.

OpenLDAP es un software robusto, rápido y escalable, que no tiene nada que envidiar aotros servicios de directorio. Además su código es "libre" y altamente configurable a diferen-cia del Directorio Activo de Microsoft que es una implementación de un servidor LDAP pre-configurada para realizar una tarea determinada. El Directorio Activo viene con un conjunto

6.1. Introducción


de herramientas administrativas personalizadas para ejecutar aplicaciones Windows. Encambio, la complejidad de OpenLDAP será apreciada por aquellos administradores que de-seen construir un servicio de directorio personalizado.

Esa característica nos permitirá integrarlo con otra pieza de software de red llamada Sam-ba y que implementa a la perfección las funciones necesarias para que las máquinas con sis-tema operativo Microsoft Windows se sientan como en su casa, en su dominio.

La principal característica de Samba es ofrecer servicios de impresión y de ficheros aclientes Windows. Conocidos son los "benchmarks" realizados entre Servidores Windows2003 y servidores Samba. Pero Samba puede funcionar también como controlador de domi-nio para los clientes Windows, implementando todas las características de un dominio Win-dows NT.

Por tanto tenemos a nuestra disposición dos piezas de software libre que nos van a per-mitir implementar un dominio de seguridad que dé servicio tanto a clientes Linux(OpenLDAP, nss_ldap) como a clientes Windows (OpenLDAP, Samba).

6.2. Estructura del Servicio de DirectorioComo se puede leer en el capítulo dedicado a dominios Linux "En el contexto de las redes de or-denadores, se denomina directorio a una base de datos especializada que almacena información sobrelos recursos, u "objetos", presentes en la red (tales como usuarios, ordenadores, impresoras, etc.) y quepone dicha información a disposición de los usuarios de la red".

En esta sección vamos a definir la estructura (Unidades Organizativas y objetos) del di-rectorio que albergará la información de usuarios, máquinas y servicios que pretendemosofrecer.

La raíz del directorio será un objeto de clase dc que albergará a las diferentes UnidadesOrganizativas:

# dsic2, upv, esdn: dc=dsic2,dc=upv,dc=esobjectClass: dcObjectobjectClass: organizationo: dsic2,dc=upvdc: dsic2

La unidad organizativa encargada de almacenar la información de usuario se denomina-rá Users y su definición en formato LDIF es la siguiente:

# Users, dsic2, upv, esdn: ou=Users,dc=dsic2,dc=upv,dc=esobjectClass: organizationalUnitou: Users

La unidad organizativa encargada de almacenar la información de grupos se denominaráGroups y su definición en formato LDIF es la siguiente:

# Groups, dsic2, upv, es

6.2. Estructura del Servicio de Directorio


dn: ou=Groups,dc=dsic2,dc=upv,dc=esobjectClass: organizationalUnitou: Groups

La unidad organizativa encargada de almacenar la información de máquinas se denomi-nará Computers y su definición en formato LDIF es la siguiente:

# Computers, dsic2, upv, esdn: ou=Computers,dc=dsic2,dc=upv,dc=esobjectClass: organizationalUnitou: Computers

Un objeto de tipo usuario tendrá la siguiente definición en el Servicio de Directorio:

# usu1, Users, dsic2, upv, esdn: uid=usu1,ou=Users,dc=dsic2,dc=upv,dc=esobjectClass: topobjectClass: inetOrgPersonobjectClass: posixAccountobjectClass: shadowAccountobjectClass: sambaSAMAccountcn: usu1sn: usu1uid: usu1uidNumber: 1000gidNumber: 513homeDirectory: /home/usu1loginShell: /bin/bashgecos: System Userdescription: System UsersambaLogonTime: 0sambaLogoffTime: 2147483647sambaKickoffTime: 2147483647sambaPwdCanChange: 0displayName: System UsersambaSID: S-1-5-21-2758841116-2178560935-410125937-3000sambaPrimaryGroupSID: S-1-5-21-2758841116-2178560935-410125937-513sambaHomeDrive: H:sambaAcctFlags: [U]sambaPwdLastSet: 1099149278sambaPwdMustChange: 1103901278

Como se puede apreciar este tipo de objeto hereda propiedades de varias clases. La claseposixAccount que define los atributos correspondientes a una cuenta de usuario Linux, laclase sambaSAMAccount que define los atributos correspondientes a una cuenta de usuarioWindows.

En cambio para definir un objeto tipo grupo se utilizará la siguiente entrada de directorio:

# RRHH, Groups, dsic2, upv, esdn: cn=RRHH,ou=Groups,dc=dsic2,dc=upv,dc=esobjectClass: posixGroupobjectClass: sambaGroupMappingcn: RRHHgidNumber: 1000sambaSID: S-1-5-21-2758841116-2178560935-410125937-3001sambaGroupType: 2displayName: RRHH

La definición de un grupo hereda las propiedades de dos clases: posixGroup, samba-GroupMapping. Estas clases proporcionaran la información necesaria a los equipos Linux y

6.2. Estructura del Servicio de Directorio


Windows.

6.3. Instalación del softwareEl software de servidor OpenLDAP puede ser bajado libremente de la web oficial de OpenL-DAP [http://www.openldap.org]; en el momento de escribir estas líneas la versión oficial es-table es la 2.4.7, pero en este curso seguiremos utilizando los paquetes que vienen por defec-to con la distribución CentOS.

Para instalar el software utilizaremos la herramienta yum que es el administrador de pa-quetes por defecto utilizado en CentOS.

# yum install openldap-servers

Esto instalará el servidor LDAP y todas sus dependencias.

El software servidor de Samba también es libre y su última versión estable (3.0.28) puedeser encontrada en la web de Samba [www.samba.org]. En este documento se utilizará el pa-quete precompilado que distribuye CentOS Linux. De nuevo, para instalar el software utili-zaremos yum:

# yum install samba

Para poder administrar o interactuar con el servicio de directorio y con el servidor Sambanecesitamos alguna herramienta de fácil utilización que nos permita crear y modificar obje-tos en el directorio. En este curso se han elegido las utilidades de IDEALX denominadassmbldap-tools. Estas utilidades se pueden bajar de la siguiente dirección:https://gna.org/projects/smbldap-tools/

Estas utilidades son scripts en perl que dependen a su vez de algunos módulos perl:perl(Net::Ldap), perl(Crypt::SmbHash).

Al final del capítulo se puede encontrar una referencia a todos estos comandos.

6.4. Configuración del servidor OpenLDAPNecesitamos configurar el servidor OpenLDAP para que actue como una base de datosSAM. Por tanto, para conseguir dicho objetivo, debemos de hacer posible que:

• OpenLDAP acepte la modificación al esquema de Samba.

• el servidor LDAP ejecute como base dc=admon.com

• se añadan las entradas mínimas para empezar a usarlo.

Para conseguir los objetivos anteriores, definiremos la estructura del directorio según el

6.3. Instalación del software


http://www.openldap.org

http://www.openldap.org

www.samba.org

https://gna.org/projects/smbldap-tools/

siguiente DIT (LDAP Directory Information Tree).

dc=admon, dc=com|---- ou = Users : cuentas de usuario tanto para linux como para Windows|---- ou = Computers : cuentas de máquina para los sistemas Windows|---- ou = Groups : cuentas de grupos tanto para linux como para Windows|---- ou = DSA : cuentas espciales de sistema

Esta estructura es conforme con las recomendaciones del RFC 2307bis. Por tanto, la con-juncion de Samba y OpenLDAP nos permitirá almacenar la siguiente información:

• Cuentas de usuario Microsoft Windows utilizando la clase de objeto sambaSAMAccount(samba.schema)

• Cuentas de máquina Microsoft Windows utilizando la clase de objeto sambaSAMAccount.

• Cuentas de usuario UNIX utilizando las clases de objeto posixAccount y shadowAccount(nis.schema)

• Grupos de usuarios utilizando las clases de objetos posixGroup y sambaGroupMapping.

• Cuentas de seguridad utilizadas por software de clientes (Samba y Linux) que utilizan laclase de objeto simpleSecurityObject (core.schema)

Los ficheros de configuración del servidor OpenLDAP se encuentran bajo el directorio /etc/openldap. El fichero de configuración principal del servidor se denomina /etc/openldap/slapd.conf. El fichero de configuración de las herramientas clientes sellama /etc/openldap/ldap.conf, y los diferentes ficheros que configuran el esquema que ofre-ce el servicio de directorio se encuentran bajo el subdirectorio schema.

El fichero base de configuración sobre el que vamos a trabajar a lo largo del libro es el si-guiente:

# Fichero /etc/openldap/slapd.conf#

# Diferentes ficheros que definen partes del esquema#include /etc/openldap/schema/core.schemainclude /etc/openldap/schema/cosine.schemainclude /etc/openldap/schema/inetorgperson.schemainclude /etc/openldap/schema/nis.schemainclude /etc/openldap/schema/samba.schema

# Ficheros que mantienen el pid del proceso servidor# y los argumentos pasados#pidfile /var/run/slapd/slapd.pidargsfile /var/run/slapd/slapd.args

6.4. Configuración del servidor OpenLDAP


# Formato de la base de datos que almacenará el directorio#database ldbm

# Raíz(sufijo) del servicio de directorio# dn y password del administrador del directorio#suffix "dc=admon,dc=com"rootdn "cn=admin,dc=admon,dc=com"rootpw {SSHA}86kTavd9Dw3FAz6qzWTrCOKX/c0Qe+UV

# Ubicación de los datos físicos del servicio de directorio#directory /var/lib/ldap

# Indices#index objectClass eqindex cn pres,sub,eqindex sn pres,sub,eqindex uid pres,sub,eqindex displayName pres,sub,eqindex uidNumber eqindex gidNumber eqindex memberUID eqindex sambaSID eqindex sambaPrimaryGroupSID eqindex sambaDomainName eqindex default sub

En el fichero de configuración del servidor OpenLDAP se aprecia la inclusión de un fi-chero de configuración del esquema que nos va a permitir definir los atributos necesarios pa-ra poder dar soporte a los objetos que requiere un cliente Windows. El fichero /etc/openldap/schema/samba.schema viene en el paquete Samba. Por tanto habrá que copiar-lo de la ubicación /usr/share/doc/samba-3.X.X/LDAP/samba.schema al directorio /etc/openldap/schema.

Una vez definido el fichero de configuración de OpenLDAP y el esquema que va a sopor-tar, el siguiente paso sería rellenar el directorio con la estructura básica que queremos imple-mentar. Para ello sería necesario obtener el fichero en formato LDIF. Si utilizamos las herra-mientas comentadas anteriormente de IDEALX, existe un comando (smbldap-populate) quenos permite crear toda esa infraestructura en el servidor LDAP. Lo único necesario sería con-figurar el fichero /etc/smbldap-tools/smbldap.conf que define algunos parámetros necesariospara dicha operación

# smbldap-populate

6.4. Configuración del servidor OpenLDAP


6.5. Configuración del cliente LinuxLa configuración de un cliente Linux para que se integre en un dominio LDAP, implica lamodificación de varios ficheros de configuración. Básicamente, el cliente Linux debe de saberde donde obtener los usuarios y grupos del dominio y como autenticarlos.

Lo primero se consigue utilizando la librería NSS (Name Service Switch) que permite re-solver nombres en el sistema y que para ello depende de un fichero llamado /etc/nsswitch.conf donde se definen las fuentes de datos para los usuarios y grupos queserá capaz de ver el sistema Linux. Al editar dicho fichero, las líneas que controlan de dondese obtendrá la resolución de usuarios y grupos, son las siguientes:

passwd: files ldapshadow: files ldapgroup: files ldaphosts: files dns wins

Estas líneas indican al sistema que para obtener la información de un usuario(UID,GID,HOME ...) primero consultará los ficheros del sistema (/etc/passwd,/etc/shadow) además de una fuente de datos LDAP.

La tarea de autenticar usuarios en un sistema Linux se relega a un módulo denominadoPAM (Pluggable Authentication Module) que consiste en insertar una capa en medio decualquier aplicación que necesite autenticación, independizando de este modo a la aplica-ción de la necesidad de saber donde se encuentran los datos de autenticación.

En un sistema CentOS Linux existe un fichero de configuración general de PAM que lue-go incluyen las aplicaciones que necesitan autentificarse. Este fichero se llama /etc/pam.d/system-auth. La modificación necesaria para que la fuente de datos sea un servi-dor LDAP se realiza de la siguiente forma:

#%PAM-1.0# This file is auto-generated.# User changes will be destroyed the next time authconfig is run.auth required /lib/security/$ISA/pam_env.soauth sufficient /lib/security/$ISA/pam_unix.so likeauth nullokauth sufficient /lib/security/$ISA/pam_ldap.so use_first_passauth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.soaccount [default=bad success=ok user_unknown=ignore service_err=ignore \system_err=ignore] /lib/security/$ISA/pam_ldap.so

password required /lib/security/$ISA/pam_cracklib.so retry=3 type=password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtokmd5 shadowpassword sufficient /lib/security/$ISA/pam_ldap.so use_authtokpassword required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.sosession required /lib/security/$ISA/pam_unix.sosession optional /lib/security/$ISA/pam_ldap.so

El módulo PAM que permite la autenticación se denomina pam_ldap y viene en el pa-quete nss_ldap, el cual implenta tanto el módulo pam_ldap como la librería necesaria (/

6.5. Configuración del cliente Linux


lib/libnss_ldap-2.3.2.so) para que el sistema de resolución de nombres (NSS) puedaleer la información de un servidor LDAP.

Estas dos piezas de software (pam_ldap, libnss_ldap) se apoyan en un fichero de configu-ración denominado /etc/openldap/ldap.conf donde se define a que servidor LDAP atacar,cual es la raíz del dominio etc ...

SIZELIMIT 200TIMELIMIT 15DEREF never

host ldap.admon.combase dc=admon,dc=combinddn cn=admin,dc=admon,dc=combindpw not24get

pam_password md5

nss_base_passwd ou=Users,dc=admon,dc=com?onenss_base_shadow ou=Users,dc=admon,dc=com?onenss_base_group ou=Groups,dc=admon,dc=com?one

En un sistema CentOS Linux, las tareas anteriores se podían haber realizado utilizando laherramienta de configuración de la autenticación denominadasystem-config-authentication, que permite al administrador definir la información necesariapara la librería NSS, así como para pam_ldap.

Hay que señalar que todo este proceso que se ha realizado en un cliente Linux, debería-mos hacerlo también en el servidor, para que este fuera capaz de ver los usuarios y gruposnecesarios. Esto se debe a que cuando pasemos a configurar el servidor Samba, los usuariosSamba tienen que tener su correspondiente usuario Linux y si por tanto el servidor Linux noes capaz de ver los usuarios como tal Linux que es, difícilmente podrá hacer que Samba lossirva.

6.6. Configuración del servidor SambaTodos los ficheros de configuración que tienen que ver con el servidor Samba se encuentranbajo el directorio /etc/samba. El fichero principal de configuración se denomina /etc/samba/smb.conf.

El objetivo es implantar un controlador de dominio Windows que obtenga la informaciónde los usuarios de un servidor LDAP, para ofrecer la posibilidad a los clientes Windows queinicien sesión en el dominio. Por tanto habrá que instruir al servidor Samba que lea los usua-rios de la base de datos LDAP.

Un fichero de configuración apropiado para conseguir dicho objetivo sería el siguiente:

[global]unix charset = LOCALEworkgroup = DSIC2netbios name = grouchopassdb backend = ldapsam:ldap://127.0.0.1username map = /etc/samba/smbuserslog level = 2syslog = 0

6.6. Configuración del servidor Samba


log file = /var/log/samba.logmax log size = 50smb ports = 139 445name resolve order = hosts wins bcastwins server = 158.42.250.200time server = Yesshow add printer wizard = Noadd user script = /usr/sbin/smbldap-useradd -a -m '%u'delete user script = /usr/sbin/smbldap-userdel -r %uadd group script = /usr/sbin/smbldap-groupadd -p '%g'delete group script = /usr/sbin/smbldap-groupdel '%g'add user to group script = /usr/sbin/smbldap-groupmod -m '%u' '%g'delete user from group script = /usr/sbin/smbldap-groupmod -x '%u' '%g'set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'add machine script = /usr/sbin/smbldap-useradd -w '%upasswd program = /usr/sbin/smbldap-passwd '%u'logon script = scripts\logon.batlogon path = \\%L\profiles\%Ulogon drive = X:domain logons = Yespreferred master = Yesldap admin dn = cn=root,dc=dsic2,dc=upv,dc=esldap group suffix = ou=Groupsldap idmap suffix = ou=Idmapldap machine suffix = ou=Computersldap passwd sync = Yesldap suffix = dc=dsic2,dc=upv,dc=esldap user suffix = ou=Usersidmap backend = ldap:ldap://127.0.0.1idmap uid = 10000-20000idmap gid = 10000-20000printer admin = Administratormap acl inherit = Yesprinting = cupsprintcap name = CUPS

[netlogon]comment = Network Logon Servicepath = /var/lib/samba/netlogonguest ok = Yeslocking = No

[profiles]comment = Profile Sharepath = /var/lib/samba/profilesread only = Noprofile acls = Yes

[print$]comment = Printer Driverspath = /var/lib/samba/driversbrowseable = yesguest ok = noread only = yeswrite list = Administrator

Se puede verificar la corrección de este fichero ejecutando en el siguiente comando:

# testparm -s

Si el test ha ido bien, sería el momento de arrancar el servidor Samba y comprobar que secomporta como un verdadero controlador de dominio. Pero como hemos elegido como basede datos donde guardar la información del dominio el servidor LDAP, Samba tiene que te-ner un mecanismo de comunicación con el servidor LDAP.



En el fichero de configuración aparecen una serie de directivas que hacen mención a laconfiguración LDAP.

• passdb backend = ldapsam:ldap://127.0.0.1

Esta directiva indica cual es la base de datos donde almacenar la información de cuen-tas (usuarios, máquinas y grupos). Los valores que puede tomar son: tdbsam, ldapsam,mysql, XML.

En nuestro caso el soporte elegido es ldapsam, lo cual implica que toda la informaciónestará en un servidor LDAP. Otro parámetro es la dirección del servidor: ldap://127.0.0.1.

• ldap admin dn = cn=root,dc=dsic2,dc=upv,dc=es

Aquí indicamos cual es el administrador del servicio de directorio.

• ldap user suffix = ou=Users

Define la Unidad Organizativa donde almacenar cuentas de usuario. La ubicación deesta OU será relativa a la raíz del directorio.

• ldap group suffix = ou=Groups

Define la Unidad Organizativa donde almacenar cuentas de grupo. La ubicación deesta OU será relativa a la raíz del directorio.

• ldap machine suffix = ou=Computers

Define la Unidad Organizativa donde almacenar cuentas de máquina. La ubicación deesta OU será relativa a la raíz del directorio.

El único parámetro que no aparece en el fichero de configuración y que es necesario paraque el administrador pueda llevar a cabo las operaciones necesarias sobre el servidor, es lacontraseña que le permita autentificarse.

En vez de definirlo en el fichero /etc/samba/smb.conf se almacena en un fichero es-pecial con un formato particular y que se denomina /etc/samba/secrets.tdb. El si-guiente comando permite introducir esa contraseña en el fichero:

# smbpasswd -w contraseña

Dicha contraseña debe ser la misma que aparece en el fichero de configuración del servi-dor LDAP (/etc/openldap/slapd.conf).

Ahora nos encontramos en disposición de arrancar el servidor Samba y comprobar que seha creado el dominio.

# smbclient -L localhost -U%# net getlocalsid



Si las cosas han funcionado bien, deberíamos obtener información sobre el dominio y elSID del mismo.

SID for domain DSIC2 is: S-1-5-21-3504140859-1010554828-2431957765

Si obtenemos una respuesta como la de arriba, procederemos a crear objetos en el domi-nio. Para ello nos basaremos en las utilidades que se instalaron a la hora de crear el serviciode directorio (smbldap-tools). Existen diferentes scripts que nos permitirán añadir, modificary borrar usuarios, grupos y maquinas en el dominio par que tanto clientes Windows comoLinux puedan autentificarse. Estos mismos scripts se utilizan para que automáticamente unamáquina se dé de alta en el dominio.

add user script = /usr/sbin/smbldap-useradd -a -m '%u'delete user script = /usr/sbin/smbldap-userdel -r %uadd group script = /usr/sbin/smbldap-groupadd -p '%g'delete group script = /usr/sbin/smbldap-groupdel '%g'add user to group script = /usr/sbin/smbldap-groupmod -m '%u' '%g'delete user from group script = /usr/sbin/smbldap-groupmod -x '%u' '%g'set primary group script = /usr/sbin/smbldap-usermod -g '%g' '%u'add machine script = /usr/sbin/smbldap-useradd -w '%upasswd program = /usr/sbin/smbldap-passwd '%u'

6.7. Configuración del cliente WindowsLa configuración de un cliente Microsoft Windows para que se integre en un dominio creadopor un servidor Samba, sigue los mismos pasos que si el controlador de dominio fuera unservidor Windows NT/2000/2003.

Lo único que habrá que hacer es ir a MiPC->Propiedades->Identificación de Red->Propiedades que nos permitirá cambiarle el nombre al PC o unirse a un dominio. Elegimosunirse a un dominio, el cual nos solicitará una cuenta de usuarios con privilegios administra-tivos y para ello utilizaremos la cuenta Administrator.

Una vez que se una al nuevo dominio, reiniciaremos la máquina y comprobaremos quetodo ha ido bien. También sería necesario comprobar que ha sido creada la cuenta de máqui-na necesaria en el servidor Samba y que define la relación de confianza implícita que existiráentre la máquina y el dominio.

dn: uid=sem0101$,ou=Computers,dc=dsic2,dc=upv,dc=esobjectClass: topobjectClass: inetOrgPersonobjectClass: posixAccountobjectClass: sambaSamAccountcn: sem0101$sn: sem0101$uid: sem0101$uidNumber: 1004gidNumber: 553homeDirectory: /dev/nullloginShell: /bin/falsedescription: ComputersambaSID: S-1-5-21-2758841116-2178560935-410125937-3008sambaPrimaryGroupSID: S-1-5-21-2758841116-2178560935-410125937-2107displayName: sem0101$sambaPwdCanChange: 1099655465

6.7. Configuración del cliente Windows


sambaPwdMustChange: 2147483647sambaPwdLastSet: 1099655465sambaAcctFlags: [W ]

Una vez que disponemos de un cliente Windows en el dominio sería factible poder admi-nistrar el dominio desde el, con las herramientas que Microsoft Windows nos proporciona:User Manager y Server Manager. Esto es posible, aunque con algunas salvedades. No todoslos atributos no pueden ser manejados.

6.8. ConclusionesComo se ha podido apreciar a lo largo de este capítulo, es posible implantar un dominio(conjunto de usuarios y máquinas) solo con software libre y que integre tanto a clientes Win-dows como Linux.

Si nuestras necesidades no requieren las capacidades extras que supone tener instaladoun dominio Active Directory y nos es suficiente con las características que ofrece un dominioWindows NT, esta es una solución escalable, altamente configurable y barata.

En cuanto a la administración del dominio, recomendaría la utilización de las herramien-tas desarrolladas por IDEALX (smbldap-tools) que aunque en línea de comandos, nos permi-ten realizar todas la tareas de creación, modificación y borrado de cuentas en el dominio.

También existe la posibilidad de crear relaciones de confianza entre dominios, para poderotorgar de una forma fácil y eficiente privilegios a usuarios de otros dominios.

En definitiva hacer hincapié en que Samba+OpenLDAP es un binomio que promete se-guir creciendo para poder ofrecer soluciones fiables al administrador de sistemas.

6.9. Comandos de referencia

[root@groucho root]# smbldap-useradd -?(c) IDEALX 2004 (http://www.idealx.com)- Licenced under GPLUsage: /usr/local/sbin/smbldap-useradd [-awmugdsckABCDEFGHMNPST?] username-o add the user in the organazional unit (relative to the user suffix)-a is a Windows User (otherwise, Posix stuff only)-w is a Windows Workstation (otherwise, Posix stuff only)-i is a trust account (Windows Workstation)-u uid-g gid-G supplementary comma-separated groups-n do not create a group-d home-s shell-c gecos-m creates home directory and copies /etc/skel-k skeleton dir (with -m)-P ends by invoking smbldap-passwd-A can change password ? 0 if no, 1 if yes-B must change password ? 0 if no, 1 if yes-C sambaHomePath (SMB home share, like '\\PDC-SRV\homes')-D sambaHomeDrive (letter associated with home share, like 'H:')-E sambaLogonScript (DOS script to execute on login)-F sambaProfilePath (profile directory, like '\\PDC-SRV\profiles\foo')

6.8. Conclusiones


-H sambaAcctFlags (samba account control bits like '[NDHTUMWSLKI]')-N canonical name-S surname-M local mailAddress (comma seperated)-T mailToAddress (forward address) (comma seperated)-? show this help message

[root@groucho root]# smbldap-userdel -?(c) IDEALX 2004 (http://www.idealx.com)- Licenced under GPLUsage: /usr/local/sbin/smbldap-userdel [-r?] username-r remove home directory-R remove home directory interactively

[root@groucho root]# smbldap-groupadd -?(c) IDEALX 2004 (http://www.idealx.com)- Licenced under GPLUsage: /usr/local/sbin/smbldap-groupadd [-agorst?] groupname-a add automatic group mapping entry-g gid-o gid is not unique-r group-rid-s group-sid-t group-type-p print the gidNumber to stdout-? show this help message

[root@groucho root]# smbldap-populate -?(c) IDEALX 2004 (http://www.idealx.com)- Licenced under GPLUsage: /usr/local/sbin/smbldap-populate [-abeiug?] [ldif]-u uidNumber first uidNumber to allocate (default: 1000)-g gidNumber first uidNumber to allocate (default: 1000)-a user administrator login name (default: Administrator)-g user guest login name (default: nobody)-e file export ldif file-i file import ldif file-? show this help message

Este comando se encarga de manejar la base de datos SAM:

[root@groucho root]# pdbedit -?Usage: [OPTION...]-L, --list list all users-v, --verbose be verbose-w, --smbpasswd-style give output in smbpasswd style-u, --user=USER use username-f, --fullname=STRING set full name-h, --homedir=STRING set home directory-D, --drive=STRING set home drive-S, --script=STRING set logon script-p, --profile=STRING set profile path-U, --user SID=STRING set user SID or RID-G, --group SID=STRING set group SID or RID-a, --create create user-r, --modify modify user-m, --machine account is a machine account-x, --delete delete user-b, --backend=STRING use different passdb backend as default

backend-i, --import=STRING import user accounts from this backend-e, --export=STRING export user accounts to this backend-g, --group use -i and -e for groups-P, --account-policy=STRING value of an account policy (like maximum

password age)-C, --value=LONG set the account policy to this value-c, --account-control=STRING Values of account control--force-initialized-passwords Force initialization of corrupt password



strings in a passdb backend-z, --bad-password-count-reset reset bad password count-Z, --logon-hours-reset reset logon hours

El comando net es una herramienta de administración de Samba y servidoresremotos CIFS.

[root@groucho root]# net -hNo command: netnet time to view or set time informationnet lookup to lookup host name or ip addressnet user to manage usersnet group to manage groupsnet groupmap to manage group mappingsnet join to join a domainnet cache to operate on cache tdb filenet getlocalsid [NAME] to get the SID for local namenet setlocalsid SID to set the local domain SIDnet changesecretpw to change the machine password in the local secrets

database onlythis requires the -f flag as a safety barrier

net status Show server status

net ads <command> to run ADS commandsnet rap <command> to run RAP (pre-RPC) commandsnet rpc <command> to run RPC commands

Type "net help <option>" to get more information on that optionValid targets: choose one (none defaults to localhost)

-S or --server=<server> server name-I or --ipaddress=<ipaddr> address of target server-w or --workgroup=<wg> target workgroup or domain

Valid miscellaneous options are:-p or --port=<port> connection port on target-W or --myworkgroup=<wg> client workgroup-d or --debuglevel=<level> debug level (0-10)-n or --myname=<name> client name-U or --user=<name> user name-s or --configfile=<path> pathname of smb.conf file-l or --long Display full information-V or --version Print samba version information-P or --machine-pass Authenticate as machine account



ANota LegalSe concede permiso para copiar, distribuir y/o modificar este documento bajo los términosde la GNU Free Documentation License, Version 1.2 o posterior, publicada por la Free Soft-ware Foundation, siendo secciones invariantes este apéndice que contiene la nota legal. Seconsidera texto de portada el siguiente:

Integración de Sistemas Linux/Windows

por Fernando Ferrer García y Andrés Terrasa Barrena

Copyright (c) 2004-2007 Fernando Ferrer y Andrés Terrasa

Versión 4.0, marzo 2009

Este documento puede ser copiado y distribuido en cualquier medio con o sin fines co-merciales, siempre que la licencia GNU Free Documentation License (FDL)[http://www.gnu.org/copyleft/fdl.html], las notas de copyright y esta nota legal diciendo quela GNU FDL se aplica al documento se reproduzcan en todas las copias y que no se añadaninguna otra condición a las de la GNU FDL.

http://www.gnu.org/copyleft/fdl.html

integración-windows-unix-dns

Documents

servidor openldap

directorio activo

configuracin de openldap

dominio linux

windows server

mandatos windows

servicios de directorio

concepto de dominio