6

ADMINISTRACIÓN DE DOMINIOS
Implantación de sistemas operativos
6.1. La estructura cliente-servidor
Como vimos en el apartado 5.2, un grupo de trabajo es un método
simple para subdividir una pequeña red local de forma que sea
más fácil de administrar. Es sencillo de implementar y gestionar, ya
que cada ordenador conserva su autonomía en cuanto a cuentas y
grupos de usuarios y a los correspondientes permisos asociados;
sin embargo, precisamente por ello es posible que algunos equipos
del grupo no puedan acceder a los recursos compartidos de otros a
causa de sus particulares restricciones de seguridad.
Así pues, los ordenadores que forman parte de un grupo de trabajo
son independientes, y no existe una máquina que orqueste el con-
trol de los dispositivos conectados, por lo que todos forman una
red entre iguales (en inglés, peer-to-peer). En un grupo de trabajo
no es un servidor central el que designa los nombres de los gru-
pos, ni existe ningún tipo de condición para sumarse a dicho grupo
excepto la de especificar su nombre de equipo en el apartado co-
rrespondiente de la configuración del sistema.
CONCEPTO
Un dominio es otro sistema de agrupación lógica de
dispositivos en red, pero con dos diferencias funda-
mentales con respecto a los grupos de trabajo: está
administrado por uno o varios servidores y aglutina
dispositivos que pueden estar conectados a redes
distintas. Dichos servidores se denominan contro-
ladores de dominio (o DC por sus siglas en inglés,
Domain Controllers) y, entre otras funciones, son los
que asignan los nombres de dominio y proporcionan
los servicios de autenticación.
En Internet, los dominios se identifican mediante su dirección IP,
y los nodos que comparten una misma máscara de red decimos
que están conectados a un mismo dominio de red. Gracias a sus
características, un dominio es la solución más adecuada en un
escenario con estructura cliente-servidor como este, en el que
existe una red heterogénea con un amplio número de clientes que
necesitan acceso a los recursos proporcionados por un servidor,
ya sea almacenamiento, aplicaciones en línea, descargas, una
impresora, etc.
El rol del servidor en una estructura cliente-servidor es pasivo, lo que
significa que espera a que los clientes realicen peticiones, las proce-
sa y les devuelve una respuesta, mientras que, lógicamente, el de los
clientes es un papel activo, es decir, realizan una petición, esperan la
respuesta por parte del servidor y finalmente, cuando esta llega,
la procesan.
229
Tema 6: Administración de dominios
6.1.1. Diferencias entre grupo de trabajo
y dominio
Existe un buen número de diferencias entre las características de un
grupo de trabajo y un dominio. A continuación citaremos algunas
de las más importantes:
• Modelo y alcance de la red. El dominio se basa en una amplia
estructura cliente-servidor que puede abarcar una o diversas
redes, mientras que los grupos de trabajo forman parte de una
misma red local, de reducidas dimensiones, y con un modelo de
igual a igual.
• Dificultad de instalación y configuración. Un dominio es más
difícil de implementar que los grupos de trabajo, pero es más fá-
cil de mantener en redes con muchos clientes, en las que además
puede crecer de forma más sencilla y ordenada.
• Control del acceso. La seguridad en un dominio es mucho mejor
que en un grupo de trabajo, gracias principalmente al control de
acceso centralizado. Esto significa que los usuarios y los grupos
de usuarios se administran a nivel de dominio, no en los diferen-
tes sistemas locales.
• Seguridad de los datos. Todos los datos relativos al dominio re-
siden en una base de datos central, y lo mismo sucede con los
recursos de almacenamiento centralizados. Por lo tanto, la se-
guridad de los datos tiene un único punto de fallo, que deberá
fortalecerse al máximo para garantizar que los datos sensibles no
se vean comprometidos en un ataque informático o que la infor-
mación esté convenientemente respaldada.
• Nomenclatura. El nombre de los dominios se asigna en función
de sus direcciones de red, mientras que los grupos de trabajo ad-
quieren un nombre de forma arbitraria.
PARA + INFO
Mientras que con los grupos de trabajo se utiliza el pro-
tocolo SMB, en una estructura cliente-servidor como la
de un dominio pueden utilizarse diversos protocolos de
comunicaciones, y dependiendo del tipo de información
que se desee transmitir se empleará el protocolo que
resulte más adecuado. Por ejemplo, para la transmisión
de archivos se puede utilizar el protocolo FTP, mientras
que para enviar correo podemos usar POP3 e IMAP, y
para acceder a páginas web, el HTTP.
230
6.2. El protocolo LDAP
Existen muchas formas posibles de implementar un dominio, pero
el sistema dominante es, sin duda, el Directorio Activo de Micro-
soft. No obstante, existe otra implementación que se utiliza en
entornos GNU/Linux denominada OpenLDAP. Ambas se basan en
el uso del estándar abierto LDAP, denominado así por las siglas en
inglés Lightweight Directory Access Protocol, es decir, protocolo
ligero de acceso a directorio.
CONCEPTO
El LDAP es un protocolo de tipo cliente-servidor
para gestionar directorios usando una base de datos
centralizada mediante el protocolo de red TCP/IP.
Esta base de datos contiene la información de todos
los recursos de la red, incluyendo usuarios, grupos,
impresoras, directorios compartidos y cualquier otro
nodo que interactúe con la red.
Desarrollado en la Universidad de Michigan hacia 1993 como
sucesor de los protocolos DIXIE y DAS para el acceso a directorios
X.500, el LDAP es un subconjunto de estándares contenidos en las
especificaciones del propio estándar X.500 y está diseñado especí-
ficamente para funcionar sobre la pila TCP/IP.
El principal foco del LDAP es definir los métodos de acceso a los
datos, y no la forma en la que estos se almacenan en el servidor.
Para ello proporciona un conjunto de métodos de conexión y des-
conexión, de búsqueda y comparación de datos y de edición de las
entradas del directorio. También ofrece cifrado de las conexiones
mediante el protocolo SSL y un sistema de autenticación segura
basado en el uso de credenciales.
Los directorios se organizan en dos tipos de estructuras o topolo-
gías, lógica y física, siendo la una independiente de la otra:
• Estructura física. Está formada por las diferentes sedes donde
pueden residir los controladores de dominio, lo cual es un fac-
tor importante en las búsquedas del directorio, las peticiones de
servicio y las operaciones de autenticación en el inicio de sesión.
Como veremos más adelante, en el caso del Directorio Activo, la
ubicación de un controlador de dominio en una sede en particular
también determina su lugar en la topología de replicación.
• Estructura lógica. Se trata de una topología jerárquica en ár-
bol denominada genéricamente DIT (siglas del inglés Directory
Information Tree, o árbol de información de directorio). En ella,
cada entrada de servicio de directorio, o DSE (Directory Service
Entry), es una rama del árbol que se relaciona con un objeto real
(un usuario, un equipo) o lógico (parámetros). La entrada princi-
pal de la que cuelga el árbol es la entrada raíz.
Implantación de sistemas operativos
¿SABÍAS QUE...?
El precursor del LDAP es
el X.500, un protocolo
de acceso a directorio
desarrollado bajo la
norma ISO/IEC 9594 que
proporciona un método
basado en el modelo OSI
para implementar un
directorio de usuarios
en una organización, y
que además permite su
publicación a través de
Internet.
231
Tema 6: Administración de dominios
PARA + INFO
El formato para el in-
tercambio de datos que
usa LDAP se denomina
LDIF, por las siglas en
inglés de Lightweight
Data Interchange
Format, que permite
la importación y la
exportación de datos
mediante archivos de
texto simple.
Para distinguir la naturaleza de los objetos que forman el árbol
se emplea un conjunto de atributos (formados por una clave y un
valor) que pueden ser de tipo normal (los datos en sí) u operacio-
nal (permiten al servidor gestionar los datos). Las claves a utilizar
dependen de la norma bajo la cual se implemente el directorio; por
ejemplo, según la norma X.509, entre los atributos más habituales
encontraríamos los siguientes:
– UID o USERID. Identificador de usuario.
– CN. Nombre común.
– O. Nombre de la organización.
– OU. Nombre de la unidad organizativa.
– DC. Componente de dominio.
– STREET. Calle (primera línea de la dirección).
– C. País.
– E o MAIL. Dirección de correo electrónico del usuario.
– UNSTRUCTUREDNAME. Nombre de anfitrión.
– UNSTRUCTUREDADDRESS. Dirección IP.
Todas las entradas disponen de un identificador único denominado
nombre distinguido o DN (Distinguished Name), formado por una
serie de atributos con formato de serie; por ejemplo, cn=Juan Fe-
rrero,ou=Contabilidad,o=Ilerna,c=España. Normalmente, el DN se
normaliza eliminando los espacios después de las comas y los que
rodean al signo igual, y, aunque puede contener varios atributos
OU y DC, solo se permite una instancia del resto.
El catálogo de objetos y atributos de un servidor LDAP recibe el
nombre de esquema, y en él podemos definir si los atributos pue-
den tener uno o más valores, y si serán obligatorios u opcionales.
Los principales procedimientos que nos ofrece LDAP para realizar
consultas y editar los datos de directorios son:
Operación
Abandon
Add
Bind
Compare
Delete
Extended
Rename
Search
Start TLS
Unbind
Traducción
Abandonar
Agregar
Enlazar
Comparar
Eliminar
Extendida
Renombrar
Buscar
Iniciar TLS
Desenlazar
Descripción
Cancela la última operación enviada al servidor.
Añade una entrada al directorio.
Inicia una sesión nueva en el servidor.
Compara dos entradas del directorio según los criterios especificados.
Borra una entrada del directorio.
Realiza una operación extendida.
Cambia el nombre de una entrada del directorio.
Realiza una búsqueda en el directorio.
Utiliza la extensión de seguridad TLS para establecer una conexión segura.
Cierra la sesión en el servidor.
Tabla 6-1
232
6.3. Diseño del dominio: subdominios
y requerimientos
Como ya apuntamos en el apartado 6.1, los dominios pueden ser
de dos tipos:
• Locales. Constan de un conjunto de equipos conectados a una
red local en la que todos los recursos se gestionan de forma cen-
tralizada para permitir el acceso a los usuarios y a los grupos del
dominio según los privilegios que se les hayan asignado.
• De Internet. Estructura jerárquica en la que se utiliza un sistema
de nombres separados por puntos para determinar la ubicación
de red (IP) de los equipos conectados a Internet gracias a una
base de datos almacenada en los servidores de nombres de do-
minio (DNS).
Un subdominio es un segundo nivel en la jerarquía del dominio que,
a nivel local, se define principalmente para facilitar la organización
y la administración de dominios extensos, y que en Internet se usa
para proporcionar acceso a diferentes secciones o contenidos de
una web.
Para determinar el nombre de un subdominio lo más frecuente es
añadir una palabra a la izquierda del nombre de dominio, aunque
lo podemos expresar también en forma de directorio; por ejemplo,
en Internet podríamos acceder a la información disponible en un
subdominio de las dos formas siguientes:
•
•
[Link]
[Link]
Lo más habitual es que los subdominios se vayan creando y
adaptando al compás de la evolución del dominio en extensión y
contenidos, pero pueden también formar parte de los requerimien-
tos a tener en cuenta a la hora de estructurar un dominio. En este
sentido, las principales consideraciones previas al diseño de un
dominio serían las siguientes:
• Nombre de dominio. El nombre del dominio es una cadena de
caracteres arbitraria que, según el protocolo LDAP, corresponde a
un atributo componente de dominio, o DC (no confundir con con-
trolador de dominio), indicado como dc=midominio.
• Extensión. La extensión de un dominio corresponde también a
un atributo componente de dominio, y se añade, separada por un
punto, tras el nombre de dominio; por ejemplo, .es, .com o .net,
entre otras muchas. Se indica como dc=es, dc=com, etc.
• Unidad organizativa Group. Contiene las unidades orga-
nizativas hijas que son grupos, y que se identifican con un
nombre común (CN); por ejemplo, cn=contabilidad. En LDAP, la
indicamos como ou=Group. Es recomendable crear los grupos de
antemano para agilizar el proceso de creación de los usuarios.
Implantación de sistemas operativos
PARA + INFO
Uno de los cambios
fundamentales que
aportó el Directorio
Activo con respecto al
LDAP tradicional fue
relegar el servicio de
nombres Internet de
Windows (WINS) a un
papel secundario como
método de resolución
de nombres en favor
del sistema de nombres
de dominio (DNS). De
hecho, el Directorio
Activo no solo usa
el DNS para resolver
nombres, sino también
para definir su propio
espacio de nombres
mediante la aplicación
de la misma serie de
convenciones a los
nombres de dominio.
Además, utiliza la
base de datos DNS
para almacenar los
roles de cada equipo,
lo cual permite dirigir
de la forma adecuada
las peticiones de los
equipos dentro del
dominio.
233
Tema 6: Administración de dominios
• Unidad organizativa People. Es el conjunto formado por todos
los usuarios individuales del dominio, que son hijos de esta OU y
que se identifican de forma unívoca mediante su UID. En LDAP se
indica como ou=People.
En cuanto a los requisitos técnicos, obviamente la decisión más
importante es qué implementación LDAP vamos a utilizar, lo cual,
a su vez, vendrá determinado por el sistema operativo del servidor
o servidores que vamos a usar, y también por el de los equipos que
formarán parte del dominio.
Si la red es Windows, podemos usar Windows Server 2019 y el
Directorio Activo, u otra solución comercial de terceros. Si la red es
GNU/Linux, podemos utilizar OpenLDAP en cualquier distribución
dirigida a servidores, como Ubuntu Server 20.04.2, que es la última
con soporte a largo plazo (LTS). En cualquiera de los casos, debe-
remos consultar los requisitos mínimos de hardware para cada uno
de los sistemas.
Por último, debemos tener en cuenta los equipos de red necesarios
para interconectar los equipos y los dispositivos que formarán parte
del dominio: rúteres, conmutadores, cables, etc.
Una vez considerados todos los requisitos y los condicionantes en
los que se enmarcará el dominio, podemos proceder a su diseño
sobre el papel. La forma más habitual de hacerlo es creando un grá-
fico en forma de árbol donde cada rama represente un elemento
dentro del dominio. El diseño más elemental que podemos crear es
el formado por los elementos mencionados anteriormente: nom-
bre y extensión del dominio, unidades organizativas de usuarios
y grupos, y un usuario administrador (cn=admin) como elemento
obligatorio adicional indicado por su nombre común. Podemos ver
una representación gráfica de este diseño en la Figura 6-1.
ponte a prueba
¿En qué consiste normalizar
un DN?
a) #En hacer todos los DN iguales
dentro del directorio.
b) #En hacer que todos los DN
tengan los mismos atributos.
c) #En usar siempre mayúsculas.
d) #En eliminar el espacio
después de una coma y los
que rodean al signo igual.
234
Figura 6-1
A partir de aquí podemos ir añadiendo elementos según nos lo
marque la organización para la cual estemos creando el dominio.
De ello se derivarán unas estructuras lógica y física particulares, de
las cuales hablaremos en los siguientes apartados tomando como
base el Directorio Activo.
6.4. Estructura lógica del Directorio
Activo (AD)
CONCEPTO
El Directorio Activo es la implementación de las
versiones 2 y 3 del protocolo LDAP que Microsoft ha
desarrollado para sus sistemas operativos Windows
Server y que, con presencia en más del 90% de las
organizaciones de la lista Fortune 1000, durante
las últimas dos décadas se ha venido afianzando
como la solución comercial líder para la gestión de
directorios.
Implantación de sistemas operativos
Llamado también AD por sus siglas en inglés, Active Directory, es
una solución para la gestión de dominios basados en Windows,
y por lo tanto trabaja de forma nativa con otros servicios de Mi-
crosoft, como el servidor de correo Exchange y el gestor de bases
de datos SQL Server. Sin embargo, carece de soporte para clientes
basados en GNU/Linux, y solo se integra bien con servicios de com-
putación en la nube a través de su extensión, Azure Active Directory
(Azure AD).
La primera versión del Directorio Activo se lanzó con Windows
2000 Server en febrero del año 2000. Uno de los principales cam-
bios que introdujo con respecto a los directorios basados en LDAP
fue la desaparición del controlador de dominio primario (en inglés,
Primary Domain Controller, o PDC).
Lo cierto es que, hasta la fecha, en un directorio basado en el proto-
colo LDAP tradicional solo podía existir un controlador primario por
dominio, mientras que el resto de controladores de dominio (DC)
actuaba a modo de copias de respaldo. El Directorio Activo es, en
cambio, un sistema multimaestro, lo cual significa que todos los DC
actúan al mismo nivel.
Ello, sin embargo, no significa que todos los DC tengan el mismo
papel dentro del dominio. Los servicios de dominio del Directorio
Activo, o AD DS (Active Directory Domain Services), definen, de
hecho, cinco posibles roles maestros, y a cada uno de ellos puede
asignarse un DC distinto que actuará como maestro de operaciones
para cada rol. Esto se hace para asegurar la consistencia de ciertas
operaciones que afectan a los controladores de dominio.
Los cinco roles de maestro de operaciones son los de esquema,
nombres de dominio, identificador relativo, infraestructura y emu-
lador del PDC.
Pero para comprender el porqué de la existencia de los maestros de
operaciones en el Directorio Activo primero es necesario entender
su estructura lógica.
235
Tema 6: Administración de dominios
En primer lugar, como ya sabemos, la estructura lógica del Direc-
torio Activo es totalmente independiente de la física, por lo que
podemos crear una OU que incluya todas las impresoras de red con
independencia de a qué equipos estuvieran conectadas.
En segundo lugar, el directorio es un conjunto de objetos y atribu-
tos organizados de forma jerárquica basado en cuatro conceptos:
• Dominios. Son las unidades administrativas básicas del Directo-
rio Activo, y constan de un cierto número de equipos definido por
un administrador que, conectados en red, comparten una misma
base de datos de directorio. El primer dominio creado es consi-
derado del dominio raíz, y es el padre de todos los dominios que
cuelgan directamente de él. Se pueden ir añadiendo directorios
a los árboles, creando una estructura de relaciones padre-hijo en
la que los nombres se asignan según el sistema de nomenclatu-
ra de dominios, o DNS, con objeto de reflejar sus relaciones de
dependencia (Figura 6-2). Entre las funciones administrativas
principales de un dominio se incluyen:
– Proporcionar identidades válidas en todos los equipos unidos al
mismo bosque, almacenándolas de forma segura en los contro-
ladores de dominio que lo componen.
– Proporcionar, a través de los controladores de dominio, los ser-
vicios de autenticación y gestión de grupos, que se pueden usar
para controlar el acceso a los recursos de la red.
– Extender los servicios de autenticación a los usuarios de domi-
nios ajenos a su propio bosque mediante el uso de diferentes
tipos de confianza.
– Replicar los datos necesarios para poder proporcionar servicios
de dominio entre los controladores de dominio, permitiendo su
administración como si constituyeran una misma unidad.
236
Figura 6-2
Implantación de sistemas operativos
• Unidades organizativas (OU). Los objetos del AD pueden organi-
zarse en estos contenedores lógicos, llamados también OU por sus
siglas en inglés, Organizational Units. Los objetos dentro de una OU
pueden ser de cualquier tipo: usuarios, grupos, dispositivos, equi-
pos e incluso otras OU. Cada unidad organizativa utiliza listas de
control de acceso (ACL) para gestionar el control sobre los objetos,
y tienen un propietario que controla: cómo se delega la adminis-
tración (pueden transferir su autoridad a otros usuarios o grupos,
confiriéndoles un grado de control administrativo limitado o com-
pleto sobre los objetos), cómo se aplica la directiva de grupo a los
objetos de la unidad, la creación de nuevos subárboles y la dele-
gación de la administración de las OU dentro de esos subárboles.
• Árboles. Un árbol está compuesto por un conjunto de dominios
con un espacio de nombres contiguo.
• Bosques. Grupos de dos o más árboles de dominio cuyos espa-
cios de nombres no son contiguos, pero que establecen relaciones
de confianza transitivas bidireccionales y que comparten una es-
tructura lógica común, un esquema de directorio (definiciones
de clase y atributo), la configuración de directorios (información
de la replicación y del sitio) y el catálogo global (capacidades de
búsqueda en todo el bosque). Entre los principales conceptos que
manejamos en un bosque, podemos destacar los siguientes:
– Relaciones de confianza. Cada nuevo dominio en un bosque
establece automáticamente una relación de confianza bidi-
reccional entre él y su dominio primario o padre. Gracias a la
naturaleza transitiva de esta relación, los subdominios que va-
yamos creando en el mismo árbol del nuevo dominio gozarán
de la misma relación de confianza bidireccional, que fluirá de
abajo arriba a través de toda la jerarquía de dominios. Dado que
las solicitudes de autenticación viajan a través de esta ruta de
relaciones de confianza, las cuentas de cualquier dominio del
bosque se pueden autenticar en cualquier otro dominio del
mismo bosque, obteniendo acceso a sus recursos con la única
condición de reunir los permisos necesarios.
– Esquema de directorio. Contiene las definiciones formales de
cada clase de objeto que se puede crear en un bosque, y las de
cada atributo que puede existir en un objeto del directorio.
– Catálogo global (GC). Permite a los usuarios y las aplicaciones
buscar objetos en un árbol de dominios, dados uno o más atri-
butos del objeto de destino, sin saber qué dominio los contiene
y sin necesidad de un espacio de nombres extendido contiguo.
El GC (por el inglés Global Catalog) se genera automáticamente
mediante el sistema de replicación del AD, y contiene una répli-
ca de todos los objetos del directorio, pero solo con un número
pequeño de sus atributos. Dichos atributos son, por un lado, los
que se usan con más frecuencia en las operaciones de búsque-
da (por ejemplo, los nombres de inicio de sesión y los apellidos
de un usuario) y, por el otro, los necesarios para buscar una ré-
plica completa del objeto.
237
Tema 6: Administración de dominios
Cuando se crea el primer controlador de dominio, los roles de
maestro de operaciones se asignan automáticamente. El primer
controlador de dominio dentro de un dominio dado tendrá los roles
de maestro de identificador relativo, maestro de infraestructura
y maestro emulador del controlador de dominio primario (estos
roles existen, por lo tanto, en cada dominio), mientras que el primer
controlador de dominio creado en un bosque tendrá los roles de
maestro de esquema y maestro de nombres de dominio (en con-
secuencia, solo podrá haber un controlador de dominio con estos
roles por bosque):
• Maestro de esquema. Es el responsable de actualizar el esque-
ma de los servicios de dominio del Directorio Activo (AD DS). Este
maestro es el único controlador de dominio en todo el bosque
que puede escribir directamente en el esquema, pero los cambios
que realiza se replican automáticamente en el resto.
• Maestro de nombres de dominio. Lleva el registro de todos los
dominios y las particiones del directorio en la jerarquía del bos-
que, pudiéndolos añadir, eliminar, replicar en controladores de
dominio adicionales, agregar o borrar objetos de referencia cru-
zada hacia o desde directorios externos y preparar al directorio
para una operación de cambio de nombre de dominio.
• Maestro de identificador relativo. Asigna bloques de identifi-
cadores relativos (RID) a cada controlador de dominio que exista
en un dominio dado, y otorga a cada nuevo objeto del directorio
su identificador de seguridad único (o SID, por el inglés Security
Identifier). Este identificador está compuesto por un SID de do-
minio, que es el mismo para todos los objetos, y el RID exclusivo
de cada objeto.
• Maestro de infraestructura. Se encarga de actualizar las refe-
rencias de objeto en su propio dominio que apuntan a un objeto
en otro dominio, poniendo también al día todas las réplicas del
dominio.
• Maestro emulador del controlador de dominio primario. El
emulador de PDC proporciona la compatibilidad hacia atrás con
sistemas antiguos, como Windows NT.
Este maestro de operaciones tiene preferencia en la replica-
ción de todos los cambios de contraseña realizados en el resto
de los controladores de dominio para un dominio determinado,
y proporciona información actualizada relativa a las contraseñas
cuando falla un intento de inicio de sesión por contraseña inco-
rrecta. El maestro emulador del controlador de dominio primario
es a su vez un punto de administración preferente para servicios
como la directiva de grupos y el sistema de archivos distribuido
(DFS), lo cual impacta directamente en su rendimiento.
Este maestro procesa también todas las peticiones de replicación
de los controladores de dominio de respaldo (BDC) de Windows
NT Server 4.0, y, en el caso del ubicado en el dominio raíz, propor-
ciona además el servicio horario de Windows (W32Time) para
todo el bosque.
238
6.5. Estructura física e instalación
del Directorio Activo
Si la estructura lógica sirve para organizar los recursos de la red,
la estructura física se utiliza para administrar el tráfico de red. Sus
componentes son los sitios y los controladores de dominio.
Los controladores de dominio son equipos con Windows Server en
los que se ha instalado el Directorio Activo, mientras que los si-
tios no son más que un conjunto de equipos relacionados con una
misma ubicación geográfica. Dichos equipos no tienen por qué
estar en el mismo lugar, pero sí conectados a una misma subred
física mediante un enlace permanente.
Todo controlador de dominio pertenece a un sitio específico que se
establece durante la instalación de AD, y ello determina, a su vez,
su lugar en la topología de replicación del directorio. La estructura
física inicial del AD se crea con el primer controlador de dominio de
la red, y consiste en un único sitio que podemos nombrar a nuestro
gusto. A partir de aquí, podemos ir añadiendo más controladores
de dominio según sea necesario.
Para una red pequeña es recomendable contar al menos con dos
controladores de dominio para garantizar unos niveles de dis-
ponibilidad y tolerancia a fallos adecuados, mientras que una
organización con muchos departamentos o sedes geográficas
necesitará crear más particiones, añadir múltiples controladores
de dominio, y probablemente también múltiples dominios, para
gestionar de forma totalmente eficiente y segura sus recursos.
Por lo tanto, a la hora de diseñar una topología de sitio para el
Directorio Activo, es necesario tomar en consideración la organiza-
ción departamental, funcional y geográfica de la organización, y a
partir de ahí elaborar un mapa que describa los puntos siguientes:
• Conexiones de red necesarias y existentes.
• Normas de replicación del Directorio Activo.
• Localización de los recursos relacionados con el bosque.
Los objetos del Directorio Activo que intervienen en este diseño, y
que se mantienen en el contenedor de configuración del bosque,
son los sitios, las subredes, los vínculos y puentes de vínculos a
sitios (cuyo papel veremos en el apartado 6.6) y los objetos de co-
nexión (que representan conexiones de replicación desde un DC de
origen a otro DC de destino). Toda esta información está disponible
localmente para todos los controladores de dominio, lo que les per-
mite gestionar adecuadamente las comunicaciones de red.
Lo cierto es que muchas de las decisiones relacionadas con la
estructura física del AD están relacionadas con las tareas de repli-
cación. De hecho, el AD utiliza los sitios y los vínculos a sitios para
determinar la ruta más eficiente para replicar los datos en todos los
controladores de dominio y los servidores de catálogo global.
Implantación de sistemas operativos
¡RECUERDA!
Dado que las estructuras
lógica y física del AD están
completamente desli-
gadas, es posible tener
varios dominios en un
mismo sitio, o un dominio
que abarque varios sitios
distintos.
239
Tema 6: Administración de dominios
Además, el AD utiliza la información del sitio para escoger el con-
trolador de dominio más cercano a cualquier cliente que quiera
iniciar sesión en la red, lo que debería permitirles autenticarse
dentro de su misma subred sin acudir a conexiones WAN. Y otras
aplicaciones que usan los servicios del Directorio Activo emplean
esta misma información de sitio de la misma manera.
Por todo ello, resulta crítico diseñar adecuadamente la topología
de la red para evitar la creación de cualquier cuello de botella. Una
vez que hayamos completado este diseño podemos proceder a ins-
talar el Directorio Activo en Windows Server 2019.
6.5.1. Instalación del Directorio Activo
en Windows Server 2019
Para realizar una instalación básica del AD en Windows Server 2019
seguiremos los pasos que se indican a continuación:
1. Empezaremos como siempre en el Panel del Administrador
del servidor, donde haremos clic sobre el enlace Agregar roles
y características. Una vez que se haya abierto la ventana del
asistente, iremos directamente al apartado Roles de servidor,
donde activaremos la casilla Servicios de dominio de Active
Directory. Este rol tiene una serie de dependencias que el
asistente seleccionará automáticamente para su instalación,
que confirmaremos pulsando el botón Agregar características
(Figura 6-3). Hacemos clic en Siguiente hasta llegar al final del
asistente, confirmando la operación mediante el botón Instalar.
2. El asistente nos informa de la instalación correcta de todos los
componentes seleccionados, pero que esta requiere de una
configuración posterior (Figura 6-4).
240
Figura 6-3
Figura 6-4
Implantación de sistemas operativos
3. Cerramos la ventana del asistente y abrimos el menú
de notificaciones del panel, donde veremos que es ne-
cesario promover el servidor a controlador de dominio.
Para ello pulsamos en el correspondiente enlace a tal
efecto (Figura 6-5).
4. Se abre el Asistente para configuración de Servicios
de dominio de Active Directory. En la primera sec-
ción, Configuración de implementación, deberemos
indicar si estamos agregando un DC a un dominio que
ya existe, si estamos agregando un nuevo dominio a
un bosque existente o si estamos creando un nuevo
bosque. En los dos primeros casos, es necesario que la
configuración DNS sea correcta para que el asistente
pueda localizar y conectarse al dominio o al bosque
existente; además, tendremos que usar las creden-
ciales de administrador de dicho dominio (dominio\
Administrador). Si, por el contrario, optamos por crear
un bosque, el nuevo dominio será también el dominio
Figura 6-5
raíz de un nuevo árbol dentro del nuevo bosque.
En el supuesto de tener registrado un dominio en Internet,
lo pondremos como nombre del dominio raíz (por ejemplo,
[Link]). Si se trata de un dominio en una intranet, utilizare-
mos siempre la terminación .local; por ejemplo, [Link]
(Figura 6-6).
5. En la siguiente sección, Opciones del controlador de dominio,
podemos escoger el nivel de compatibilidad del bosque con
otras ediciones de Windows Server, las capacidades del con-
trolador de dominio de nuestro servidor y la contraseña que
deseamos establecer para el modo de restauración de servicios
de directorio, o DSRM.
El Directorio Activo requiere de un servidor de nombres de do-
minio, por lo que, si no tenemos uno en la red, deberemos dejar
activada esta casilla (Figura 6-7). En este caso, no tenemos que
preocuparnos de la sección Opciones de DNS, ya que no esta-
mos integrando el servidor en una estructura DNS existente y
por tanto no es posible crear una delegación.
Figura 6-6
Figura 6-7
241
Tema 6: Administración de dominios
[Link] el caso de que estemos añadiendo un nuevo DC a un domi-
nio, en Opciones adicionales podremos escoger desde qué DC
se realizará la replicación. Si estuviéramos creando un nuevo
bosque, aquí podremos cambiar el nombre NetBIOS de la má-
quina. En cualquiera de los casos, en Rutas de acceso podemos
personalizar los directorios donde se almacenan la base de datos
y los archivos de registro (por defecto, C:\WINDOWS\NTDS) y la
carpeta SYSVOL (C:\WINDOWS\SYSVOL) (Figura 6-8).
Figura 6-8
7. Tras revisar la configuración realizada, se efectuará una com-
probación de los requisitos previos para la promoción del
servidor a controlador de dominio y se nos informará de cual-
quier circunstancia que pueda afectar al funcionamiento del
controlador (Figura 6-9). Si la operación de comprobación da
un resultado positivo, el asistente nos invitará a completar la
instalación pulsando el botón Instalar, con lo cual se realizarán
los cambios necesarios y se reiniciará el equipo.
8. Tras el reinicio, veremos que se nos han añadido los dos nuevos
roles instalados, AD DS y DNS (Figura 6-10).
242
Figura 6-9
Figura 6-10
Cuando creamos un nuevo sitio, es recomendable tener al menos
dos DC en el dominio para que el servicio de replicación DFS pueda
cumplir con su función. Debido a que los diferentes servicios recién
instalados requieren de un cierto tiempo para acabar de configurar-
se en los servidores, es posible que la replicación se vea retrasada.
Cuando el servicio DFSR falla, reintenta la operación en 60 minutos,
aunque podemos forzar la réplica abriendo una ventana de Símbolo
del sistema y ejecutando:
Implantación de sistemas operativos
> repadmin /replicate servidor02 servidor01
dc=midominio,dc=local
En este ejemplo, servidor02 es el servidor de destino y servidor01
es el de origen de la replicación.
Degradar un controlador de dominio
Si quisiéramos degradar el servidor para que deje de ser contro-
lador de dominio, tendríamos que desinstalar el rol Servicios de
dominio de Active Directory a través de la opción Quitar roles y
funciones del menú Administrar en el Administrador del servidor.
El asistente de desinstalación detectará que el equipo es un con-
trolador de dominio y mostrará un diálogo donde deberemos
hacer clic sobre el enlace Disminuir el nivel de este controlador de
dominio (Figura 6-11).
En el Asistente para la configuración de Servicios de dominio de
Active Directory podemos forzar la eliminación del controlador
(Figura 6-12).
Figura 6-11
Figura 6-12
243
Tema 6: Administración de dominios
En la sección Advertencias se nos informará de los roles que hos-
peda el DC (Figura 6-13). Marcaremos la casilla Continuar con la
eliminación y pulsaremos Siguiente.
Figura 6-13
Tendremos también que indicar una nueva contraseña de adminis-
tración (puede ser la misma que habíamos usado con anterioridad)
(Figura 6-14).
ponte a prueba
Indica si la siguiente afirma-
ción es verdadera o falsa:
En una intranet, los dominios
deben llevar la terminación
.es si se ubican en España.
a)b)#Verdadero
Falso
244
Figura 6-14
Finalmente, pulsaremos Disminuir nivel (Figura 6-15), tras lo cual
el equipo se reiniciará.
Figura 6-15
Implantación de sistemas operativos
6.6. Configurar la replicación entre
sitios
Como ya se ha apuntado anteriormente, el Directorio Activo utiliza
una técnica de replicación multimaestro, por lo que todos los con-
troladores de dominio mantienen una copia editable del directorio.
Este tipo de replicación tiene numerosas ventajas con respecto a
la basada en un esquema de replicación de maestro único, como
la que existía en Windows NT 4.0. En primer lugar, se elimina el
punto de fallo único en las operaciones de actualización; esto no
significa que la información esté perfectamente replicada en todos
los DC en todo momento, ya que algunos pueden tardar algo más
que otros en sincronizar los cambios, pero obviamente representa
una mejora sustancial en el aseguramiento de la información del
directorio.
El esquema multimaestro también acelera las operaciones de repli-
cación gracias a que la información se va transmitiendo de un DC a
otro, con lo cual eliminamos los problemas de distancia geográfica
entre el controlador de dominio maestro y los controladores más
lejanos, y también los derivados de tener a un solo DC efectuando
todas las operaciones de replicación sobre todos los controladores
de dominio.
Protocolos de replicación del AD
El tráfico de los datos de replicación requiere del uso de un pro-
tocolo de red. Cuando la replicación se realiza exclusivamente
dentro de un sitio, se utiliza siempre el protocolo RPC sobre IP sin
compresión de datos, y cuando se produce entre sitios podemos
optar por los protocolos RPC o SMTP, en ambos casos con compre-
sión de datos:
• Remote Procedure Call (RPC). El protocolo de llamada de pro-
cedimiento remoto sobre IP proporciona un sistema robusto y
rápido para gestionar las comunicaciones cliente/servidor. Se
trata de una capa intermedia entre el transporte de red y el pro-
tocolo de aplicación, y es compatible con la mayor parte de tipos
de red.
• Simple Mail Transfer Protocol (SMTP). Este protocolo se usa
también para la transmisión de mensajes de correo electrónico.
Es más fiable que el RPC, pero a su vez aumenta el volumen de
tráfico de la red, por lo que no es recomendable si lo que prima es
la conservación del ancho de banda. Además, si bien podremos
utilizarlo para replicar la información de configuración y el catá-
logo global, no admite la replicación entre DC pertenecientes al
mismo dominio.
245
Tema 6: Administración de dominios
Configuración de vínculos a sitios
Sabemos también que definir y gestionar la topología de sitio resul-
ta clave para determinar cómo deben replicarse los controladores
de dominio, lo que representa una de las tareas más laboriosas de
un administrador de Directorio Activo en redes medianas y gran-
des. Para ayudarnos en esta tarea disponemos del comprobador
de coherencia de réplica, o KCC (del inglés Knowledge Consistency
Checker), a través del cual se gestionan las conexiones de replica-
ción y se obtiene información acerca de cómo organizar los sitios y
los vínculos a sitios para optimizar el tráfico de red.
CONCEPTO
Los vínculos a sitios son de especial importancia
en la creación de réplicas del AD porque reflejan la
conectividad entre sitios y el método que se usa
para transferir el tráfico de replicación. Ello hace
necesario conectar los sitios con vínculos a sitios
para que sus respectivos controladores de dominio
puedan replicar los cambios en el directorio.
PARA + INFO
Los puentes de víncu-
los a sitios conectan
dos o más vínculos
a sitios, los cuales
deben tener un sitio en
común con otro vínculo
a sitios en el mismo
puente; esto permite la
transitividad entre ellos.
Un escenario típico
para la activación de los
puentes de vínculos a
sitios es cuando se debe
controlar la replicación
en redes segmentadas
por cortafuegos.
246
Para administrar los objetos que representan los sitios y los ser-
vidores que residen en ellos utilizaremos el complemento Sitios y
servicios de Active Directory de la consola de administración de Mi-
crosoft (MMC). Podemos acceder a él desde el menú Herramientas
del Administrador del servidor.
Si desplegamos por completo el árbol de sitios, veremos como, al
generarse el dominio, se ha creado el sitio por defecto, denominado
Default-First-Site-Name (Figura 6-16). Además, en Inter-Site
Transports > IP (que es el protocolo de transporte RPC sobre IP),
observaremos un vínculo a sitio llamado DEFAULTIPSITELINK.
Figura 6-16
Implantación de sistemas operativos
Lo primero que haríamos sería cambiar el nombre del sitio por
uno más descriptivo escogiendo, en su menú contextual, la op-
ción Cambiar nombre. A continuación, haremos clic derecho sobre
Subnets e indicaremos la subred que utiliza el sitio (es necesario
marcar explícitamente el sitio en el apartado Seleccionar un sitio de
objeto para este prefijo) (Figura 6-17).
Para añadir un nuevo sitio hacemos clic derecho sobre Sites y, en
el menú contextual, escogemos Nuevo sitio. Solo tenemos que in-
dicar el nombre del sitio y el vínculo que
utilizaremos (en nuestro caso, el que se
creó por defecto) (Figura 6-18).
Figura 6-18
Es obligatorio asignar una subred al nuevo sitio, por lo que procede-
remos de nuevo como se ha explicado anteriormente (Figura 6-19).
El vínculo que comunica los dos sitios ha quedado configurado
como DEFAULTIPSITELINK. Podemos renombrarlo para poder
identificarlo más fácilmente en el futuro (clic derecho > Cambiar
nombre) (Figura 6-20).
Figura 6-17
Figura 6-19
Figura 6-20
247
Tema 6: Administración de dominios
Para que dos sitios en diferentes ubicaciones
geográficas puedan comunicarse es necesario
conectarlos a través de Internet utilizando una
red privada virtual, o VPN. Por seguridad, es
importante que los servidores VPN en cada
extremo de la conexión estén en el mismo grupo
de trabajo pero no pertenezcan a un dominio.
Si ahora hacemos doble clic sobre este vínculo, veremos por fin
la configuración de replicación entre los sitios, cuya frecuencia
está establecida, por defecto, en tres horas (180 minutos), y no
puede sobrepasar la semana (10 080 minutos) (Figura 6-21).
En nuestro ejemplo, la replicación será cada 30 minutos.
Si queremos realizar una programación con mayor nivel de de-
talle, podemos hacerlo pulsando Cambiar programación, donde
podemos escoger los días de la semana y las horas en las que
se producirá la replicación (Figura 6-22). La programación y el
intervalo forman una pauta conjunta donde la replicación se pro-
duce en las horas programadas y con la frecuencia establecida.
Figura 6-21En este diálogo también podemos editar el valor de costo de
la replicación, un número arbitrario que refleja el ancho de
banda asociado a la conexión. Un número mayor significa una
conexión más lenta. El valor por defecto es 100, pero puede ir
desde 1 hasta 32 767. Por ejemplo, si creamos otra conexión
que es el doble de lenta que la actual, podríamos asignarle un
costo de 200 para reflejar la diferencia de velocidad de forma
proporcional.
248
Figura 6-22
6.7. Unidades organizativas
CONCEPTO
Una unidad organizativa, u OU por el inglés Organi-
zational Unit, es un tipo de contenedor del Directorio
Activo que puede albergar diferentes objetos perte-
necientes al mismo dominio en el que reside: grupos,
cuentas de usuarios y equipos y otros contenedores.
Es, por lo tanto, una unidad administrativa simple,
a la cual un administrador puede asociar objetos de
directiva de grupos u otorgar permisos sobre ella a
otros usuarios y grupos.
Los responsables de crear diseños de unidades organizativas para
sus dominios son los propietarios de los bosques. Ello implica
asignar los roles de propietario y crear las diferentes unidades or-
ganizativas de cuentas y recursos. Las OU podrán servir también
para aplicar directivas de grupo a los usuarios y a los equipos que
contengan, así como para limitar su visibilidad.
Como ya se mencionó en el apartado 6.4, los propietarios de las
unidades organizativas controlan un subárbol de objetos en los
Servicios de dominio de Active Directory (AD DS), y pueden delegar
su administración y determinar cómo se aplican las directivas a los
objetos de la unidad organizativa. También pueden crear nuevos
subárboles y delegar la administración de las unidades organizati-
vas dentro de esos subárboles.
Existen dos tipos de unidades organizativas:
• De cuentas. Contienen objetos de usuario, grupo y equipo. Cuan-
do se crea un nuevo dominio, resulta recomendable crear también
una unidad organizativa de cuentas con el fin de poder delegar el
control de las cuentas en el dominio.
• De recursos. Contienen recursos y los objetos de cuentas res-
ponsables de su administración. Este tipo de OU aumenta el nivel
de autonomía en la administración de datos y equipos, ya que el
propietario del bosque puede delegar también estas tareas en el
propietario de la OU.
Para crear una unidad organizativa es necesario
utilizar una cuenta de administrador de dominio,
o bien que dichos permisos se nos hayan delega-
do a nivel de dominio o de cuenta específica.
Implantación de sistemas operativos
¡RECUERDA!
Es importante recordar
dos aspectos esenciales
en la administración de las
unidades organizativas:
primero, que la delegación
de unidades organizativas
en otros administradores
o usuarios no implica que
se les otorgue privilegios
de administrador sobre
el dominio; y segundo,
que, cuando aplicamos
una directiva de grupo
sobre una OU, estamos
aplicándola también
sobre todas las cuentas de
usuario y de equipo que
están contenidas en ella.
249
Tema 6: Administración de dominios
Las unidades organizativas se crean desde el complemento de la
Consola de administración de Microsoft (MMC) llamado Usuarios
y equipos de Active Directory, al que podemos acceder desde el
menú Herramientas del Administrador del servidor, o bien pulsan-
do las teclas Windows + R y ejecutando [Link].
En la estructura del dominio por defecto podemos observar que
se han creado varios contenedores, entre ellos la OU Domain Con-
trollers, que contendrá todos los controladores de dominio y está
ligada a la directiva de controlador de dominio; Builtin, que contie-
ne los grupos de seguridad administrativo y de dominio locales, y
Computers y Users, que son los contenedores por defecto para las
nuevas cuentas de equipo y de usuarios y grupos, respectivamente.
Primero hacemos clic derecho sobre nuestro dominio y selecciona-
mos Nuevo > Unidad organizativa (Figura 6-23).
Figura 6-23
Seguidamente, damos nombre a la OU y pulsamos el botón Aceptar
para crearla (Figura 6-24).
250
Figura 6-24
Las OU se crean con la característica de protección contra elimina-
ción accidental activada. Esto significa que, si intentamos eliminar
la nueva OU, el sistema no nos lo permitirá a menos que la desacti-
vemos. El problema es que el acceso a este parámetro no está visible
en el diálogo de Propiedades por defecto de la OU (Figura 6-25).
Para acceder a esta propiedad seleccionaremos la OU, haremos clic
derecho sobre ella y seleccionaremos Ver > Características avanza-
das (Figura 6-26). Observaremos cómo aparece un nuevo conjunto
de contenedores que están invisibles en la vista normal.
Implantación de sistemas operativos
Figura 6-25
Figura 6-26
Con este modo de vista activado, al hacer clic derecho sobre la OU
y seleccionar Propiedades, veremos varias pestañas adicionales,
entre ellas una llamada Objeto. Aquí es donde podremos desmarcar
la casilla Proteger objeto contra eliminación accidental, para luego
proceder a su borrado (Figura 6-27). Es necesario tener mucho cui-
dado con esta operación, ya que al eliminar una OU desaparecerá
también cualquier objeto anidado.
Se puede anidar una OU dentro de otra OU. Por ejemplo, si qui-
siéramos crear una estructura por departamentos en una OU
determinada, simplemente seguiríamos los mismos pasos que
hemos indicado pero haciendo clic derecho sobre la OU donde
queremos crear los contenedores anidados (Figura 6-28).
Figura 6-27
Figura 6-28
251
Tema 6: Administración de dominios
Con la estructura de OU creada, podemos cambiar el contenedor
en el que las cuentas de usuario y los grupos se crean por defecto.
En nuestro ejemplo, si quisiéramos que se crearan en la OU llamada
Usuarios del dominio [Link], podemos usar la orden:
> redirusr OU=USUARIOS,DC=ILERNA,DC=LOCAL
Para obtener el mismo efecto con las cuentas de equipo:
> redircmp OU=EQUIPOS,DC=ILERNA,DC=LOCAL
Por último, podemos delegar los permisos sobre la OU en otros
usuarios haciendo clic derecho sobre ella y escogiendo Delegar
control. Con esto se ejecuta el Asistente para delegación de control,
donde usaremos el botón Agregar para añadir los usuarios o los
grupos en los que vamos a delegar el control (Figura 6-29).
ponte a prueba
¿Quiénes son los responsa-
bles de crear el diseño de la
estructura de OU en el Direc-
torio Activo?
a) #Los propietarios de los
bosques.
b) #Los propietarios de las
unidades organizativas.
c) #Los administradores de los
controladores de dominio.
d) #Cualquier administrador en el
bosque.
252
Figura 6-29
Para finalizar, escogeremos las acciones que podrá realizar la cuen-
ta o el grupo en los que delegamos de entre una lista de tareas
predefinidas (Figura 6-30), o personalizándolas.
Figura 6-30
Implantación de sistemas operativos
6.8. Administración de grupos
Para simplificar la administración del dominio, es posible trabajar
con grupos de usuarios en lugar de con cuentas de usuario y de
equipo individuales.
En el Directorio activo existen dos tipos de grupos:
• De distribución. Se utilizan exclusivamente para crear listas de
distribución de correo electrónico, y por lo tanto solo funcionan
en aplicaciones de correo como Exchange.
• De seguridad. Se emplean para asignar permisos a recursos
compartidos. Los grupos de seguridad tienen, por lo tanto, cier-
tos derechos de usuario asignados, que determinan las acciones
que pueden realizar los miembros de dichos grupos en un domi-
nio o en un bosque.
Cuando se instala el Directorio Activo, se crean varios grupos de
seguridad que permiten asignar ciertas tareas administrativas a
determinados usuarios. Todos los miembros de un grupo heredan
todos los derechos de usuario asignados a dicho grupo.
Además de los derechos de usuario, pueden asignarse también
permisos para recursos a los grupos de seguridad. Estos determi-
nan quién puede obtener acceso al recurso y su nivel de acceso.
Por último, los grupos de seguridad pueden usarse en aplicacio-
nes de correo electrónico a modo de listas de distribución.
¿SABÍAS QUE...?
Las listas de control de acceso discrecional, o DACL
(Discretionary Access Control List), son las que definen
los permisos en recursos y objetos. Dichos permisos se
designan a un grupo de seguridad en lugar de a usuarios
individuales.
Todos los grupos tienen un ámbito que define en qué contexto
(bosque o árbol de dominio) pueden recibir permisos. En el Directo-
rio Activo, dichos ámbitos pueden ser universal, global y dominio
local. En la tabla 6-2 podemos ver resumen de las características
asociadas a cada uno de ellos.
253
Tema 6: Administración de dominios
Ámbito
Universal
Global
Dominio
local
Posibles miembros
•••Cuentas de cualquier
dominio del mismo
bosque.
Grupos globales de
cualquier dominio del
mismo bosque.
Otros grupos universales
de cualquier dominio del
mismo bosque.
••Cuentas del mismo
dominio.
Otros grupos globales del
mismo dominio.
•••••Cuentas de cualquier
dominio o de cualquier
dominio de confianza.
Grupos globales de
cualquier dominio o
cualquier dominio de
confianza.
Grupos universales de
cualquier dominio del
mismo bosque.
Otros grupos locales
de dominio del mismo
dominio.
Cuentas, grupos globales
y grupos universales
de otros bosques y de
dominios externos.
Posible miembro de
• Otros grupos universales
en el mismo bosque.
• Grupos locales de
dominio en el mismo
bosque o bosques de
confianza.
• Grupos locales en
equipos del mismo
bosque o bosques de
confianza.
• Grupos universales de
cualquier dominio del
mismo bosque.
• Otros grupos globales
del mismo dominio.
• Grupos locales de
dominio de cualquier
dominio del mismo
bosque o de cualquier
dominio de confianza.
• Otros grupos locales
de dominio del mismo
dominio.
• Grupos locales en
equipos del mismo
dominio, excluyendo los
grupos integrados que
tienen SID conocidos.
Conversión de ámbito
••Se puede convertir
a ámbito local de
dominio si el grupo no
es miembro de ningún
otro grupo universal.
Se puede convertir
al ámbito global si
el grupo no contiene
ningún otro grupo
universal.
Se puede convertir al
ámbito universal si el
grupo no es miembro
de ningún otro grupo
global.
Puede conceder
permisos
En cualquier
dominio del
mismo bosque
o bosques de
confianza.
En cualquier
dominio del
mismo bosque
o en dominios
o bosques de
confianza.
Se puede convertir al
ámbito universal si
el grupo no contiene
ningún otro grupo local
de dominio.
Dentro del
mismo dominio.
Tabla 6-2
(Fuente: Microsoft)
Tal como los define Microsoft en su documentación oficial, en
Windows Server 2016 y 2019 existen un total de 50 grupos de se-
guridad predeterminados, de los cuales citaremos aquí algunos de
los más destacados:
• Operadores de cuentas. Concede privilegios para crear y mo-
dificar la mayor parte cuentas, incluidas las de usuarios, grupos
locales y grupos globales. Los miembros de este grupo pueden
iniciar sesión localmente en controladores de dominio.
• Administradores. Tienen acceso completo y sin restricciones al
equipo y, si este se promociona a DC, también al dominio.
254
Implantación de sistemas operativos
• Operadores de copia de seguridad. Los miembros de este gru-
po pueden hacer una copia de seguridad y restaurar todos los
archivos de un equipo, sin importar los permisos que los protejan.
También pueden iniciar sesión y apagar el equipo.
• Administradores de dominio. Los miembros de este grupo
controlan el acceso a todos los controladores de dominio en un
dominio, y pueden modificar la pertenencia de todas las cuentas
administrativas del dominio. Además, son los propietarios prede-
terminados de cualquier objeto creado en el AD para el dominio
por cualquier miembro del grupo.
• Equipos de dominio. Incluye todos los equipos y servidores que
se han unido al dominio, excepto los controladores de dominio.
Cualquier cuenta de equipo creada de forma automática será
miembro de este grupo.
• Controladores de dominio. Los nuevos controladores de domi-
nio se agregan automáticamente a este grupo.
• Invitados de dominio. Este grupo incluye la cuenta de invita-
do integrada del dominio. Cuando los miembros de este grupo
inician sesión como invitados locales en un equipo unido a un do-
minio, se crea un perfil de dominio en el equipo local.
• Usuarios de dominio. Incluye todas las cuentas de usuario de un
dominio. Las cuentas de usuario creadas en el ámbito del domi-
nio se agregan automáticamente a este grupo.
• Administradores de empresa. El único miembro del grupo es, de
manera predeterminada, la cuenta de administrador del dominio
raíz del bosque, y proporciona acceso completo para configurar
todos los controladores de dominio.
• Administradores de clave de empresa. Los miembros de este
grupo pueden realizar acciones administrativas en objetos clave
dentro del bosque.
• Propietarios del creador de directivas de grupo. Los miembros
de este grupo están autorizados a crear, editar o eliminar objetos
de directiva de grupo en el dominio. De forma predeterminada, el
único miembro del grupo es Administrador.
• Invitados. De manera predeterminada, su único miembro es la
cuenta de invitado. El grupo permite a los usuarios ocasionales
o únicos iniciar sesión con privilegios limitados en la cuenta de
invitado integrada de un equipo.
• Operadores de configuración de red. Sus miembros tienen
privilegios administrativos que les permiten gestionar la configu-
ración de la red en aspectos como por ejemplo las propiedades
del protocolo TCP/IP, el nombre de las conexiones locales o de ac-
ceso remoto, eliminar conexiones de acceso remoto, inhabilitar o
habilitar una red local, etc.
• Administradores de esquema. Solo los miembros de este grupo
(que existe únicamente en el dominio raíz de un bosque) pueden
modificar el esquema del Directorio Activo.
255
Tema 6: Administración de dominios
• Operadores de impresión. Los miembros de este grupo pueden
administrar, crear, compartir y eliminar impresoras conectadas a
controladores de dominio en el dominio. Al poder cargar y des-
cargar controladores de dispositivo en todos los DC del dominio,
es necesario tomar las debidas precauciones antes de agregar
nuevos usuarios a este grupo.
• Usuarios de Escritorio remoto. Este grupo se emplea para con-
ceder a los usuarios y grupos permisos para conectarse de forma
remota a un servidor anfitrión de sesión de Escritorio remoto.
• Replicador. Solo los equipos que son miembros de este grupo
admiten la replicación de archivos en un dominio.
• Operadores de servidor. Los miembros pertenecientes a este
grupo (que solo puede existir en el ámbito de un DC) podrán ad-
ministrar controladores de dominio.
• Usuarios. Inicialmente su único miembro es el grupo Usuarios
autenticados. Sus miembros pueden ejecutar la mayoría de las
aplicaciones, usar impresoras locales y de red, y apagar o bloquear
el equipo. Cuando un equipo se une a un dominio, los usuarios de
este grupo se agregan al grupo Usuarios de dicho equipo.
Como en el caso de las OU, podemos crear y administrar nuestros
grupos desde el complemento Usuarios y equipos de Active Direc-
tory (Windows + R > [Link]).
En esta ocasión, haremos clic derecho en el dominio y selecciona-
remos Nuevo > Grupo. En el diálogo de creación del nuevo objeto,
daremos nombre al grupo y, si es necesario, podremos cambiar su
ámbito y tipo (Figura 6-31).
256
Figura 6-31
Implantación de sistemas operativos
6.9. Cuentas de usuario y de equipo
A la hora de evaluar el papel de las cuentas de usuario en el AD, lo
primero es definirlas como un objeto o entidad de seguridad cuya
misión es doble: permiten autenticar identidades y hacen posible
autorizar o denegar el acceso a las funciones y los recursos del
dominio, para lo cual se les asigna identificadores únicos de segu-
ridad o SID (acrónimo del inglés Security Identifier).
Estos objetos no tienen por qué representar a personas, ya que de-
terminados servicios y aplicaciones, tanto locales como remotos,
pueden utilizar también cuentas de usuario como forma de obte-
ner acceso al dominio. Además, según los privilegios que tengan,
concedidos se pueden utilizar para administrar otras entidades
de seguridad, así como para auditar las acciones realizadas desde
cada una de las cuentas.
En el AD existen dos tipos de usuario:
• Globales. Se crean en los controladores de dominio y pueden
usarse para acceder a otros dominios de confianza.
• Locales. Se crean en servidores o equipos de trabajo que no
son DC, por lo que no se pueden utilizar para conectarse a nin-
guno de ellos y solo tienen permisos en el equipo donde se
hayan creado.
Cuando creamos un dominio, con él se crean diversas cuentas
globales de forma predeterminada, que son independientes de las
cuentas de usuario locales. Estas cuentas se almacenan en el conte-
nedor Users en Usuarios y equipos de Active Directory, y se asignan
automáticamente a un grupo de seguridad preconfigurado con los
permisos adecuados para realizar tareas específicas.
Encontraremos el acceso al complemento Usuarios y equipos de Active
Directory en el menú Herramientas del Administrador del servidor.
257
Tema 6: Administración de dominios
Microsoft recomienda mantener las
cuentas locales predeterminadas en
el contenedor de usuario y no intentar
moverlas a una unidad organizativa
(OU) diferente.
PARA + INFO
Por seguridad, solo se
permite iniciar sesión
en el servidor a los
administradores y a los
usuarios que perte-
nezcan a los grupos de
operadores de cuentas,
de servidores, de copia
de seguridad y de
impresión. Podemos
encontrar y editar esta
directiva en la Directiva
de seguridad local,
dentro de Directivas
locales > Asignación
de derechos de usuario
> Permitir el inicio de
sesión local.
258
Las cuentas de usuario predeterminadas del Directorio Activo son
las siguientes:
• Administrador. La cuenta de administrador proporciona al usua-
rio permisos de control total sobre los archivos, los directorios,
los servicios y cualquier otro recurso del servidor local. Se puede
usar para crear usuarios locales y asignar derechos de usuario y
permisos de control de acceso. Esta cuenta puede también inha-
bilitarse cuando no resulte necesaria, y aun así puede usarse para
acceder a un DC mediante el modo seguro. En un controlador de
dominio, la cuenta de administrador se denomina cuenta de ad-
ministrador de dominio.
• Invitado. Proporciona acceso limitado al equipo y está inhabili-
tada de forma predeterminada. Al tener la contraseña en blanco,
permite a los usuarios que no tienen una cuenta individual en el
equipo iniciar sesión en el servidor o dominio local de forma anó-
nima con derechos y permisos restringidos. Este hecho, unido a
que esta cuenta tiene un SID conocido, hacen recomendable de-
jar esta cuenta inhabilitada, o bien únicamente habilitarla en caso
de extrema necesidad y por un tiempo muy limitado.
• KRBTGT. Actúa como una cuenta de servicio para el servicio del
Centro de distribución de claves (KDC), un sistema criptográfico
derivado del protocolo Kerberos que proporciona un servicio de
autenticación (AS) y otro de concesión de vales (TGS). Este últi-
mo emite vales para la conexión de equipos en su propio dominio
cada vez que un cliente quiere acceder a un equipo, mientras que
el servicio AS emite vales para la conexión al TGS en su propio
dominio o en cualquier otro dominio de confianza. Esta cuenta no
se puede eliminar y no se le puede cambiar el nombre. Además,
su contraseña se usa para derivar una clave secreta que sirve para
cifrar y descifrar las solicitudes TGT que se emiten, por lo que re-
sulta crítico que sea una contraseña segura y que se cambie de
forma periódica.
• HelpAssistant. Se habilita cuando se ejecuta una sesión de asis-
tencia remota en un sistema operativo Windows, y se inhabilita
automáticamente cuando no hay solicitudes de asistencia remo-
ta pendientes. Dado que la asistencia remota es un componente
opcional de Windows Server, es posible que este usuario no se
habilite nunca.
Para crear una cuenta de usuario abrimos el complemento Usuarios
y equipos de Active Directory, hacemos clic derecho sobre el con-
tenedor Users para acceder a su menú contextual y seleccionamos
Nuevo > Usuario (Figura 6-32).
Figura 6-32
En el diálogo siguiente rellenamos los datos de la cuenta. Tras ello,
indicamos la contraseña de la cuenta (que deberá cumplir con los
requisitos de fortaleza establecidos) (Figura 6-33), y escogemos
las opciones relativas que apliquen en nuestro caso. Hacemos clic
en Siguiente, y a continuación en Finalizar para crear la cuenta.
Implantación de sistemas operativos
¿SABÍAS QUE...?
Algunas de las cuentas
predefinidas están
protegidas por un
proceso en segundo
plano que comprueba y
aplica periódicamente
la configuración de
seguridad (o descriptor
de seguridad) asociada
a ellas. De esta forma,
cualquier cambio no
autorizado en este
descriptor se sobrescri-
birá con la configuración
protegida. El objeto que
contiene el descriptor de
seguridad se denomina
AdminSDHolder.
Figura 6-33
Si hacemos doble clic sobre la cuenta, podremos editar estas y otras
muchas propiedades con información personal y administrativa
(Figura 6-34). En el siguiente apartado configuraremos algunos de
estos parámetros para crear una plantilla de usuario.
Figura 6-34
259
Tema 6: Administración de dominios
Creación de cuentas de equipo
Por otra parte, la cuenta de equipo sirve para autenticar la máquina
en el dominio. Al igual que las cuentas de usuario, las cuentas equi-
po deben ser únicas dentro del dominio.
Las cuentas de equipo se crean de la misma forma que las de usua-
rio, pero desde el contenedor Computers, en cuyo menú contextual
seleccionaremos Nuevo > Equipo (Figura 6-35).
Haciendo doble clic sobre el equipo podremos editar sus propie-
dades, incluyendo su pertenencia a un sitio, su nombre DNS, las
opciones de delegación de servicios o su ubicación, entre otras
(Figura 6-36).
Figura 6-35
Figura 6-36
6.9.1. Plantillas de cuenta
En organizaciones donde es necesario crear de manera frecuente
cuentas de usuario, contar con una serie de plantillas a partir de las
cuales crear los nuevos perfiles puede ahorrarnos mucho tiempo.
Además, estas plantillas contribuyen a reducir la posibilidad de co-
meter un error; por ejemplo, al asignar los nuevos usuarios a ciertos
grupos, o configurando aspectos como los horarios de trabajo,
entre otros muchos.
Supongamos que existe un departamento de contabilidad en el
cual todos los usuarios tienen en común las mismas propiedades,
por ejemplo, a través de su pertenencia a un grupo de seguridad
determinado, y a los cuales se les permite acceso a una misma
carpeta compartida. Si creamos las cuentas de usuario desde cero,
tendremos que configurar una por una todas estas propiedades,
mientras que, si nos basamos en una plantilla, todo lo que tendre-
mos que hacer es modificar los datos personales.
260
Para crear una plantilla, primero debemos crear una cuenta de usua-
rio siguiendo el procedimiento detallado en las páginas iniciales
de este mismo apartado 6.9. Dado que probablemente tendremos
creada una OU para segmentar los usuarios por departamento,
crearemos la plantilla dentro de la unidad organizativa correspon-
diente; por ejemplo, Usuarios > Madrid > Ventas (Figura 6-37).
Implantación de sistemas operativos
Figura 6-37
Como Nombre completo podemos optar por un nombre descripti-
vo; por ejemplo, Plantilla de usuario de Ventas (Figura 6-38).
Figura 6-38
En el diálogo de configuración de contraseña debemos asegurar-
nos también de activar dos opciones específicas: El usuario debe
cambiar la contraseña en el siguiente inicio de sesión y La cuenta
está deshabilitada (Figura 6-39).
Figura 6-39
261
Tema 6: Administración de dominios
Una vez creado el usuario, procederemos a editar sus propiedades
para crear una plantilla que podamos aplicar a los nuevos usuarios
de la OU. Haremos lo siguiente:
[Link] clic derecho sobre la nueva cuenta de usuario y selec-
cionamos Propiedades (Figura 6-40).
[Link] 6-40
Vamos a la pestaña Miembro de y lo agregamos a los grupos de
usuarios que corresponda (Figura 6-41).
262
Figura 6-41
[Link] la pestaña Organización rellenamos la información relevante
(Figura 6-42).
Implantación de sistemas operativos
Figura 6-42
[Link] la pestaña Cuenta podemos definir el horario laboral pulsan-
do el botón Horas de inicio de sesión (en el ejemplo, de 8 a 18
horas, de lunes a viernes) (Figura 6-43).
Figura 6-43
263
Tema 6: Administración de dominios
Una vez finalizada la creación de la plantilla, para aplicarla haremos
lo siguiente:
1. Hacemos clic derecho sobre la plantilla y escogemos la opción
Copiar del menú contextual (Figura 6-44).
[Link] 6-44
A continuación completamos los campos del nuevo objeto con
la información del usuario (Figura 6-45).
264
Figura 6-45
[Link] el siguiente paso indicamos una contraseña provisional, ya
que el usuario deberá cambiarla por una contraseña propia en
cuanto intente iniciar la sesión (Figura 6-46).
Implantación de sistemas operativos
Figura 6-46
[Link] y, tras aceptar la advertencia, veremos que la nueva
cuenta de usuario aparece junto a la plantilla que le sirvió de
base. Si accedemos a sus propiedades, veremos que, excepto
por los datos que acabamos de rellenar, son los mismos que los
de la plantilla. En este punto no debemos olvidarnos de habi-
litar el nuevo perfil, desde la pestaña Cuenta, desmarcando la
casilla La cuenta está deshabilitada (Figura 6-47).
Figura 6-47
265
Tema 6: Administración de dominios
6.9.2. Carpetas particulares
Las denominadas carpetas particulares son las carpetas perso-
nales de los usuarios del Directorio Activo. Se trata de directorios
compartidos en el servidor, donde cada usuario del dominio puede
almacenar sus archivos privados y que, para dichos usuarios, apa-
recen como unidades de red.
Para crear una estructura de directorios personales, lo primero es
crear una carpeta contenedora en el servidor, dentro de la cual se
irán creando todas las carpetas particulares. Para ello seguiremos
los pasos que se indican a continuación:
[Link] en el servidor (preferiblemente, y por seguridad, en una
unidad para datos que no sea la del sistema) una nueva carpeta
usando el Explorador de archivos de Windows (Figura 6-48).
Figura 6-48
[Link] las propiedades de la nueva carpeta y vamos a la pes-
taña Compartir. Pulsamos el botón Uso compartido avanzado
y activamos la casilla Compartir esta carpeta. Adicionalmente,
editaremos el nombre del recurso compartido, añadiendo un
símbolo $ al final para que no se muestre cuando cualquier
usuario acceda a la lista de carpetas compartidas (Figura 6-49).
266
Figura 6-49
[Link] el botón Permisos y agregamos el grupo Usuarios del
dominio, otorgándoles control total sobre este recurso, y elimi-
naremos el grupo Todos de la lista (Figura 6-50).
Implantación de sistemas operativos
Figura 6-50
[Link] vez configurada la carpeta contenedora, procederemos a
editar las cuentas de usuario para configurar en ellas la ruta a
sus carpetas particulares. Podemos editarlas una por una, o
seleccionarlas todas para realizar la configuración requerida de
manera simultánea:
Abrimos la herramienta Usuarios y equipos de Active Directory,
seleccionamos los usuarios a editar, hacemos clic derecho
sobre cualquiera de ellos y escogemos la opción Propiedades
(Figura 6-51).
Figura 6-51
267
Tema 6: Administración de dominios
5. Accedemos a la pestaña Perfil y marcamos la casilla Carpeta
particular. Aquí podemos indicar una ruta de acceso local, o
bien asignar el recurso a una unidad de red, lo cual resultará
más accesible y claro para los usuarios al separar su árbol de
directorios del recurso compartido. Indicaremos la ruta de ac-
ceso de red agregándole la variable de entorno %username%
para que se utilice un directorio con el nombre de usuario de
la cuenta (Figura 6-52). En nuestro ejemplo, quedaría así:
\\SERVIDOR01\Carpetas particulares$\%username%.
ponte a prueba
¿Qué función tiene una
cuenta de equipo?
a) #Organizar los usuarios dentro
de ese mismo equipo.
b) #Autenticar la máquina en un
dominio.
c) #Es otra forma de denominar
las cuentas de grupo.
d) #Son los contenedores donde
se crean las plantillas de
cuenta.
268
Figura 6-52
[Link] aplicar los cambios, si regresamos a la carpeta compartida
veremos que ya se han creado en ella las carpetas particulares
de todos los usuarios que habíamos seleccionado (Figura 6-53).
Figura 6-53
Implantación de sistemas operativos
6.9.3. Perfiles móviles y obligatorios
Los perfiles de usuario móviles o itinerantes (o Roaming User
Profiles en inglés) se almacenan en el servidor, de forma que los
contenidos y las personalizaciones de los usuarios están siempre
disponibles con independencia de la máquina física en la que
estos inicien la sesión.
Esto permite, además, que los administradores de sistemas puedan
formatear o reemplazar los equipos cliente sin tener que preo-
cuparse de salvaguardar los datos de los usuarios, cuya copia de
seguridad se realizará de forma centralizada en el servidor.
Los pasos para crear un perfil móvil son: crear una carpeta con-
tenedora en el servidor, editar los permisos de dicha carpeta para
que solo los usuarios autorizados puedan acceder a sus contenidos
y modificar la configuración de las cuentas para que su perfil se
almacene en dicha carpeta.
Para los dos primeros pasos nos remitiremos al apartado 6.9.2,
solo que esta vez llamaremos Perfiles (o cualquier otro nombre
descriptivo de su contenido) a la carpeta contenedora, y en lugar
de conceder permisos a todos los usuarios del directorio, se los
otorgaremos a grupos concretos (pueden ser departamentales o
un grupo de usuarios móviles genérico).
Una vez creada la carpeta de perfiles en el servidor, lanzaremos el
complemento Usuarios y equipos de Active Directory (Windows + R >
[Link]), y seguiremos los pasos que se indican a continuación:
1. Seleccionamos los usuarios a los que queremos otorgar un
perfil móvil, hacemos clic derecho sobre cualquiera de ellos
y escogemos la opción Propiedades (o bien, si se trata de un
único usuario, hacemos doble clic sobre él) (Figura 6-54).
Figura 6-54
269
Tema 6: Administración de dominios
[Link] la pestaña Perfil, indicamos la ruta de acceso al perfil móvil
en el cuadro correspondiente. Como en el caso de las carpetas
particulares, debemos especificar la ruta de red y añadir la va-
riable %username% al final para que se cree la carpeta con el
nombre de usuario de la cuenta. En nuestro ejemplo, la ruta que-
daría así: \\SERVIDOR01\Perfiles$\%username% (Figura 6-55).
Figura 6-55
PARA + INFO
La primera vez que se inicie sesión con un perfil móvil se
creará su carpeta en el directorio contenedor de perfiles
del servidor. Veremos que al nombre de usuario se añade
la extensión .V6, que indica la compatibilidad del perfil
con otras ediciones de Windows Server. Las versiones de
Windows XP y Server 2003 no llevan número de versión,
y a partir de Windows Vista se han utilizado cinco versio-
nes distintas: V2 (Windows Vista, Windows 7, Windows
8 y 8.1, Windows Server 2008 y 2008 R2 y Windows
Server 2012 y 2012 R2), V3 (Windows 8 y Windows
Server 2012), V4 (Windows 8.1 y Windows Server 2012
R2), V5 (Windows 10) y V6 (Windows 10 de la versión
1607 en adelante, Windows Server 2016 y Windows
Server 2019).
270
Implantación de sistemas operativos
Convertir un perfil itinerante en obligatorio
Los perfiles obligatorios son una variante de los perfiles móviles
en la cual los usuarios no pueden realizar cambios en sus perfiles.
Esto puede resultar útil cuando se desea mantener una serie de
elementos fijos en el perfil itinerante por cuestiones funcionales o
de directiva corporativa.
Para convertir un perfil móvil en uno obligatorio realizaremos los
siguientes pasos:
1. Entramos en la carpeta contenedora de los perfiles, hacemos
clic derecho sobre el perfil a convertir y seleccionamos Propie-
dades. Accedemos a la pestaña Seguridad, y hacemos clic en
el botón Opciones avanzadas. En diálogo de configuración de
seguridad avanzada pulsamos el enlace Cambiar para cambiar
el propietario de la carpeta, y asignamos la propiedad al grupo
Administradores. Aceptamos todos los diálogos y volvemos a
abrir las propiedades de la carpeta. Veremos que esta vez nos
aparecen los permisos que necesitaremos para efectuar los
cambios necesarios (Figura 6-56).
Figura 6-56
PARA + INFO
Si vamos a convertir una cuenta local en obligatoria,
lo más cómodo es copiar primero la carpeta del perfil
local ubicada en C:\Usuarios en la carpeta de perfiles
itinerantes del servidor, añadirle la extensión .V6 y editar
la ruta de acceso al perfil en Usuarios y equipos de Active
Directory de la forma previamente descrita.
271
Tema 6: Administración de dominios
[Link] en la carpeta de perfil y activamos en el Explorador de
archivos la visibilidad de los elementos ocultos (Figura 6-57).
Figura 6-57
3. Abrimos las propiedades del archivo [Link] y, en la
pestaña Seguridad, añadimos el grupo Administradores a los
permisos con control total (Figura 6-58).
4. Renombramos el archivo [Link] como [Link]. Con
esto, el perfil itinerante se habrá convertido en obligatorio, y
todos los cambios que el usuario realice durante la sesión se
perderán en cuanto esta finalice.
272
Figura 6-58
Implantación de sistemas operativos
6.9.4. Directivas de bloqueo de cuentas
La directiva de bloqueo de cuentas es un elemento importante
en la seguridad del dominio, ya que limita el número de veces que
puede realizarse un intento de inicio de sesión con la contraseña
incorrecta antes de que la cuenta se bloquee. De esta forma cerra-
mos la brecha de seguridad que supone la posibilidad de un ataque
basado en la adivinación de contraseñas por la fuerza bruta o en un
diccionario.
Los pasos necesarios para editar esta directiva son los siguientes:
[Link] al menú Iniciar > Herramientas administrativas de Win-
dows > Administración de directivas de grupo (Figura 6-59).
Expandimos el bosque y los dominios, hacemos doble clic sobre
nuestro dominio y hacemos clic derecho sobre la directiva de
dominio por defecto (Default Domain Policy) seleccionando
Editar en el menú contextual (Figura 6-60).
Figura 6-59
[Link] vez en el Editor de administración de directivas de grupo,
vamos a Configuración del equipo > Directivas > Configuración
de Windows > Configuración de seguridad > Directivas de cuen-
ta > Directiva de bloqueo de cuenta. Dentro de esta directiva
veremos las tres configuraciones de bloqueo de cuenta dispo-
nibles en el AD (Figura 6-61), las cuales, por el momento, están
sin definir.
Figura 6-60
Figura 6-61
273
Tema 6: Administración de dominios
[Link] doble clic sobre Duración del bloqueo de cuenta y mar-
camos la casilla Definir esta configuración de directiva, con lo que
podremos decidir por cuánto tiempo permanecerán bloquea-
das las cuentas (por defecto, entre 0 y 99 999 minutos) (Figura
6-62). Si ponemos a cero la duración del bloqueo, la cuenta per-
manecerá bloqueada hasta que el administrador la desbloquee.
Dado que la directiva de duración del bloqueo solo tiene sen-
tido si se cambia la configuración de las otras dos directivas,
Windows Server sugiere que se apliquen ciertos valores y rea-
liza estas modificaciones de forma automática (Figura 6-63).
Figura 6-62
Figura 6-63
6. Si queremos modificar el valor manualmente, podemos, como
en el caso anterior, hacer doble clic sobre el parámetro para
editarlo (Figura 6-64). Mediante el valor de Umbral de bloqueo
de cuenta configuramos
el número máximo de
intentos fallidos de inicio
de sesión que se permite
antes de bloquear la cuen-
ta, y el valor de tiempo
de restablecimiento de
los recuentos de bloqueo
determina el número de
minutos (entre 1 y 99 999)
que debe transcurrir tras
un intento fallido para que
el contador de intentos de
inicio de sesión incorrec-
tos se restablezca a cero,
no pudiendo superar este
intervalo la duración del
Figura 6-64
bloqueo de cuenta.
274
Implantación de sistemas operativos
6.9.5. Restricción del inicio de sesión
En el apartado 6.9.1 dedicado a la configuración de plantillas de
cuentas vimos cómo, desde el complemento Usuarios y equipos de
Active Directory, podíamos definir el horario laboral pulsando el
botón Horas de inicio de sesión en la pestaña Cuentas de las propie-
dades de una cuenta de usuario.
Esta configuración evitará que el usuario pueda iniciar la sesión en
ciertos días y a determinadas horas, aunque, una vez iniciada, la
sesión podría prolongarse fuera del horario laboral.
Para evitarlo debemos configurar una directiva de grupo utili-
zando la herramienta Administración de directivas de grupo que
encontraremos en el menú Iniciar > Herramientas administrativas
de Windows. Una forma de acceder directamente al editor de
directivas es lanzarlo con [Link] desde el diálogo Ejecutar
(Windows + R).
El procedimiento es básicamente el mismo que seguimos al confi-
gurar las directivas de bloqueo de cuentas: expandimos el bosque
y los dominios, hacemos doble clic sobre nuestro dominio y hace-
mos clic derecho sobre la directiva de dominio por defecto (Default
Domain Policy) seleccionando Editar en el menú contextual.
En esta ocasión, sin embargo, en el Editor de administración de
directivas de grupo iremos a Configuración del equipo > Directi-
vas > Configuración de Windows > Configuración de seguridad >
Directivas locales > Opciones de seguridad y, en el panel derecho,
buscaremos la directiva Seguridad de red: forzar el cierre de sesión
cuando expire la hora de inicio de sesión, haciendo doble clic sobre
ella (Figura 6-65).
Por último, habilitamos la directiva y aceptamos el cambio (Fi-
gura 6-66).
Figura 6-65
Figura 6-66
275
Tema 6: Administración de dominios
Por otra parte, para evitar que se pueda iniciar la sesión en deter-
minados ordenadores, contamos con diferentes alternativas.
Por un lado, podemos iniciar sesión como administradores en cada
equipo y, mediante el Editor de administración de directivas de
grupo, editar la directiva Permitir el inicio de sesión local (Figura
6-67), que encontramos en Configuración del equipo > Directivas >
Configuración de Windows > Configuración de seguridad > Directi-
vas locales > Asignación de derechos de usuario.
La directiva nos permitirá configurar de manera explícita qué
usuarios y grupos podrán iniciar sesión en el equipo, pero debemos
asegurarnos de no dejar fuera ninguna cuenta o grupo que pudie-
ran estar usando ciertos servicios y aplicaciones; de otra forma,
Figura 6-67
estos procesos dejarían de funcionar correctamente.
Si queremos evitar los posibles inconvenientes asociados a esta
directiva, y como estrategia alternativa si la restricción afecta a un
número limitado de usuarios o grupos, podemos impedirles que
inicien la sesión utilizando en su lugar la directiva Denegar el inicio
de sesión local.
También es posible hacer que determinados usuarios solo puedan
iniciar sesión en un determinado equipo editando las propiedades
de su cuenta. Para ello lanzamos [Link] desde el diálogo Ejecutar
(Windows + R), hacemos doble clic sobre la cuenta a editar y, en la
pestaña Cuenta, pulsamos el botón Iniciar sesión en (Figura 6-68).
En el diálogo Estaciones de trabajo de inicio de sesión, marcamos el
botón Los siguientes equipos y agregamos los equipos en los que el
usuario podrá iniciar la sesión indicando su nombre NetBIOS o DNS
y pulsando el botón Agregar (Figura 6-69).
Se pueden añadir hasta 64 equipos a esta lista.
276
Figura 6-68
Figura 6-69
Implantación de sistemas operativos
6.10. S cripts de inicio y apagado
Las directivas de grupo permiten asociar archivos de script a cuatro
eventos concretos: el encendido y el apagado de la máquina, y el
inicio o el cierre de una sesión.
Los scripts pueden ser secuencias de instrucciones en archivos
.bat o .cmd, scripts de PowerShell, lenguajes soportados por el
anfitrión de scripts de Windows (Windows Script Host en inglés,
o WSH), como por ejemplo Jscript o VBScript, o cualquier otro
lenguaje de script soportado en el cliente. Para asignar un script
a cualquiera de los eventos citados empezaremos siempre abrien-
do la herramienta Administración de directivas de grupo desde el
menú Iniciar > Herramientas administrativas de Windows, o bien
la lanzaremos directamente con [Link] desde el diálogo Ejecu-
tar (Windows + R). A continuación, haremos lo siguiente:
[Link] la directiva de grupo asociada a la unidad organizati-
va que contiene los objetos de equipo a los que vamos a asignar
el script; por ejemplo, la que corresponde a los controladores de
dominio (Figura 6-70).
Figura 6-70
2. En el Editor de administración de directivas de grupo desple-
gamos Configuración de equipo > Directivas > Configuración
de Windows y seleccionamos Scripts (inicio o apagado) (Fi-
gura 6-71).
Figura 6-71
277
Tema 6: Administración de dominios
¡RECUERDA!
Los scripts de inicio y apa-
gado se ejecutan mediante
la cuenta de sistema local,
por lo que adquieren todos
los derechos necesarios
para ello. Debemos tenerlo
en cuenta a la hora de
permitir que ciertos scripts
se ejecuten con estos
privilegios, ya que podrían
comprometer la integridad
de los datos o la seguridad
del equipo.
[Link] el panel derecho, hacemos doble clic en la directiva en la que
aplicaremos el script, ya sea Inicio o Apagado, y pulsamos el
botón Agregar (Figura 6-72).
Figura 6-72
[Link] el diálogo Agregar un script, indicamos la ruta completa al
archivo de script o lo buscamos con el botón Examinar. Si el
script requiere de parámetros adicionales, los indicaremos en
el cuadro Parámetros del script de igual manera en que lo haría-
mos desde el indicador del símbolo del sistema (Figura 6-73).
Figura 6-73
[Link] scripts de PowerShell se indican en una pestaña aparte.
Podemos escoger si ejecutar los scripts de este tipo antes o des-
pués que el resto de los scripts, en caso de que por algún motivo
tuvieran preferencia los unos sobre los otros (Figura 6-74).
278
Figura 6-74
En caso de querer aplicar los scripts de inicio y apagado no a nivel
de máquina, sino al de inicio y cierre de sesión de los usuarios,
los pasos son esencialmente los mismos, con las diferencias que
se indican a continuación:
[Link] la directiva de grupo de la OU que contiene los usua-
rios a los que aplicar el script (Figura 6-75). En caso de que no
tuvieran una directiva específica, la crearemos ahora haciendo
clic derecho sobre la unidad organizativa y seleccionando Crear
un GPO en este dominio y vincularlo aquí. También podríamos
editar la directiva por defecto del dominio, llamada Default
Domain Policy, para aplicar el script a todos sus usuarios.
Figura 6-75
[Link] Configuración de usuario > Directivas > Configu-
ración de Windows y seleccionamos Scripts (inicio de sesión o
cierre de sesión) (Figura 6-76). A partir de este punto los pasos
a seguir son los mismos que para los scripts de inicio y apagado
del equipo.
Implantación de sistemas operativos
ponte a prueba
Indica si la siguiente afirmación
es verdadera o falsa: Los scripts
de inicio y apagado se ejecutan
mediante la cuenta de sistema
local.
a) Verdadero
b) Falso
Figura 6-76
Finalmente, podemos ejecutar un script de inicio de sesión para
un usuario en particular abriendo sus propiedades desde la herra-
mienta Usuarios y equipos de Active Directory, y especificando la
ruta al script en el cuadro Script de inicio de sesión de la pestaña
Perfil (Figura 6-77).
Figura 6-77
279
Tema 6: Administración de dominios
¡RECUERDA!
Las variables de entorno,
tanto las de sistema como
las de usuario, son de gran
utilidad para no tener que
escribir las rutas com-
pletas a ciertos recursos
o los nombres concretos
de ciertos objetos, lo
que además nos permite
automatizar algunas
operaciones, como por
ejemplo la creación de
directorios.
6.11. Creación de variables
de entorno
En el apartado 3.5.1 introdujimos el concepto de variable de entor-
no y vimos dónde especificarla en la Configuración de Windows.
Dejando aparte la variable %path%, que es la más utilizada, otras
variables que hemos visto hasta el momento son %systemroot%
(C:\Windows), %programfiles% (C:\Archivos de programa) y
%username% (nombre de usuario). De entre el resto de las varia-
bles de entorno, algunas de las que más suelen utilizarse son las
siguientes:
• %windir%. Ruta al directorio de instalación de Windows (equi-
vale a %systemroot%).
• %computername%. Nombre del equipo.
• %userprofile%. Ruta a la carpeta del perfil de usuario.
• %temp%. Ruta al directorio de archivos temporales del perfil de
usuario, ubicado en %userprofile%\AppData\Local\Temp.
• %appdata%. Ruta al directorio %userprofile%\Appdata\Roaming.
Pero, además de las variables de entorno del sistema, utilizando
las directivas de grupo podemos crear nuestras propias variables.
Para ello abriremos la herramienta Administración de directivas
de grupo desde el menú Iniciar > Herramientas administrativas de
Windows (o bien lanzamos [Link] desde el diálogo Ejecutar que
se invoca al pulsar Windows + R). A continuación:
[Link] una nueva directiva en el dominio haciendo clic sobre
él y seleccionando la opción Crear un GPO en este dominio y
vincularlo aquí, y seguidamente la editamos (clic derecho >
Editar). Desplegamos el árbol Configuración del equipo > Pre-
ferencias > Configuración de Windows y hacemos clic derecho
sobre Entorno, seleccionando Nuevo > Variable de entorno en el
menú contextual (Figura 6-78).
280
Figura 6-78
Implantació[Link] el diálogo Nuevas propiedades de entorno escogemos Crear
de entre la lista de acciones, marcamos la opción Variable de
usuario y definimos la variable dándole un nombre y un valor. En
la pestaña General (Figura 6-79), creamos una variable llamada
%edge% cuyo valor es la ruta donde se ubica el ejecutable del
navegador Microsoft Edge.
A continuación, vinculamos la nueva directiva a un OU; por
ejemplo, la del departamento comercial de nuestro dominio
de ejemplo. Para ello hacemos clic derecho sobre la unidad
organizativa y escogemos la opción Vincular un GPO existente.
Escogemos la directiva de entre todas las definidas, y la veremos
aparecer en el panel Objetos de directiva de grupo vinculados
(Figura 6-80).
de sistemas operativos
Figura 6-79
Figura 6-80
[Link] limitar el alcance de esta directiva exclusivamente a un
grupo de usuarios concreto (como, por ejemplo, Comerciales)
eliminamos Usuarios autenticados de la lista Filtrado de seguri-
dad del panel derecho, y añadimos a ella el grupo o los usuarios
individuales que nos interesen (Figura 6-81).
Figura 6-81
5. Abrimos una ventana de Símbolo del sistema y usamos la
instrucción GPUpdate/Force para actualizar las directivas de
equipo y de usuario. Tras cerrar la sesión y abrirla con cualquiera
de los usuarios del grupo al que hemos aplicado la directiva, la
nueva variable de usuario entrará en efecto.
ponte a prueba
¿Cuál de estas variables no es de
sistema?
a) %windir%
b) %appdata%
c) %userprofile%
d) %userdata%