Triaje adminCount equipos AD: DC protegidos o hosts miembros

¿Qué es el triaje adminCount equipos AD?

El triaje adminCount equipos AD es el proceso de explicar por qué un objeto del directorio relacionado con una máquina lleva adminCount=1 antes de decidir si hace falta cambiar algo. Un controlador de dominio, una cuenta de servicio y un servidor miembro corriente pueden aparecer en la misma lista de candidatos y requerir decisiones muy distintas. El resultado útil es una clasificación respaldada por pruebas de identidad, pertenencia y permisos.

La referencia del esquema Admin-Count de Microsoft describe un atributo asociado a la protección de las ACL tras la pertenencia directa o transitiva a grupos administrativos. El marcador por sí solo no demuestra privilegios actuales, una ruta de ataque ni una ACL obsoleta. Trátelo como un motivo para investigar el objeto, no como una instrucción para borrar un valor.

Este procedimiento genera un registro para cada SID: protegido, excepción justificada, residuo plausible o indeterminado. Complementa nuestro procedimiento de limpieza de adminCount obsoleto en cuentas de usuario, que pide explícitamente clasificar los equipos y los grupos por separado. Sus comandos de limpieza de usuarios no deben convertirse en una receta de mantenimiento masivo de máquinas.

Cómo afecta la protección a los DC, los RODC y otros objetos

El apéndice C: cuentas y grupos protegidos de Microsoft incluye tanto Domain Controllers como Read-only Domain Controllers en la lista protegida. AdminSDHolder proporciona los permisos de la plantilla, y SDProp compara los permisos de los objetos protegidos con esa plantilla. Los objetos protegidos tienen la herencia deshabilitada; mover uno a otra OU no elimina su protección.

Por tanto, un DC o RODC verificado puede tener una explicación legítima para su protección. Determine su función real y sus pertenencias en lugar de tratar cada marcador de máquina como un acceso administrativo accidental. En una estación de trabajo miembro o un servidor de aplicaciones, investigue las rutas actuales de pertenencia a grupos y su finalidad empresarial. Ni el nombre de host ni su ubicación en una OU bastan para demostrar su función.

También importa la búsqueda de equipos del colector: utiliza (objectClass=computer). En la revisión examinada, el analizador reconoce explícitamente msDS-GroupManagedServiceAccount dentro de esa población. En consecuencia, un gMSA puede aparecer como un hallazgo Computer sin ser un host corriente. Confirme la clase estructural devuelta y el responsable del servicio; no le conceda una excepción general solo por ser una cuenta de servicio.

La explicación histórica de AdminSDHolder y SDProp de Microsoft documenta marcadores residuales y herencia deshabilitada después de que un usuario deje una pertenencia protegida. Esto explica por qué el residuo es una hipótesis que merece comprobarse. No demuestra que un equipo concreto sea huérfano, y su antigua lista de grupos protegidos no debe sustituir al apéndice C actual. El mismo artículo describe la protección mediante grupos de seguridad o distribución anidados, por lo que la investigación de pertenencias debe conservar esas rutas.

Detección: recopilar identidad y pruebas independientes del directorio

Empiece por Get-ADComputer, cuyos parámetros documentados incluyen -LDAPFilter, -SearchBase, -Server y -Properties. Esta adaptación solicita los atributos necesarios para investigar los equipos candidatos:

Get-ADComputer -LDAPFilter "(adminCount=1)" -SearchBase "DC=corp,DC=example" -Server "dc01.corp.example" -Properties adminCount,memberOf,primaryGroupID,PrimaryGroup,nTSecurityDescriptor,Enabled,SID,ObjectClass,userAccountControl

Esta consulta independiente conserva deliberadamente los resultados habilitados y deshabilitados para clasificarlos. El control EtcSec descrito más adelante selecciona únicamente entradas Computer habilitadas. Registre explícitamente el estado de habilitación al conciliar ambas poblaciones; una diferencia de alcance no implica necesariamente una discrepancia en el marcador.

Use el SID y el DN para relacionar el hallazgo con el objeto del directorio. Conserve también su GUID como identificador, su clase, el dominio y el servidor consultados, la hora de captura y cualquier lectura fallida. Mantenga las pruebas de atributos sin procesar, en lugar de solo un listado formateado en pantalla. Un resultado vacío con una base de búsqueda más limitada no resuelve un hallazgo recopilado en otro ámbito.

Para un candidato que pueda ser un gMSA, lea el DN exacto sin restringir la clase. Get-ADObject documenta la identidad mediante DN y las propiedades adicionales:

Get-ADObject -Identity "CN=svcInventory,CN=Managed Service Accounts,DC=corp,DC=example" -Server "dc01.corp.example" -Properties objectClass,objectSid,adminCount,memberOf,primaryGroupID,nTSecurityDescriptor,userAccountControl

Compare esa identidad con el hallazgo antes de elegir la vía de revisión de host o de cuenta de servicio. Una búsqueda específica de equipos que falle no debe descartar silenciosamente un objeto devuelto por el filtro de clase más amplio del colector.

Remediación: clasificar cada objeto antes de aprobar cambios (Remediation)

Paso 1 — Establecer la referencia de grupos protegidos

Resuelva los grupos aplicables del apéndice C en los dominios pertinentes y en la raíz del bosque, y registre sus SID y DN. Los nombres pueden cambiar o estar localizados. La referencia de SID de Microsoft explica los identificadores de dominio y los identificadores relativos; use identidades de grupo verificadas en lugar de comparar solo los nombres.

Get-ADGroup acepta un SID para -Identity y admite propiedades adicionales. Esta adaptación documentada lee el grupo integrado Administrators en un contexto de dominio explícito:

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

Repita la operación con los grupos protegidos aplicables usando sus SID verificados. Este ejemplo es una única consulta, no un inventario completo de grupos protegidos. Separe las cuentas directamente protegidas de los grupos de pertenencia y registre las excepciones pertinentes de configuración del dominio. Un grupo de referencia sin resolver deja la investigación incompleta.

Paso 2 — Resolver las pertenencias más allá de la primera vista

Get-ADPrincipalGroupMembership admite equipos, grupos y cuentas de servicio. El SID de ejemplo es un valor que debe sustituirse por el SID verificado del candidato:

Get-ADPrincipalGroupMembership -Identity "S-1-5-21-111111111-222222222-333333333-1101" -Server "dc01.corp.example"

Microsoft documenta que la búsqueda de grupos requiere un catálogo global y que los grupos locales de otro dominio requieren el contexto de recurso apropiado. Registre los errores no terminantes como fallos de resolución de pertenencias, en lugar de aceptar una salida parcial como un resultado sin problemas. Consulte los dominios de recursos pertinentes cuando el objeto tenga pertenencias en ellos.

Use los grupos devueltos y las pruebas memberOf del objeto como puntos de partida. Para cada grupo, lea sus grupos superiores con Get-ADGroup -Properties memberOf,groupType y continúe hasta que las rutas terminen o alcancen el conjunto protegido verificado. Conserve las identidades intermedias, gestione los ciclos y cubra los dominios implicados. Aquí no se presenta una sola invocación de cmdlet como un recorrido transitivo completo y validado.

Paso 3 — Resolver el grupo principal por separado

La referencia de protocolo primaryGroupID de Microsoft explica que la pertenencia principal se omite de memberOf en el objeto y de la lista member ordinaria del grupo. La documentación de Get-ADComputer también muestra PrimaryGroup y primaryGroupID en su salida de equipos.

Vuelva a leer un equipo verificado y resuelva de forma independiente el DN de su grupo principal:

$machine = Get-ADComputer -Identity "CN=APP01,OU=Servers,DC=corp,DC=example" -Server "dc01.corp.example" -Properties PrimaryGroup,primaryGroupID,memberOf,adminCount,nTSecurityDescriptor

Get-ADGroup -Identity $machine.PrimaryGroup -Server "dc01.corp.example" -Properties memberOf,groupType

Ejecute la segunda lectura solo si PrimaryGroup se ha resuelto correctamente. Si solo está disponible el RID, construya el SID del grupo principal a partir del SID verificado del dominio de la cuenta y de ese RID, y luego resuelva el SID completo. No lo sustituya por el SID completo del equipo ni suponga un grupo principal esperado a partir de la función de la máquina. Revise también las rutas de los grupos superiores del grupo principal. Las pruebas ausentes o contradictorias mantienen el caso indeterminado.

Paso 4 — Examinar los permisos del objeto y de su contenedor superior

Conserve el descriptor de seguridad y revise la herencia, la propiedad y las ACE explícitas. Compare el objeto con su función prevista y con la referencia de su contenedor superior. La protección de permisos puede ser legítima; a la inversa, un marcador conocido no explica una concesión explícita sospechosa.

La referencia de Dsacls de Microsoft documenta la visualización de la ACL y el uso de /A para añadir información de propiedad y auditoría. Son operaciones de lectura independientes:

dsacls "\\dc01.corp.example\CN=APP01,OU=Servers,DC=corp,DC=example" /A

dsacls "\\dc01.corp.example\OU=Servers,DC=corp,DC=example" /A

Un fallo de acceso significa que las pruebas solicitadas no están disponibles. Una captura de texto es un artefacto de investigación, no una garantía de copia de seguridad restaurable. Establezca el método de restauración aprobado antes de cualquier mantenimiento posterior de ACL.

Nuestra revisión de derechos, delegación y grupos peligrosos de los objetos de equipo explica la superficie de ataque más amplia de las máquinas. Esas exposiciones requieren sus propias pruebas: adminCount=1 por sí solo no demuestra ninguna. Mantenga diferenciadas la ACL del objeto, sus pertenencias y los derechos que posee en otros ámbitos dentro del registro de revisión.

Paso 5 — Registrar la decisión y validar el resultado previsto

Una excepción justificada es una decisión empresarial; no convierte un objeto protegido en uno sin protección. Un residuo plausible es una clasificación de investigación, no una autorización para limpiar. Canalice cualquier cambio propuesto de pertenencia o ACL a través del responsable de la máquina o del servicio, con la referencia capturada y los permisos finales esperados.

Tras un mantenimiento aprobado, repita las lecturas de identidad, pertenencia y ACL en los servidores registrados. Tenga en cuenta la replicación del directorio y, cuando se aplique la protección, observe el resultado posterior de SDProp según la programación configurada. Registre el éxito o el fallo y pruebe el comportamiento previsto de administración o del servicio. No borre repetidamente un marcador para ocultar un resultado sin explicar.

Cómo detecta EtcSec este caso

En la revisión del colector 9f698083354a1cb7f625df5cb490a515823c3257, el control COMPUTER_ADMIN_COUNT examinado recorre las entradas Computer recopiladas, omite las deshabilitadas y selecciona aquellas cuyo booleano AdminCount es verdadero. Emite un hallazgo Info con el número seleccionado; los detalles de las entidades afectadas solo se incluyen cuando se han solicitado los detalles y existen candidatos.

El analizador LDAP solo establece ese booleano como verdadero cuando el valor adminCount devuelto es igual a 1. Un valor ausente o distinto de 1 pasa a ser falso en esa representación. El control no excluye DC, RODC ni gMSA, no resuelve pertenencias directas, transitivas o al grupo principal, ni examina ACL. Por tanto, proporciona candidatos para clasificar, en lugar de un veredicto de protección obsoleta o privilegios peligrosos.

El proveedor de equipos no solicita primaryGroupID ni nTSecurityDescriptor en su lista de atributos predeterminada. Su ausencia en esta recopilación no debe interpretarse como ausencia de grupos o derechos. BaseDN y MaxComputers limitan la población recopilada; un error de GetComputers detiene la recopilación. El detector sigue devolviendo un hallazgo Info con un recuento de cero cuando no tiene candidatos seleccionados, por lo que la presencia del tipo de hallazgo por sí sola no demuestra una coincidencia.

Concilie el alcance de la auditoría y las identidades de los candidatos con las lecturas independientes anteriores. Use el registro de clasificación para explicar la protección legítima, escalar los hosts sin resolver y conservar la incertidumbre. Repetir la auditoría permite comparar la lista de candidatos dentro del alcance con ese registro, pero no sustituye la resolución de pertenencias ni la validación de permisos.