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.

¿Qué son y para que sirven los grupos restringidos en Active Directory?

En esta ocasión trataré el tema de grupos restringidos en Active Directory, primero voy a explicar qué son y para que nos sirven, luego mostraremos cómo se implementan.

Los grupos restringidos son una configuración que se realiza a través de la directiva de grupo, que permite que hagamos que cualquier grupo de dominio sea miembro de algún grupo local predeterminado en Windows, la ruta donde encontramos esta configuración durante la edición de la GPO es la siguiente:

Computer Configuration\Windows Settings\Security Settings\Restricted Groups

Pero...para qué nos sirve esto y en qué casos nos puede llegar a ser útil?

La respuesta es simple, nos srive para otorgar acceso a servidores y equipos cliente a usuarios normales de dominio, sin que estos cuenten con privilegios especiales dentro de Active Directory.

Expliquemoslo un poco mejor:

Supongamos que en nuestra empresa tenemos un grupo de Help Desk, y los miembros de este grupo son usuarios comunes y corrientes de dominio, es decir sin ningún privilegio especial, y deseamos que este grupo de usuarios tenga acceso administrativo por ejemplo a los equipos cliente, porsupuesto sin necesidad de tener que otorgarles privilegios como administradores de dominio, es en ese momento donde entran en acción los grupos restringidos.

Entonces aclaremos el objetivo, lograr que un grupo de dominio llamado Help Desk tenga privilegios administrativos sobre varias estaciones cliente que se encuentran en una OU llamada Desktop Computers

Teniendo lo anterior presente iniciemos desde la creación de la GPO, la cual llamaremos GPO_RestrictedGroupHelpDesk

La editamos, y expandimos la siguiente ruta: Computer Configuration\Windows Settings\Security Settings\Restricted Groups hacemos clic derecho sobre Restricted Groups y seleccionamos la opción Add group

Y seleccionamos el grupo de dominio que en este caso se llama CONTOSO\HelpDesk

Una vez hagamos clic en el botón OK aparecerá la siguiente ventana, en la cual la mayoría de personas encuentran dificultades en entender cómo funciona.

Observemos que tiene dos parte "Members of this group" y "This group is a member of"

La primera en español significa "Miembros de este grupo" ¿de cuál?, pues el que tenemos en el título de la ventana y elegimos en el paso anterior CONTOSO\HelpDesk, es entonces cuando se puede presentar una confusión, cómo así que los miembros de este grupo, si esos ya existen y actualmente son miembros de ese grupo, pues se trata de mi personal de Help Desk, yo lo que quiero es que ese grupo sea administrador de mis equipos cliente. 

Ah bueno!, si eso es lo que quieres, la opción "Miembros de este grupo" no es la que se necesita, en su lugar debemos utilizar la segunda, que en español significa "Este grupo es miembro de", entonces hacemos clic en el botón Add de la segunda opción y escribimos el grupo en los equipos cliente al cual deseamos que pertenezca, en este caso el grupo  Administrators integrado, la ventana queda de la siguiente forma:

Lo anterior significa: que el grupo de dominio CONTOSO\HelpDesk será miembro del grupo Administrators de los equipos a los cuales se les aplicará la GPO, al ser el grupo HelpDesk miembro del grupo local de administradores, todos los que pertenezcan al grupo de Help Desk tendrán privilegios administrativos sobre las estaciones, es importante tener en cuenta que la opción "This group is a member of" es acumulativa, es decir; si existen otros administradores locales no serán eliminados, y los que definamos simplemente se agregarán a la lista, en este caso el grupo HelpDesk estará junto a los otros grupos que allí se encuentren, por ejemplo el de administradores de dominio y cualquier otro grupo o usuario que haya sido agregado manualmente.

La configuración de la directiva deberá quedar similar a la siguiente:

La segunda opción "Members of this group" define la pertenencia definitiva al grupo y funciona al contrario de la primera opción, es decir, esta vez en el primer paso no elegimos el grupo de dominio sino el grupo integrado predeterminado del cual deseamos configurar su pertenencia, veamos un ejemplo de la primera opción también para el grupo local de administradores.

En esta ocasión en lugar de elegir el grupo de dominio CONTOSO\HelpDesk, eligiremos el grupo predeterminado que queremos controlar, en este caso Administrators, pero también podemos hacerlo con otros grupos predeterminados como Remote Desktop Users o Server Operators.

Al hacer clic se abrirá nuevamente la ventana para seleccionar entre "Miembros de este grupo" o "Este grupo es miembro de"

En esta ocasión si usaremos la primer opción "Miembros de este grupo" a diferencia de la segunda opción, ésta si define la pertenencia final del grupo, es decir; cualquier otro usuario o grupo que exista será eliminado y solo permanecerá el que le indiquemos, que en nuestro caso es CONTOSO\HelpDesk

Lo anterior significa: que el grupo local integrado Administrators tendrá como miembro el grupo de dominio HelpDesk, pero ATENCION, cualquier otro usuario o grupo será eliminado, incluyendo el grupo Domain Admins que siempre hace parte del grupo administradores de todas las máquinas del dominio, la única cuenta que se mantiene es la del Administrador local, lo cual da como resultado que después de aplicada la directiva la pertenecia del grupo Administrators de los equiopos sobre los cuales se aplicará la directiva estará conformado solamente por la cuenta Administrator y el grupo de dominio CONTOSO\HelpDesk

Tengan mucho cuidado con esta segunda opción, ya que se puede dar el caso de que por alguna razón exista alguna cuenta de administrador local que se utilice para algún servicio o aplicación, ya que esta opción elimina cualquier otro miembro diferente a la cuenta administrador integrada.

Al final la configuración debe quedar similar a la siguiente:

Nótese la diferencia con la otra opción:

 Bueno amigos, espero haber logrado dejar un poco más claro este tema, ya que he notado muchas confusiones sobre este tema por parte de los administradores de Active Directory.