Limpiar adminCount Active Directory: un procedimiento seguro

Limpiar adminCount Active Directory: qué se está corrigiendo

El objetivo operativo de limpiar adminCount Active Directory es eliminar un marcador administrativo residual y restaurar la herencia de permisos prevista en las cuentas que realmente han dejado los grupos protegidos. Es una tarea habitual de mantenimiento tras cambios de función y bajas de personal. Nuestra guía de puertas traseras de AdminSDHolder y SDProp aborda otro escenario: una ACE no autorizada en la plantilla puede propagarse a los objetos protegidos. Aquí, la decisión parte de las pertenencias actuales y de la ACL de la cuenta, sin dar por hecho que intervenga un atacante.

Comprobar los anidamientos, borrar el marcador y habilitar la herencia son solo una parte de este procedimiento. Un registro de mantenimiento seguro debe identificar los grupos protegidos por SID, resolver el grupo primario por separado, revisar la OU superior, aprobar cada cuenta individualmente y verificar el resultado después de un ciclo posterior de SDProp. Un inventario adminCount=1 más reducido es útil, pero no demuestra que los permisos efectivos sean correctos.

Cómo funciona SDProp y por qué persiste el marcador

AdminSDHolder proporciona los permisos de plantilla para los objetos protegidos. SDProp compara sus permisos con esa plantilla en el emulador PDC (PDCE) de cada dominio, cada 60 minutos de forma predeterminada, y restablece las diferencias. Los objetos protegidos tienen la herencia deshabilitada; trasladarlos a otra OU no elimina la protección. Microsoft lo documenta en el Apéndice C: cuentas y grupos protegidos. La especificación del protocolo AdminSDHolder explica la protección periódica de los descriptores de seguridad.

La referencia del esquema Admin-Count de Microsoft describe el atributo como un registro de una ACL reforzada tras una pertenencia administrativa directa o transitiva. No es un inventario completo de los privilegios actuales. El artículo histórico de Microsoft sobre AdminSDHolder y SDProp explica que, tras eliminar la pertenencia protegida, permanecen adminCount=1 y la herencia deshabilitada. El antiguo miembro deja de recibir la ACL de la plantilla, pero sigue sin heredar del objeto superior.

Utilice la lista actual del Apéndice C en lugar de la lista antigua del artículo histórico:

Administrator y Krbtgt son cuentas, no grupos de pertenencia. Registre cualquier configuración de dominio o excepción de bosque aplicable; no cambie dSHeuristics para simplificar la limpieza. El grupo Protected Users es un control de autenticación independiente; no está protegido por AdminSDHolder por sí mismo.

Trampa 1: una eliminación directa deja una ruta anidada

El artículo histórico de Microsoft describe la protección transitiva, incluidas las rutas a través de grupos de distribución. Un usuario eliminado de Domain Admins puede seguir llegando a un grupo protegido a través de otro grupo. Si esa ruta permanece, borrar un atributo no elimina la protección, y SDProp puede deshacer la habilitación de la herencia. No prometa que borrar el marcador por sí solo necesariamente provoca que vuelva a establecerse en un momento preciso del siguiente ciclo; la conclusión respaldada es que la pertenencia restante sigue haciendo que el objeto esté protegido.

Trampa 2: el marcador desaparece, pero la ACL sigue siendo incorrecta

Para un antiguo miembro confirmado, borrar adminCount deja la herencia sin cambios. Por tanto, la delegación de la OU superior puede seguir sin llegar a la cuenta. Esto no demuestra que la ACL existente de la cuenta sea más permisiva: puede que le falten los derechos de administración previstos. A la inversa, habilitar la herencia bajo una OU con delegación excesiva puede añadir permisos no deseados. Las ACE explícitas también requieren su propia revisión; habilitar la herencia no las elimina por sí mismo.

Detección: crear un inventario de candidatos

Empiece con un inventario de solo lectura. Get-ADObject documenta -LDAPFilter, -Properties y -Server; esta adaptación solicita el marcador y el estado necesarios para la investigación:

Get-ADObject -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,objectSid,primaryGroupID,nTSecurityDescriptor -Server "dc-pdce.corp.example"

Los resultados pueden incluir grupos y equipos. Clasifíquelos por separado en vez de aplicar el procedimiento de cuentas de usuario a todos los objetos devueltos. Para la población de usuarios contemplada por las dos comprobaciones de EtcSec, utilice los parámetros documentados de Get-ADUser:

Get-ADUser -LDAPFilter "(adminCount=1)" -Properties adminCount,memberOf,Enabled,SID,primaryGroupID -Server "dc-pdce.corp.example"

Un valor memberOf vacío o aparentemente normal es una pista para investigar, no una prueba de que la cuenta sea huérfana. La página del esquema MemberOf describe los DN de los grupos; esta propiedad por sí sola no proporciona el análisis completo de protección requerido a continuación.

Este procedimiento detecta una condición del estado del directorio mediante consultas y revisión de ACL. No requiere un identificador de evento inventado ni considera una eliminación histórica de un grupo como prueba de que actualmente sea seguro modificar la cuenta.

Corrección: verificar y después modificar una cuenta (Remediation)

Paso 1 — Conservar el estado de la cuenta y del objeto superior

Para cada candidato, registre su DN, SID, estado habilitado, grupos directos, RID del grupo primario, responsable funcional, ACL completa y estado de herencia. Registre el DC y la hora de captura. Mantenga disponible un método aprobado de restauración de ACL; guardar una salida de texto aporta pruebas útiles, pero no permite afirmar que exista una copia de seguridad de AD restaurable.

La referencia de Microsoft Dsacls documenta cómo mostrar las entradas de acceso sin modificarlas. La salida predeterminada omite la información de propiedad y auditoría; /A incluye esos detalles al recopilar el registro de seguridad completo. Ejecute cada lectura por separado:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

dsacls "\\dc-pdce.corp.example\OU=Staff,DC=corp,DC=example"

Revise el objeto superior antes de permitir la herencia. Identifique qué derechos heredados deberían aparecer y qué ACE explícitas de la cuenta deben permanecer o revisarse por separado. Una ACL sospechosa lleva la cuenta a investigación, en lugar de a una limpieza automática.

Paso 2 — Resolver los grupos protegidos por SID

Utilice la referencia de SID de Microsoft para distinguir el identificador del dominio del RID. Resuelva todos los grupos protegidos del dominio correspondiente; los grupos de bosque requieren una cobertura adecuada del dominio raíz del bosque. Los nombres de grupos renombrados o localizados no son una comprobación de identidad suficiente.

Get-ADGroup acepta un SID para -Identity. El SID específico del dominio que aparece a continuación es un valor ilustrativo, no un grupo descubierto. También se muestra el SID del grupo integrado Administrators, con un servidor explícito para establecer el contexto del dominio:

Get-ADGroup -Identity "S-1-5-21-111111111-222222222-333333333-512" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Get-ADGroup -Identity "S-1-5-32-544" -Properties memberOf,groupType -Server "dc-pdce.corp.example"

Documente el SID y el DN resueltos para cada entrada de la lista protegida. Un fallo de búsqueda deja una laguna de cobertura. No equivale a confirmar que el grupo no contiene ningún miembro pertinente.

Paso 3 — Comprobar la pertenencia recursiva y el grupo primario

La documentación de Get-ADGroupMember incluye un ejemplo de pertenencia recursiva. Adáptelo a cada SID verificado de grupo protegido y compare los SID de usuario devueltos con el candidato:

Get-ADGroupMember -Identity "S-1-5-21-111111111-222222222-333333333-512" -Recursive -Server "dc-pdce.corp.example"

Repítalo para toda la lista protegida y los dominios pertinentes. Incluya las rutas a través de grupos de distribución. -Recursive devuelve los miembros de la jerarquía que no tienen objetos secundarios; no es una lista completa de las relaciones intermedias entre grupos. Microsoft también documenta una limitación con otros bosques cuando el bosque carece de Active Directory Web Service. Una enumeración fallida o incompleta debe dejar el veredicto indeterminado.

Compruebe el grupo primario por separado. La referencia Primary-Group-ID de Microsoft define el valor como el RID del grupo primario del usuario. La referencia del protocolo primaryGroupID confirma que memberOf del usuario y el atributo member del grupo primario omiten esta pertenencia. El colector revisado construye el SID del grupo primario a partir del SID del dominio y ese RID. Resuelva ese SID completo mediante Get-ADGroup; no deduzca la respuesta de un nombre descriptivo de grupo.

Después determine si el grupo primario está protegido directamente o llega a un grupo protegido mediante anidamiento. Esta adaptación documentada de Get-ADGroup lee el siguiente conjunto de objetos superiores:

Get-ADGroup -Identity "CN=PrimaryGroup,OU=Groups,DC=corp,DC=example" -Properties memberOf -Server "dc-pdce.corp.example"

Continúe revisando cada objeto superior con gestión de ciclos y cobertura de los dominios afectados. El ejemplo es una sola lectura, no un programa de recorrido completo y validado. Que un candidato no aparezca en la salida de miembros recursivos no exime de comprobar el grupo primario. Los miembros externos sin resolver, los dominios no consultados o los ciclos sin resolver impiden aprobar una escritura.

Paso 4 — Registrar la decisión antes de escribir

Las cuentas integradas Administrator y Krbtgt siguen protegidas aunque no exista una pertenencia directa que lo explique. El colector revisado las identifica por RID 500 y 502, incluso después de renombrarlas. Una cuenta deshabilitada que siga protegida corresponde a la primera fila, no a la de huérfanos. Para una cuenta huérfana deshabilitada confirmada, decida entre mantenimiento y retirada según la política de conservación; este procedimiento no la vuelve a habilitar automáticamente.

Paso 5 — Borrar solo el atributo residual confirmado

Set-ADObject documenta -Clear con el nombre para mostrar LDAP, además de -WhatIf y -Confirm. Primero previsualice el cambio individual:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -WhatIf

Solo después de la decisión y la revisión, ejecute la escritura confirmada independiente:

Set-ADObject -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Clear adminCount -Server "dc-pdce.corp.example" -Confirm

-Clear elimina el valor; no escribe el número cero. La orden no elimina pertenencias, no modifica ACE explícitas ni habilita la herencia. Una previsualización correcta tampoco demuestra que el candidato sea realmente huérfano.

Paso 6 — Habilitar la herencia y revisar la ACL resultante

La referencia de Dsacls define /P:N como permitir que el objeto herede los permisos del objeto superior. Aplíquelo únicamente al objeto aprobado, después de revisar el objeto superior:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example" /P:N

Compruebe el resultado de ejecución y repita inmediatamente la lectura de ACL del paso 1. Compare los derechos heredados con la referencia aprobada del objeto superior y revise las entradas explícitas de forma independiente. /P:N cambia la protección del objeto frente a la herencia; no cambia la capacidad de una ACE para heredarse. No lo sustituya por /S o /S /T: /S restaura la seguridad predeterminada del esquema del objeto, y /T amplía esa restauración al árbol solo cuando se utiliza con /S.

Validación después del siguiente ciclo de SDProp

Vuelva a leer la cuenta en el servidor registrado, con los parámetros de Get-ADUser documentados anteriormente:

Get-ADUser -Identity "CN=FormerAdmin,OU=Staff,DC=corp,DC=example" -Properties adminCount,memberOf,primaryGroupID,Enabled -Server "dc-pdce.corp.example"

Lea su ACL por separado:

dsacls "\\dc-pdce.corp.example\CN=FormerAdmin,OU=Staff,DC=corp,DC=example"

Repita también la resolución de pertenencias: pueden cambiar entre el inventario y el mantenimiento. Espere a una pasada posterior de SDProp conforme al intervalo realmente configurado y tenga en cuenta la replicación antes de comparar DC. Registre la hora de comprobación y los servidores, la ausencia del marcador residual, la herencia esperada, la revisión de ACE explícitas y una prueba real de la delegación prevista. Afirme «validado después del ciclo» solo cuando exista esa observación.

Si la protección reaparece, investigue una ruta de grupo restante, una incorporación reciente o una recopilación incompleta. Borrar el atributo repetidamente no es una solución. El Apéndice C de Microsoft proporciona un método opcional de laboratorio con Ldp.exe en el PDCE y el rootDSE RunProtectAdminGroupsTask=1. Prefiera el ciclo normal para este procedimiento de mantenimiento en producción y deje su frecuencia sin cambios. La operación FixUpInheritance del artículo histórico no debe sustituir automáticamente a esa tarea.

Nuestra guía sobre deriva del acceso privilegiado explica por qué las excepciones de grupos y ACL necesitan responsables y una nueva validación frente a los derechos efectivos. Aplique ese principio aquí: limpiar el marcador correctamente es un resultado de mantenimiento, mientras que demostrar que los permisos de la cuenta coinciden con su función prevista requiere la revisión más amplia de derechos.

Cómo detecta EtcSec esta situación

Las dos comprobaciones revisadas de etc-collector comparten el mismo predicado de cuenta huérfana basado en pertenencia directa o primaria, aplicado a distintas poblaciones de cuentas:

Los bloques de selección normalizados solo difieren en if u.Disabled frente a if !u.Disabled; los títulos, la gravedad y las recomendaciones también difieren. Son dos ramas de la misma comprobación según el estado de la cuenta, no mecanismos independientes que puedan sumarse como prueba de un riesgo mayor.

No se resuelven las pertenencias anidadas. Ninguna comprobación expande un grupo anidado en un grupo protegido, incluido un grupo primario que a su vez esté anidado. Esas cuentas pueden seguir protegidas y producir un falso candidato huérfano. La función auxiliar resuelve los DN de los grupos protegidos a partir de los sufijos SID del índice recopilado y después compara los DN directos; la falta de datos de grupos o SID también puede dejar un candidato sin explicación.

Ningún método Detect() lee la ACL de la cuenta ni su estado de herencia. Por tanto, un hallazgo no demuestra derechos residuales peligrosos, no prueba la ausencia de protección SDProp ni autoriza a borrar el atributo. Confírmelo mediante el procedimiento de pertenencias y ACL antes de realizar cambios. Tras el mantenimiento y la validación del directorio, vuelva a ejecutar la auditoría para comparar los hallazgos candidatos con el resultado registrado.