Firmar scripts PowerShell [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Firmar scripts PowerShell

• [Parte 1 de 2]: Hardening en la política de ejecución
• [Parte 2 de 2]: Entidad de certificación CA (ADCS), despliegue de certificado vía GPO e integridad de firma

Continuando con el artículo sobre como firmar scripts PowerShell estableciendo una política de ejecución AllSigned. En este post comentaré como hacer uso de las plantillas de certificados para el propósito de "Firma de código" emitidas por una Entidad de certificación CA implementada en un entorno de dominio haciendo uso del servicio ADCS (Active Directory Certificate Services), desplegando el certificado vía GPO y finalmente realizar una comprobación de integridad del script PowerShell firmado.

CA raíz y CA subordinadas

La CA raíz contiene la clave privada de toda la jerarquía de certificados, si un atacante obtuviera este certificado o emite un certificado para una entidad no autorizada, se compromete la seguridad basada en el certificado de la organización de todos los certificados que se han emitido en esa jerarquía.

Lo ideal y por seguridad sería disponer de una CA raíz que emita certificados para una CA subordinada, de modo que no se exponga directamente el primer nivel de certificado de la CA raíz, las CA subordinadas requieren una jerarquía de PKI establecida.

Entidades de certificación: empresarial e independientes

• Entidad de certificación empresarial: Deben pertenecer al dominio, se suele utilizar cuando es necesario emitir muchos certificados y aprobarlos rápidamente para un entorno de dominio Active Directory.
• Entidad de certificación independiente: Pueden pertenecer a un grupo de trabajo o a un dominio. No requieren de ADDS, se suele utilizar para emitir certificados directamente a los clientes. Dado que no tiene el certificado raíz, ofrece una mayor seguridad. La desventaja es que todos los certificados que se emiten deben ser aprobados.

Descripción del escenario para este lab

Por motivo de falta de recursos y no desplegar una CA subordinada, para estos ejemplos se hará uso únicamente de una CA raíz tipo empresarial ya implementada con el nivel de confianza máximo en la jerarquía de PKI de la organización y un equipo Windows 10 unido al dominio en el que se probará la ejecución de scripts PowerShell firmados donde se le aplicará una GPO con el certificado necesario. 

Entidad de certificación CA (ADCS) y plantilla de Firma de código

Esto sería opcional pero para tener un control de permisos podemos crear un nuevo grupo en AD para este fin y asignarlo desde la consola de "Plantillas de certifiado" (certtmpl.msc) a la plantilla de que tiene como propósito la "Firma de código". De modo que todos los usuarios/grupos que formen parte del grupo añadido tengan permisos para poder solicitar esta plantilla a la entidad de certificación desde las propia consola local de administración de certificados de usuario (certmgr.msc).

Figura 1: Asignación de permisos a la plantilla de certificado "Firma de código".

Desde la consola de "Entidad de certificación" (certsrv.msc). Emitimos la publicación de una nueva plantilla de certificado "Firma de código".

Figura 2: Emitir plantilla de certificado "Firma de código" desde una Entidad de certificación CA.

Es el momento de solicitar un certificado para "Firma de código". Esto lo haremos desde el propio almacén de certificados de Windows (certmgr.msc) y con un usuario que tenga permisos para poder solicitar el certificado de Firma de código a la Entidad de certificación.

Figura 3: Solicitar a la CA un certificado de Firma de código. 

Una vez solicitado, exportamos el certificado en formato .cer.

Figura 4: Exportar el certificado .cer con propósitos de Firma de código.

Despliegue de certificado vía GPO

Para que el resto de equipos del dominio dispongan del certificado .cer en su almacén de certificados, se crea una nueva GPO desde la consola de Administración de directivas de grupo (gpmc.msc). 

A nivel de directiva de equipo, importamos el certificado .cer en el almacén de "Editores de confianza" (Trusted Publishers). Es importante que esté importado en este almacén, de lo contrario la ejecución de scripts PowerShell firmados en cualquier máquina unida al dominio y que tenga establecida una política de ejecución de scripts en modo AllSigned nos arrojará un mensaje de advertencia inicial (como se muestra en la Figura 7).

Figura 5: Desplegar certificado para firma de código vía GPO. 

Firmar scripts PowerShell con un certificado tipo "Firma de código"

Con el mismo usuario que hemos solicitado el certificado, firmamos un script PowerShell. Si visualizamos el fichero de script vemos que se ha incluido una firma complementaria al final del código.

Get-AuthenticodeSignature -FilePath .\MyScript.ps1

$cert = Get-ChildItem -Path Cert:\CurrentUser\My -CodeSigningCert

Set-AuthenticodeSignature -FilePath MyScript.ps1 -Certificate $cert

Figura 6: Firmar y ejecutar script PowerShell desde el mismo usuario.

Ejecución del script firmado en otro equipo y usuario del dominio

Probamos a ejecutar el script firmado desde otro usuario y equipo unido al dominio, en este caso un cliente Windows 10 con la política de ejecución de scripts establecida en AllSigned.

Como vemos en la siguiente captura, hay posibilidad de ejecutar el script pero nos muestra un advertencia indicando que el certificado no está importado en el almacén de "Editores de confianza" (Trusted Publishers). Por esta razón lo comentado en el punto anterior de la figura 5. De momento cancelamos la ejecución (ctrl+c).

Figura 7: Ejecutar script PowerShell desde otra máquina y usuario del dominio (sin certificado importado).

Para importar el certificado en el almacén local de la máquina realizamos un forzado de la actualización de políticas (gpupdate /force). Una vez tenemos el certificado ya importado a través de la aplicación de la GPO creada en la Figura 5, podemos observar que al volver ejecutar el script firmado ya no se muestra ninguna advertencia.

Lógicamente si ejecutamos un script no firmado (MyScript_noSigned.ps1) se nos mostrará el mensaje de error común debido a la restricción aplicada AllSigned en la política de ejecución de scripts.

Figura 8: Ejecutar script PowerShell desde otra máquina y usuario del dominio (con certificado importado).

Comprobación de la integridad de firma en scripts PowerShell

¿Qué pasa si se modifica el código del script firmado?

Para realizar la verificación de integridad de la firma del script se modifica el código del script firmado y se vuelve a comprobar el estado del certificado. 

Si ejecutamos el script después de modificarlo se nos muestra un error indicando que "es posible que alguien no autorizado haya modificado el contenido del archivo", comprobamos nuevamente la firma del fichero y veremos un estado HashMismatch indicando claramente que se ha modificado rompiendo su integridad respecto a la firma.

Será necesario volver a firmarlo con el mismo certificado, generando así una nueva firma asignada al script. 

Figura 9: Modificar script PowerShell firmado para comprobar su integridad.

Saludos!

Instalar características RSAT en Windows 10 cuando WSUS bloquea su descarga

A partir de las últimas versiones de Windows 10 las RSAT (Remote Desktop Services Tools) ya no se descargan e instalan como un paquete de actualizaciones de Microsoft. Sino que se incorporan como características avanzadas independientes que podemos descargar/instalar directamente desde el nuevo panel de configuración del sistema.

En el caso de que estemos trabajando en una máquina Windows 10 bajo un entorno de actualizaciones controladas por WSUS (Windows Server Update Services) es muy probable que el propio servidor WSUS esté bloqueando la descarga de las características RSAT.

Comprobar si las actualizaciones están controladas por WSUS

Para comprobar que el equipo está controlado por un servidor WSUS podemos comprobar la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate

Si vemos que los valores "WUServer" y "WUStatusServer" existen y apuntan a una dirección, normalmente HTTP puerto 8530 o HTTPS puerto 8531 con un nombre DNS interno significará que nuestro equipo recibe actualizaciones controladas directamente de un servidor WSUS.

¿Cómo instalar RSAT bajo un entorno controlado por WSUS?

Para poder instalar RSAT desde las características avanzadas del nuevo panel de control, abrimos un regedit en un contexto privilegiado como administradores, siguiendo la rama anterior, localizamos la siguiente rama.

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\WindowsUpdate\AU

La clave "AU" nos indica la sección de "Actualización automáticas de Windows Update". Aquí vemos el siguiente valor "UseWUServer" y lo establecemos a un valor 0.

• 1 = Obtiene actualizaciones de un servidor WSUS.
• 0 = Obtiene actualizaciones de Microsoft Update.

Abrimos una consola PowerShell como administrador y reiniciamos el servicio wuauserv "Windows Update Agent Service".

Restart-Service wuauserv

Ahora ya podemos añadir las características RSAT que queremos, una vez instaladas ya podemos habilitar de nuevo a través del registro la obtención de actualizaciones a través de WSUS.

Figura 1: Instalar características RSAT deshabilitando WSUS. 

Saludos!

Active Directory: Auditar creación y cambios en cuentas de usuario (ID de eventos)

Para poder auditar la creación y cambios de cuentas de usuarios de Active Directory debemos establecer esta política a nivel de dominio en la plantilla "Default Domain Controllers Policy" situada en Objetos de directiva de grupo.

La editamos y configuramos:

Configuración del equipo > Directivas > Configuración de Windows > Configuración de seguridad > Directivas locales > Directiva de auditoría

Habilitamos "Auditar la administración de cuentas" en intentos "Correcto" y "Error".

Figura 1: Habilitar la auditoría de administración de cuentas en la plantilla "Default Domain Controllers Policy".

Si también queremos que se realice auditoría de la administración de cuentas locales en cualquier equipo unido al dominio, que no sean cuentas Active Directory. Debemos aplicar esta política a nivel de dominio dentro de la plantilla "Default Domain Policy".

Los ID de eventos que nos interesan para este caso son sobre la creación de nuevas cuentas de usuarios de Active Directory.

• ID de evento 4720: Se creó una cuenta de usuario.
• ID de evento 4722: Se habilitó una cuenta de usuario.
• ID de evento 4724: Se intentó restablecer la contraseña de una cuenta.
• ID de evento 4738: Se cambió una cuenta de usuario.

En el visor de eventos (eventvwr.msc) de un controlador de dominio, registros de Windows > Seguridad.

Creamos un filtro por los ID que nos interesen, separado por comas si queremos buscar más de un número de ID distinto.

En la siguiente captura se puede ver un ejemplo de un ID 4722, como se habilitó una nueva cuenta en Active Directory, más arriba tendríamos el ID 4720 donde se creó dicha cuenta.

Figura 2: Filtrar por ID de eventos para encontrar la creación de nuevas cuentas de usuario de Active Directory.

Saludos!

Migración de replicación FRS a DFSR entre controladores de dominio Windows Server [dfsmig]

En el caso que tengamos un controlador de dominio Windows Server 2008 R2 con replicación FRS (File Replication Service) y se necesite migrar a unos nuevos controladores de dominio Windows Server 2019 que haga uso de del sistema de replicación DFS (Distributed File System) habría que realizar una migración de los controladores viejos a un sistema de replicación DFS.

Elevar el nivel funcional

Primero será necesario elevar el nivel funcional del dominio en los controladores de dominio viejos. El nivel funcional determina las características de los Servicios de dominio de Active Directory (AD DS) que están habilitadas en un dominio o bosque. El nivel funcional del bosque limita al nivel funcional del dominio y solo afecta a los servicios de AD de los controladores de dominio, en el el caso de tener un servicio DHCP, IIS, WSUS, etc. no se verían afectados.

En los controladores de dominio viejos. Dominios y confianzas de Active Directory.

Figura 1: Elevar el nivel el nivel funcional del dominio...

Figura 2: Elevar el nivel funcional del dominio disponible al nivel más alto posible.

Comprobar el estado de la carpeta SYSVOL

Comprobar que la carpeta SYSVOL se está compartiendo. Ejecutar net share en uno de los controladores de dominio.

Comprobar el estado de los DCs con dcdiag.

dcdiag /e /test:sysvolcheck /test:advertising

Comprobar el path y el estado de la carpeta SYSVOL a través del registro de uno de los DCs. Valor "SysvolReady" a 1.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Netlogon\Parameters

Figura 3: Comprobar que la replicación de SYSVOL en el registro.

Comprobar replicación entre DCs

Verificar con repadmin la replicación antes de realizar la migración.

# Muestra el estado de replicación de los controladores de dominio por última vez.
repadmin /showrepl

# Identifica los DC's que fallan en la replicación entrante o saliente.
repadmin /replsummary

# Otra forma de comprobar la replicación usando dcdiag.
dcdiag /test:replications

Comprobar que el servicio de "DFS Replication Service" está corriendo en modo automático en todos los DCs de dominio.

sc qc DFSR

 

Tipos de estado de migración FRS a DFSR

Estados Estables / Estados Globales de Migración

• STATE 0 START
• STATE 1 PREPARED
• STATE 2 REDIRECTED
• STATE 3 ELIMINATED

Estados de Transición / Estados Locales de Migración

• STATE 4 Preparing
• STATE 5 Waiting for initial sync to complete
• STATE 6 Redirecting
• STATE 7 Eliminating
• STATE 8 Undo redirecting
• STATE 9 Undo preparing

Una vez que hemos pasado al estado 3 ELIMINATED ya no hay posibilidad de hacer rollback a una situación anterior.

Más info: https://blogs.technet.microsoft.com/filecab/2008/02/08/sysvol-migration-series-part-1-introduction-to-the-sysvol-migration-process

Migración RFS a DFSR

Se hará uso de la herramienta en línea de comandos dfsrmig.

dfsrmig /setglobalstate 1

Estado 1 glocal (PREPARED) se crearán todos los objetos necesarios para la replicación DFS-R. Se crea un nuevo recurso compartido SYSVOL_DFSR (C:\Windows\SYSVOL_DFSR) dejando de momento el actual SYSVOL. Podemos usar "dfsrmig /getmigrationstate" para comprobar el estado actual de la migración.

Figura 4: Migración RFS a DFSR - Estado 1 global (Prepared).

Estado 2 global (REDIRECTED) lanzará el proceso de migración desde SYSVOL a SYSVOL_DFSR.

dfsrmig /setglobalstate 2

Figura 5: Migración RFS a DFSR - Estado 2 global (Redirected).

El editor ADSI (Active Directory Services Interfaces) es un editor del directorio de bajo nivel basado en LDAP que permite la edición y visualización de atributos de los objetos del bosque.

Además nos permite modificar aquellos atributos que no podemos trabajar desde las otras consolas de administración del directorio como Usuarios y equipos de Active Directory, Sitios y servicios u otras.

AD LDS (Active Directory Lightweight Directory Services) es un servicio de directorio LDAP que proporciona almacenamiento y recuperación de datos a aplicaciones habilitadas para el uso de directorios, sin las dependencias necesarias para los Servicios de dominio de Active Directory.

Comprobamos que FRS como DFSR siguen activos en este punto de la migración.

Figura 6: Comprobación de estado de FRS y DFSR en el editor ADSI.

Estado 3 global (ELIMINATED) eliminará la carpeta SYSVOL y deshabilitará el servicio FSR. En este punto como ya se comentó anteriormente no hay posibilidad de vuelta atrás.

dfsrmig /setglobalstate 3

Figura 7: Migración RFS a DFSR - Estado 3 global (Eliminated).

Una vez finalizada la migración comprobamos a través del editor ADSI que que el servicio FRS ya no se esté usando.

Figura 8: Comprobación de eliminación de FRS en el editor ADSI

Comprobamos en la consola de servicios (services.msc) que FRS está en estado deshabilitado y DFSR está en ejecución.

Figura 9: Comprobar el estado de los servicios FRS y DFS-R.

Por último, comprobamos que no hay fallos y que la replicación es correcta entre todos los controladores de dominio.

repadmin /replsummary
repadmin /showrepl

Figura 10: Comprobar finalmente la correcta replicación entre todos los controladores.

Saludos!

Fallos en la replicación FRS y DFSR en Active Directory: Como forzar la sincronización no-autoritativa y autoritativa [Burflags]

Replicación FRS y DFSR

• FRS (File Replication Service) servicio para distribuir archivos compartidos y objetos de directiva de grupo entre controladores de dominio a través del recurso C:\Windows\SYSVOL. Windows Server 2003 R2 y Windows Server 2008 son compatibles con DFS (Distributed File System) y el servicio de replicación de archivos.

• DFSR (Distributed File System Replication) disponible por defecto a partir de Windows Server 2008 R2, reemplaza al sistema FRS para la replicación del recurso SYSVOL en los servicios de dominio de Active Directory. DFS replica los objetos de configuración almacenados de Active Directory.

Restauración "no autoritativa" y "autoritativa"

• Restauración No-Autoritativa: conserva los USN (Update Sequence Number) de los objetos del Directorio Activo desde la fecha que se creó la copia de seguridad del estado del sistema (System State). El sistema de replicación de Active Directory utiliza este número para detectar y propagar los cambios de Active Directory entre los distintos servidores de la organización. Debido a que el USN del servidor restaurando siempre será anterior a los USN actuales, los datos de este servidor nunca se replicarán con el resto de controladores de dominio. Por el contrario, si existen datos más recientes en los otros servidores, el sistema de replicación de AD los utilizará para actualizar los datos restaurados. Este procedimiento se suele realizar cuando queremos restaurar algún complemento del Sistema Operativo como una cuenta de usuario, equipo, DC, etc.

• Restauración Autoritativa: debemos de realizar primero una restauración no autoritativa y luego mediante la utilidad NTDSUTIL realizar una restauración autoritativa. De esta forma se consigue que los Objetos restaurados se les cambie el número de secuencia de actualización USN para que sea mayor al de cualquier otro USN del directorio. Así el servidor restaurado se asegura de que cualquier dato u objeto sea replicado y distribuido adecuadamente en todos los controladores de dominio.

Fallo de replicación FRS

En el caso de que tengamos dos o más controladores de dominio y que se apague un controlador de dominio el cual no esté correctamente sincronizado. Posteriormente, se levante un nuevo controlador de dominio con un sistemas operativo más actual que PDC (Primary Domain Controller) si el DC viejo se volviese a levantar puede que ocurra fallos en la sincronización.

Figura 1: Mensaje de fallo de replicación FRS en servicios de Active Directory.

Registro de evento Id. 1308: KCC (Knowledge Consistency Checker) ha detectado errores. KCC Es un proceso integrado que se ejecuta en todos los controladores de dominio y genera la topología de replicación de bosque de Active Directory.

Figura 2: Comprobador de coherencia de la información KCC . Id. 1308.

Registro de evento Id. 13508: Problemas en la replicación de objetos de los servicios de AD entre uno de los controladores de dominio. En este caso el servidor "X3550" no sincroniza con el servidor "SRVDOMINIO".

Figura 3: Fallo de sincronización de uno de los controladores de dominio. Id. 13508.

¿Cómo reinicializar o forzar la sincronización de replicación autoritativa o no autoritativa? 

El valor del registro Burflags genera la copia de cada controlador de dominio del árbol de volumen del sistema (SYSVOL) en todos los controladores de dominio de Active Directory.

Los valores D2 y D4 Burflags son los que controlan como se replica FRS entre los controladores de dominio.

• Si se inicia FRS con valor del registro Burflags establecido en D4 (sincronización autoritativa):

FRS trata inicialmente los archivos y carpetas de su copia local del árbol de SYSVOL como autorizados para el conjunto de réplicas. Si tenemos varios controladores de dominio, Burflags se debería establecer con valor D4 en un controlador de dominio único y en D2 en los demás controladores de dominio de ese dominio. Esta configuración se conoce como "Restauración autoritativa".

• Si se inicia FRS con el valor del registro Burflags establecido en D2 (sincronización no autoritativa):

FRS realiza una sincronización completa de los archivos y carpetas desde un asociado de replicación directo o transitivo que aloje la copia autorizada de los archivos y carpetas del conjunto de réplicas. Esta configuración se conoce como "Restauración no autoritativa" aunque no se produzca ninguna restauración del estado del sistema (System State). La configuración D2 regenera la parte de FRS del controlador de dominio como si fuera nuevo.

Configurar las réplicas de SYSVOL como autoritativo

Detener el servicio FRS de todos los controladores de dominio. En el PDC (Principal Domain Controller). (podemos averiguar el PDC haciendo un "netdom query fsmo"). Nos situamos en la siguiente rama del registro.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Cumulative Replica Sets\GUID

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\GUID

GUID (Globally Unique Identifier) del conjunto de réplicas del volumen del sistema del dominio.

Creamos o modificamos el valor DWORD BurFlags y lo establecemos a D4.

Figura 2: Repliación FRS: Sincronización autoritativa BurFlags con valor D4.

Reiniciamos el controlador de dominio principal y comprobamos que los servicios de Active Directory estén nuevamente sincronizados.

Más info: https://support.microsoft.com/es-es/help/315457/how-to-rebuild-the-sysvol-tree-and-its-content-in-a-domain

Después de forzar la sincronización entre los controladores de dominio, puede que nos interese transferir los roles FSMO y hacer purgado de los servicios del dominio (de darse el caso). Transferir roles FSMO Windows Server y hacer purgado de los servicios del dominio.

Saludos!

Transferir roles FSMO Windows Server y hacer purgado de los servicios de Active Directory del dominio

Los roles de maestros de operaciones FSMO (Flexible Single Master Operations) es una característica de Active Directory. Se trata de un conjunto de tareas de un controlador de dominio usadas principalmente para la replicación entre controladores de dominio.

Existen 5 roles FSMO en un Active Directory:

• Schema Master (Maestro de Esquema). Uno por Bosque.

• Domain Naming Master (Maestro de Nomenclatura de Dominios). Uno por Bosque.

• RID Master - Relative Identifier Master (Maestro Identificador Relativo). Uno por Dominio.

• Infrastructure Master (Maestro de Infraestructura). Uno por Dominio.

• PDC Emulator - Primary Domain Controller Emulator (Maestro Controlador Principal de Dominio). Uno por Dominio.
  

Figura 1: 5 Roles FSMO en Active Directory.

Comprobar el estado de los controladores de dominio

dcdiag (Domain Controller Diagnostic Tool) es una herramienta con la que podemos analizar el estado de los controladores de dominio de un bosque, ejecutando una serie de verificaciones se podrá diagnosticar su funcionamiento.

En el siguiente caso vemos el resultado del análisis en un bosque en el que existen dos controladores de dominio, uno de ellos está activo (SrvDominio Windows Server 2016) y el otro inactivo (apagado, Windows Server 2008 R2).

C:\>dcdiag
... ...

   Probando servidor: Nombre-predeterminado-primer-sitio\SRVDOMINIO
      Iniciando prueba: Advertising
         Advertencia: SRVDOMINIO no se está anunciando como un servidor horario.
         ......................... SRVDOMINIO no superó la prueba Advertising
      Iniciando prueba: FrsEvent
         Existen eventos de advertencia o de error en las últimas 24 horas después de compartir SYSVOL. Los problemas
         de replicación de SYSVOL incorrecta pueden ocasionar problemas de la directiva de grupo.
         ......................... SRVDOMINIO superó la prueba FrsEvent
      Iniciando prueba: DFSREvent
         ......................... SRVDOMINIO superó la prueba DFSREvent
      Iniciando prueba: SysVolCheck
         ......................... SRVDOMINIO superó la prueba SysVolCheck
      Iniciando prueba: KccEvent
         ......................... SRVDOMINIO superó la prueba KccEvent
      Iniciando prueba: KnowsOfRoleHolders
         [ADCONTROL1] Error en DsBindWithSpnEx(): 1722,
         El servidor RPC no está disponible..
         Advertencia: ADCONTROL1 es Schema Owner, pero no responde al enlace RPC de DS.
         Error en la búsqueda de atributos con capacidad de búsqueda LDAP en el servidor ADCONTROL1. Valor devuelto =
         81
         Advertencia: ADCONTROL1 es Schema Owner, pero no responde al enlace LDAP.
         Advertencia: ADCONTROL1 es Domain Owner, pero no responde al enlace RPC de DS.
         Advertencia: ADCONTROL1 es Domain Owner, pero no responde al enlace LDAP.
         Advertencia: ADCONTROL1 es PDC Owner, pero no responde al enlace RPC de DS.
         Advertencia: ADCONTROL1 es PDC Owner, pero no responde al enlace LDAP.
         Advertencia: ADCONTROL1 es Rid Owner, pero no responde al enlace RPC de DS.
         Advertencia: ADCONTROL1 es Rid Owner, pero no responde al enlace LDAP.
         Advertencia: ADCONTROL1 es Infrastructure Update Owner, pero no responde al enlace RPC de DS.
         Advertencia: ADCONTROL1 es Infrastructure Update Owner, pero no responde al enlace LDAP.
         ......................... SRVDOMINIO no superó la prueba KnowsOfRoleHolders

... ...

Transferir roles FSMO entre Domain Controller

Listar los roles FSMO

Consolas de Microsoft

Podemos ver los roles FSMO de forma gráfica a través de las propias consolas de gestión de Microsoft. 

En la consola de "Usuarios y equipos de Active Directory" (dsa.msc) podemos ver los siguientes roles de maestros de operaciones: 

• Administrador de grupos RID, PDC y Maestro de infraestructura.

Figura 2: Maestro de operaciones dsa.msc (RID, PDC e Infrastructure).

En la consola de "Sitios y confianzas de Active Directory" (domain.msc) podemos ver los siguientes roles de maestros de operaciones: 

• Maestro de nomenclatura de dominio. 

Figura 3: Sitios y confianzas de Active Directory domain.msc (Maestro de nomenclatura de dominio).

Para poder gestionar la siguiente consola debemos registrar antes una dll en el sistema. 

regsvr32 schmmgmt.dll

Una vez registrada, abrimos una mmc.exe y agregamos el complemento de la consola de "Esquema de Active Directory" donde podemos ver los siguientes roles de maestros de operaciones:

• Maestro de esquema.

Figura 4: Esquema de Active Directory (Maestro de esquema).

Obtener Roles FSMO

Opción 1: netdom

Existe otra forma de ver más rápidamente y gestionarlo de forma más cómoda como es utilizar netdom una utilidad de línea de comandos para la administración de Active Directory y Relaciones de confianza.

netdom query fsmo

Figura 5: netdom query fsmo

ntdsutil es una utilidad de línea de comandos para la administración de ADDS (Active Directory Domain Services).

Opción 2: PowerShell - Get-ADDomainController y Get-ADForest

Obtener un listado de todos los controladores de dominio de todos los dominios disponibles, comprobar si están habilitados, Hostname e IP (indicar -Domain para indicar un dominio específico).

Get-ADDomainController -Filter * | Select-Object HostName, IPv4Address, Enabled

Obtener un listado de los roles FSMO asociados a los controladores de dominio.

Get-ADDomain | Select-Object InfrastructureMaster, RIDMaster, PDCEmulator | Format-List

Get-ADForest | Select-Object DomainNamingMaster, SchemaMaster | Format-List

 

FSMO: ¿Transfer o Seize?

Transferir ROLES de un servidor activo a uno nuevo (de ADCONTROL1 a SRVDOMINIO)

C:\>ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server SrvDominio
Enlazando a SrvDominio ...
Conectado a SrvDominio usando credenciales de usuario conectado localmente.
server connections: q
fsmo maintenance: transfer naming master
fsmo maintenance: transfer infrastructure master
fsmo maintenance: transfer PDC
fsmo maintenance: transfer RID master
fsmo maintenance: transfer schema master
fsmo maintenance: q
ntdsutil: q

Transferir ROLES de un servidor inactivo (apagado) a uno activo (de ADCONTROL1 a SRVDOMINIO)

C:\>ntdsutil
ntdsutil: roles
fsmo maintenance: connections
server connections: connect to server SrvDominio
Enlazando a SrvDominio ...
Conectado a SrvDominio usando credenciales de usuario conectado localmente.
server connections: q
fsmo maintenance: seize naming master
fsmo maintenance: seize infrastructure master
fsmo maintenance: seize PDC
fsmo maintenance: seize RID master
fsmo maintenance: seize schema master
fsmo maintenance: q
ntdsutil: q

Una vez transferidos los roles FSMO volvemos a comprobar su estado y que se transfirieron correctamente.

Figura 6: netdom query fsmo

Purgado de servicios de Active Directory en el caso de que un DC ya no vaya estar operativo en el dominio

Si se trata de un servidor que ya no estará operativo en el bosque habrá que limpiar o "purgar" el resto de servicios que puedan estar asociados al DC viejo.

1. Limpiar registros DNS

Eliminar todos los registros que apunten al DC viejo en toda la jerarquía del Administrador de DNS.

Figura 7: Eliminar registros DNS del DC viejo.

2. Limpiar Sitios y Servicios de Active Directory

Eliminar el servidor DC viejo de "Sitios y Servicios de Active Directory".

Figura 8: Eliminar registros de "Sistios y servicios de Active Directory".

3. Limpiar Active Directory

Eliminar los objetos de equipos de las OU (Organizational Unit) Computers y Domain Controllers.

Figura 9: Eliminar los DC de Active Directory.

4. Cambiar opciones del servicio DHCP

En el caso de tener el rol del servicio DHCP instalado, eliminar de los servidores DNS de las Opciones de ámbito la dirección IP del DC viejo.

Figura 10: Eliminar IP del DC del servicio DHCP.

5. Cambiar direcciones DNS a los equipos de la red interna

Cambiar las direcciones DNS al resto de máquinas de la red interna con ip estática definida Windows o Linux ya sean servidores o equipos clientes.

Saludos!