Uso Recomendado de Grupos en Dominios Windows Server

Lo primero a tener en cuenta es que existen dos clases de grupos:

• Grupos Locales: estos grupos son los que podemos crear en cualquier instalación, salvo que sea Controlador de Dominio
  Se pueden usar para asignar privilegios únicamente en la máquina local
  Si la máquina está en grupo de trabajo, es la única posibilidad
• Grupos de Dominio: estos grupos los creamos y administramos en los Controladores de Dominio del Dominio, normalmente a través de la consola de administración del Dominio

Hay dos temas importantes a tener en cuenta:

• ¿Cuándo usamos cada uno? más adelante veremos las características de cada uno, y de ahí veremos el uso recomendado
• Convención de nombres para los grupos: veamos esto primero

Como todos sabemos los grupos se usan principalmente para la asignación de privilegios (permisos y derechos). Siempre es conveniente asignarlos a grupos y no a cuentas individuales. Podemos ahorrarnos mucho trabajo a futuro en la eventualidad de un cambio, o crecimiento de la estructura

Es muy común que los administradores, en el momento de la creación decidan el nombre, sin seguir ninguna regla en especial (“¿cómo me voy a olvidar para qué lo creé?”)

Pero sin embargo pasado un tiempo, o ante cambio o asingación de nuevos administradores, el tema comienza a complicarse

Un caso típico se da cuando un administrador va a crear un grupo, y no recuerda si ya existe otro, con la membresía que necesita. Ante la duda crea uno nuevo

Y el resultado es: grupos que están duplicados, triplicados, y más :-)

A partir de lo anterior, algún administrador quiere comenzar a poner orden, pero ¿cómo identificar los repetidos? ¿lo podré borrar sin consecuencias? ¿cómo sé quién y para qué lo creó?

Y salta inmediatamente las preguntas “¿Cómo puedo saber si determinado grupo se está usando o no?” o “¿Como puedo saber qué permisos tiene el grupo en la red?”

Ninguna de las dos tiene una respuesta fácil, porque generalmente se usa el anidamiento de grupos (grupos dentro de grupos). Luego cualquier búsqueda debe tener en cuenta este anidamiento que puede tener varios niveles

Así que lo primero a tener en cuenta es que es necesario adoptar una buena convención de nombres para los grupos que creemos, que con sólo ver el nombre sepamos qué tipo de grupo es, para qué se creó, qué cuentas contiene, y qué y dónde tiene permisos ¿estamos de acuerdo supongo?

Volviendo al primer punto, debemos ver cuándo usar cada uno. Nombramos antes los Grupos Locales, pero también tenemos los Grupos de Dominio, y éstos tienen muchas más variantes.

Lo primero a tener en cuenta es el tipo, ya que pueden ser de dos diferentes:

• Grupos de Distribución: no se pueden usar para asignar privilegios. Simplemente si tenemos una aplicación de correo integrada a Active Directory (Exchange) y habilitamos al grupo, podremos enviarle un correo al grupo y lo recibirán todos los miembros
• Grupos de Seguridad: tienen la misma característica que el anterior con respecto al envío de correos, pero además estos sí los podemos usar para asignar privilegios

Los grupos de Dominio, además del tipo, tienen algo que se llama “Alcance” (Scope) y de acuerdo a éste tienen diferentes características tanto de membresía como del visibilidad (dónde los voy a poder usar para asignarle permisos)

Pongamos una tabla resumen porque escribir uno por uno sería muy largo, y además es interesante verlos comparativamente

Hay dos puntos importantes a tener en cuenta:

• Qué puede contener: ya que esto me dice qué cuentas puedo poner en el grupo (Ver las tres primeras columnas de datos)
• Dónde lo puedo ver: es decir, dónde lo puedo usar para asignar privilegios

La asignación de privilegios en ambiente Microsoft, tiene algo muy bueno, es sumamente flexible e intuitiva, per esto mismo se puede volver en contra, porque permite hacer casi cualquier cosa sin ninguna planificación

Supongamos situaciones, si alguien no usa grupos y asigna todos los privilegios cuenta por cuenta ¿funcionará? si, por supuesto que lo hará.

Y si sólo agrupo cuentas en Grupos Globales ¿funcionará? si, también lo hará. No voy a seguir repitiendo pero funciona con cualquiera de los ámbitos de grupo, sólo limitará la membresía y el alcance

Pero por supuesto hay ventajas importantes usándolos de una forma planificada, y también teniendo en cuenta el tamaño de la organización y su crecimiento futuro. Es fácil ver que no es lo mismo un ambiente de por ejemplo 20 usuarios, que uno de 500, que de 5000, o de 50000

En un ambiente “pequeño” seguramente no utilizaremos anidamiento de grupos, a diferencia de el uso en organizaciones más grandes. Y análogamente los requerimientos de una organización con varios miles de usuarios repartidos entre varios Dominios en diferentes sitios geográficos  no serán los mismos que los de una pequeña empresa

Voy a centrarme en una empresa mediana, o chica pero que se puede esperar crecimiento a futuro. Cuidado que lo que hoy es una pequeña empresa en un tiempo puede comenzar a ser una mediana empresa, y si nuestra base no está bien hecha comenzarán los problemas de re-organizar todo, que da bastante trabajo.

Sin entrar en una gran disquisición de los motivos, pero créanme que tiene su fundamento, Microsoft recomienda el uso para cada uno de los alcances de grupos

Grupos Locales: única alternativa en ambiente de grupo de trabajo. En ambiente de Dominio, sólo en casos que se necesiten asignar privilegios específicos locales. Ejemplos: que un grupo del Dominio sea administrador local de la máquina, o que un grupo de Dominio pueda ejecutar copias de seguridad o recuperación en un equipo en particular

Grupos Globales: se recomienda utilizarlos para agrupar cuentas con función similar. Por ejemplo, un sector, un cargo, etc.

Grupos Locales de Dominio: se recomienda utilizarlos para asignar privilegios (permisos y derechos)

Grupos Universales: se recomienda la utilización cuando se requiere agrupar Grupos Globales de diferentes Dominios

Resumiendo, para una empresa mediana, la preferencia es:

• Agrupar por función: cuentas –> Globales (Accounts –> Global Groups)
• Agrupar por permisos: Grupos Locales de Dominio <– Permisos (DL <– Permissiones

Más resumido: Cuentas –> Grupos Globales –> Grupos Locales de Dominio <– Permisos

O aún más: A–>GG–>DLG<–P

Respecto al uso de Grupos Universales, son muy flexibles pero hay que usarlos con cuidado, ya que bajo determinadas circunstancias pueden aumentar considerablemente el tráfico de red. Básicamente el motivo es porque no sólo el nombre, sino además la membresía será replicada a todos los Catálogos Globales del Bosque.

Y ahora sí, finalmente, si usamos lo anterior podemos pensar en una buena convención de nombres que nos sea útil a nuestras necesidades

Por ejemplo pongo una que he utilizado más de una vez y expongo algunos motivos:

• En un ambiente multidominio, como la visibilidad puede abarcar a todos ellos sería bueno poner un prefijo que indique en qué dominio se ha creado
• Como a primera vista no se diferencia si un grupo es Local de Dominio, o Global o Universal, sería bueno que el nombre lo indique
• Los grupos Globales deberían indicar claramente quiénes son los miembros
• Los grupos Locales de Dominio deberían indicar claramente sobre qué recurso y qué permisos se le han otorgado

Entonces suponiendo que tuviéramos el Dominio que típicamente usa Microsoft para su demostraciones y cursos que se llama Contoso, una posibilidad de definir nombres de grupos podría ser:

CON-GG-HR_Central

Creo que es fácil deducir que está creado en el Dominio “Contoso” (CON), que es de tipo Global (GG), y que contiene al personal de recursos humanos (HR) del sitio central (Central)

Fácilmente podría distinguir el anterior de uno que se llame SUB-GG-Mkt_Pers

Y como los Locales de Dominio se utilizarán para dar permisos entonces se podría hacer algo así:

CON-DL-Prod_DB-R

Le agrego la sigla de dominio (CON) sólo para ser consistente ya que estos grupos no podrán ser vistos en otros Dominios, DL me indica que es un grupo Local de Dominio (Domain Local), que tiene permisos sobre la base de producción (Prod_DB) y el permiso es de lectura (R=Read)

Para crear un grupo que necesite permiso de cambios sobre el recurso, utilizaría por ejemplo: CON-DL-Prod_DB-CH (CH=Change)

Y todavía podemos agregar un par más de consideraciones. Primero, recordemos que aunque podemos extendernos, serán visibles los primeros 20 caracters de los nombres de un grupo.

Y segundo, recordemos que en las propiedades de cada grupo tenemos dos campos disponibles que podemos usar a nuestra conveniencia: Descripción y Notas

Práctica de estrategia de grupos AGDLP

Descarga aquí

Resolución

Descargar aquí

Fuente: https://windowserver.wordpress.com/2012/12/14/uso-recomendado-de-grupos-en-dominios-windows-server/

Permisos – Permisos Efectivos

Trataremos en esta nota de resumir y aclarar algunos conceptos importantes en cuanto se refiere a la aplicación de permisos en ambiente Windows.

En esta ocasión no haremos una descripción detallada de cada uno y su uso, ya que sería muy extenso, y nunca se podrían cubrir todos los escenarios, pero sí como para comprender su funcionamiento.

Debemos tener en cuenta que existen dos clases de permisos:

• Permisos de Seguridad (NTFS)
• Permisos de Compartido (Share)

Dependiendo del tipo de acceso nos afectarán sólo los de Seguridad, o ambos.

Permisos de Seguridad (NTFS)

Los permisos de Seguridad nos afectarán siempre, esto es, tanto cuando accedemos remotamente a un equipo, como cuando estamos trabajando localmente en el mismo.

Estos permisos residen en el sistema de archivos (File System) y son propios de las unidades con formato NTFS

Tienen varias ventajas, entre las que podemos citar:

• Los podemos manejar individualmente por cada carpeta y archivo
• Hay permisos “standard” que son los de uso más común, y además hay permisos “avanzados”. Los primeros son combinaciones ya hechas de los segundos.
• Cada permiso tiene la opción específica de Permitir o Denegar

Normalmente un usuario pertenece a varios grupos, y cada uno puede tener diferentes permisos sobre un recurso. Inclusive, aunque no recomendado, el propio usuario puede tener permisos.

Entonces ¿Cuál es el permiso efectivo (final) de este usuario sobre ese archivo o carpeta?

El permiso efectivo de Seguridad, es la combinación de todos los permisos  “Permitido”, salvo que los de “Denegar” siempre prevalecen (ganan)

Por ejemplo, si de la pertenencia a un grupo tengo “Permitir Lectura” y de otro grupo “Permitir Escritura”, el permiso efectivo es “Lectura + Escritura”.

Pero si por pertenencia a otro grupo obtengo algún “Denegar”, éste será el efectivo

No tener permisos, implica que no se puede acceder, en cambio “Denegar” siempre ganará a los “Permitir”. No tener permisos no resta.

¿Qué sucede con los permisos cuando copiamos un archivo/carpeta?

Cuando se copia, se genera un objeto nuevo, el original no se altera. La copia hereda los permisos de la carpeta que lo contiene. Tener en cuenta que la raíz de un disco, es una carpeta.

¿Qué sucede con los permisos cuando movemos un archivo/carpeta?

Se pueden producir dos situaciones diferentes depende si se mueve en mismo disco, o entre discos diferentes.

Si movemos un archivo/carpeta, dentro del mismo disco (partición o volumen), cambian los permisos heredados, pero se mantienen los permisos específicamente dados sobre el archivo/carpeta

En cambio, si movemos un archivo/carpeta, entre discos diferentes, sólo hereda los nuevos permisos, Eso es así, porque el mover entre discos en realidad es “copiar” seguido de “borrar” el original.

Permisos de Compartido (Share)

Los Permisos de Compartido, a diferencia de los anteriores, nos afectan únicamente cuando estamos accediendo remotamente (desde otro equipo). No tienen ningún efecto cuando estamos trabajando directamente sobre el equipo.

Se aplican únicamente a Carpetas, y será el mismo permiso para todo el contenido de dicha carpeta, y todos los archivos y subcarpetas contenidos en la primera.

Además debemos tener en cuenta, que no residen en el Sistema de Archivos, sino que están especificados en el Registro del sistema operativo

Además podemos observar que son mucho más “limitados” que los de Seguridad.

Igual que en el caso anterior, por pertenencia a grupos podemos recibir diferentes permisos por cada grupo, y análogamente al caso anterior:

El permiso efectivo de Compartido, es la combinación de todos los permisos “Permitido”, salvo que los de “Denegar” siempre prevalecen (ganan)

1. El permiso de lectura permite:

• ver los nombres de archivos y de subcarpetas
• recorrer las subcarpetas
• ver los datos de los archivos
• ejecutar archivos de programa

2. El permiso de cambio proporciona todos los permisos de lectura, así como:

• agregar archivos y subcarpetas
• cambiar datos en archivos
• eliminar subcarpetas y archivos

2. El permiso de control total se aplica de forma predeterminada a los recursos compartidos que se crean. Este permiso se asigna al grupo Todos al compartir un recurso. Proporciona todos los permisos de lectura y de cambio, así como:

• cambiar permisos
• tomar posesión

Permisos Efectivos

Resumiendo, cuando trabajamos localmente, nos afectan sólo los permisos de Seguridad. Pero cuando lo hacemos remotamente nos afectan ambos.

Y en este caso ¿cuál va a ser el permiso efectivo (final)?

El permiso efectivo (final) va a resultar ser el más restrictivo entre los de Seguridad y los de Compartido

Fuente :http://windowserver.wordpress.com/2011/04/30/permisos-permisos-efectivos/

ELIMINAR UN CONTROLADOR DE DOMINIO (SUBDOMINIO)

 ntdsutil

partition management

connections 

connect to server dc01

quit 

list 

delete nc dc=Domain...

quit

ntdsutil: metadata cleanup

connections

connect to server dc01

quit 

matadata cleanup:select operation target 

list domains

select operation target :select domain 1

list servers in site

select operation target:list sites 

select site O 

list servers in site :select server 0

quit

metadata cleanup :remove selected server

remove selected domain  

quit      

Eliminar sitios y servicios el server

La zona del DNS

En el Server dc03 quito el rol                                                       

ERROR DE REPLICACIÓN : el nombre principal de destino es incorrecto

 https://learn.microsoft.com/es-es/troubleshoot/windows-server/active-directory/replication-error-2146893022

GPOs

Una GPO (Group Policy Object – Objetos de Política de Grupo), es básicamente un conjunto de políticas para crear en el dominio, tanto en el servidor local como en los equipos cliente, una serie de condiciones y restricciones enfocadas en mejorar la seguridad de los equipos ya que en muchas organizaciones los usuarios pueden realizar acciones que van en contra de las buenas prácticas y estas dan como resultado una afectación global en Windows Server.

Uso GPO

Como administradores podemos usar las GPO para controlar todo esto, si deseamos implementar una GPO tengamos en cuenta:

Los equipos a gestionar deben estar unidos al dominio y los usuarios deben contar con las credenciales de dominio para el inicio de sesión.

La red local debe estar configurada a través de AD DS, esto implica que el servidor debe contar el rol AD DS (Active Directory) ya configurado.

Se requiere contar con permisos para editar la Política de grupo en el dominio.

Tipos GPO

Existen dos tipos de GPO que son:

 Default Domain Policy: como su nombre lo indica, es la política por defecto del dominio e integra configuraciones de políticas para todos los equipos y usuarios en el dominio.

Default Domain Controller Policy: es otra política por defecto, pero orientada al controlador de dominio.

Prioridades de la GPO.

El orden de precedencia de las políticas de grupo en Windows Server es un aspecto importante de la administración del sistema que determina cómo se resuelven y aplican las configuraciones de políticas conflictivas a los objetos de Active Directory dentro de un dominio. Comprender este orden es esencial para administrar y proteger eficazmente los entornos de Windows Server.

Los objetos de directiva de grupo (GPO) son contenedores para la configuración de directivas que se pueden vincular a sitios, dominios o unidades organizativas (OU) dentro de Active Directory. Cuando varios GPO están vinculados a un objeto específico, pueden surgir conflictos si estos GPO contienen configuraciones conflictivas. Las reglas de precedencia de directivas de grupo establecen el orden en que se procesan y aplican los GPO, lo que garantiza que los conflictos se resuelvan de forma coherente.

La prioridad de la directiva de grupo en Windows Server sigue un orden específico, conocido como modelo LSDOU, que significa Local, Sitio, Dominio y Unidad organizativa. Este modelo representa la jerarquía de los objetos de Active Directory y determina el orden en que se aplican los GPO. Exploremos cada nivel de precedencia en detalle:

1. GPO local: el objeto de directiva de grupo local es el nivel de prioridad más bajo y se aplica a equipos individuales. Permite a los administradores definir configuraciones específicas que se aplican solo a la máquina local. La configuración de GPO local se almacena en el registro y entra en vigor antes de que se procesen otros GPO.

2. GPO del sitio: el GPO del sitio es el siguiente nivel de prioridad y se aplica a todos los objetos dentro de un sitio de Active Directory específico. Los sitios son agrupaciones lógicas de equipos en función de su conectividad de red y se utilizan para optimizar la replicación y la autenticación. Los GPO del sitio están vinculados al objeto del sitio en Active Directory y aplican configuraciones a todos los objetos dentro de ese sitio.

3. GPO de dominio: el GPO de dominio se aplica a nivel de dominio y afecta a todos los objetos dentro del dominio. Está vinculado al objeto de dominio en Active Directory y aplica la configuración a todos los usuarios y equipos dentro de ese dominio. Los GPO de dominio tienen una prioridad más alta que los GPO locales y de sitio.

4. GPO de unidad organizativa (OU): el GPO de unidad organizativa es el nivel más alto de precedencia y se aplica a unidades organizativas específicas dentro de un dominio. Las unidades organizativas son contenedores que se utilizan para organizar y administrar objetos dentro de Active Directory. Se pueden vincular varios GPO a una unidad organizativa y la configuración de estos GPO se aplica en el orden especificado por el administrador.

Cuando se producen conflictos entre los GPO en diferentes niveles, las reglas de precedencia de la directiva de grupo dictan qué configuración tiene prioridad. El modelo LSDOU garantiza que la configuración de los GPO de nivel superior invalide la configuración en conflicto de los GPO de nivel inferior. Por ejemplo, si se define una configuración tanto en el GPO local como en el GPO de dominio, la configuración del GPO de dominio tendrá prioridad.

Además del modelo LSDOU, existen otros factores que pueden influir en la precedencia de la directiva de grupo, como la herencia forzada y bloqueada. Los GPO obligatorios se aplican independientemente de las reglas de herencia, mientras que la herencia bloqueada evita que los GPO se apliquen a los objetos secundarios.

Comprender el orden de precedencia de las políticas de grupo en Windows Server es importante para administrar eficazmente la configuración de políticas y garantizar configuraciones consistentes y seguras en toda la red. Siguiendo el modelo LSDOU y considerando otros factores que influyen, los administradores pueden establecer una jerarquía bien definida de GPO que cumpla con los requisitos de seguridad y cumplimiento de la organización.

Cómo crear y administrar una GPO en Windows Server 2019

Vamos al Panel de Administrador del servidor -Herramientas-Administración de directivas de grupo

Esto abre la siguiente ventana donde vemos el bosque actual del dominio:

Damos clic derecho en el dominio y seleccionamos la opción "Crear una GPO en este dominio y vincularlo aquí":

Asignamos el nombre a la GPO:

Damos clic derecho sobre la GPO creada y seleccionamos "Editar":

Vamos a la ruta "Configuración de usuario - Directivas - Plantillas administrativas - Menú Inicio y barra de tareas":

Buscar GPO.

GPO - Aplicar a un usuario o grupo específico

En la pantalla Administración de directivas de grupo, seleccione el GPO y accede a la pestaña Delegación.

Agregaremos el grupo gpo creado anteriormente en el Active Directory del cual es  miembro el usuario kk . Comprobaremos que a otro usuario que no está en dicho grupo ,no le afecta la poítica de grupo . 

En el laboratorio del final el usuario kk vuelve a tener los botones de Apagar, Reiniciar puesto que se implementa la política con prioridad 1 que es la Política del Dominio por Defecto ,que hemos configurado .

GPO - Prioridad de una política 












Gpresult /R /SCOPE COMPUTER /V
Gpresult /R  /SCOPE USER /V
Gpresult / R
rsop.msc en la máquina w10

Introducción a las actualizaciones de Windows Server

https://learn.microsoft.com/es-es/windows-server/get-started/upgrade-overview 

Untangle NG Firewall-PRÁCTICA PARA CASA

[PRÁCTICA OBLIGATORIA]

Windows server 2019 : Configurar y desconfigurar conmutación por error.

[PRÁCTICA OBLIGATORIA]

En la clase de hoy, vamos a configurar y desconfigurar un sistema de conmutación por error del servicio de DHCP, usando el entorno gráfico de Windows server 2019. De manera, que podamos reutilizar la configuración que teníamos de failover en un futuro si lo necesitáramos.

Vamos a empezar con la configuración desde cero de un sistema de conmutación por error del servicio de DHCP y ya comentamos que podíamos usar antiguas configuraciones de una relación de failover para ahorrar tiempo. En el siguiente enlace vemos cómo lo vamos a hacer paso a paso.

• http://iso-eti.blogspot.com/2020/04/dhcp-con-conmutacion-por-error.html

Nuestro entorno de laboratorio tiene varios controladores de dominio de Active Directory y dos de ellos tienen el servicio de DHCP instalado y son servidores autorizados para nuestro dominio.

Entre nuestros dos servidores existe una relación de de conmutación por error del servicio de DHCP para desconfigurar la relación de conmutación por error que existe actualmente en nuestro servicio de DHCP, solo tenemos que seleccionar el ámbito de DHCP en uno de los dos servidores de DHCP que forman parte del sistema de conmutación por error, con el botón derecho de nuestro ratón y en el menú desplegable seleccionaremos la opción llamada Desconfigurar conmutación por error.

Una cosa que hemos de saber antes de continuar es que, el servidor que acabamos de seleccionar, sea cual sea de los dos que componen la relación de conmutación por error, será el servidor que quedará activo y con el ámbito configurado después del proceso de desconfiguración. Es importante tener claro esto porqué al otro servidor se le eliminará el ámbito de nuestro entorno.

Aparecerá una ventana de advertencia con el mensaje:

Esta acción quitará los ámbitos seleccionados de las relaciones de conmutación por error asociadas. Los ámbitos seleccionados también se eliminaran del servidor asociado. Haga clic en Aceptar para continuar o en cancelar para anular la acción.

Pulsaremos el botón Aceptar para desconfigurar la relación de conmutación por error. Una vez pulsado el botón Aceptar, aparecerá una ventana informativa con el mensaje:

Esta acción quitará todos los ámbitos que formen parte de la relación de conmutación por error. La relación de conmutación por error puede eliminarse tras la acción. Una vez pulsado el botón aceptar, aparecerá una ventana que nos informará del proceso de desconfiguración.

Esperaremos a que el proceso termine y si refrescamos la ventana de la consola de gestión de nuestro servidor de DHCP comprobaremos que el servidor asociado pierde la configuración del ámbito.

Fuente:https://www.pantallazos.es/2019/07/windows-server-2012-desconfigurar-dhcp-failover-gui.html

Diagnóstico de errores de replicación de Active Directory

[ PRÁCTICA OBLIGATORIA]

Solución

REPADMIN

Repadmin /replsummary

La operación “/replsummary” resume rápidamente el estado de la replicación y la salud relativa de un bosque.

Repadmin /Showrepl

Este comando muestra el estado de la replicación cuando el controlador de dominio intentó por última vez implementar una replicación entrante de particiones de Active Directory.

repadmin /showrepl /errorsonly

repadmin /syncall <DC-name> /AeD

repadmin /syncall dc01 /Aed

R: Este modificador significa “Todas las particiones”. Indica a Repadmin que sincronice todas las particiones de directorio en el controlador de dominio especificado cuando se utiliza. Esto garantiza que se produzca la replicación para cada partición alojada en ese controlador de dominio.

d: El modificador “d” corresponde a “Dominio”. Especifica que la sincronización debe ocurrir a nivel de dominio, incluida la partición del directorio del dominio.

e: El modificador “e” corresponde a “Configuración empresarial”. Incluye la partición del directorio de configuración, lo que garantiza que todos los cambios en la configuración empresarial estén sincronizados.

P: Este modificador significa “Esquema”. Al incluir este modificador se garantiza que la partición del directorio de esquema esté sincronizada, lo que permite propagar cualquier cambio de esquema realizado dentro del bosque de Active Directory .

repadmin /showrepl DC01

Formateo de la salida del comando repadmin:

repadmin /showrepl * /csv | convertfrom-csv | out-gridview

repadmin /showrepl * /csv >showrepl.csv

DCDIAG

DCDiag.exe analiza el estado de los controladores de dominio (DC) en un bosque o empresa e informa de cualquier problema que le ayude a solucionar problemas.

DCDIAG /TEST:Replications

DCDIAG /s:DC01.aso.org 

DCDIAG /test:dns

Borrar caché

ipconfig /flushdns

CONTROLADOR ADICIONAL DEL DOMINIO

[PRÁCTICA OBLIGATORIA]

 SERVIDOR DE RESPALDO