¿Qué es AdminSDHolder en Active Directory?

El propósito del objeto AdminSDHolder es proporcionar una "plantilla" de permisos para las cuentas y grupos protegidos en un dominio de Active Directory, AdminSDHolder es creado de manera automática como un objeto del contenedor System en cada dominio, su ruta es: CN=AdminSDHolder,CN=System,DC=,DC=

Al contrario de muchos objetos en Active Directory cuyo propietario es el grupo Administradores, AdminSDHolder tiene como propietario el grupo Domain Admins, de manera predeterminada los miembros del grupoEnterprise Admins pueden hacer cambios en el objeto AdminSDHolder, sin embargo aunque el propietario de este objeto es el grupo Domain Admins, los miembros del grupo Administrators y Enterprise Admins pueden tomar propiedad de este objeto.

Pero, mejor de manera gráfica veamos cómo funciona este objeto, si se compara la lista de control de acceso (ACL) de un grupo protegido, por ejemplo Domain Admins con la del objeto AdminSDHolder se puede apreciar que son exactamente iguales.

Si revisamos la ACL de cualquier cuenta o grupo protegido podemos ver que tiene siempre la misma ACL y esta ACL es simplemente un reflejo de la ACL del objeto AdminSDHolder, pero dónde encontramos dicho objeto?

En la consola Usuarios y Equipos de Active Directory podemos ver el contenedor System y al expandirlo veremos el objeto AdminSDHolder

Simplemente hacemos clic derecho sobre el objeto, propiedades, y seleccionamos la pestaña Seguridad para ver la ACL que se propaga sobre las cuentas y grupos protegidos.

Ahora, hagamos una prueba, utilicemos una cuenta protegida y modifiquemos su ACL, agreguemos un usuario llamado John Smith y otorgemosle control total sobre la cuenta protegida Usuario1

Bien, hasta este momento el usuario John Smith tiene control sobre la cuenta protegida Usuario1, de igual modo pudo haber modificado la ACL de un grupo protegido, por ejemplo Domain Admins, es en este momento que entra en acción el objeto AdminSDHolder y "protegerá" la ACL del objeto modificado, en este caso la cuenta Usuario1, y la tarea es sencilla, simplemente remplazar la ACL del objeto modificado por la ACL del objeto AdminSDHolder.

Como podemos apreciar, en la ACL de Usuario1 ya no se encuentra la entrada para el usuario John Smith que se agregó en el paso anterior, esto debido a que el proceso automático se encargó de establecer la ACL de la cuenta protegida.

En resumen, el objeto AdminSDHolder contiene los permisos predeterminados de todas las cuentas y grupos protegidos, si no sabes cuáles son puedes revisar este artículo, si una ACL de cualquiera de los objetos protegidos es modificada, ésta será restablecida tomando como base la ACL definida en el objeto AdminSDHolder.

¿Qué es SDProp en Active Directory?

SDProp (Security Descriptor Propagator), es un proceso que se ejecuta cada 60 minutos por defecto,en el controlador de dominio que tiene el rol de emulador PDC. SDProp compara los permisos del objetoAdminSDHolder con los permisos de cuentas y grupos protegidos en el dominio, si los permisos de alguna cuenta o grupo protegido no coinciden con los que contiene el objeto AdminSDHolder, los permisos establecidos en las cuentas o grupos protegidos son restablecidos de tal forma que coincidan con los definidos en el objeto AdminSDHolder.

Adicional a lo anterior, la herencia será deshabilitada en las cuentas y grupos protegidos, lo cual significa que si alguno de estos objetos es movido a una ubicación diferente en el directorio, éste no heredará los permisos de los objetos padre en la nueva ubicación. la herencia es deshabilitada en el objeto AdminSDHolder, con lo cual cualquier cambio en la herencia del objeto padre no afectará lo establecido en el objetoAdminSDHolder.

Caso de la vida real: Muchas veces me he encontrado con administradores que no se explican porqué la herencia en un usuario o grupo está deshabilitada y a pesar de que se habilite vuelve a su estado después de un momento (ese momento son los 60 minutos que tarda en ejecutarse el SDProp), así que usted ya sabe que si esto ocurre es un proceso normal dado que se trata de una cuenta o grupo protegido.

¿Porqué se deshabilita la herencia?...usted ya lo sabe :-)

Cambiar el intervalo del SDProp en Active Directory

De manera predeterminada el proceso SDProp se ejecuta cada 60 minutos, normalmente usted no necesita cambiar este intervalo de tiempo, a menos que lo desee hacer con propósitos de prueba, si usted necesita cambiar este intervalo debe hacerlo sobre el controlador de dominio que tiene el rol emulador PDC, modificando el valor de registro AdminSDProtectFrequency que se encuentra en la siguiente rama:

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

El rango de valores está dado en segundos, desde 60 hasta 7200 (un minuto a dos horas). Para reversar los cambios hechos en el registro basta con eliminar la llave AdminSDProtectFrequency, esto causará que el tiempo de ejecución del SDProp se restablezca a su valor por defecto (60 minutos).

Generalmente usted no debería reducir el intervalo de tiempo por defecto en un ambiente de producción, ya que esto puede incrementar la carga de procesamiento de LSASS en el controlador de dominio, el impacto puede variar dependiendo del número de objetos protegidos existentes en el dominio. Veamos el paso a paso.

1. Abra el editor de registro y expanda la siguiente rama: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters

2. En un área vacía de la parte derecha del editor haga clic derecho, en el menú Nuevo seleccione DWORD

3. Escriba el siguiente nombre para la llave: AdminSDProtectFrequency

4. Establezca el nuevo valor en segundos entre 60 y 7200 y haga clic en OK

De esto modo tenemos un nuevo intervalo de ejecución para el proceso SDProp

Ejecutar proceso SDProp manualmente en Active Directory

El proceso SDProp se ejecuta automáticamente cada 60 minutos, este intervalo de tiempo puede ser cambiado y puede definirse entre 60 y 7200 segundos (vea aquí cómo hacerlo), pero también podemos manualmente generar la ejecución del mismo, revisemos cómo.

Es importante tener en cuenta que este proceso es ligeramente diferente en Windows Server 2008 y Windows Server 2012, así que antes de ejecutarlo tenga en cuenta su versión de Windows.

Ejecutar SDProp manualmente en Windows Server 2008 y anteriores

1. En ejecutar escriba ldp y presione Enter

2. En la ventana ldp haga clic en Connection y luego en Connect

3. En el cuadro de diálogo Connect escriba el nombre del controlador de dominio que tiene el rol emulador PDC y haga clic en OK

4. Una vez conectado, haga clic en Connection/Bind

5. En el cuadro de diálogo Bind escriba las credenciales de una cuenta de usuario que tenga privilegios para modificar el objeto rootDSE, si ya está logueado con un usuario que posea estos permisos, simplemente haga clic en Bind as currently logged on user y haga clic en OK

6. Luego, hacemos clic en Browse y clic en Modify 

7. En el cuadro de diálogo Modify, deje en blanco el campo DN. En el campo Edit Entry Attribute digite FixUpInheritance, y en el campo Values escriba Yes, luego haga clic en Enter para poblar el campo Entry List y haga clic en Run

Por último verifique que efectivamente los permisos definidos en el objeto AdminSDHolder han sido aplicados en la ACL de la cuenta o grupo protegido.

Ejecutar SDProp manualmente en Windows Server 2012 o Windows Server 2008 R2.

1. En ejecutar escriba ldp y presione Enter

2. En la ventana ldp haga clic en Connection y luego en Connect

3. En el cuadro de diálogo Connect escriba el nombre del controlador de dominio que tiene el rol emulador PDC y haga clic en OK

4. Una vez conectado, haga clic en Connection/Bind

5. En el cuadro de diálogo Bind escriba las credenciales de una cuenta de usuario que tenga privilegios para modificar el objeto rootDSE, si ya está logueado con un usuario que posea estos permisos, simplemente haga clic en Bind as currently logged on user y haga clic en OK

6. Luego, hacemos clic en Browse y clic en Modify 

7. En el cuadro de diálogo Modify, deje en blanco el campo DN. En el campo Edit Entry Attribute digite RunProtectAdminGroupsTask, y en el campo Values escriba 1, luego haga clic en Enter para poblar el campo Entry List y haga clic en Run

Por último verifique que efectivamente los permisos definidos en el objeto AdminSDHolder han sido aplicados en la ACL de la cuenta o grupo protegido, como se puede apreciar la diferencia entre las versiones de Windows se enccuentra en este último paso.

Cuentas y grupos protegidos en Active Directory

En Active Directory existe un conjunto de cuentas y grupos que son considerados "protegidos", generalmente si tenemos administradores designados estos mismos pueden cambiar y asignar permisos incluso pueden agregarse como miembros a cualquier grupo.

Con cuentas y grupos protegidos, los permisos de los objetos son establecidos de manera forzosa a través de un proceso automático que asegura que los permisos en los objetos permanezcan estables, incluso si el objeto es movido dentro del directorio, lo cual significa que si alguien (por ejemplo un administrador designado) cambia de manera manual los permisos de un objeto protegido en Active Directory éstos retornarán a su estado original o "por defecto" de manera automática.

Los siguientes son los grupos protegidos en un controlador de dominio:

• Administrators
• Domain Admins
• Enterprise Admins
• Schema Admins

Ahora bien, algo importante a considerar es que las cuentas pertenecientes a un grupo protegido automáticamente se convertirán en cuentas protegidas.

Para identificar una cuenta o grupo protegido, basta con revisar las propiedades del objeto y revisar el valor del atributo adminCount si está establecido en 1 significa que se trata de una cuenta o grupo protegido, de lo contrario este valor no estará establecido, veámos un ejemplo.

Revisemos el atributo adminCount de la cuenta Administrator.

Como podemos apreciar el valor efectivamente es 1, si no puedes ver la pestaña Attribube Editor ó Editor de Atributos de la cuenta, basta con hacer clic en el menú Ver y activar la opción Características avanzadas, de esta forma aparecerá la pestaña.

Ahora examinemos el mismo atributo pero en una cuenta normal llamada Usuario1

Como se puede apreciar su valor no está establecido, por lo cual se trata de una cuenta NO protegida.

Bien, ahora agreguemos a un grupo protegido, por ejemplo Domain Admins al usuario Usuario1

Después de agregarlo, ahora vamos a revisar sus atributos nuevamente.

Ahora ya vemos como el atributo adminCount ha sido establecido a 1, con lo cual podemos comprobar que cualquier cuenta vinculada a un grupo protegido automáticamente la cuenta quedará protegida, con ello su lista de control de acceso ACL se restablecerá cada 60 minutos a través de un proceso automático, esto previene la modificación o alteración de la lista de control de acceso de grupos o cuentas  sensibles por parte de administradores delegados por ejemplo.

Solucionar problemas de replicación de SYSVOL

En este artículo veremos cómo solucionar problemas de replicación del volumen del sistema o SYSVOL, este tipo de errores pueden detectarse de la siguiente forma:

Al realizar un gpupdate desde alguna estación cliente podemos recibir un mensaje de error que indica que ha fallado el procesamiento de la directiva de grupo:

"The processing of Group Policy failed. Windows attempted to read the file from a domain controller and was not successful."

Esta es una forma de detectar el error, la otra puede ser realizando un simple ejercicio, y se trata de observar el contenido de la carpeta SYSVOL en dos controladores de dominio, con lo cual se puede apreciar la existencia de diferencias, de igual forma si copiamos por ejemplo un archivo de texto en Servidor 1, podemos notar que no será replicado a Servidor 2

Si el contenido de la carpeta SYSVOL no se está replicando se experimentarán problemas con la aplicación de las directivas configuradas.

Antes de intentar corregir este inconveniente con la carpeta SYSVOL es recomendable realizar antes un análisis de la replicación en general entre los controladores de dominio para descartar que el problema solamente es a nivel de replicación de SYSVOL.

Lo primero que debemos hacer, es verificar los registros de eventos asociados a File Replication Service

Y allí debemos buscar con los eventos con ID 13568:

The file replication service has detected that the replica set is in jrnl_wrap_error

This indicates that the service is in a journal wrap state. Once you identify the DC that is in journal wrap condition, we must re-initializing SYSVOL replication. Before we start, we need to determine whether replication is being done by FRS (also known as NTFRS) or DFS-R.

El error básicamente lo que está indicando es que el servidor ha caido en un estado "journal wrap",  y en esencia cuando habla de journal se está refiriendo más exactamente al sistema de archivos, es decir a NTFS, y más específicamente a una característica de este sistema llamada NTFS Journal ó USN Journal, que de forma muy resumida se encarga de llevar un registro de los cambios hechos en un volumen con formato NTFS, y pues la replicación se basa en estos registros para saber qué información debe enviar al otro servidor (hablando en términos de SYSVOL), entonces al encontrarnos con este estado significa que hay inconsistencias entre el contenido del registro de un servidor con respecto al otro, las posibles causas de esto son las siguientes:

• Se ha formateado el volumen
• Se ha eliminado el registro NTFS USN journal del volumen o se ha truncado mediante una aplicación del comando chkdsk (el cual pudo encontrar entradas corruptas al final del journal).
• El servicio de replicación se ha detenido por un período de tiempo prolongado.

El error también indica que una vez identifiquemos el servidor que ha caído en este estado (evento 13568), debemos reinicializar la replicación SYSVOL, además indica que se debe identificar cuál mecanismo de replicación se está usando FRS ó DFSR, pues entonces antes de iniciar de reiniciar la replicación SYSVOL revisemos cuál de los dos métodos estamos usando, para evitar esta revisión puede tener en cuenta lo siguientes, si está usando una edición de Windows anterior a 2008, por ejemplo 2003, la replicación será FRS, si está usando 2008 o superior será DFSR, pero atención!!! si tiene Windows Server 2008 pero fue actualizado desde una versión 2003 la replicación será FRS, aunque se puede migrar a DFSR, pero esto no lo trataremos aquí, sin embargo iniciemos el proceso de revisión.

Debemos ingresar a la siguiente rama del registro: 

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\DFSR\Parameters\SysVols\Migrating Sysvols\LocalState

Si el valor de la llave LocalState es 3, se está usandeo DFSR, si la llave no existe o tiene un valor diferente a 3 se está usando FRS.

En este caso, podemos observar que el valor es 0, pero se trata de un 2008 que fue migrado desde 2003, lo cual tiene sentido, por lo cual el método de reinicialización de SYSVOL que usaremos será para FRS.

Antes de iniciar el proceso es importante  determinar las causas del problema, ya que de otra forma no servirá de mucho hacer la reparación ya que pronto se volverá a presentar, por ello es importante por lo menos tener en cuenta lo siguiente:

• Verificar que el servicio FRS ó DFSR según el caso, se encuentren corriendo.
• Verificar que hay conectividad entre los servidores, mediante ping a la IP y al FQDN
• Verificar que el servicio RPC esté arriba y que no exista un firewall bloquendo los puertos 135 y 445
• Verificar que no exista lentitud en el canal de comunicación.
• Verificar que no existan problemas físicos de disco duro o de memoria
• Garantizar que los DC no pierdan conexión entre sí por períodos prolongados de tiempo.

La necesidad de identificar si se trata de replicación FRS ó DFSR se debe a que el proceso de reinicialización es diferente para cada una, debido a que hemos identificado que la replicación es FRS iniciaremos con este proceso.

Reinicializar carpeta SYSVOL en sistema con replicación FRS

Para este caso tenemos dos tipo de replicación de SYSVOL autoritativa y no autoritativa.

Es recomendable siempre intentar la no autoritativa, para ello debemos garantizar conectividad con otro servidor que del cual deseamos replicar la información que necesitamos.

El primer paso es detener el servicio de replicación a través del comando net stop ntfrs

Luego abrir la siguiente rama desde el editor del registro.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup

Debemos modificar el valor de la llave BurFlags el cual se encuentra establecido en 0 a D2, con lo cual la llave queda de la siguiente manera:

Con esto le hemos indicando al sistema que se trata de una restauración no autoritativa de SYSVOL., en este artículo no se tratará la restauración autoritativa

Por último volvemos a iniciar el servicio de replicación con el comando net start ntfrs

Después de esto el proceso puede tardar varios minutos dependiendo de la cantidad de información a replicar, al finalizar se generará un evento 13516

De esta forma hemos terminado de restablecer la replicación SYSVOL con FRS

Reinicializar carpeta SYSVOL en sistema con replicación DFSR

Para este caso no he generado screenshots ya que el problema se presentó en un servidor con FRS, sin embargo pondré los pasos.

1. Debemos abrir la consola adsiedit.msc y navegar hasta la siguiente ruta en cada uno de los DC:

CN=SYSVOL Subscription,CN=Domain System Volume,CN=DFSR-LocalSettings,CN=,OU=Domain Controllers,DC= 

establecer el siguiente valor msDFSR-Enabled=FALSE

2. Forzar la replicación a través de todo el dominio.

3. Ejecutar el siguiente comando en los servidores que semarcarán como no autoritativos: dfsrdiag polladd

4. Se generará un evento 4114 indicando que SYSVOL ni seguirá siendo replicado.

5. En la misma ruta del paso 1 volver a establecer el valor a true msDFSR-Enabled=TRUE

7. Volver a forzar la replicación a través de todo el dominio.

8. Se generará un evento 4614 indicando que la operación finalizó.

Importante: Los procesos descritos en este artículo tanto FRS como DFSR solo tratan la restauración no autoritativa de SYSVOL

Recuperar objetos eliminados en Active Directory con papelera de reciclaje deshabilitada

En esta ocasión mostraré como recuperar objetos eliminados en Active Directory, a partir de Windows Server 2008 R2 contamos con la característica 'Recycle Bin', la cual nos permite recuperar objetos eliminados de Active Directory manteniendo todos sus atributos completos, muy bonito verdad?, pero qué pasa si no tenemos esta característica habilitada? o qué pasa si nuestro nivel funcional de bosque no está establecido a Windows Server 2008 R2 debido que aún no hemos podido elevar el nivel funcional por algún motivo?

Antes cualquier situación en la que no podamos recuperar un objeto por no tener la papelera habilitada, no nos queda más remedio que acudir a la herramienta LDP, a continuación entonces mostraré cómo recuperar un objeto de Active Directory cuando no tenemos la papelera de reciclaje habilitada.

NOTA: Este procedimiento recupera el objeto en crudo, es decir non tendrá pertenencia a ningún grupo y todas sus propiedades estarán en blanco, a esto también se le conoce como recuperar el SID. Por lo cual una vez recuperemos el objeto debemos volver a poner los grupos a los que pertenece y poner las propiedades que tenía antes de ser eliminado, como lo pueden ser Teléfono, Departamento, etc.

1. Abrimos la herramienta ldp.exe con privilegios de administrador

2. Una vez abierta la herramienta hacemos clic en el menú Connection y luego Connect

3. En el cuadro Server escribimos el nombre del servidor, dejamos el puerto LDAP por defecto (389), y hacemos clic en OK

4. Una vez conectado, hacemos clic nuevamente en Connection y luego en Bind, en la ventana que aparece dejamos habilitada la opción por defecto, que es usar las credenciales del usuario actual, luego hacemos clic en el botón OK

5. Luego vamos al menú Options y seleccionamos la opción Controls

6. De la lista desplegable Load Predefined seleccionamos Return Deleted Objects y hacemos clic en OK

7. Luego hacemos clic en el menú View y seleccionamos Tree

8. En la ventana Tree View escribimos el nombre del contenedor donde se encuentran los objetos eliminados, el cual es: CN=Deleted Objects,DC=[dominio],DC=[com] (reemplazar lo encerrado en corchetes por el nombre de su dominio) y hacer clic en OK

9. Después de hacer clic en el botón OK de la imagen anterior, veremos en el panel de la derecha de la consola ldp el contenedor de objetos eliminados, el cual podemos expandir para buscar todos los objetos eliminados, en nuestro caso solo tenemos un usuario eliminado.

Como podemos ver, tenemos un usuario eliminado llamado Andres Gomez, lo primero que debemos hacer es doble clic sobre el objeto eliminado, de tal forma que podamos ver todas las propiedades de este objeto en el panel derecho de la consola ldp, pero en este caso es muy importante tener en cuenta el atributo distinguishedName del objeto, el cual podemos ver en el recuadro rojo de la siguiente imagen.

Seleccionamos y copiamos el DN del objeto, a partir de CN en el recuadro anterior.

10. Una vez copiado el DN del objeto, vamos al menú Browse y seleccionamos Modify

11. En el cuadro DN pegamos lo que hemos copiado en el paso 9, en el cuadro Attribute escribimos isDeleted, en Operation activamos Delete, y por último hacemos clic en el botón Enter

Al hacer clic en el botón Enter el campo vacío Entry List se llenará con la información que hemos establecido quedando de la siguiente forma:

12. Ahora, sin cerrar la ventana ni nada, vamos a reemplazar la palabra isDeleted del cuadro Attribute por la palabra distinguishedName, luego en el campo Values escribimos el nuevo DN del objeto, en este caso lo dejaré en raíz del dominio: CN=Andres Gomez,DC=Corp,DC=local, luego en Operation activamos la opción Replace, y hacemos clic en el botón Enter, la nueva entrada quedará debajo de la ya existente:[Delete]isDeleted; por último activamos la casilla Extended y hacemos clic en el botón Run. Antes de hacer clic en el botón Run asegúrese de que su ventana tiene una apariencia como la siguiente:

13. Al hacer clic en el botón Run debemos poder apreciar en el panel derecho de la consola ldp el resultado satisfactorio de la operación, tal como se muestra en la siguiente imagen:

14. Con esto finaliza la restauración del objeto, ahora si vamos a revisar en la consola Usuarios y Equipos de Active Directory, se podrá observar el objeto recién recuperado.

Como se puede apreciar el objeto se encuentra deshabilitado, simplemente lo habilitamos y de este modo hemos recuperado nuestro usuario borrado del directorio sin utilizar la papelera de reciclaje.

Y el resultado final:

Esto es todo amigos, espero les sea de utilidad en algún momento.