¿En qué consiste un control AD de equipos en OU de servidores?
Un control AD de equipos en OU de servidores comprueba si la ubicación de un equipo en el directorio corresponde a su función real y a las directivas que debe recibir. Un equipo habilitado que parece una estación de trabajo dentro de una OU cuyo nombre sugiere servidores merece una revisión. Su ubicación por sí sola no demuestra un fallo de directivas, un incidente de seguridad ni una infracción de cumplimiento.
La pregunta útil es concreta: ¿cambiaría el traslado de este equipo el resultado de directivas previsto y puede su responsable demostrar que el cambio es adecuado? Empiece por la función real del dispositivo y la convención de OU de la organización. Después conserve el resultado actual de directivas del equipo, revise el destino propuesto y pruebe un piloto aprobado antes de ampliar el cambio.
Esta guía aborda una señal de clasificación de WORKSTATION_IN_SERVER_OU. No introduce una estructura universal de OU. Una jerarquía compartida, un nombre heredado o un dispositivo con una función especial documentada pueden explicar un hallazgo. La revisión debe producir una decisión de ubicación con un responsable identificado y pruebas de directivas que la respalden, incluida la decisión de conservar la ubicación actual cuando esté justificada.
Relación entre la ubicación y el ámbito de las directivas
La referencia de Microsoft sobre el procesamiento de directivas de grupo describe el procesamiento local, de sitio, de dominio y de OU, incluidas las OU superiores. El orden de los vínculos, su aplicación forzada, la herencia bloqueada, las secciones deshabilitadas, el filtrado de seguridad y el filtrado WMI afectan al resultado. La forma en que se escribe el nombre de una OU no es un ajuste de directiva.
Prepare una comparación entre origen y destino en GPMC. Registre los vínculos y la herencia pertinentes de cada ubicación y, después, identifique los ajustes que el responsable del dispositivo espera conservar, obtener o perder. Use las identidades de las directivas además de sus nombres para mostrar, de modo que las GPO con nombres similares no se confundan en el registro del cambio. Resuelva las diferencias sin explicación antes de programar el piloto.
Para la capa de permisos, lea nuestra guía sobre Read para equipos, Apply dirigido y filtrado de seguridad GPO. Read y Apply Group Policy son distintos; la recuperación por parte del equipo y el conjunto de destinatarios previsto para la aplicación requieren comprobaciones separadas. Esa guía respalda la revisión del ámbito que se presenta aquí. No demuestra que el nombre de una OU haya provocado un fallo.
Cuando la experiencia del usuario dependa del equipo, revise también el procesamiento de bucle invertido, o loopback. La referencia de procesamiento de Microsoft distingue Merge, que añade la lista de directivas de usuario basada en el equipo, de Replace, que usa esa lista en su lugar. Registre el modo configurado e incluya pruebas de usuarios representativas cuando proceda. Un resultado exclusivo del equipo no puede responder a todas las preguntas sobre las sesiones de usuario.
Existe además un problema independiente de contenedores predeterminados. Nuestra guía sobre CN=Computers, la redirección y los resultados de directivas del cliente explica que el contenedor predeterminado no puede tener un vínculo GPO directo como una OU. Redirigir las creaciones futuras, reubicar los objetos existentes y validar los resultados de los clientes son tareas distintas. Un objeto que ya está dentro de una OU llamada Servers no requiere automáticamente ese procedimiento de redirección.
Detección: identificar el dispositivo y conservar su resultado
1. Confirmar las entradas del hallazgo
Para cada candidato, conserve el nombre distintivo, sAMAccountName, el atributo de directorio operatingSystem, el estado habilitado, la hora de recopilación y el ámbito de recopilación. Identifique qué parte del DN coincidió con el patrón de nombre de servidor. Una coincidencia en un antecesor tiene una explicación administrativa distinta de una coincidencia en el elemento superior inmediato, aunque el detector acepta ambas.
Pida al responsable del dispositivo que verifique su función actual y su sistema operativo mediante el inventario fiable de dispositivos de la organización o una comprobación autorizada del dispositivo. Concilie las discrepancias con los atributos del directorio. Un prefijo de nombre es una pista para investigar; no constituye una prueba independiente de que el host sea actualmente un equipo de escritorio ni de que deba trasladarse.
Use esta matriz de revisión para separar las pruebas:
| Entrada de la revisión | Qué respalda | Siguiente pregunta |
|---|---|---|
| Subcadena coincidente del DN | Por qué la heurística del nombre de OU seleccionó el objeto | ¿La OU coincidente es su elemento superior inmediato o un antecesor, y qué significa ese nombre localmente? |
| Prefijo de nombre de cuenta o cadena de SO coincidentes | Por qué lo seleccionó la heurística de estación de trabajo | ¿Cuál es la función actual aprobada del dispositivo? |
| Revisión de directivas de origen y destino | Una diferencia de directivas propuesta | ¿Aprueba el responsable esa diferencia? |
| Informe RSoP del equipo | Un resultado de procesamiento registrado | ¿Contiene los ajustes de equipo previstos? |
| Comprobaciones de ajustes y servicios después del piloto | Pruebas frente a los criterios de aceptación del piloto | ¿Puede continuar el cambio o debe revertirse? |
2. Capturar el RSoP del equipo antes de cambiar su ubicación
Microsoft documenta Get-GPResultantSetOfPolicy como un cmdlet que escribe información RSoP en un archivo. Su sintaxis acepta Computer, ReportType y Path. El siguiente ejemplo para el lector adapta esos parámetros documentados a una estación de trabajo ficticia y a un nombre de archivo de referencia:
Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-before.xml'
Use el nombre verificado del dispositivo, un directorio disponible para los informes y una cuenta autorizada en su entorno. La guía de Microsoft sobre los resultados de directivas de grupo documenta el acceso remoto mediante el permiso delegado Remotely access Group Policy Results data en el dominio o la OU que contiene el objeto, o mediante la pertenencia al grupo Administrators local del equipo de destino. Verifique también la conectividad de red con el destino. Conserve el informe junto con la identidad del objeto, el DN original, la hora de captura y el registro de revisión. Examine el contexto de registro devuelto y la sección de equipo del informe para confirmar que las pruebas corresponden al dispositivo previsto. Una consulta fallida deja el resultado desconocido; no es una referencia vacía obtenida correctamente.
El cmdlet devuelve resultados de registro. Microsoft remite a los administradores a GPMC para el modelado RSoP. Por tanto, este informe registra el procesamiento observado en lugar de predecir el resultado en el destino. Compárelo con la referencia aprobada y enumere las diferencias pendientes antes de plantearse un traslado. Cuando un ajuste rija un servicio o una protección, planifique también una comprobación operativa correspondiente.
Remediación: validar un piloto antes de trasladar más hosts (Remediation)
1. Elegir una decisión documentada
Clasifique al candidato revisado como una excepción aprobada, una discrepancia de clasificación o un cambio de ubicación que requiere validación. Registre el responsable, la explicación y las pruebas. Conservar un objeto puede ser el resultado correcto si su función y las directivas previstas ya se satisfacen. Cambiar el nombre de un dispositivo o una OU únicamente para eliminar la coincidencia heurística no aporta pruebas de que haya mejorado su resultado de directivas.
Para un traslado propuesto, documente el DN de origen, el destino aprobado, la diferencia de directivas esperada, el dispositivo piloto, los criterios de aceptación y el responsable de la reversión. Confirme que el cambio afecta al mismo dominio y al equipo seleccionado. Una migración entre dominios requiere su propio procedimiento revisado; queda fuera del ejemplo de ubicación de un único equipo que se presenta aquí.
2. Revisar la operación individual del directorio
La referencia de Microsoft de Move-ADObject documenta Identity, TargetPath, WhatIf y Confirm. El siguiente ejemplo sustituye en esa sintaxis un DN de equipo ficticio y una OU aprobada ficticia:
Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -WhatIf
-WhatIf muestra una vista previa de la operación. No mueve el objeto ni simula el procesamiento de GPO. Revise el origen y el destino resueltos antes de continuar. Nunca envíe todos los hallazgos por una canalización a una operación de traslado: el predicado no conoce la decisión del responsable, la idoneidad del destino ni el plan de mantenimiento aprobado.
Después de la validación y la autorización, la operación piloto individual puede usar los mismos parámetros documentados con confirmación:
Move-ADObject -Identity 'CN=PC01,OU=Servers,DC=contoso,DC=com' -TargetPath 'OU=Workstations,DC=contoso,DC=com' -Confirm
Sustituya cada identificador de ejemplo por los valores revisados. La confirmación es una solicitud de ejecución; no sustituye la aprobación de la organización ni valida el diseño de las directivas. Son ejemplos documentados para el lector, no comandos ejecutados contra un dominio AD para este artículo.
3. Comparar el resultado después del piloto
Verifique la nueva ubicación en el directorio y complete el procesamiento de directivas que exige el plan de pruebas aprobado. La referencia de procesamiento de Microsoft distingue el inicio, el inicio de sesión y la actualización en segundo plano; esta última no procesa todas las extensiones. Registre el contexto de procesamiento antes de interpretar un informe recopilado después del traslado.
Capture un resultado separado para el mismo equipo con los parámetros RSoP documentados:
Get-GPResultantSetOfPolicy -Computer 'pc01.contoso.com' -ReportType Xml -Path 'C:\Reports\pc01-after.xml'
Compare los dos informes conservados con los cambios previstos y, después, compruebe los ajustes pertinentes y los criterios de aceptación operativos. Cuando el loopback sea relevante, incluya las comparaciones aprobadas de sesiones de usuario. Investigue las adiciones, omisiones o fallos inesperados antes de ampliar el piloto. Use el procedimiento de reversión registrado si no se cumplen los criterios de aceptación y verifique su resultado, en vez de suponer que restaurar el DN restaura todos los ajustes.
Cierre la revisión con la decisión, las pruebas y las excepciones pendientes. Un hallazgo eliminado puede confirmar que el directorio ya no coincide con esta heurística. Los informes de directivas y las comprobaciones operativas determinan si se ha logrado el resultado previsto. No combine estos criterios de finalización en un único estado verde.
Cómo detecta EtcSec este caso
Esta sección describe únicamente WORKSTATION_IN_SERVER_OU, revisado en el commit de etc-collector 20268a321609c193b79c5da6764f3f56950449cb, en public/internal/audit/detectors/ad/computers/organization/workstation-in-server-ou.go:37.
El detector omite los equipos marcados como Disabled. Para los equipos restantes proporcionados, busca en todo el DN los patrones no anclados y sin distinción entre mayúsculas y minúsculas ou=server y ou=datacenter. Estos patrones pueden coincidir con un antecesor y con prefijos como OU=Serverless; no analizan un nombre exacto de OU superior inmediata.
Un objeto seleccionado se clasifica como estación de trabajo si su sAMAccountName empieza, sin distinguir mayúsculas y minúsculas, por ws, pc, laptop, desktop o nb, o si su cadena de SO contiene Windows 10, Windows 11, Windows 7 o Windows 8. Cualquiera de las dos vías basta. Por ejemplo, un prefijo coincidente puede seleccionar un objeto sin una cadena de SO de estación de trabajo coincidente. Son pruebas de cadenas, no una comprobación en vivo de la función del dispositivo.
El proveedor LDAP en public/internal/providers/ldap/client.go:515 proporciona objetos de equipo, y parser.go:220–278 lee el DN, el nombre de cuenta, el sistema operativo y el control de cuenta de usuario en el modelo de equipo. El estado deshabilitado se deriva del control de cuenta de usuario. Los valores configurados BaseDN y MaxComputers limitan el inventario; un recuento cero debe interpretarse dentro del ámbito real de recopilación.
El hallazgo es informativo. El comentario del código identifica explícitamente una heurística del producto sin un estándar de nomenclatura de un proveedor ni reglamentario, y no registra una activación confirmada en laboratorio ni una validación de introducción y reversión. La descripción del hallazgo afirma un efecto GPO incorrecto, pero el predicado revisado no lee la función real ni un informe de directivas resultantes y no puede sustentar esa afirmación causal.
Use el hallazgo para seleccionar una revisión documentada. Confirme la función y la convención local, evalúe la ruta de las directivas y conserve pruebas de antes y después para cualquier traslado aprobado. Aquí no se afirma que se haya realizado con éxito un piloto AD, una corrección de directivas ni un resultado de laboratorio.
Explore las páginas de identidad que apoyan este tema

