ASO01. - Administración de Servicios de Directorios

Administración de servicios de directorio.
Caso práctico
En la empresa BK Sistemas Informáticos están valorando cambiar el sistema actual de
comunicaciones de datos por otro que le genere mayores prestaciones.
¿Qué sistema tiene nuestra empresa? Las comunicaciones entre los ordenadores se
realizan por difusión de red. En el que cada equipo trata, de igual a igual al resto. Esto está
provocando inseguridad en la red en todos los aspectos. En el aspecto de los datos, no se
sabe en cuantas máquinas se encuentran archivos duplicados o con versiones distintas. En
el aspecto de seguridad que consistiría, sobre todo, en la difusión de virus, troyanos, etc.
¿Qué solución se plantea? La solución que se plantea es el crear uno o varios servidores
Alain Bachellier (CC BY-NC-SA)
(conectados entre sí) dónde se centralice toda la información, usuarios registrados, modos
de acceso y, sobre todo, seguridad en los archivos propios de la empresa.
Vindio y Laro trabajan en el departamento de informática y llevarán el peso de todo el proceso, con la ayuda de Noiba,
Naroba y Jana, alumnas que están haciendo la FCT en la empresa.
Para proceder a la instauración de ese sistema, nuestro departamento de informática debe llevar a cabo una serie de
pruebas que permitan tomar una decisión definitiva a la hora de implantar el sistema.
Lo que tiene claro nuestro departamento, y por unanimidad, es la implantación de un sistema LDAP (Protocolo Ligero de
Acceso a Directorios) Un sistema eficaz y flexible. Pero no nos ponemos de acuerdo en si todos los servidores LDAP
deben ser servidores Windows usando Active Directory o bien, máquinas servidores GNU/Linux con soporte OpenLDAP.
En esta unidad de trabajo aprenderás conceptos importantes como qué son los LDAP (Protocolo Ligero de Acceso a Directorios) y su
utilización en varios sistemas operativos tanto en Windows como Linux y su relación con equipos cliente, con sistemas operativos
Windows y Linux.
Se trata de la primera unidad de trabajo del módulo y con ella se pretende que conozcas los conceptos propios de un sistema de LDAP,
así como su administración e integración con equipos cliente. De esta manera podrás comprender mejor la importancia de los sistemas
servidores y su integración en Intranets y Extranets. Sin olvidarnos la posibilidad de integración en Internet.
Ministerio de Educación y Formación Profesional (Dominio público)
Materiales formativos de FP Online propiedad del Ministerio de Educación y Formación Profesional.

Aviso Legal
1.- Servicio de directorio.
Caso práctico
Antes de afrontar todas las instalaciones y configuraciones tanto a nivel de servidores como a nivel
de máquinas cliente, hemos decidido recopilar la información necesaria.
Como parte de esa información, debemos estudiar las ventajas, y desventajas, de un servicio de
directorio. Es el principio o concepto básico de todo LDAP.
Noiba se va a encargar de realizar esta tarea y ponerla a disposición del departamento, dónde se
estudiará detenidamente.
Alain Bachellier (CC BY-NC-

SA)
Debemos empezar preguntándonos ¿qué es un servicio de directorio? Es una aplicación o un

conjunto de aplicaciones que almacena y organiza la información sobre los usuarios de una red de
ordenadores, sobre recursos de red, y permite a los administradores gestionar el acceso de usuarios a
los recursos sobre dicha red. Además, los servicios de directorio actúan como una capa de
abstracción entre los usuarios y los recursos compartidos.
Pongamos un ejemplo. Un servicio de directorio es un servicio de

nombres que hace corresponder los nombres de los recursos de la
red, con sus respectivas direcciones de red. Con este tipo de servicio,
Pascal Kotte (CC BY-SA) un usuario no tiene que recordar la dirección física de los diferentes
recursos de la red, pues con saber simplemente su nombre estará
accediendo al recurso demandado. Cada recurso de la red se considera como un objeto en el servidor
de directorio, donde la información de un recurso en particular se almacena en forma de atributos de
ese objeto. La información que representa un objeto se establece de forma segura, accediendo a tales
objetos usuarios con los permisos adecuados para poder manipular dicha información. Directorios m lobo (CC BY-SA)
más sofisticados son diseñados con multitud de características y preferencias para poder manipular su
información, según la dificultad de gestión que su administrador pretenda manejar.
Ahondando en el ejemplo: el típico recurso de una carpeta compartida. En vez de acceder mediante su identificación de red y ruta
completa, podríamos acceder mediante su nombre de máquina y su nombre de recurso. Por ejemplo: la máquina A comparte el
directorio o carpeta c:\documents and settings\usuario\compartir y lo nombra como micarpeta. La máquina B puede acceder al recurso de la
siguiente forma: \\A\micarpeta.
En la imagen podemos apreciar cómo se interrelacionan los distintos objetos con servicios como DNS, carpetas, servidores de
impresoras, grupos, etc.
Para saber más

En el siguiente enlace puedes aprender más sobre este tema.
Servicio de directorio.
Autoevaluación
¿Las carpetas son parte del directorio activo?
Si, dejan de controlarse a nivel local para que lo administre el directorio activo.
No, es parte del sistema operativo a nivel local.
Sí, porque el directorio activo controla todas las transacciones del sistema.
No, dependen directamente del cliente.
No. Creo que no lo has entendido bien.

Muy bien, has entendido algo muy importante.
No es la respuesta correcta porque el directorio activo no deja de ser más que un servicio del sistema.
Incorrecto. Deberías repasar este punto.
Solución
1. Incorrecto
2. Opción correcta
3. Incorrecto
4. Incorrecto
1.1.- Definición, elementos y nomenclatura.
Vamos a empezar a entender los términos que utilizaremos en esta unidad. Y empezaremos por las
siglas LDAP que es un protocolo de tipo cliente-servidor para acceder a un servicio de directorio.
Otro concepto, directorio , es una estructura jerárquica que almacena información acerca de los
objetos existentes en la red, tanto en la propia máquina raíz del dominio como en aquellas que se
encuentren en la misma red. Los objetos en cuestión no son sólo carpetas, sino recursos en general. Es
decir, elementos como carpetas (o directorios en su nomenclatura anterior), impresoras, usuarios, etc.
La estructura del directorio se basa en los siguientes conceptos:
Dominio : es la estructura básica. Permite agrupar todos los objetos que se administrarán en
forma estructurada y jerárquica.
Organización :en el caso de que el dominio sólo atienda a una organización, será única. En caso
contrario, un mismo dominio puede albergar varias organizaciones.
Unidad organizativa : es una unidad jerárquica inferior del dominio, puede estar compuesta por
otra serie de objetos como unidades organizativas (de nivel jerárquico inferior), grupos, etc.
Topsy at Waygood (CC BY-NC-SA)
Grupos : son objetos del mismo tipo. Se utilizan, sobre todo, para la asignación de los derechos
de acceso a los recursos.
Objetos : son representaciones de los recursos de red como: usuarios, ordenadores, impresoras, etc.
Denominamos árbol de dominios del directorio a una estructura jerárquica de dominios que comparten un espacio de nomenclatura
contiguo, un esquema común y un catálogo global común. Pongamos un ejemplo. Tenemos un dominio llamado bk.com y un
subdominio de éste, aula2.bk.com . Estos pueden formar parte de un árbol puesto que comparten la misma nomenclatura contigua y
pueden tener esquema y catálogo global comunes.
Un bosque es la colección de uno o más dominios, que comparten sus objetos, sus atributos y reglas en el directorio activo.
Los atributos se definen independientemente de las clases. Se define sólo una vez pero se puede utilizar en múltiples clases.
Las clases describen los posibles objetos del directorio que se puede crear. Cada clase es una colección de atributos.
Estamos viendo que, en cuanto a nomenclatura, es similar a las DNS, es decir, hay un dominio.
Reflexiona
Que un espacio de nomenclatura es el conjunto de nombres que representan a un dominio. Y un espacio de nomenclatura
contiguo indica que la primera parte del nombre del dominio es común.
Autoevaluación
Un grupo, ¿Está por encima de una unidad organizativa?
No, si existen unidades organizativas, los grupos deben estar contenidos en una de ellas.
No, todos los objetos están en el mismo nivel. Un grupo puede estar contenido en una unidad organizativa, pero no
viceversa.
Sí, porque puede contener derechos y privilegios sobre objetos.
No, todos los grupos y usuarios deben estar contenidos en una unidad organizativa.
No lo tienes claro, repasa la unidad.
No es correcta la respuesta porque una unidad organizativa puede tener delegados privilegios y derechos asignados
por el administrador.
Mejor que repases los conceptos de la unidad.
Solución
1. Incorrecto
2. Opción correcta
3. Incorrecto
4. Incorrecto
1.2.- LDAP.
El modelo de datos de LDAP(derivado de X.500) define una estructura jerárquica de objetos en forma de árbol, donde cada objeto
o entrada posee un conjunto de atributos . Cada atributo viene identificado mediante un nombre o acrónimo significativo, pertenece a
un cierto tipo y puede tener uno o varios valores asociados.
Cada objeto está identificado inequívocamente en la base de datos del directorio mediante un atributo
especial denominado nombre distinguido o dn . El resto de los atributos de la entrada depende de
qué objeto esté describiendo dicha entrada u objeto.
La definición de los posibles tipos de objetos, así como de sus atributos, que pueden ser utilizados por
el directorio de un servidor LDAP, la realiza el propio servidor mediante el denominado esquema del
directorio. El esquema contiene las definiciones de los objetos que pueden darse de alta en el
directorio.
El nombre distinguido de cada entrada del directorio es una cadena de caracteres formada por pares
tipo_atributo=valor separados por comas, que representa la ruta invertida que lleva desde la posición Wbenton (Dominio público)
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 existen en 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 el sufijo de los nombres
distinguidos de todas las entradas que mantiene el directorio.
Aunque existen dos formas de nombrar la raíz de un directorio LDAP, nosotros utilizaremos la nomenclatura basada en nombres de
dominio de Internet (como en los DNS), que utiliza los dominios DNS para nombrar la raíz de la organización. Por ejemplo, la base de la
organización BK, sería " dc=bk, dc=com ".
A partir de esa base, el árbol se subdivide en nodos y subnodos, tantos como se estimen oportunos para estructurar, de forma
adecuada, los objetos de la organización. Objetos que se ubican finalmente como las hojas del árbol. De esta forma, el nombre
distinguido de cada entrada describe su posición en el árbol de la organización, de forma análoga a un sistema de archivos típico, en el
que el nombre absoluto (unívoco) de cada archivo equivale a su posición en la jerarquía de directorios del sistema, y viceversa.
Reflexiona
Aunque los nombrados se basan en formatos de Internet, no tienen por qué ser nombres cualificados (es decir, registrados
en Internet). Podríamos utilizar dc=bk, dc=local , que no estaría registrado en internet.
2.- Esquema del servicio de directorio.
Caso práctico
Uno de los problemas que se presentan a la hora de identificar usuarios, es que estos pueden ser
identificados mediante distintas credenciales. Es decir, un usuario puede tener distinta credencial
para utilizar el servicio de correo electrónico, el acceso a su carpeta, etc. Para evitar esto, el
departamento estudia cómo afrontar, mediante unas mismas credenciales, el uso de distintos
recursos por el mismo usuario y con las mismas credenciales.
Para lograr este reto, debemos perfilar correctamente nuestro esquema del servicio de directorio.
Este trabajo de campo lo realizará una de nuestras alumnas en prácticas del departamento,
Naroba.
Ya hemos mencionado qué es el esquema de un servicio de directorio. Ahora vamos a profundizar un

poco en él.
Debemos definir, primero, qué es un esquema de directorio: el esquema es la colección de atributos

definidos, clases de objetos definidas, para controlar dónde es almacenado cada dato. De forma
colectiva se utiliza la nomenclatura ACL, o lista de control de acceso.
Por ejemplo, tu grupo puede dar facilidades de acceso como cambiar la localización de los empleados,
Wilfredor (Dominio público)su ubicación en general, o número de oficina, pero no se permite que se modifiquen entradas de
cualquier otro campo. Las ACL pueden controlar el acceso dependiendo de quién está solicitando los
datos, qué datos están siendo solicitados, dónde están los datos almacenados, y otros aspectos del registro que está siendo modificado.
Todo esto hecho directamente a través del directorio LDAP, así que no necesitas preocuparte de hacer comprobaciones de seguridad en
el nivel de aplicación de usuario.
Cualquier base de datos, sin tener en cuenta su complejidad o tecnología subyacente, tiene un esquema. Para entendernos aún mejor,
un esquema es el modelo de los datos, el diseño de cómo deben almacenarse los datos, qué tipos de datos podrán ser accesibles, y las
relaciones entre datos almacenados en varias entradas.
Cuando configuras un directorio LDAP, la información para cualquier entrada dada se almacena con una serie de atributos. Tú puedes
crear nuevos tipos de valores que serán almacenados en el directorio.
Colectivamente, a todos los atributos que pueden ser utilizados para un tipo de objeto específico se les llama Clases de Objetos (Object
Class, en ingles). Como con los atributos, podemos definir nuevas clases de objetos para adecuarlas a la organización de los datos, es
decir, según tus necesidades. Dentro de cada clase de objetos, podemos designar qué atributos son requeridos, y cuáles son
meramente opcionales.
(Para aquellos con un bagaje en bases de datos tradicionales, puede ser útil pensarlo de ésta
manera: los campos son similares a los atributos, las tablas son similares a las clases de
objetos.)
En la imagen podemos observar un típico esquema de un servicio de directorio. En ella, para

llegar al identificador "Naroba" debemos recorrer una estructura en forma de árbol.
Es decir, en un formato de Internet, tipo URL, sería "Naroba.Usuarios.bk.com.".
Ahora bien, en formato DN "DN: 'uid=Naroba, ou=Usuarios,dc=bk,dc=com'".
Comúnmente se usan las estructuras de árbol para jerarquizar la información en un medio.

Como ejemplo, tenemos la estructura de un sistema de archivos dentro de un sistema operativo.
De esta manera, nos permiten ordenar y organizar la información en subdirectorios que
contienen información específica.
Como ejemplo, además, podemos añadir el formado de los servidores DNS. Por ejemplo, en
"www.empresa.com", sería "www" un subdominio de empresa.com.
Federico Martínez Pérez (Elaboración propia)
Autoevaluación
¿Qué entendemos por esquema en un entorno LDAP?
Un gráfico indicando la organización del LDAP.
Es un modelo de los datos.
Es un modelo transaccional entre varias bases de datos que se interrelacionan con el sistema base.
Es la base de datos del sistema que sirve de referencia o índice de todos los recursos, grupos y usuarios del
sistema.
No has acertado. Deberías repasar este punto de nuevo.
No es la respuesta correcta.
Incorrecto, debes repasar bien este punto.
Solución
1. Incorrecto
2. Opción correcta
3. Incorrecto
4. Incorrecto
3.- Funciones del dominio.
Caso práctico
En las sucesivas reuniones y puestas en común que hemos tenido, hemos ido recopilando datos de qué es un Servicio de
Directorio y, más concretamente, la base de datos LDAP.
Nuestras alumnas en prácticas, Noiba, Naroba y Jana, con los datos que han recopilado nos indican que tenemos que
definir qué funciones y tareas que gestionará el servicio LDAP que queremos implantar.
Actualmente hay, en el mercado, dos productos que están basados en la misma idea, LDAP. Estos son
Active Directory de Microsoft para plataformas propietarias de Windows y OpenLDAP, de libre
distribución.
¿Por qué marcamos estas diferencias? Porque Active Directory integra todos los servicios dentro del
Directorio Activo. Sin embargo, openLDAP no los integra, deben ser integrados o, más bien, ceder parte
del control de un servicio al servicio openLDAP.
A modo de ejemplo: en Linux existen servicios como Samba, NFS. Son servicios independientes
y gestionan recursos de forma independiente. Puede darse el caso que queramos que determinados
Grey Hargreaves (CC BY) usuarios tengan acceso a recursos gestionados por alguno de estos dos servicios. Entonces habrá que
configurar ambos servicios para que estos usuarios puedan acceder a los recursos mencionados. Pues
bien, si estos servicios los integramos en OpenLDAP, sólo será necesario configurar estos usuarios dentro del LDAP para que accedan
a dichos recursos.
Dadas las características de LDAP, sus usos más comunes son:
Directorios de información . Por ejemplo bases de datos de empleados organizados por departamentos (siguiendo la estructura
organizativa de la empresa), o cualquier tipo de páginas amarillas.
Sistemas de autenticación/autorización centralizada . Grandes sistemas donde se guardan grandes cantidades de registros y se
requiere un uso constante de los mismos.
Por ejemplo:
Active Directory Server de Microsoft, para gestionar todas las cuentas de acceso a una red corporativa y mantener
centralizada la gestión del acceso a los recursos.
Sistemas de autenticación para páginas web; algunos de los gestores de contenidos más conocidos disponen de sistemas
de autenticación a través de LDAP.
Sistemas de control de entradas a edificios, oficinas, etc.
Veamos más características de LDAP:
Sistemas de correo electrónico . Grandes sistemas formados por más de un servidor que accedan a un repositorio de datos
común.
Pongamos como ejemplo un caso práctico:
Cada usuario se identifica por su dirección de correo electrónico, los atributos que se guardan de cada usuario son su contraseña, su
límite de almacenamiento o cuota, la ruta del disco duro donde se almacenan los mensajes (buzón), y, posiblemente, atributos
adicionales para activar sistemas anti-spam o anti-virus.
Como se puede apreciar en este sistema, LDAP recibirá cientos de consultas cada día (una por cada email recibido y una cada vez que
el usuario se conecta mediante POP3, IMAP o webmail, utilizando el protocolo IMAP o POP3). No obstante, el número de
modificaciones diarias es muy bajo, ya que sólo se podría cambiar la contraseña o dar de baja al usuario, operaciones ambas que no se
realizan de forma frecuente.
Sistemas de alojamiento de páginas web y FTP , con el repositorio de datos de usuario compartido.
Grandes sistemas de autenticación basados en RADIUS , para el control de acceso de los usuarios a una red de conexión o
ISP.
Poniendo un ejemplo:
Cada usuario se identifica con un nombre de usuario y los atributos asignados son la contraseña, los permisos de acceso, los grupos de
trabajo a los que pertenece, la fecha de caducidad de la contraseña, etc.
Este sistema recibirá una consulta cada vez que el usuario acceda a la red y una más cada vez que intente hacer uso de los recursos
del grupo de trabajo (directorios compartidos, impresoras, etc.), para comprobar los permisos del usuario.
Frente a estos cientos de consultas, solo unas pocas veces se cambia la contraseña de un usuario o se le incluye en un nuevo grupo de
trabajo.
Servidores de certificados públicos y llaves de seguridad.

Autenticación única ó " single sign-on" para la personalización de aplicaciones.
Perfiles de usuarios centralizados , para permitir itinerancia ó "Roaming". Por ejemplo, en Active Directory los perfiles nos
permiten mantener ciertos elementos (como escritorio y "mis documentos") guardados en el propio servidor. En los equipos
clientes aparecen como perfiles móviles.
Libretas de direcciones compartidas.
Autoevaluación
Un uso muy común de LDAP es …
Controlar los accesos al sistema.

Gestión de usuarios y grupos
Sustituir diversos servicios del sistema.
Actúa como CRM (servicio al cliente) del sistema.
No es correcto. Esta función es exclusiva del sistema operativo.
Muy bien, esta puede ser una de sus funciones.
No es la respuesta correcta. No los sustituye, los puede gestionar.
Incorrecto, los CRM son aplicaciones específicas ajenas al propio sistema.
Solución
1. Incorrecto
2. Opción correcta
3. Incorrecto
4. Incorrecto
4.- Controladores de dominio.
Caso práctico
En la última reunión Laro planteó la posibilidad de realizar accesos a través de Internet. Plantea un
problema —dijo Vindio—, la seguridad. Hubo un debate si permitir accesos desde Internet o bien
utilizar la red Internet y crear DNS internas creando una Intranet empresarial.
Finalmente se deja la decisión al director, Juan, informando de las ventajas y desventajas de tener
un dominio cualificado.

SA)
Empezamos por preguntarnos, ¿qué es un controlador de dominio? Un controlador de dominio es una entidad administrativa, esto es,
no es un ordenador en concreto, sino un conjunto de ordenadores agrupados que se ciñen a unas reglas de seguridad y autenticación
comunes.
Para regular un dominio, se precisa al menos de un equipo que sea el controlador principal, la fuente primera donde se almacenan las
reglas del dominio, y donde serán consultadas esas reglas en última instancia. Un controlador primario de dominio (PDC) puede
implementarse tanto bajo Windows como bajo GNU/Linux.
Por ejemplo, el controlador de dominio es el centro neurálgico de un dominio de un servidor Windows con Active Directory. Los
controladores de dominio tienen una serie de responsabilidades. Una de ellas es la autenticación de los usuarios que acceden al
sistema. De esta forma podrá denegar el acceso a los recursos compartidos de la propia máquina o a otra máquina de la red. Y esto se
realiza, normalmente, mediante la combinación de usuario y clave.
¿Pueden existir varios controladores de dominio? No, si queremos implementar un sistema de control único a distintos recursos de la
red, no debemos crear varios dominios. Sí es conveniente que existan varios servidores que permitan distribuir los recursos a los que
accederán los distintos usuarios.
Por ejemplo, en servidores Windows el servidor puede estar como controlador de dominio, como servidor miembro (es un equipo en el
que se ejecuta Windows Server y pertenece al dominio, pero que no actúa como controlador de dominio. Puede realizar funciones de
servidor de aplicaciones, de impresión, etc.), o como servidor independiente (se trata de un servidor que se incorpora a un grupo de
trabajo en lugar de a un dominio).
En el caso de servidores Windows, pueden coexistir más de un servidor como controlador de dominio pero para dominios
completamente distintos. Inclusive puede existir lo que se denomina una confianza mutua. Es decir, se confían datos de un controlador
de dominio a otro, pero realmente son controladores de su propio dominio.
Otro caso es que un servidor sea subdominio o secundario de otro. Active Directory permite crear estructuras jerárquicas de dominios y
subdominios, facilitando la estructuración de los recursos según su localización o función dentro de la organización a la que sirven. Otra
característica importante es el uso de estándares como X.500 y LDAP para el acceso a la información.
Autoevaluación
La función de un controlador de dominio es…
Gestionar las consultas de un dominio.

Dar servicio a las máquinas clientes.
Ceñirse a unas reglas de seguridad y autenticación comunes siendo una entidad administrativa unificada.
No es correcto. Parece lo mismo pero es función del servicio DNS.
No es la opción correcta, es una de sus funciones pero no es la principal.
Muy bien. Has leído este apartado.

Solución
1. Incorrecto
2. Incorrecto
3. Opción correcta
5.- Acciones sobre el servicio de directorio.
Caso práctico
Ya hemos decidido, en el departamento de informática, qué batería de pruebas realizaremos. Se
van a aplicar sobre máquinas virtuales debidamente configuradas para que soporten los distintos
sistemas operativos, tanto los que actuarán como servidores, como los que actuarán como clientes.
Vindio va a supervisar a las alumnas de prácticas, Noiba, Naroba y Jana, que serán las
encargadas de realizar esta tarea.
Una vez acabado todo el proceso, se realizará un informe que se remitirá al director, Juan.
Jonny Goldstein (CC BY)
Ya sabemos que el servicio de directorio se basa en la arquitectura del modelo cliente-servidor.
Uno o más servidores LDAP contienen los datos que conforman el árbol de directorio LDAP o base de
datos troncal, el cliente LDAP se conecta con el servidor LDAP y le hace una consulta. El servidor contesta
con la respuesta correspondiente, o bien con una indicación de donde puede el cliente encontrar más
información. No importa con qué servidor LDAP se conecte el cliente, ya que siempre observará la misma
vista del directorio; el nombre que se le presenta a un servidor LDAP hace referencia a la misma entrada a
la que haría referencia en otro servidor LDAP.
Para llegar al momento en que el servicio de directorio se comporte para lo que fue diseñado, debemos
seguir un proceso: instalación, configuración y personalización.
Desde luego, debe realizarse una planificación de todo el proceso. Qué vamos a instalar, qué árbol, qué
grupos tendremos, qué usuarios y en qué grupos estarán englobados, qué privilegios tendrán, con qué
recursos contaremos, qué privilegios tendrán los distintos usuarios y/o grupos sobre los recursos, a qué
máquinas dará servicio, cómo se conectarán, etc.
Frank Da Silva (CC BY-NC-ND)
Todo eso debe estar planificado antes de proceder a la realización de la instalación.
Autoevaluación
Debemos organizar, antes de proceder a la instalación, el árbol de directorio. Es decir, saber todos los usuarios,
claves, máquinas, grupos, etc. que se unirán al árbol de directorio.
Verdadero.
Falso
No es correcto. Debemos organizar la estructura y prever su crecimiento, no recabar información concreta de los
objetos.
Muy bien, organizar no implica recabar toda la información que contendrá el árbol de directorio.
Solución
1. Incorrecto
2. Opción correcta
5.1.- Instalación.
Una vez que tengamos planificado cómo organizar el servidor LDAP, procedemos a realizar la instalación. Lo primero que debemos
tener es el sistema base, independientemente del sistema operativo que debemos utilizar (tomaremos como referencia los sistemas
operativos Windows Server, en cualquiera de sus versiones, y el sistema operativo GNU/Linux en cualquiera de sus distribuciones).
Es decir, instalamos el sistema operativo "en bruto".
Después, pasamos al proceso de creación del dominio.
Cuando creamos un dominio debemos considerar en qué jerarquía se encuentra el servidor que estamos instalando. Es decir, si la
función del servidor es ser un controlador de dominio raíz, si va a albergar un subdominio y, por consiguiente, debe indicar dónde se
ubica el controlador de dominio, etc. En definitiva, cuando se habla de dominios podemos estar hablando de dominios cualificados
(registrados en Internet) o bien dominios de carácter empresarial, institucional o asociativo.
Pero no debemos olvidar que puede tratarse de un dominio, por ejemplo empresarial, que, a la vez, está registrado en Internet. Puede
darse la coincidencia que registremos un dominio, por ejemplo entretuyyo.com, que utilizaremos para que se estén relacionando entre
los distintos servidores pero que puede ser accesible desde cualquier puesto conectado a Internet y ver la página web de la empresa.
Vamos a ver cómo crear un dominio tanto en Windows Server con AD como en GNU/Linux con OpenLDAP.
Para saber más

En el siguiente apartado, observamos cómo se instala Active Directory en el sistema operativo Windows Server.
◄ 1 2 3 4 5 6 7 8 9 ►
INSTALACIÓN DE ACTIVE DIRECTORY
NiloGlock.(Dominio público)
Primero debemos obtener un servidor Windows Server. En el siguiente enlace podemos descargar una versión
de evaluación:
https://www.microsoft.com/es-es/cloud-platform/windows-server-trial
AGREGAR NUEVA FUNCIONALIDAD

Debemos agregar una nueva funcionalidad al servidor, empezaremos a través del administrador del servidor.
Seleccionaremos Servicios de dominio de Active Directory y las características que nos pida por defecto.
Windows Server (Elaboración propia)

AGREGAR SERVICIO DE DOMINIO DE ACTIVE

DIRECTORY
Obtendremos este cuadro de diálogo de información. Podemos acceder a más información detallada sobre la
instalación de AD.
En este otro cuadro de diálogo, sólo nos pide confirmación
CONTROLADOR DE DOMINIO DE ACTIVE DIRECTORY

Una vez finalizado el proceso de instalación, procedemos a la segunda parte, la promoción del servidor a
Controlador de Dominio, pulsando en el enlace azul mostrado en la captura
El primer servidor de AD debe ser un controlador de dominio. Es decir, debemos crear un dominio nuevo en un
bosque nuevo.
Otro caso es que deseemos agregar nuestro servidor en un bosque existente. Entonces nuestro servidor no será
controlador de dominio, sino que será parte integrante del dominio.
En éste punto debemos indicar el nombre del dominio. ¿Qué criterio debemos tomar para poner el nombre?
¿Debe estar terminado en .com, .es, etc.? No tiene por qué ser un nombre cualificado (registrado en Internet).
Puede ser, como en la imagen, uno inventado. Es más, si sabemos que no tendrá acceso desde el exterior a
través de Internet, o bien no queremos que sea "visible" por las DNS públicas, debemos huir de ese tipo de
nombres para no entrar en conflicto con algún servidor DNS.
PROMOCIÓN DEL CONTROLADOR DE DOMINIO

Es importante tener en cuenta el nivel funcional del dominio. En nuestro caso, escoge el más alto que existe,
WS 2016. Si existiera algún servidor en nuestra red que usara una versión más antigua de WS, tendríamos que
adaptar este nivel a esa versión, o actualizar ese servidor a WS 2016.También nos da la opción de crear un
RODC, muy útil para establecer réplicas del PDC, pero innecesario en nuestro ejemplo.
El controlador de dominio necesita el apoyo del servidor DNS. Es posible que nos aparezca un aviso sobre la
necesidad de poner una dirección IP fija, si no la pusimos antes (es recomendable hacerlo) Esto se puede
realizar a posteriori y no afecta al funcionamiento del servidor.También nos aparecerá una advertencia sobre
delegaciones DNS. No tiene importancia, porque este servidor no estará delegado a ningún otro, es el principal.

PROMOCIÓN DEL CONTROLADOR DE DOMINIO (2)
Comprobamos el nombre NETBIOS, muy importante para el funcionamiento adecuado del dominio.
Rutas en el equipo local para dónde se ubican: la base de datos, archivos de registro y la carpeta SYSVOL.
Una vez hecho esto, nos dará información sobre qué se va a hacer. Dado que en realidad lo que se hace es
ejecutar un script de Powershell, se nos permite revisar dicho script, con todas las opciones seleccionadas.
REQUISITOS PREVIOS A LA PROMOCIÓN

En la última pantalla previa a la instalación y reinicio del sistema, vemos que hay una serie de advertencias que
podemos revisar.
Lo verdaderamente importante aparece al final, con un símbolo verde que indica que podemos continuar.
INICIO DE SESIÓN EN EL CONTROLADOR DE DOMINIO

El sistema se reinicia con la nueva configuración, mostrando cambios en la pantalla de inicio: el administrador ya
no es local, como se puede ver, ya que su nombre es BK\Administrador.Esto es así porque en nuestro AD los
usuarios ya no son locales, y se les puede llamar de dos maneras:
nombre DNS: [email protected]

nombre NETBIOS: BK\Administrador

COMPROBACIONES
Al iniciar sesión y revisar nuestra información de dominio, vemos en la herramienta "Administrador del Servidor",
en la sección "Servidor Local", que efectivamente estamos dados de alta en nuestro dominio “bk.com”
Vemos como aparece nuestro dominio en la herramienta “Usuarios y equipos de Active Directory”, con objetos
creados por defecto para empezar a trabajar inmediatamente.
Y en el siguiente, la instalación del servicio LDAP en GNU/Linux (Ubuntu server 18.04).
◄ 1 2 3 4 5 6 7 8 9 10 ►
INSTALACIÓN DE OPENLDAP EN GNU/LINUX

Primero debemos obtener un servidor GNU/Linux.Esta instalación se ha realizado sobre una distribución Ubuntu
18.04:http://www.ubuntu.com/
Ubuntu Teamwork (Dominio público)
PASOS PREVIOS
Una vez instalamos Ubuntu 18.04 con un entorno gráfico, pasamos a configurar nuestro sistema con IP fija. Del
mismo modo que asignamos una IP fija, definimos un dominio de búsqueda en la configuración de red.
Las capturas se refieren a un Ubuntu Server 18.04, que utiliza Netplan para la configuración de red.
En nuestro caso, usaremos los siguientes datos:
IP fija 10.0.2.15/24
Puerta de enlace 10.0.2.1
Dominio de búsqueda “bk.com”
Para más información sobre gestión de redes en Ubuntu Server: https://help.ubuntu.com/lts/serverguide/network-

configuration.html
INSTALACIÓN DE LOS PAQUETES

Procedemos a instalar el software slapd y ldap-utils. En distribuciones tipo Debian, como en nuestro ejemplo, se
hace usando el comando
sudo apt install slapd ldap-utils
Nos pedirá solamente una contraseña para el administrador del nuevo dominio, y hace una instalación por
defecto.
Para configurarlo adecuadamente, procedemos a ejecutar
sudo dpkg-reconfigure slapd
Ahora, debemos seguir esta configuración respondiendo NO a “omitir la configuración del servidor OpenLDAP”.
Posteriormente, introducimos la DNS para nuestro dominio (bk.com, en nuestro ejemplo)
Después, nos pedirá la clave para el nuevo administrador del dominio, que tendremos que introducir por
duplicado.
Acerca del motor de Base de Datos que usará para el esquema de LDAP, dejaremos el que está por defecto, y
en la última pregunta borraremos la BD.
CONFIGURACIÓN BÁSICA
Siguiendo las indicaciones de la versión correspondiente, pasamos a revisar el esquema de LDAP y preparar el
directorio para trabajar con él.https://help.ubuntu.com/lts/serverguide/openldap-server.html
Qué es un “schema”: Son paquetes que contienen la definición de todos los objectclass y atributos. Usando el
siguiente comando, vemos los ficheros que componen el esquema básico de OpenLDAP:
ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

DANDO FORMA A LDAP

Ahora, comenzaremos a poblar nuestra Base de Datos. Crearemos unidades organizativas para nuestros
usuarios y grupos, un usuario (John Doe) y un grupo (miners).Siguiendo con el ejemplo de la página de Ubuntu
https://help.ubuntu.com/lts/serverguide/openldap-server.html, creamos el archivo add_content.ldif y realizamos los
siguientes cambios en el archivo:
dn: dc=example,dc=com dn: dc=bk,dc=com
dn: cn=admin,dc=example,dc=com dn: cn=admin,dc=bk,dc=com
userPassword: secret userPassword: {SSHA} CLAVE
dn: ou=People,dc=example,dc=com dn: ou=usuarios,dc=bk,dc=com
dn: ou=Groups,dc=example,dc=com dn: ou=grupos,dc=bk,dc=com
GRUPOS: GRUPOS:
dn: cn=example,ou=Groups,dc=example,dc=com dn: cn=grupo,ou=grupos,dc=bk,dc=com
objectClass: posixGroup objectClass: posixGroup
cn: example cn: grupo
gidNumber: 10000 gidNumber: 10000
ldapadd -x -D cn=admin,dc=bk,dc=com -W -f add_content.ldif
INTRODUCCIÓN DE DATOS EN LDAP

Una vez introducimos el comando que aparece al final de la tabla anterior, vemos cómo se crean los objetos, y
también mostramos uno de ellos en pantalla, con el comando:
ldapsearch -x -LLL -b dc=bk,dc=com 'uid=john' cn gidNumber

Para ver un resumen de todo lo que hay en nuestro directorio, usaremos el comando:
sudo ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b dc=bk,dc=com dn
SOFTWARE CLIENTE
Podemos realizar la configuración del dominio a través de las herramientas LDAP o bien podemos instalar más
software de utilidades.
En nuestro caso instalaremos el paquete ldap-account-manager (https://www.ldap-account-manager.org), y jxplorer

(http://jxplorer.org/)
El primero es una aplicación escrita en PHP. Con lo cual necesitamos tener habilitado un servidor web, por
ejemplo Apache, con soporte PHP con LDAP.
En el segundo caso es una aplicación de escritorio hecha en Java.
Instalación de jxplorer:
apt-get install jxplorer

Instalación de LAM:
apt-get install ldap-account-manager
Para acceder a la aplicación, se hace a través de la url: http://localhost/lam/
LDAP ACCOUNT MANAGER: CONFIGURACIÓN GENERAL

Para configurar LAM, sigo los pasos detallados aquí. Hay que entrar primero en “LAM Configuration”, y “Edit
General Settings”. La contraseña por defecto es “lam”. En esta ventana, simplemente cambiaremos el “master
password” por otra clave más segura.

LDAP ACCOUNT MANAGER: PERFILES DEL SERVIDOR
Lo siguiente es entrar en “Edit server profiles”, que es más importante. La contraseña para esta parte de la
interfaz vuelve a ser la que tiene este software por defecto, “lam”, aunque la hayamos cambiado ya en “Edit
General Settings”.Esta otra contraseña también tendremos que cambiarla por otra más segura.
En la pestaña “general settings”, lo que tendremos que modificar es lo siguiente:
Tree suffix: ahí tendremos que poner los datos de nuestro dominio; en nuestro caso, “dc=bk,dc=com”.
Language settings: seleccionamos el idioma español.
Security settings: debemos editar el nombre del usuario, recordando cuál era nuestro administrador:en mi
caso, “cn=admin,dc=bk,dc=com”
New password/Reenter password: cambiamos la contraseña maestra. A partir de ahora, será la que
utilicemos para entrar en estas opciones. No tiene por qué ser la misma que utilicemos para entrar al
dominio; son cosas distintas.
Volvemos a la pantalla de inicio de la interfaz, pero ahora está en castellano. Todavía no hemos terminado con la
configuración, así que volvemos a los perfiles del servidor, eso sí, con la última contraseña que introdujimos.
Ya sólo nos queda modificar, en la pestaña “Tipos de cuentas”, las unidades organizativas que vamos a utilizar,
para que sean las mismas que definimos previamente. Vemos que hay definidas algunas; lo que haremos será
modificar los valores por defecto para que coincidan con los de las que creamos antes, como se ve en la captura.
Admite otras configuraciones relacionadas con Samba, pero eso lo dejamos para otra ocasión.
Por último, entramos a través de la interfaz principal con nuestra contraseña del usuario “admin”, y vemos cómo
funciona realmente este software:
JXPLORER
Con Jxplorer, a la hora de conectar, nos encontramos con esta ventana. Para el dominio bk.com y su
administrador, esta sería su configuración:
Una vez introducida correctamente la clave, obtendremos el árbol que se muestra en la imagen.
Reflexiona
Las instalaciones de LDAP en sistemas operativos GNU/Linux, suelen tener ciertas diferencias con respecto a las
configuraciones especificadas por la web de openLDAP. Debemos visitar la página oficial de la distribución para observar
las diferencias y seguir sus indicaciones y así conseguir instalar, adecuadamente, el servicio LDAP.
Autoevaluación
Cuando se procede a realizar la instalación de un controlador de dominio debemos indicar el dominio que va a
gestionar.
Verdadero.
Falso.
Es correcto. Cuando realizamos la instalación, el controlador debe conocer qué dominio va a gestionar.
No es correcta, deberías repasar el proceso de instalación de los ejemplos.
Solución
1. Opción correcta
2. Incorrecto
5.2.- Configuración.
En primer lugar, deberemos tener organizadas las unidades organizativas, los grupos, los usuarios y los recursos.
Posteriormente, debemos configurar todas las interfaces necesarias para que este servicio esté disponible desde una conexión remota.
Por ejemplo, desde otro equipo que actúe como cliente. Recuerda que estamos en una arquitectura cliente/servidor.
¿Qué significa "configurar todas las interfaces necesarias"? Pues realizar tareas como:
Configuración del Protocolo de Internet (IP).

Activar la conexión de red durante la instalación.
Conexión "Siempre encendido". Sólo si queremos proporcionar a los clientes acceso a Internet.
Configuración DNS.
Conexiones de cliente.
NetBIOS sobre TCP/IP. Sólo Active Directory.
Paquete de cifrado elevado y software de conexión a Internet. Sólo Active Directory.
Para el caso de Active Directory, este servicio integra todo en el sistema del dominio. Es decir, no debemos realizar ninguna tarea salvo
asignar la clave, en la instalación, del usuario administrador. Todo el sistema de recursos lo gestiona directamente su LDAP.
En el caso de LDAP para GNU/Linux cambia radicalmente el concepto y la configuración. ¿Por qué? Porque LDAP realmente lo trata
como servicio y las tareas que debemos realizar serán delegar los servicios que deseamos integrar para que los gestione LDAP. ¿Qué
tareas debemos realizar? En primer lugar, migrar los usuarios y grupos del sistema como parte integrante del LDAP.
Para saber más

En el ejemplo siguiente, veremos cómo configurar AD para conectarse desde una máquina que actúa de cliente.
◄ 1 2 3 4 5 6 7 8 9 ►
CONFIGURACIÓN DE ACTIVE DIRECTORY

Active Directory viene, prácticamente, configurado para su uso nada más instalarse.
A diferencia del LDAP para GNU/Linux, el Active Directory viene, por defecto, con una serie de unidades de
organización, grupos y usuarios.

CREACIÓN DE UNA UNIDAD ORGANIZATIVA
Lo primero que vamos a hacer es crear un grupo y varios usuarios dentro de una unidad organizativa (aunque no
es imprescindible, porque podemos usar los que ya existen previamente)
¿Cómo?
Nos situamos sobre el dominio con el ratón, pulsamos botón derecho y seleccionamos Nuevo -> Unidad
Organizativa.
Windows Server (Elaboración previa)
Damos nombre a la Unidad Organizativa (Conviene NO proteger la unidad por si tenemos que eliminarla)
CREACIÓN DE USUARIOS
Realizamos la misma operación que en la creación de una UO, seleccionando la opción de usuario nuevo.
A continuación, pondremos el nombre del usuario y su "login", o nombre de inicio de sesión.

Y, por último, ponemos la contraseña (por duplicado) y configuramos algunas opciones para la cuenta.
CREACIÓN DE GRUPOS DE SEGURIDAD

Pulsando en la OU donde queramos que esté ubicado, creamos el grupo de seguridad.
AÑADIR USUARIOS A UN GRUPO

Para agregar usuarios a un grupo, basta con seleccionarlos y usar la opción "Agregar a un grupo" en el menú de
contexto. Puede hacerse con un usuario o con varios a la vez.
Una vez dada la orden, tenemos que seleccionar el grupo al que queremos añadir los usuarios. Para ello,
podemos usar la herramienta de búsqueda de grupos de Windows, muy sencilla de manejar.
Una vez terminemos, aparecerá un cuadro de diálogo indicando que se ha hecho con éxito.
CONFIGURACIÓN DE RED DEL CLIENTE

Utilizaremos como cliente Windows 10; podemos descargar una versión de evaluación aquí:
https://www.microsoft.com/es-es/software-download/windows10. Es importante usar una edición de Windows 10
distinta de Home, ya que ésta no puede ser cliente de AD.
Indicamos, en la interfaz de red, una IP que esté en la misma red que el servidor; y como DNS principal,
ponemos la dirección correspondiente a nuestro servidor Windows Server.
Windows (Elaboración propia)
AGREGAR EL CLIENTE AL DOMINIO
En el menú de inicio, escribimos “Dominio” y abrimos la herramienta que aparece como “Obtener acceso al
trabajo o la escuela”.
Windows 10 (Elaboración propia)
Ahora pulsamos “conectar” y después “Unir este dispositivo a un dominio local de Active Directory”
CREDENCIALES DE DOMINIO
A continuación, introducimos las credenciales del dominio: DNS del mismo, nombre de usuario con privilegios
administrativos (administrador, habitualmente), y clave. Una vez haya completado toda la información, solicitará
un reinicio del sistema.
INICIO DE SESIÓN EN EL DOMINIO

Una vez reiniciemos, habrá concluido el proceso. Ahora nos pedirá usuario y clave dentro de los registrados en el
dominio; podemos entrar con cualquier usuario de los creados anteriormente.
A continuación, verás la configuración del servicio LDAP en GNU/Linux (Ubuntu Server 18.04), probando su conectividad
desde un equipo cliente.
◄ 1 2 3 4 5 6 7 8 9 10 11 12 13 ►
CONFIGURACIÓN DE LDAP
La información en LDAP se gestiona a través de ficheros en formato ldif, que es en el que se almacenan las
entradas de directorio.
Los comandos para manejar dicho directorio son: ldapsearch, ldapadd, ldapmodify, ldapdelete.
Sus parámetros comunes son:
-b DN DN base desde donde se realiza la búsqueda.
-D DN DN del usuario con el que nos autenticamos.
-h Host Host del servidor LDAP.

-p Puerto Puerto del servidor LDAP.
-w Clave Clave para una autenticación simple.
-x Autenticación simple.
INTEGRACIÓN DE LOS USUARIOS DEL SISTEMA EN

LDAP
En cualquier sistema GNU/Linux, podemos tener nuestra configuración de usuarios locales previamente a instalar
LDAP. Vemos a continuación algunos de esos usuarios locales (aquellos que no son automáticos, sino que nos
permiten iniciar sesión y trabajar con ellos), gracias al comando cat /etc/passwd |grep bash
Si tenemos intención de integrar esos usuarios con LDAP, podemos hacerlo gracias a las "migration tools".
Instalación:
apt install migrationtools
Hay que modificar el archivo /etc/migrationtools/migrate_common.ph con los datos de nuestro dominio:
#Default DNS domain
$DEFAULT_MAIL_DOMAIN = “bk.com";
……
# Default base
$DEFAULT_BASE = "dc=bk,dc=com";
……
# turn this on to support more general object clases such as person.
$EXTENDED_SCHEMA = 1;
Para la migración, es necesario generar una serie de ficheros que nos permitirán la migración de usuarios,
grupos y claves.
#migramos el sistema base
/usr/share/migrationtools/migrate_base.pl > /etc/ldap/base.ldif
#migramos los grupos
/usr/share/migrationtools/migrate_group.pl /etc/group /etc/ldap/group.ldif
#migramos los usuarios

/usr/share/migrationtools/migrate_passwd.pl /etc/passwd /etc/ldap/passwd.ldif
FICHEROS LDIF GENERADOS

Entradas significativas del fichero base.ldif:
Hay que modificar los valores relacionados con nuestro dominio.
#sistema base.
dn: dc=bk,dc=com
dc: bk
objectClass: top
objectClass: domain
dn: ou=Hosts,dc=bk,dc=com
ou: Hosts
objectClass: top
objectClass: organizationalUnit
dn: ou=Rpc,dc=bk,dc=com
ou: Rpc
objectClass: top
dn: ou=Services,dc=bk,dc=com
ou: Services
objectClass: top
………………………. (más)
Entradas significativas del fichero group.ldif:
Hay que modificar los valores relacionados con nuestro dominio; además, el nombre de la UO para usar la que
ya teníamos creada (grupos), y dejaremos sólo aquellos grupos que queramos migrar (no hace falta migrarlos
todos)
# El grupo root
dn: cn=root,ou=grupos,dc=bk,dc=com
objectClass: posixGroup
objectClass: top
cn: root
userPassword: {crypt}x
gidNumber: 0
# el grupo bin dn: cn=bin,ou=grupos,dc=bk,dc=com

objectClass: posixGroup
objectClass: top
cn: bin
userPassword: {crypt}x
gidNumber: 2
...
# el grupo usuarios genéricos con gid 1000
dn: cn=usuario,ou=grupos,dc=bk,dc=com objectClass: posixGroup
objectClass: top
cn: usuario userPassword: {crypt}x gidNumber: 1000
FICHEROS LDIF GENERADOS

Entradas significativas del fichero passwd.ldif:
Hay que modificar los valores relacionados con nuestro dominio; además, el nombre de la UO para usar la que
ya teníamos creada (usuarios), y dejaremos sólo aquellos usuarios que queramos migrar (no hace falta migrarlos
todos). Como ejemplo, dos usuarios tipo, el root y otro usuario convencional:
#usuario root
dn: uid=root,ou=usuarios,dc=bk,dc=com
uid: root
cn: root
sn: root
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}*
shadowLastChange: 18295
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 0
gidNumber: 0
homeDirectory: /root
gecos: root
#usuario “usuario”
dn: uid=usuario,ou=usuarios, dc=bk,dc=com
uid:
cn:
objectClass: account
objectClass: posixAccount
objectClass: top
objectClass: shadowAccount
userPassword: {crypt}$1$Rxs0Oeuw$z/
shadowLastChange: 18361
shadowMax: 99999
shadowWarning: 7
loginShell: /bin/bash
uidNumber: 1000
gidNumber: 1000
homeDirectory: /home/usuario
gecos: usuario,,,
INTEGRACIÓN DE LOS ARCHIVOS LDIF EN LDAP

Añadimos las entradas de esos ficheros al directorio LDAP. Con ldapadd, añadimos como administrador (admin),
cada fichero ldif al servidor LDAP de la máquina local.El atributo uidNumber es el identificador (uid) de usuario y el
gidNumber el idetificador (gid) de grupo al que pertenece ese usuario; esa información se mostrará una vez
ejecutemos los comandos.
# Añadimos como administrador al servidor LDAP el fichero base.ldif

ldapadd -x -D "cn=admin, dc=bk,dc=com" -W -f /etc/ldap/base.ldif -h 127.0.0.1
# Añadimos como administrador al servidor LDAP el fichero group.ldif

ldapadd -x -D "cn=admin, dc=bk,dc=com" -W -f /etc/ldap/group.ldif -h 127.0.0.1
# Añadimos como administrador al servidor LDAP el fichero passwd.ldif

ldapadd -x -D "cn=admin, dc=bk,dc=com" -W -f /etc/ldap/passwd.ldif -h 127.0.0.1
NOTA: Si se ha seguido el tutorial anterior, poblando ya nuestro directorio con algunos objetos y OU, debe
modificarse el archivo base.ldif y quitar la primera entrada (la que crea el dominio bk.com).
Y, además, respetar la nomenclatura que usamos antes para las unidades organizativas: en group.ldif, modificar la
unidad organizativa (OU) que pondrá “Group” por “grupos”, por ejemplo; o “Users” por “usuarios”
ESTRUCTURA DE LDAP TRAS LA MIGRACIÓN

Vemos en JXplorer cómo se han portado todos los usuarios del sistema, y todos los grupos.
OTROS ARCHIVOS
Quedan por modificar algunos otros ficheros de nuestro sistema.
Modificamos el archivo /etc/ldap/ldap.conf con los datos de nuestro dominio:
BASE dc=bk,dc=com
URI ldap://ldap.bk.com:666
Modificamos el archivo /etc/hosts, el encargado de la resolución local de nombres, y creamos una nueva entrada:
127.0.0.1 ldap.bk.com
NOTA: Mientras no se modifique la resolución de nombres, DNS, para que resuelva el dominio bk.com,
podemos realizar una resolución local y, en principio, provisional.
CONFIGURACIÓN NSS
NSS es una característica de los sistemas UNIX que permite obtener información sobre nombres de hosts,
contraseñas, usuarios, alias de correo e información sobre los usuarios a partir de distintas fuentes de
información, por ejemplo sistema local, de un servidor NIS, de servidor DNS o LDAP.
La idea es realizar autenticación LDAP a través de la búsqueda en NSS. Para que el cliente pueda realizar
autenticación LDAP, hemos de instalar libnss-ldap, y configurar libnss_ldap.conf y /etc/nsswitch.conf.
apt install libnss-ldap
Nos irá apareciendo unos cuadros de diálogo indicando dónde se ubica el servidor LDAP (en nuestro caso
127.0.0.1 o su IP local), el dominio con el que estamos trabajando, (en nuestro caso bk.com); y nos preguntará
quién es el root de acceso a la base de datos LDAP. En nuestro caso, cn=admin, dc=bk, dc=com. Y, por último,
introduciremos la contraseña.También nos preguntará sobre la versión de LDAP; usaremos la 3.
Pero, ¿y si nos hemos equivocado?. No pasa nada; ejecutamos, en modo comando,

dpkg-reconfigure ldap-auth-config
En las siguientes diapositivas vemos un ejemplo.
CONFIGURACIÓN LDAP-AUTH-CONFIG
En nuestro caso, usaremos la IP local o la de loopback, ldapi:///127.0.0.1
Introducimos nuestro dominio de trabajo, bk.com (el equivalente: dc=bk,dc=com)
Ahora, introducimos la versión de LDAP (3).
CONFIGURACIÓN LDAP-AUTH-CONFIG: BASE DE DATOS

Crear un administrador para gestionar la base de datos. Indicamos NO (cuidado con la imagen, marca la
respuesta incorrecta)
Del mismo modo, indicamos que NO hay que entrar en la Base de Datos LDAP (la imagen marca la respuesta
incorrecta, cuidado).

En la siguiente ventana, introducimos los datos del administrador, que, como bien sabemos, es el usuario admin:
cn=admin,dc=bk,dc=com.
Y la contraseña correspondiente.
Federico Martínez Pérezç (Elaboración propia)
CONFIGURACIÓN LDAP-AUTH-CONFIG (3)

Ahora crearemos un usuario sin privilegios para iniciar sesión en la BD, y su clave correspondiente. Respetamos
el mismo usuario sin privilegios que propone por defecto el asistente, pero con cuidado de que los datos de
nuestro dominio estén bien (cn=proxyuser,dc=bk,dc=com, en nuestro ejemplo).
Ahora, seleccionaremos el sistema de encriptación md5, y con esto, hemos terminado de configurar ldap-auth-config.

CONFIGURACIÓN PAM
Con esto estará configurado NSS. Pero aún nos falta un pequeño detalle, el comando:
#auth-client-config -t nss -p lac_ldap
...que preparará el archivo nsswitch.conf.
A continuación, hemos de configurar PAM, que consiste en una serie de módulos "enchufables"y establece una
interfaz entre los programas de usuario y distintos métodos de autenticación. De esta forma, el método de
autenticación se hace transparente.
Hemos de ejecutar el siguiente comando:
#pam-auth-update
Con ello, conseguiremos que PAM nos autentique con LDAP para distintos mecanismos de autenticación (hay
que marcarlo si no lo está ya).
CONFIGURACIÓN FINAL DEL SERVIDOR

¿Qué función tiene el archivo /etc/nsswitch.conf? Indica en qué orden de búsqueda se sigue para buscar los datos de
inicio de sesión en el sistema.
Por ejemplo: para el apartado
hosts: files dns
Indicará que primero busca en los archivos del sistema correspondientes (en este caso, el fichero hosts) y, si no lo
encuentra, realiza la consulta a un servidor dns.
En el caso que nos ocupa, se utiliza la directiva passwd y shadow.
Deberían quedar como sigue:
passwd: files ldap

shadow: files ldap
Tenemos que editarlo y comprobar que es correcto, de forma que realice las búsquedas primero en los ficheros
(files) passwd y shadow; y, posteriormente, en ldap.
Volvemos a ejecutar el comando para actualizar todo el sistema de claves:

#pam-auth-update
Y también instalaremos algunos scripts de utilidades, por si queremos usarlo en lugar de las interfaces gráficas:
#apt-get install ldapscripts
Como último paso a realizar con el servidor, modificaremos el fichero /etc/ldap.conf. En dicho fichero, debemos
modificar nuestro nombre de dominio y comprobar los datos siguientes:
host 127.0.0.1 //nombre o IP del servidor LDAP

base dc=bk,dc=com
ldap_version 3
rootbinddn cn=admin,dc=bk,dc=com
nss_base_passwd ou=usuarios,dc=bk,dc=com?one
nss_base_shadow ou=usuarios,dc=bk,dc=com l?one
nss_base_group ou=grupos,dc=bk,dc=com?one
◄ 1 2 3 4 5 6 ►
PRUEBA EN UN CLIENTE LINUX

Instalamos una segunda máquina con GNU/Linux en la misma red que el servidor LDAP, y procedemos a darle
de alta. Para ello, nos serviremos de las instrucciones publicadas aquí.
Es importante señalar que, a partir de ahora, todo se hará en el equipo cliente.
Comenzamos por instalar los siguientes paquetes:
libnss-ldap: Permitirá que NSS obtenga de LDAP información administrativa de los usuarios (Información de
las cuentas, de los grupos, información de la máquina, los alias, etc.)
libpam-ldap: Que facilitará la autenticación con LDAP a los usuarios que utilicen PAM.
ldap-utils: Facilita la interacción con LDAP desde cualquier máquina de la red.
Ejecutaremos el comando
apt-get install libnss-ldap libpam-ldap ldap-utils
Este comando da comienzo a la instalación del software, y nos abrirá una serie de ventanas de configuración de
las cuales hablaremos a continuación.
INSTALACIÓN DEL CLIENTE LDAP

En la primera ventana, tendremos que cambiar algunas cosas:
La URI tiene que ser ldap://, NO ldapi:///

La dirección será la ip del servidor, en mi caso ldap://10.0.2.15
En la siguiente pantalla, pondremos nuestro “Distinguished Name” (dn)En nuestro caso, dn=bk,dn=com
INSTALACIÓN DEL CLIENTE LDAP (2)

Usamos el protocolo LDAP v3...
Hacemos que la BD sea administrada por el usuario "root" local...
En el cliente LDAP no es requerido iniciar sesión en la BD.
Y, por ultimo, introducimos las credenciales del administrador de LDAP para dar de alta el equipo en el dominio:
CONFIGURACIÓN DE NSS Y PAM

Modificamos a continuación algunos ficheros:
En el /etc/nsswitch.conf, nos aseguraremos de que en las líneas passwd, group y shadow aparezca la opción “ldap”, como en
la imagen, para que se contemple ese método de inicio de sesión.
En el /etc/pam.d/common-password, nos aseguraremos de borrar la opción use_authtok, que sirve para impedir usar un
segundo método de autenticación cuando falla otro. Suele estar en la línea 26.
CONFIGURACIÓN DE PAM Y NSS

Siguiendo con las normas para PAM, editamos el fichero /etc/pam.d/common-sesión, añadiendo la siguiente línea al final
del fichero:
session optional pam_mkhomedir.so skel=/etc/skel umask=077
Esta línea sirve para que, cuando iniciemos sesión con el usuario y no tenga carpeta personal (“home") en esa
máquina, dicha carpeta sea creada automáticamente, a partir de la plantilla existente en /etc/skel.
Ya sólo nos queda activar el servicio libnss-ldap, que se encargará de poner en marcha la autenticación, usando el
comando
service libnss-ldap start

INICIO DE SESIÓN EN EL CLIENTE
Normalmente, nuestro cliente GNU/Linux nos solicitará el nombre de usuario y la contraseña cuando iniciemos
sesión. En este caso, usaremos un nombre de usuario que sólo esté en LDAP, y que no exista en el cliente como
local.
En la captura, podemos ver varias cosas:
El usuario con que hemos iniciado sesión no está en el fichero passwd (usuario “fede”)
La sesión está correctamente iniciada
5.3.- Personalización.
¿Qué significa "personalizar" un servicio? La personalización es el acto de adaptar el resultado en primer
lugar a la instalación y posterior configuración general, y en segundo lugar adaptarlo a las necesidades
requeridas.
Pongamos un ejemplo, con el AD necesitamos que los usuarios accedan, desde un terminal, a su área de
trabajo asignando una unidad lógica para los datos de dichos usuarios. Bien, pues debemos lanzar la
herramienta para gestionar los usuarios y equipos de AD y realizar las tareas que nos conduzcan a cumplir
con los requisitos necesarios.
Otro ejemplo más: si tenemos una máquina con servidor Ubuntu y queremos configurar la autenticación en
LDAP: dpkg-reconfigure ldap-auth-config, podremos modificar cómo queremos que se realice la autenticación.
Tawel (CC BY-NC-SA)
Más ejemplos. Pongamos el ejemplo de un servidor GNU/Linux con el servicio LDAP instalado. Tendremos
también, Samba, para poder acceder desde máquinas Windows. Si deseamos que el servidor GNU/Linux
actúe como PDC debemos personalizar el servicio Samba teniendo en cuenta que debe estar debidamente conectado al servicio
LDAP. Habrá que comprobar los requisitos necesarios para que actúe como controlador de dominio.
6.- Integración del servicio de directorio con otros servicios.
Caso práctico
Una vez que Noiba, Naroba y Jana han instalado el LDAP, configurado todo el esquema y probado
las credenciales de los usuarios, deberán pasar a la fase de los servicios que controlará el servicio
LDAP.
Deben tener especial cuidado en el aspecto de seguridad. No deben dar ciertos permisos no
controlados y obtener accesos no deseados.

SA)
Ya se ha mencionado anteriormente que LDAP es un servicio independiente. Y debemos tener otros servicios
como, por ejemplo, servidor FTP, servidor de correo electrónico, SMTP y/o POP3/IMAP, etc. Para obtener las
ventajas de dicho servicio, debemos estimar cuáles deseamos integrar dentro del LDAP.
Pongamos un ejemplo.
El servidor FTP cuando un usuario intenta conectarse al servidor FTP lo hará con unas credenciales. Estas
credenciales, por defecto, estarán integradas en el sistema. Si el usuario "juan" con contraseña "SanTanDer"
quiere acceder a su área de trabajo, utilizará un cliente FTP, introducirá su usuario y contraseña, y, si es
correcto, accederá a su área de trabajo.
El usuario y su correspondiente contraseña, en sistemas operativos GNU/Linux, se encuentran en los archivos

"/etc/passwd" y "/etc/shadow".
Youssefdahmani (CC BY-SA)
Utilizando el servicio LDAP como soporte para las credenciales de los usuarios, el usuario que intente acceder
a su área de trabajo, estará en la base de datos del sistema o en la base de datos del servicio LDAP. Para conseguir esto, debemos
indicar en la configuración del servicio FTP, que busque los usuarios, aparte de en la base de datos del sistema operativo, en la base de
datos que utiliza el servicio LDAP.
En el caso de AD todos los servicios propios del sistema operativo se integran automáticamente. Sólo debemos tener en cuenta
aquellos que no son propios del sistema operativo. Por ejemplo, si instalamos el servidor Apache, es posible que no lo integre en el AD y
tenemos que realizarlo nosotros manualmente.
Autoevaluación
El servicio LDAP es un servicio que integra, de forma automática, otros servicios.
Verdadero.
Falso.
No es correcto. En el caso de Windows se integran parte, pero no todos.
Muy bien. Son servicios independientes.
Solución
1. Incorrecto
2. Opción correcta
7.- Filtros de búsqueda.
Caso práctico
Cuando queremos realizar búsquedas de un objeto, o entradas en el directorio, en concreto
debemos acotar las restricciones de búsqueda. Es decir, cuando buscamos una entrada en el
árbol de directorio es porque no sabemos dónde ubicarla. Pero podemos "intuir" por dónde
buscar.
Vindio le pone un ejemplo a Jana:
—Si buscamos en un listín telefónico el número de teléfono de Juan Martínez que sabemos que
vive en la calle Juan Fernández. Buscamos alfabéticamente por la "M" y después seguimos por
los apellidos hasta encontrarnos con "Martínez". Como habrá muchos (es un apellido muy común)
Alain Bachellier (CC BY-NC-SA) comprobaremos aquellos que vivan en la calle "Juan Fernández".
¿Hemos acotado la búsqueda? —pregunta Vindio
— Sí, hemos restringido la búsqueda teniendo en cuenta los datos que ya conocemos —responde Jana.
Pues de eso se trata, restringir las búsquedas mediante filtros, mediante restricciones con información que ya disponemos. Cuanta más
información tengamos, menor cantidad de resultados nos dará y será más fácil encontrar el objeto que buscamos.
La búsqueda de objetos o entradas al directorio se pueden realizar bien a nivel de comando, o bien con un entorno gráfico que permita
esta opción.
Autoevaluación
¿Para qué podemos utilizar los filtros de búsqueda?
Para gestionar el LDAP.
Para separar los usuarios del sistema del árbol del directorio.
Para buscar un objeto en el árbol de directorio.
Ninguna respuesta es correcta.
No es correcto. Repásalo de nuevo.
No es correcto. Repásalo otra vez.
Muy bien. Encontramos un elemento del árbol mediante un criterio de acotamiento.
No, una de las otras respuestas es la correcta.
Solución
1. Incorrecto
2. Incorrecto
3. Opción correcta
4. Incorrecto
7.1.- Filtros de búsqueda en GNU/Linux.
En un entorno LDAP de GNU/Linux, y en modo terminal, utilizamos el comando ldapsearch. Este comando
abre una conexión a un servidor LDAP, enlaza y hace una búsqueda usando los parámetros especificados.
El comando ldapsearch incluido en las últimas versiones de OpenLDAP tiene esta sintaxis:
ldapsearch [opciones] [filtros [atributos_a_recuperar]]
Debemos entender por filtro la condición que se debe cumplir para la búsqueda de entradas. Tamorlan (CC BY)
Parámetros obligatorios:
-b basedn: especifica el DN base para las búsquedas.
-s scope: alcance de la búsqueda: base, one ó sub.
Parámetros opcionales:
-A: sólo muestra los nombres de los atributos (no los valores).
-a deref: referencias a los alias: never, always, search, or find.
-B: permite imprimir valores no-ASCII.
-D binddn: cuando se autentica con un directorio, permite especificar la entrada binddn. Usar con la opción -w password.
-d debug level: nivel de debug.
-E "character_set": especifica la página de codificación de caracteres.
-f file: ejecuta la sentencia de búsquedas archivadas en el archivo file.
-h ldaphost: conecta al servidor LDAP en la dirección ldaphost. El valor por defecto es localhost.
-L: muestra las entradas en formato LDIF.
-l timelimit: cuenta atrás en segundos antes de abandonar una búsqueda.
-p ldapport: conecta al servidor en el puerto TCP especificado en ldapport. Por defecto conecta en el puerto 389.
-S attr: ordena los resultados por el atributo indicado.
-v: modo extendido.
-w passwd: especifica la contraseña para hacer el bind (para autenticación simple).
-z sizelimit: especifica el número máximo de entradas que pueden ser mostradas.
Un ejemplo completo con el comando:
ldapsearch -LLL -h localhost -p 389 –x -D "cn=admin,dc=bk,dc=com" -w claveAdmin -b "ou=usuarios,dc=bk,dc=com"
¿Qué significa toda la línea?
-LLL: define el tipo de formato LDIF que entregará el comando. Las tres L permiten obtener una salida que es importable a través
de los comandos de manipulación LDIF adecuados.
-h localhost: corresponde al host donde se encuentra el árbol. En nuestro caso, nuestra propia máquina.
-p 389: el puerto sobre el que atiende el servidor.
-D "cn=admin,dc=bk,dc=com": indica la entrada (usuario) a la que nos uniremos para hacer las consultas. Esto es especialmente
importante, como es lógico, para los árboles LDAP que no permiten ingresos anónimos.
-w claveAdmin: la contraseña para el bind con el dato anterior. Junto con la clave, el usuario presenta las credenciales de
autenticación que deberían permitir la búsqueda.
-b "ou=usuarios,dc=bk,dc=com": la base de búsqueda.
Otros ejemplos:
ldapsearch -x –h localhost –x –b 'dc=bk,dc=com' 'cn~=profesores' cn sn mail
Busca entradas al directorio que sea parecido a profesores. Sólo mostrará el atributo cn, sn y mail. Si no se marcan los atributos que
queramos ver, se mostrarán todos. El último valor, 'cn~=profesores' busca una entrada similar a "profesores".
Si sustituimos el filtro por, por ejemplo, 'cn=*jos*' nos mostrará todas las entradas que contengan las letras "jos".
La forma de expresar consultas complejas en LDAP es a través de notación prefija, en la que el operador lógico se antepone. Los
operadores válidos son !, | y & , para NOT, OR y AND respectivamente. Podemos utilizar diferentes tipos de consulta. Igualdad: (cn=Juan);
Presencia: (uid=*); Subcadenas: (sn=J*); Semejanza: (ou~=Joan)
Ejemplo de uso: (|(cn~=Pedro)(cn=Peter)) : Que tenga el atributo cn parecido a Pedro o sea igual a Peter.
No debemos olvidar que, al tratarse de un comando, podemos combinarlo con otros y obtener una búsqueda más filtrada.
Por ejemplo:
ldapsearch -x | grep 'mail:' | cut -d " " -f 2 > pp; echo $(cat pp | awk '{print $1"," }') > email
Explicación: el archivo email contendrá la lista de todos los e-mail, separados por comas "," y en una sola línea.
7.2.- Filtros de búsqueda en Windows Server.
Y, ¿en Windows? La forma habitual de trabajar con Windows es con interfaz gráfica; aún así, existe la posibilidad
de utilizar Windows Server Core (sin interfaz gráfica) y, obviamente, tenemos a nuestra disposición comandos que
pueden sernos de utilidad para realizar búsquedas restringidas mediante filtros.
Encontramos dos tipos de comandos a la hora de trabajar desde terminal con Windows Server: la línea de
comando tradicional, basada en el antiguo MS-DOS y el intérprete command.com, y la novedosa PowerShell, un
intérprete de comandos completo, orientado a objetos y basado en .NET.
Uno de los comandos que usa la línea de comando tradicional, es dsquery. Pongamos un ejemplo:
kn (CC BY-SA)
dsquery user -name usua*|dsget user –samid -upn
Busca, en el árbol de directorio, a todos los usuarios que comiencen por "usua". Además, muestra el nombre de usuario (-samid) y el
nombre principal de usuario (-upn).
Otro ejemplo: dsquery user "dc=bk,dc=com" obtendríamos las entradas al árbol del AD. Es decir, una salida como la siguiente:
En las últimas versiones de Windows Server, se conservan estos comandos por una cuestión de compatibilidad, y se anima al
administrador a trabajar directamente con PowerShell.
Este intérprete de comandos funciona a través de los "cmdlets", que utilizan una gran cantidad de argumentos y opciones. Veamos
algunos de ellos, junto con la página del manual técnico de Microsoft correspondiente:
https://docs.microsoft.com/en-
Conseguir información de
Get-ADUser us/powershell/module/addsadministration/get-aduser?
usuarios
view=win10-ps
Get-ADGroup us/powershell/module/addsadministration/Get-ADGroup?
grupos
view=win10-ps
Get-ADComputer us/powershell/module/addsadministration/get-adcomputer?
Equipos
view=win10-ps
Conseguir información de todo
Get-ADForest us/powershell/module/addsadministration/get-adforest?
el dominio
view=win10-ps
Por ejemplo, para mostrar toda la información (muy completa, varias páginas) de un usuario llamado "john":
Get-ADUser john -Properties * | more

Para saber más

Podemos aprender mucho más sobre gestión de usuarios con PowerShell en éste enlace.
Y en éste otro,sobre gestión de grupos.

8.- Objetos que administra un dominio.
Caso práctico
Noiba, Naroba y Jana ya han instalado el LDAP, configurando los servicios que gestiona,
etc. Deben organizar los objetos que administrará nuestro LDAP. Cómo estructurarlos, quién
gestionará esos objetos. Ya sabemos que el administrador puede delegar funciones; a quién
delegaremos, qué delegaremos y cómo delegaremos.
¿Por qué? Porque las delegaciones tienen una propiedad que es la herencia. Y si no
afinamos, podemos tener un problema de acceso.
Los objetos que administra un dominio son: organizaciones, unidades organizativas, grupos, usuarios,
equipos.
Asimismo, puede gestionar servicios. En el caso de un servidor Windows, se realiza de forma automática.
En el caso de OpenLDAP no.
¿Por qué AD sí y OpenLDAP no? El AD es parte integrante del Sistema Operativo del servidor Windows.
Sin embargo, OpenLDAP no, es un servicio independiente en las mismas condiciones que el resto de
servicios. Para darle utilidad debemos configurar el servicio OpenLDAP para que gestione otros servicios y
también debemos configurar estos los servicios para que acepten la gestión de su servicio por otro.
Mano tecleando (Dominio público)
Tomemos como referencia el AD de Windows Server en sus diferentes versiones.
El Directorio Activo es una base de datos jerárquica de objetos, que representan las entidades que pueden
administrarse en una red de ordenadores, o más correctamente en nuestro caso, en un dominio de sistemas Windows Server. Esta base
de datos de objetos de administración es compartida, para consultas, por todos los equipos que son, a su vez, miembros del dominio y
para modificación, por todos los controladores del dominio (o DC). Hay que añadir, a esto último, que puede existir lo que se denomina
relación de confianza entre dominios de tal manera que un controlador de dominio puede llegar a gestionar el Directorio Activo de otro.
Por tanto, en Windows Server, la gestión de un dominio puede realizarse de forma centralizada, administrando únicamente el Directorio
Activo. En este contexto, "administrar" significa crear y configurar adecuadamente los objetos del directorio que representan a las
entidades o recursos que existen en el dominio: usuarios, grupos, equipos, etc.
Autoevaluación
El administrador de un controlador de dominio Windows Server puede administrar de forma remota cualquier
equipo conectado a la red.
Sí, si está dentro de la difusión.

Sí, si está integrado en el dominio.
Sí, si el cortafuegos se lo permite y está integrado en la base de datos del controlador de dominio.
No, porque el administrador no está dado de alta en el equipo local.
Incorrecto. No sabemos si el equipo está en la base de datos del dominio.
No es correcto y lo vas a entender. El cortafuegos del propio equipo puede impedir este tipo de acceso externo.
Muy bien. Has captado la idea.
No es la opción correcta. El administrador del dominio tiene suficiente entidad para administrar todos los equipos
integrados en su base de datos. Siempre y cuando el cortafuegos lo permita.
Solución
1. Incorrecto
2. Incorrecto
3. Opción correcta
4. Incorrecto
8.1.- Usuarios globales.
Los controladores de dominios suelen venir, predeterminados, con un conjunto determinado de usuarios
calificados como globales. ¿En qué consisten y cuál es su misión? En Windows Server aparecen usuarios de
carácter global como son los administradores.
Estos usuarios tienen una función determinada, con unos derechos y privilegios sobre los objetos del dominio
predeterminados.
Pongamos un ejemplo. El usuario administrador del AD es el encargado de gestionar todo el árbol del directorio.
Esto es, crear objetos como grupos, usuarios, etc.; asignar recursos y derechos y privilegios de éstos, los
recursos, a los distintos grupos y usuarios. También tiene asignado tareas de mantenimiento del servidor.
También podremos observar un usuario, invitado, que aparece por defecto deshabilitado.
Jakub Steiner (Dominio público) ¿Quiere esto decir que sólo el usuario administrador puede realizar tareas de administración? No, el propio
administrador puede asignar o delegar tareas a otros usuarios. Puede delegarle todo o partes.
¿Sólo pueden ser usuarios globales los que están definidos en la instalación? No, podremos añadir usuarios con esas características y
utilizarlos siguiendo un esquema predeterminado por el administrador del sistema. Pongamos un ejemplo: podremos crear un usuario,
admonprinter, al que deleguemos el mantenimiento de las impresoras conectadas al servidor. Esto quiere decir, gestionar las impresoras
así como sus colas de impresión, etc.
Para asignar estos privilegios al usuario, podemos actuar de dos maneras:
Haciendo al usuario "admonprinter" miembro de un grupo que le de esos privilegios (en este caso, el grupo "Operadores de
impresión"). Este tipo de grupos son creados automáticamente junto con el dominio.
Asignando directamente estos privilegios. a través de las llamadas directivas de grupo.
En esta imagen podemos observar cómo hay, después de realizar la instalación de un sistema
operativo Windows Server, un objeto (unidad organizativa) llamado "users" en el que están englobados
todos los grupos y usuarios predeterminados del sistema.
En el caso de Windows, el administrador del AD también administra el sistema de forma global. Hay una
"fusión" entre el servicio LDAP y el sistema.
Sin embargo, en GNU/Linux no ocurre lo mismo. Por defecto, el usuario administrador del servicio
LDAP, habitualmente llamado admin o manager, no tiene por qué administrar el sistema en su conjunto. Windows Server (Elaboración propia)
Esa labor le corresponde al usuario "root".
Para saber más

Los usuarios de AD son objetos con muchísimas posibilidades y opciones. Algunas de ellas:
Se puede asignar un horario permitido de inicio de sesión, limitando así cuándo podrán conectarse determinados
usuarios.
Se puede limitar los equipos a los que un usuario puede acceder.
Comprobar a qué grupos pertenece un usuario.
Recuperación / modificación de contraseñas.
Deshabilitar / habilitar una cuenta (y asignarle fecha de caducidad).
Copiar cuentas de usuario.
Eliminarlas.
Para aprender todo esto y más, puedes visitar el siguiente enlace:
Operaciones frecuentes con usuarios en AD

8.2.- Grupos.
En el caso de los grupos ocurre otro tanto. Tendremos un conjunto de grupos predeterminados con una
serie de funciones, privilegios y derechos.
Por ejemplo, un servidor Windows crea automáticamente una serie de grupos locales que pueden
contener cuentas de usuario, cuentas de usuario de dominio, cuentas de equipos y otros grupos
globales.
Podemos definir tres tipos de grupos en AD:
Grupos locales del dominio : En un dominio en modo mixto, pueden coexistir cuentas de usuario
Clker-Free-Vector-Images (Dominio público)
y grupos globales de cualquier dominio del bosque. En un dominio en modo nativo, pueden
contener además grupos universales y otros grupos locales del dominio. Sólo son visibles en el
dominio en que se crean, y suelen utilizarse para conceder permisos y derechos en cualquiera de los ordenadores del dominio (en
modo mixto, sólo son visibles por los DC del dominio, y por tanto sólo se pueden utilizar para administrar permisos y derechos en
esos ordenadores).
Grupos globales: En un dominio en modo mixto, pueden contener cuentas de usuario globales del mismo dominio. En un
dominio en modo nativo, pueden contener además otros grupos globales del mismo dominio. Son visibles en todos los dominios
del bosque, y suelen utilizarse para clasificar a los usuarios en función de las labores que realizan.
Grupos universales: Sólo están disponibles en dominios en modo nativo. Pueden contener cuentas de usuario y grupos
globales, así como otros grupos universales, de cualquier dominio del bosque. Son visibles en todo el bosque.
En el caso de OpenLDAP, no tendrá grupos definidos. Sólo obtendremos un usuario, el administrador. Lo que debemos realizar es una
parte que sí hace el AD. ¿Cuál es? La migración de usuarios y grupos del sistema a usuarios y grupos de OpenLDAP.
Para saber más

En AD, existen un montón de grupos predefinidos creados para facilitar la labor de administración. Estos grupos tienen
asignados unos determinados privilegios que se hacen extensibles a todos los usuarios o grupos miembros. Puedes ver
cómo se hace aquí.
También se pueden asignar estos privilegios de forma directa, a través de las Directivas de Grupo. Sobre ellas hablaremos
más adelante.
8.3.- Unidades Organizativas.
No debemos olvidar las unidades organizativas. ¿Qué son y para qué se utilizan? Las unidades
organizativas, cuyo acrónimo es OU, son objetos del directorio que pueden contener otros objetos. El
uso fundamental de las OU es organizar de forma lógica los objetos de un dominio. Además, podemos
utilizarlos para delegar derechos y privilegios que competen a la administración los objetos
seleccionados a otros usuarios distintos del administrador del dominio, y personalizar el comportamiento
de los usuarios y/o equipos mediante la aplicación de directivas específicas a la unidad.
RRZEIcons (CC BY-SA)
Para saber más

La delegación de derechos y privilegios nos permite repartir tareas entre distintos usuarios sin tener que hacerlos a todos
administradores. ¿Por qué?
Por cuestiones de seguridad, es recomendable que sólo tengamos un administrador. De hecho, es recomendable
deshabilitar el usuario administrador creado por defecto y crear otro con diferente nombre, para dificultar posibles
ataques.
La organización a gestionar puede llegar a ser bastante grande. Por ejemplo, una empresa con muchos
departamentos. Podemos tener un empleado encargado de administrar cada uno de esos departamentos,
organizados a través de OU, y que sería capaz de gestionar, por ejemplo, los usuarios de esa OU. De esta manera,
descargamos de trabajo al administrador principal.
Para más información, puedes visitar éste enlace.

8.4.- Directivas de Grupo (GPO).
Una herramienta primordial en la administración de AD es, sin duda, el uso de las Directivas de Grupo (GPO).
Mediante las GPO se pueden personalizar muchísimos detalles dentro de AD:
Detalles personalizados del entorno de trabajo: fondo de escritorio, aplicaciones pre-instaladas en los clientes, configuración
personalizada de programas como Chrome o Internet Explorer, carpetas de perfil personalizadas, restricciones en el escritorio y en
los menús de trabajo, configuración del panel de control (red, impresoras)...
Configuraciones de seguridad: configuraciones de contraseña, control de los cortafuegos de la red, bloqueo de aplicaciones,
privilegios administrativos para usuarios y grupos, elevación automática de privilegios,...
Auditorías del sistema, para controlar los eventos que queramos en cualquier equipo de la red
A la hora de administrarlas, es importante tener en cuenta que hay GPOs que se aplican a usuarios, y otras que se aplican a
equipos.
Se puede personalizar por completo cualquier equipo de la red con sólo hacerlo miembro de AD.
Para saber más

Veamos un ejemplo de personalización de entorno a través de GPO: cambio del fondo de escritorio en todos los equipos
del dominio, y personalización de carpetas de perfil para algunos usuarios.
◄ 1 2 3 4 5 6 7 8 9 10 ►
Administrador de Directivas de Grupo

En primer lugar, abriremos la herramienta encargada de gestionar las GPO, el Administrador de Directivas de
Grupo. Podemos acceder a ella a través del menú "Herramientas" del Administrador del Servidor.
Esta herramienta muestra las distintas divisiones administrativas de nuestro Directorio:
Dominios (caso de haber varios)

Sitios: ubicaciones de red definidas por el administrador: pueden ser equipos conectados por VPN,
distintas sedes de la empresa, aulas con subredes...
Unidades Organizativas.
Herencia
Es importante explicar cómo se propagan las GPO, y cómo se solapan según dónde estén vinculadas. El orden
de ejecución es el siguiente:
1. GPOs locales de equipo (definidas en la herramienta "Directivas de Seguridad Local", disponible en

cualquier equipo Windows)
2. GPOs vinculadas al sitio
3. GPOs vinculadas al dominio
4. GPOs vinculadas a las Unidades Organizativas de primer nivel, luego de segundo nivel, y así
sucesivamente.
Así pues, entendemos que una GPO vinculada en una Unidad Organizativa "machacará" las anteriores que se
apliquen al mismo objeto.
Por ejemplo: creamos una GPO que restringe el acceso a determinadas partes del Panel de Control. Si la
vinculamos a todo el dominio, se aplicará a todos los equipos del dominio, incluidos los Controladores de
Dominio. Podríamos crear una directiva que afecte sólo a dichos Controladores, que haga el efecto opuesto y sí
nos permita ese acceso. Para ello, usaríamos la UO "Domain Controllers" (que es donde se encuentran), y
vincularíamos ahí una GPO específica.
Otra cosa que podemos hacer (y es una buena práctica, sin duda) es bloquear la herencia para esa UO; con lo
cual, las GPO de equipo no alcanzarán a nuestros servidores. Para las directivas de usuario, hemos de tener
especial cuidado a la hora de vincularlas, y evitar aplicarlas a todo el dominio salvo que estemos seguros de que
no habrá problema si se aplican en los servidores.
Creación de GPOs
Para crear GPOs, es muy sencillo, a través del menú de contexto. Lo normal es crearlas y vincularlas
directamente en algún punto de nuestro esquema, pero también pueden ser creadas y vincularlas después donde
queramos. Las GPOs pueden ser vinculadas a uno o varios puntos de nuestro esquema, sin problema.
Windows Server (Elaboración Propia)

Editor de GPOs
Una vez creado el objeto GPO, podemos editarlo. En la edición es donde realmente se le da significado y
funcionalidad al objeto. Es tan sencillo como usar el botón derecho del ratón y seleccionar la opción "Editar".
Un mismo objeto GPO puede ejecutar una o múltiples funcionalidades. Lo recomendable es agrupar con cierto
sentido, facilitando su posterior modificación.
Vemos que hay dos grandes categorías:
Equipos . Las directivas se aplicarán cuando el equipo se arranque o reinicie.

Usuarios . Las directivas se aplicarán cuando el usuario inicie sesión.
Dentro de ellas, encontramos:
Directivas
Configuración de software: instalación automática de software.
Configuraciones de Windows: configuración de seguridad, ejecución de scripts, impresoras, carpetas
de perfil...
Plantillas administrativas: Políticas para configuración de los componentes de Windows, el escritorio,
los menús, configuración del sistema...
Preferencias
Configuración de Windows: Personalización del Registro de Windows, variables de entorno, carpetas
personalizadas, unidades de red...
Configuración del Panel de Control: Usuarios y grupos locales, opciones de energía, impresoras,
servicios, tareas programadas...
A la hora de aplicar las directivas, el sistema suele tardar entre 90 y 120 minutos en su actualización. Para
acortar este plazo, podemos usar el comando gpupdate /force, desde la línea de comando de Windows en modo
administrador. Ésto fuerza la actualización inmediata de las directivas. Es interesante ejecutarlo tanto en el
servidor como en los clientes donde queramos que se aplique la directiva; eso, o esperar.
GPO para el fondo de escritorio

Un ejemplo de directiva podría ser definir un fondo de escritorio común para todos los clientes de nuestro
dominio.
Con este fin, crearemos un GPO asociada a todo el dominio, o a las unidades organizativas donde tenga los
usuarios, y buscaremos la directiva adecuada.
Vemos que se nos pide la ruta donde se va a almacenar el fondo. Es importante señalar, en este punto, que, para
que esté disponible para todo el directorio, tendremos que poner dicho fondo en una carpeta compartida.
Compartir carpetas
Vamos a crear una carpeta compartida para ayudarnos con las directivas. La carpeta la llamaremos "Datos
Dominio".
Es importante definir los permisos adecuados, como se ve en la última pantalla. En este caso, sólo es necesario
leer de la carpeta el fondo, pero si queremos almacenar datos y no sólo verlos, tendremos que modificarlos y dar
acceso de escritura.
Lo siguiente será copiar el fondo de escritorio en la carpeta compartida, y modificar la directiva:

Perfiles de usuario en Windows

Vamos a ver otro ejemplo de GPO bastante útil. Antes de ello, hablaremos de los perfiles de usuario.
El perfil de un usuario en Windows es un conjunto de carpetas y datos que se almacenan en el equipo al crearse
dicho usuario. El mayor inconveniente que nos encontramos en esta definición es que tendremos un perfil
diferente en cada equipo en el que nos conectemos. Hay diversas alternativas:
Podemos definir este perfil como móvil, haciendo que se almacene el el servidor. Nos lo descargaremos
automáticamente al iniciar sesión en cualquier equipo del dominio. Presenta otro inconveniente: puede
ralentizar mucho el inicio o cierre de sesión, y más si lo hacen varios usuarios a la vez.
También podemos crear una carpeta compartida y pedirle a los usuarios que almacenen ahí los datos que
quiera conservar. El problema de esta solución es que es poco transparente y algunos usuarios pueden
equivocarse fácilmente.
Windows Server nos da otra solución, a través de directivas. Nos permite redirigir algunas de las carpetas
del perfil (Documentos, Descargas, ...) a otra ubicación, con lo cual nuestros usuarios no tendrán que hacer
nada extraordinario para conservar sus datos, y el uso de la red es más eficiente.
Carpeta para redirección

A la hora de redireccionar la información de los perfiles, tenemos que pensar en primer lugar en dónde la vamos
a guardar. Como queremos que esté disponible a lo largo de todo nuestro dominio, la almacenaremos en una
carpeta compartida. Podemos aprovechar la misma carpeta que usamos en el ejemplo del fondo, cuidando que
los permisos sean de escritura, y crear una subcarpeta para nuestros datos.
GPO para redirección de perfiles

En primer lugar, tenemos que decidir a qué conjunto de usuarios va dirigida nuestra directiva de redirección. En
mi ejemplo, voy a hacerlo sólo con los usuarios que están dentro de la UO "Contabilidad" (no confundir con grupo
"contabilidad"; a nivel de GPO, sólo trabajaremos con UO). Esto significará que el usuario Administrador no se
verá afectado por la directiva.
Vemos en la captura cómo se ha creado y vinculado el GPO a la UO indicada, y la ubicación de la directiva

adecuada en el Editor:
Cuando queremos modificar las opciones de alguna de las carpetas de perfil (Documentos, en la captura) vemos
algunas opciones:
No configurado: la opción por defecto, que no hace nada.

Básico: Nos permite definir una misma carpeta o ruta para todos los usuarios
Avanzado: Permite hacer una configuración más personalizada; por grupos, incluso por usuarios
individuales
Veamos qué podemos hacer con la opción de configuración básica:
Redirigir al directorio particular del usuario: si existe un "directorio particular" definido para el usuario, se
enviaría allí. En nuestro caso, no está definido.
Crear una carpeta para cada usuario en la ruta raíz: esto nos creará una carpeta donde nosotros
escojamos, y creará subcarpetas para cada usuario. Escogemos esta opción.
Redirigir a la ubicación siguiente: esto envía todos los documentos de todos los usuarios afectados por la
GPO a la misma ruta. Sería útil en caso de que queramos compartir esos datos, pero no es lo que
buscamos aquí.
Redirigir a la ubicación local del perfil de usuario: Lo deja en la máquina local, olvidando cualquier otra
configuración de red. Esto podría ser muy útil para ficheros temporales, o descargas locales.
La ruta donde vamos a almacenar nuestros datos será la de la carpeta compartida previamente: \\SERVIDOR\Datos
Dominio\Usuarios\. Automáticamente, la directiva creará una subcarpeta para cada usuario, y, dentro, otra subcarpeta
para Documentos:\\SERVIDOR\Datos Dominio\Usuarios\john\Documentos, en el caso del usuario john.
Lo que guardemos en esta carpeta, estará accesible automáticamente desde cualquier equipo del dominio, a
través del perfil del usuario.
Comprobación en los clientes

En la siguiente captura, y tras haber ejecutado el comando gpupdate /force en el servidor, vemos el inicio de sesión
de un cliente para comprobar si se han aplicado las directivas:
En la imagen, podemos apreciar algunos detalles interesantes:
El fondo es el que definimos en la directiva; ha cambiado automáticamente.

Cuando vemos la información de nuestro usuario, la carpeta "Documentos" aparece con un icono circular
de color verde. Ese icono indica que es una carpeta sincronizada en red.
Cuando vemos su ubicación en las propiedades de dicha carpeta, nos muestra la carpeta en red tal y como
la definimos en la GPO.
Esto demuestra que nuestras GPOs han funcionado correctamente.

8.5.- Otros.

En el caso de AD podremos observar que hay otros objetos que gestiona. Uno especialmente útil es el
apartado de "computers", que son los equipos que se conectan con el servidor. En esta carpeta
tendremos información de todos los equipos cliente que han sido dados de alta en el sistema. El
sistema necesita saber quién ha entrado, con qué credenciales y desde dónde. Es decir, debe existir
una relación de confianza a nivel cliente/servidor.
¿Tiene alguna utilidad más? Por supuesto, podremos seleccionar un equipo y administrarlo de forma
remota. Eso sí, con una cuenta con nivel de administración.
OpenClipArt (Dominio público)
Autoevaluación
Hemos instalado, en el servidor, un software que permite imprimir archivos PDF. ¿Se puede administrar derechos
y privilegios a usuarios y/o grupos a través del LDAP?
Verdadero.
Falso.
Muy bien. Es un objeto que como tal puede ser administrado.
Te has equivocado. Al ser un objeto del sistema, puede especificarse quiénes, máquinas, usuarios, grupos, etc.
pueden interactuar con el objeto.
Solución
1. Opción correcta
2. Incorrecto
9.- Relaciones de confianza entre dominios.
Caso práctico
Nuestro departamento, como parte del banco de pruebas, va a realizar la instalación de varios
servidores que estarán conectados entre sí. Para ello, Vindio y Laro asesorarán al resto de sus
compañeros para que conozcan qué tienen que establecer, cómo y a qué nivel se conectarán.
Para realizar esta tarea, Vindio y Laro indican que debemos establecer una relación de confianza
entre dominios. Lo que estamos dilucidando es cómo establecer esa confianza, si hacerlo con
dominios distintos o bien con subdominios de uno principal.
Nate Steiner (CC0)
En ocasiones puede ser interesante que dos organizaciones o dominios necesiten una de la otra por
intereses comunes. Pongamos un ejemplo. En una UTE hay empleados, de una de las empresas A, que
necesita acceder a recursos que están ubicados en la otra empresa B. Bien, pues una de las empresas
puede generar una relación de confianza entre dominios para que un usuario determinado acceda a un
servidor en el que no ha sido dada de alta la máquina cliente.
¿Cómo funcionaría? Se da de alta al usuario en la empresa B. Al existir una relación de confianza, que
puede ser unidireccional o bidireccional, le deberá aparecer, al usuario, la posibilidad de autenticarse en
dos dominios. Una vez seleccionado el dominio al que quiere acceder, introducirá sus credenciales para
que le autentique el servidor al que desea acceder.
Otra forma de generar una relación de confianza es crear un servidor que sea subdominio de otro. whologwhy (CC BY)
Imagínate, un grupo de empresas tiene su servidor con su dominio, entretuyyo.com, al cual acceden una
serie de usuarios. La empresa tiene una sucursal en Laredo y desea descentralizar el servidor. ¿Qué
puede hacer? Crear un servidor en Laredo que sea, a su vez, subdominio del principal. Como subdominio podríamos escoger, por
ejemplo, laredo.entretuyyo.com.
Con las relaciones de confianza obtendremos la ventaja de no tener que dar de alta el equipo como cliente-terminal de todos los
servidores, con una vez bastará. Es decir, comprobará si el equipo que no está en la base de datos del sistema está, sino, consultará,
por el principio de relación de confianza, con el otro servidor para consultar si está dado de alta en ese servidor.
Para saber más

En el siguiente ejemplo vemos más detalladamente cómo se crea una relación de confianza instalando un subdominio de
otro ya existente.
◄ 1 2 3 4 ►
SERVIDOR ADICIONAL
Vamos a aprovechar bien nuestros recursos, y para ello voy a utilizar como servidor adicional un Windows Server
Core. Veremos más adelante que en nuestro caso no es necesario en absoluto instalar este segundo servidor
con interfaz gráfica.
Una vez instalado, la herramienta que da paso a las tareas administrativas más importantes es el comando sconfig.
Lo primero es cambiar las propiedades de red; para ello, entramos en la opción "8" y sustituimos el DNS principal
por la IP de nuestro servidor principal.
Por último, nos damos de alta en el dominio con la opción "1" ( y ya de paso, le cambiamos el nombre al equipo
por uno más fácil de recordar)
Administración remota de servidores

Una vez dado de alta en el dominio, la administración del nuevo servidor puede hacerse fácilmente de forma
remota desde el servidor principal.
Simplemente añadimos el nuevo servidor para que sea administrado en la herramienta "Administrador del
Servidor", y ya podemos trabajar con él como si también tuviera interfaz gráfica.
Instalación del rol

Una vez hemos añadido nuestro nuevo servidor a la herramienta de administración de servidores, paso a instalar
el rol AD tal cual hice la primera vez, pero con algunos cambios en el proceso, obviamente. Por comodidad, solo
pongo aquellos pasos con diferencias sobre el proceso del dominio original.
En primer lugar, tendremos cuidado al escoger el servidor en el que pretendemos instalar el nuevo rol.
En segundo lugar, procedemos a dar nombre a nuestro nuevo dominio: aula2.bk.com. Hay que tener especial
cuidado en introducir las credenciales del administrador del dominio principal.
Más adelante, veremos como ahora sí nos permite crear una delegación DNS, sin errores. Es necesario también
introducir las credenciales del administrador del dominio principal, bk.com.
Final
Para terminar, el servidor se reiniciará automáticamente y, transcurrido un tiempo, nos mostrará que está todo
correcto. Podemos abrir la herramienta "Dominios y Confianzas de AD" para comprobar que existe el nuevo
subdominio, como vemos en la captura:
Autoevaluación
¿Se pueden establecer relaciones de confianza (Windows Server 2019) entre servidores de distinto dominio?
No, en ningún caso.

Sí, pero sólo en un sentido.
Sí, puede ser unidireccional y bidireccional.
No, sólo es posible en el sentido subdominio a dominio.
No es correcto. No lo has probado.
No has acertado. Deberías probarlo.

Muy bien. La relación de confianza es posible.
No, hay otras posibilidades.
Solución
1. Incorrecto
2. Incorrecto
3. Opción correcta
4. Incorrecto
10.- Herramientas gráficas de administración del servicio de
directorio.
Caso práctico
Ya tenemos todo instalado y funcionando. Nuestro principal inconveniente es la
administración. Hay que intentar que esta sea lo más cómoda y rápida posible. La manera
más cómoda es mediante herramientas gráficas.
Noiba, Naroba y Jana, que ya están suficientemente cualificadas sobre el tema, nos
introducirán en el tema de las herramientas gráficas.
Entre todos, con el debido asesoramiento de Noiba, Naroba y Jana, valoraremos de qué
herramientas disponemos, sus características y ver si es factible utilizarlas por su sencillez
y, sobre todo, por su nivel de seguridad. Alain Bachellier (CC BY-NC-SA)
Hoy en día, aunque es posible llevar a cabo todas las tareas de administración de un directorio a nivel de comando (shell en GNU/Linux,
PowerShell en Windows), es mucho más cómodo hacerlo en modo gráfico. En sistemas basados en Windows, las herramientas gráficas
están completamente integradas en el sistema; pero no ocurre lo mismo en sistemas basados en GNU/Linux.
A diferencia de Windows, las herramientas gráficas habitualmente realizan tareas de frontend. Es decir, realmente funcionan como
rutinas que llaman a comandos del sistema para realizar las tareas encomendadas.
¿Esto es bueno? Tal vez, pero lo que es innegable es que si el entorno gráfico de una aplicación no funciona adecuadamente, siempre
podremos trabajar a nivel de terminal.
A continuación vamos a valorar las ventajas de las herramientas gráficas.
Escribir menos código y ahorrar tiempo: gracias a las herramientas gráficas, se pueden crear interfaces de usuario basadas en
tecnologías visuales. De esta manera, podemos generar una orden sencilla o compleja seleccionando objetos y relacionando estos
con la tarea que queremos generar.
Ayuda personalizada: la definición de interfaces de usuario supone algunas ventajas adicionales. Por ejemplo, el administrador es
quien decide qué temas de ayuda u objetos se necesitan para administrar.
Independiente de plataforma: las herramientas gráficas pueden ser independientes de la plataforma, y administrar un servidor
tanto local como remotamente.
10.1.- Herramientas gráficas en Windows Server.
La herramienta administrativa más utilizada de AD es "Usuarios y equipos de Active Directory". Esta
herramienta permite gestionar todos los permisos y privilegios de: unidades organizativas, grupos,
usuarios, agregar máquinas al dominio, administrar dichas máquinas, etc.
En la imagen se muestra la organización del dominio con esta herramienta.
En el panel izquierdo de Usuarios y equipos de Active Directory está el árbol de la consola, que muestra
el nombre de dominio completo en el nivel raíz. El contenedor raíz incluye varios contenedores
predeterminados:
Builtin: contenedor para cuentas de usuario integradas.
Computers: contenedor predeterminado para objetos de equipo.
Domain Controllers: contenedor predeterminado para controladores de dominio.
ForeignSecurityPrincipals: contenedor para entidades principales de seguridad de dominios externos de confianza. Los
administradores no deben modificar manualmente el contenido de este contenedor.
Users: predeterminado para objetos de usuario.
Sin embargo, lo que nos encontramos nada más arrancar el servidor es la herramienta "Administrador
del Servidor". A lo largo del tema hemos visto algunas de sus posibilidades: administración remota de
servidores, instalación/configuración de roles.... Podemos fácilmente, a través de esta herramienta:
Darnos de alta en un dominio/grupo de trabajo (si no lo estamos ya)

Configurar la red
Seguridad de cortafuegos, Internet Explorer, Escritorio remoto...
Actualizaciones
Configuración de fecha/hora
Desde aquí, tenemos acceso a muchas otras

herramientas específicas para todos los roles
administrativos de Windows Server, tal como se
muestra en esta otra imagen.

Por último, es interesante mencionar que de un tiempo a esta parte se ha creado una herramienta para gestión de los objetos de AD
más moderna, integrada con PowerShell y con otras funcionalidades avanzadas de Windows Server, y es el Centro de Administración
de Active Directory.
Para saber más

En Active Directory, las herramientas administrativas gráficas nos permiten gestionar muy eficientemente el árbol de
directorio. El siguiente enlace nos muestra usos avanzados de la herramienta "Centro de Administración de Active
Directory"
Gestión avanzada de AD con el Centro de Administración de Active Directory
10.2.- Herramientas gráficas en distribuciones GNU/Linux.
En similar situación se encuentran las herramientas gráficas de LDAP. Tenemos una herramienta web
muy popular, phpldapadmin, con la cual podremos gestionar todos los objetos LDAP del servidor. En la
imagen se muestra la apariencia de esta utilidad.
Para su instalación, podemos seguir esta guía. La forma de acceso es indicándole el usuario con nombre distinguido (DN). Es decir, el
usuario admin se le indicará, en el login, como cn=admin,dc=bk,dc=com. Posteriormente, introducimos la clave correspondiente.
También hemos visto a lo largo de este mismo tema el LDAP Account Manager, muy completo.
Otra herramienta, a nivel de aplicación escritorio, es la aplicación jxplorer. Nos permite conectar a un
servidor LDAP, tanto si ese servidor está en nuestro propio equipo como en otro externo, y realizar tareas
comunes de administración del árbol de directorio.
No debemos olvidar que la forma de acceso a los recursos LDAP se debe realizar en formato LDAP. Es
decir, introducimos el dominio indicando el formato, por ejemplo el dominio bk.com y el usuario admin:
DN: dc=bk, dc=com

User DN: cn=admin, dc=bk, dc=com
Password: su clave correspondiente.
Para saber más

Si quieres más información sobre estas aplicaciones, puedes conseguirla en los siguientes enlaces:
Sitio oficial de jxplorer
Sitio oficial de phpLDAPadmin
Sitio oficial de LDAP Account Manager
Aparte de estas herramientas, tenemos otra de ámbito general. Se trata de la aplicación Webmin. Es una herramienta de
configuración de sistemas accesible vía web compatible son el servicio Apache (suele utilizar el puerto 10000 para su
acceso) para OpenSolaris, GNU/Linux y otros sistemas derivados de Unix. Aunque es general, podremos administrar,
también, el servicio LDAP.
Sitio oficial de Webmin

ASO01. - Administración de Servicios de Directorios

Cargado por

Copyright:

Formatos disponibles

ASO01. - Administración de Servicios de Directorios

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

ASO01. - Administración de Servicios de Directorios

Cargado por

Copyright:

Formatos disponibles

Administración de servicios de directorio.

Ministerio de Educación y Formación Profesional (Dominio público)

Materiales formativos de FP Online propiedad del Ministerio de Educación y Formación Profesional.

Alain Bachellier (CC BY-NC-

Debemos empezar preguntándonos ¿qué es un servicio de directorio? Es una aplicación o un

Pongamos un ejemplo. Un servicio de directorio es un servicio de

Para saber más

No. Creo que no lo has entendido bien.

Incorrecto. Deberías repasar este punto.

La estructura del directorio se basa en los siguientes conceptos:

No lo tienes claro, repasa la unidad.

Muy bien, has entendido algo muy importante.

Mejor que repases los conceptos de la unidad.

Alain Bachellier (CC BY-NC-SA)

Ya hemos mencionado qué es el esquema de un servicio de directorio. Ahora vamos a profundizar un

Debemos definir, primero, qué es un esquema de directorio: el esquema es la colección de atributos

En la imagen podemos observar un típico esquema de un servicio de directorio. En ella, para

Es decir, en un formato de Internet, tipo URL, sería "Naroba.Usuarios.bk.com.".

Ahora bien, en formato DN "DN: 'uid=Naroba, ou=Usuarios,dc=bk,dc=com'".

Comúnmente se usan las estructuras de árbol para jerarquizar la información en un medio.

Federico Martínez Pérez (Elaboración propia)

No has acertado. Deberías repasar este punto de nuevo.

Muy bien, has entendido algo muy importante.

Incorrecto, debes repasar bien este punto.

Alain Bachellier (CC BY-NC-SA)

Dadas las características de LDAP, sus usos más comunes son:

Veamos más características de LDAP:

Pongamos como ejemplo un caso práctico:

Servidores de certificados públicos y llaves de seguridad.

Controlar los accesos al sistema.

No es correcto. Esta función es exclusiva del sistema operativo.

Muy bien, esta puede ser una de sus funciones.

No es la respuesta correcta. No los sustituye, los puede gestionar.

Incorrecto, los CRM son aplicaciones específicas ajenas al propio sistema.

Alain Bachellier (CC BY-NC-

Gestionar las consultas de un dominio.

No es correcto. Parece lo mismo pero es función del servicio DNS.

No es la opción correcta, es una de sus funciones pero no es la principal.

Muy bien. Has leído este apartado.

Jonny Goldstein (CC BY)

Ya sabemos que el servicio de directorio se basa en la arquitectura del modelo cliente-servidor.

Es decir, instalamos el sistema operativo "en bruto".

Después, pasamos al proceso de creación del dominio.

Para saber más

INSTALACIÓN DE ACTIVE DIRECTORY

AGREGAR NUEVA FUNCIONALIDAD

Windows Server (Elaboración propia)

AGREGAR SERVICIO DE DOMINIO DE ACTIVE

Windows Server (Elaboración propia)

En este otro cuadro de diálogo, sólo nos pide confirmación

Windows Server (Elaboración propia)

CONTROLADOR DE DOMINIO DE ACTIVE DIRECTORY

Windows Server (Elaboración propia)

PROMOCIÓN DEL CONTROLADOR DE DOMINIO

Windows Server (Elaboración propia)

Windows Server (Elaboración propia)

Windows Server (Elaboración propia)

Windows Server (Elaboración propia)

Windows Server (Elaboración propia)