redircmp redirusr contenedores predeterminados GPO: guía AD

¿Qué son los contenedores predeterminados en Active Directory?

La cuestión práctica detrás de redircmp redirusr contenedores predeterminados GPO es dónde se crean las nuevas identidades y si esa ubicación pertenece a la estructura de directivas prevista. Active Directory proporciona CN=Computers y CN=Users al instalar el dominio. Son contenedores, no unidades organizativas. La guía de Microsoft sobre redirección de contenedores explica su función predeterminada, mientras que su introducción a las directivas de grupo identifica la OU como el nivel más bajo de AD al que se puede asignar una directiva de grupo.

No se puede vincular una GPO directamente a estos contenedores predeterminados. Eso no significa que sus equipos y usuarios no reciban ninguna directiva de grupo: las GPO vinculadas al sitio y al dominio pueden seguir aplicándose, y la directiva local sigue siendo relevante. La carencia es más específica. Un objeto en CN=Computers queda fuera del subárbol de una directiva vinculada únicamente a la OU de estaciones de trabajo o servidores. La referencia de Redircmp de Microsoft confirma la ausencia de un vínculo directo de directiva de grupo al contenedor predeterminado. Las reglas de ámbito de sitio, dominio y OU se documentan en la introducción a las directivas de grupo citada anteriormente.

Esta guía separa cuatro preguntas: dónde residen actualmente los objetos, dónde los situará la futura creación predeterminada, qué directivas llegan realmente al cliente y qué cuentas de equipo necesitan una revisión del aprovisionamiento. Un hallazgo sobre el contenedor predeterminado responde a la primera pregunta. La redirección aborda la segunda. Ninguno establece el estado de LAPS del cliente ni la seguridad de una cuenta de máquina preparada de antemano.

Funcionamiento: el destino y el ámbito de las directivas son independientes

La creación predeterminada sigue una referencia del directorio

Microsoft documenta los destinos predeterminados en el atributo wellKnownObjects del dominio. Las API de creación antiguas consultan estas referencias para usuarios, grupos y equipos. Las utilidades de redirección cambian esas referencias a OU elegidas por el administrador; no convierten los contenedores originales en OU. Los nuevos objetos creados mediante las rutas predeterminadas afectadas utilizan después el nuevo destino. KB324949 describe tanto las referencias como las operaciones que dependen de ellas.

Un flujo de unión también puede indicar explícitamente un destino. La referencia de netdom join documenta /ou e indica que la creación de la cuenta utiliza el destino de equipos predeterminado del dominio cuando se omite esa opción. En una instalación estándar sin redirección, ese destino es CN=Computers; tras la redirección puede ser la OU designada. Reutilizar una cuenta existente para una unión es otro caso. Por tanto, evite suponer que cada unión crea necesariamente un objeto nuevo en el contenedor predeterminado.

Para los usuarios, redirusr afecta a la ubicación de creación predeterminada de usuarios, grupos y cuentas de usuario de confianza creados mediante las API documentadas. La ubicación de un grupo no significa que el propio grupo procese la configuración de usuario como un usuario con sesión iniciada. Distinga el inventario de cuentas del procesamiento de directivas y conserve las cuentas predeterminadas, salvo que un cambio revisado por separado requiera lo contrario. S1 describe el conjunto más amplio de objetos afectados por el destino Users.

La ubicación en una OU crea una ruta elegible, no un control completado

El ámbito de las directivas de grupo sigue los vínculos en sitios, dominios y OU, incluida la jerarquía pertinente de OU superiores. Mover un equipo a la OU prevista puede situarlo bajo esa jerarquía, pero sigue siendo necesario validar el procesamiento y los ajustes previstos. La introducción de Microsoft describe el ámbito basado en la ubicación y el procesamiento del lado del cliente.

Nuestra guía de filtrado de seguridad de GPO aborda la siguiente capa: ámbito de los vínculos, permiso Read del equipo, permiso Apply del usuario y diferencia entre permitir la recuperación y ampliar el público destinatario. Explica que la ubicación correcta y una directiva vinculada no bastan sin los permisos y las condiciones de procesamiento necesarios. Realice esa revisión después de corregir la ubicación.

LAPS añade sus propios requisitos de implementación. El procedimiento de Windows LAPS con respaldo en AD de Microsoft distingue el permiso de escritura del dispositivo, el permiso de recuperación de contraseñas, la directiva del dispositivo y la verificación de actualizaciones del directorio. Por ello, un equipo fuera de una OU que sea la única fuente de su directiva LAPS puede tener un problema de cobertura; un equipo que reciba una directiva equivalente por otra vía compatible puede no tenerlo.

La guía relacionada sobre brechas de cobertura de LAPS examina la implementación parcial, el almacenamiento heredado, los derechos excesivos de recuperación y las pruebas necesarias para validar la rotación. Proporciona la revisión posterior cuando la ubicación revela una posible brecha. Contar los equipos en CN=Computers no mide los equipos sin LAPS.

Medir la ubicación antes de cambiar los destinos predeterminados

1. Inventariar los equipos del contenedor predeterminado

Utilice un dominio definido y registre la base de búsqueda, la hora de recopilación, el estado habilitado y los identificadores de objeto. El siguiente ejemplo para el lector adapta los parámetros documentados Filter, SearchBase, SearchScope y Properties de Get-ADComputer. Los nombres de dominio y de objeto usados en toda esta guía son valores ficticios de ejemplo.

Get-ADComputer -Filter * -SearchBase 'CN=Computers,DC=contoso,DC=com' -SearchScope OneLevel -Properties Enabled,userAccountControl

El objetivo es enumerar los objetos secundarios directos para revisar su ubicación. Esta consulta incluye cuentas deshabilitadas, mientras que el detector de ubicación de EtcSec revisado las excluye. Mantenga separadas esas poblaciones al comparar resultados. Un inventario administrativo y el recuento de un detector no tienen por qué coincidir, porque sus predicados difieren.

El recuento de un contenedor mide la ubicación en el directorio, no la cobertura de protección. Decida qué objetos pertenecen a producción, cuáles son cuentas de preparación aprobadas y cuáles necesitan investigación. Para cada objeto, registre el destino propuesto y su responsable. Son decisiones de revisión; el comando proporciona datos del directorio, no una evaluación de la protección del endpoint.

2. Inventariar usuarios sin tratar el contenedor como una única clase de cuentas

El siguiente ejemplo sustituye la base del patrón documentado de búsqueda en contenedores por el contenedor Users predeterminado y solicita el estado habilitado mediante Properties. Get-ADUser documenta ambos parámetros:

Get-ADUser -Filter * -SearchBase 'CN=Users,DC=contoso,DC=com' -Properties Enabled

Esto recupera usuarios, no un inventario completo de todos los grupos y objetos especiales del contenedor. La guía de redirección de Microsoft trata específicamente los grupos predeterminados y las cuentas de usuario de confianza. Antes de migrar, distinga los usuarios ordinarios de las cuentas integradas o dependientes de aplicaciones y determine qué objetos deben permanecer en su ubicación.

Revise conjuntamente el origen y el destino. Un usuario movido a otra OU puede entrar en una jerarquía diferente de directivas de usuario, igual que un equipo puede entrar en otra jerarquía de directivas de equipo. Utilice el modelo de ámbito de las directivas de grupo para identificar el cambio esperado antes de mover el objeto, en lugar de considerar una vista más ordenada del directorio como criterio de finalización.

3. Revisar por separado la señal de aprovisionamiento de cuentas de máquina

Un equipo puede estar preparado en una OU apropiada y aun así requerir revisión. A la inversa, un equipo activo en el contenedor predeterminado no tiene por qué coincidir con la señal de preparación. Para obtener el atributo subyacente, este ejemplo utiliza el parámetro Properties documentado de Get-ADComputer:

Get-ADComputer -Filter * -Properties userAccountControl

La referencia de UserAccountControl de Microsoft asigna a PASSWD_NOTREQD el valor 0x20 y a WORKSTATION_TRUST_ACCOUNT el valor 0x1000. El colector los combina en 0x1020, decimal 4128, y comprueba si están presentes ambos bits. El predicado exacto se explica más adelante; no lo sustituya por una prueba de igualdad sobre el atributo completo.

Para las cuentas coincidentes, pregunte quién creó el objeto, a qué solicitud de aprovisionamiento responde, si la máquina prevista se ha unido y qué pruebas independientes de actividad existen. Establezca un plazo local de revisión con el propietario de la cuenta. El detector no proporciona un umbral de antigüedad ni un historial verificado de unión, por lo que ninguno debe incluirse en un resultado presentado como resultado del detector.

Detección: correlacionar señales del directorio con resultados del cliente

Un objeto mal ubicado es candidato a una revisión del ámbito

Trate la ubicación como una señal para investigar la relación de directiva prevista. Registre las GPO de referencia esperadas para el equipo, las ubicaciones de sus vínculos y los resultados reales del cliente. La documentación de gpresult define los informes del conjunto resultante de directivas y los modificadores de ámbito de equipo y resumen utilizados aquí:

gpresult /scope computer /r

Ejecute la comprobación documentada para el lector en el equipo afectado con el acceso adecuado. Compare las GPO aplicadas con la referencia esperada y después verifique los ajustes relevantes. Un informe que muestra la aplicación de una directiva es una prueba distinta de una copia de seguridad LAPS correcta o del estado efectivo de un ajuste de auditoría. Este artículo no afirma haber obtenido resultados de un dominio real.

Para Windows LAPS nativo con respaldo en AD, el procedimiento de implementación de Microsoft identifica el evento 10018 como prueba de que una nueva contraseña se actualizó correctamente en AD. Utilícelo como comprobación de resultado independiente cuando esa implementación sea aplicable. La ausencia de un evento exige investigar los tiempos y los registros disponibles; no es una prueba deducida del DN del objeto.

Las contraseñas predeterminadas históricas requieren contexto de versión

La creación previa puede ser un flujo legítimo. La guía de Microsoft sobre permisos de unión al dominio describe un administrador creando una cuenta de equipo y otra identidad autorizada reutilizándola. Una cuenta preparada merece gestión de su ciclo de vida, pero la preparación por sí sola no establece un compromiso.

Existe un riesgo histórico distinto. La referencia de NetProvisionComputerAccount documenta una opción explícita que utiliza el nombre de máquina en minúsculas como contraseña inicial y recomienda evitarla cuando sea posible. Esto describe un modo concreto de aprovisionamiento. La máscara UAC no lee el secreto y no puede establecer que se usó esa opción, que una contraseña está vacía o es predecible, o que una autenticación tuvo éxito.

La versión importa. Los cambios de Windows Server 2025 documentados por Microsoft describen contraseñas iniciales de cuentas de equipo generadas aleatoriamente, controles que rechazan valores predeterminados derivados del nombre y la eliminación en ADUC/ADAC de la posibilidad de crear cuentas anteriores a Windows 2000. La directiva documentada es Domain controller: Refuse setting default machine account password. Compruebe las versiones de los controladores de dominio, las herramientas de creación y esta directiva antes de aplicar el modelo histórico a las cuentas actuales. Una identidad abandonada sigue necesitando un propietario y una decisión de ciclo de vida aunque su secreto inicial fuera aleatorio.

Remediación: redirigir las creaciones futuras y migrar objetos existentes (Remediation)

1. Diseñar las OU de destino y sus responsabilidades

Elija las OU de destino según los requisitos de administración y directivas. Decida si la creación predeterminada debe llegar a una OU de preparación o a la jerarquía final de producción y documente quién completa la transición. Una OU llamada «Staging» solo resulta útil cuando su directiva prevista y su equipo responsable están claros. La introducción a las directivas de grupo trata el equilibrio entre delegación y requisitos de directivas.

Los siguientes comandos adaptan el ejemplo 1 de New-ADOrganizationalUnit, sustituyendo dos nombres de destino y el dominio ficticio. El ejemplo documentado crea una OU con la protección contra eliminación accidental activada implícitamente. Cada operación se muestra por separado:

New-ADOrganizationalUnit -Name 'MyComputers' -Path 'DC=contoso,DC=com'

New-ADOrganizationalUnit -Name 'MyUsers' -Path 'DC=contoso,DC=com'

Prepare las directivas y la delegación previstas antes de utilizar estas OU como destinos predeterminados. Crear la OU es una operación de gestión de objetos; no vincula una GPO, no autoriza el aprovisionamiento ni establece que un dispositivo haya procesado una configuración de referencia.

2. Verificar los requisitos previos de redirección

KB324949 exige un nivel funcional de dominio Windows Server 2003 o superior, una OU de destino existente, credenciales de administrador del dominio y un PDC accesible. Compruebe la configuración real del dominio en lugar de deducir el nivel funcional del sistema operativo de un único servidor.

La antigua página de Redircmp enumera versiones históricas de niveles funcionales. Para este procedimiento, utilice el requisito «2003 o superior» de la KB actual. La referencia de Redircmp también exige un símbolo del sistema con privilegios elevados. Elevar el nivel funcional del dominio, si fuera necesario, es una decisión de compatibilidad independiente; no debe presentarse como un paso accesorio en un artículo sobre ubicación de objetos.

3. Cambiar independientemente los destinos predeterminados de equipos y usuarios

Los dos comandos siguientes reproducen los ejemplos de Microsoft de S1, omitiendo el prefijo del símbolo del sistema. Cada comando cambia un destino predeterminado distinto:

redircmp ou=mycomputers,DC=contoso,dc=com

redirusr ou=myusers,DC=contoso,dc=com

La sintaxis genérica documentada es redircmp container-dn y c:\windows\system32\redirusr container-dn. El argumento es el nombre distinguido de la OU de destino. Sustituya el destino aprobado; un comando correcto aborda la creación futura mediante las rutas predeterminadas afectadas.

Ninguna de las dos utilidades mueve los objetos existentes. Trate la ubicación futura y la existente como tareas separadas. El aprovisionamiento con una OU explícita y la reutilización de cuentas también necesitan validación propia, en lugar de deducirse del nuevo destino predeterminado.

4. Migrar los objetos existentes seleccionados con una revisión de directivas

Evalúe las dependencias de aplicaciones, la finalidad de la cuenta y el cambio esperado de directivas antes de seleccionar cada objeto. El siguiente comando adapta la sintaxis documentada Identity y TargetPath de Move-ADObject a un equipo existente ficticio:

Move-ADObject -Identity 'CN=PC01,CN=Computers,DC=contoso,DC=com' -TargetPath 'OU=MyComputers,DC=contoso,DC=com'

Seleccione los objetos reales mediante un inventario revisado. No realice un movimiento masivo indiscriminado de todo lo que haya en CN=Users o CN=Computers. La KB de redirección trata la compatibilidad con versiones anteriores y las cuentas predeterminadas; la introducción a las directivas de grupo explica la herencia que hace que un cambio de destino sea operativamente significativo.

Tras el movimiento, confirme la nueva ubicación del objeto y repita la revisión de directivas del cliente. Cierre la tarea de ubicación con pruebas del directorio y cierre cualquier brecha de protección con pruebas de esa protección. Son comprobaciones relacionadas con criterios de finalización distintos.

5. Delegar deliberadamente la creación, la reutilización y la gestión de directivas

La guía de delegación de control de Microsoft separa tareas como unir equipos, gestionar usuarios y gestionar vínculos GPO. Delegue las tareas necesarias en el ámbito adecuado. Cambiar un destino predeterminado no concede a la identidad que realiza la unión permiso para crear o reutilizar cuentas allí.

Para las cuentas de equipo reutilizadas, revise el propietario y los permisos requeridos según el procedimiento de permisos de unión al dominio. Diagnostique una unión fallida dentro de esos requisitos. No amplíe la pertenencia administrativa ni eluda las comprobaciones de propiedad solo para hacer funcionar un flujo recién redirigido.

Para Windows LAPS nativo con respaldo en AD, el procedimiento de implementación documenta el permiso del dispositivo para actualizarse a sí mismo. Este ejemplo sustituye la OU de equipos aprobada en ese comando:

Set-LapsADComputerSelfPermission -Identity 'OU=MyComputers,DC=contoso,DC=com'

Esto no configura la directiva LAPS ni establece derechos de recuperación de contraseñas. Valide por separado la directiva prevista y una actualización correcta del cliente. Revise también la población autorizada para la recuperación; situar un equipo en el ámbito de una directiva no resuelve un acceso excesivo de recuperación.

6. Revisar cuentas preparadas y probar los flujos futuros

Para cada candidato de preparación, conserve la finalidad empresarial, el propietario, la herramienta de aprovisionamiento y las pruebas que justifican su uso continuado. Determine si la cuenta debe completar el aprovisionamiento, permanecer en un proceso de preparación aprobado o entrar en el procedimiento de retirada de la organización. No se deduce ningún umbral universal de antigüedad ni regla automática de eliminación de la máscara UAC.

Tras la remediación, pruebe un flujo autorizado de nueva cuenta que utilice la ruta predeterminada y un flujo que reutilice una cuenta creada previamente. Verifique el destino resultante, los permisos, la aplicación esperada de GPO y los resultados de servicios aplicables. Los permisos de unión y las reglas de destino de netdom de Microsoft explican por qué estos flujos deben considerarse por separado.

Todos los comandos de esta guía son ejemplos documentados para el lector o adaptaciones identificadas explícitamente. No se ejecutaron contra un dominio AD para este artículo y no constituyen pruebas de una redirección, migración o rotación correcta.

Cómo detecta EtcSec este problema

Las siguientes descripciones reflejan las implementaciones Detect() revisadas en el commit de etc-collector b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c. Las rutas siguientes son relativas a public/internal/audit/detectors/.

COMPUTER_WRONG_OU, en ad/computers/organization/wrong-ou.go:35, omite los equipos deshabilitados, convierte el DN a minúsculas y busca ,cn=computers,dc= en las líneas 39–49. Informa de una gravedad Low. Es una prueba de subcadena, no una comparación analizada del objeto superior con una OU de destino configurada. No realiza un inventario de la aplicación efectiva de GPO ni establece la ausencia de LAPS, refuerzo de seguridad o auditoría.

COMPUTER_PRE_CREATED, en ad/computers/status/pre-created.go:35, prueba UserAccountControl & 0x1020 == 0x1020 en las líneas 38–41. Se permiten bits adicionales, incluido el estado deshabilitado. Su hallazgo Medium no incluye ninguna condición de DN, umbral de antigüedad, prueba de historial de inicio de sesión ni inspección del valor secreto. El nombre del hallazgo identifica una señal de revisión de preparación; el predicado no demuestra que el equipo nunca se haya unido.

Un control adyacente, SERVER_NO_ADMIN_GROUP, se ha revisado, pero no está etiquetado en este artículo. En ad/computers/organization/server-no-admin-group.go:43, selecciona equipos habilitados clasificados heurísticamente como servidores y comprueba la cobertura mediante vínculos habilitados a datos analizados de Restricted Groups que contienen una lista no vacía de miembros de Administrators. Sus funciones auxiliares están en las líneas 102–186. No detecta específicamente la residencia en CN=Computers, no calcula el filtrado efectivo ni inspecciona los miembros locales reales del servidor. Sin datos de directivas GPO suministrados, su recuento cero no establece conformidad.

Utilice estos hallazgos para elegir el siguiente paso de validación. Corrija la ubicación, verifique el aprovisionamiento futuro, establezca la protección real del cliente y resuelva por separado la propiedad de las cuentas preparadas. Un predicado de directorio que deja de coincidir es una prueba útil para ese predicado; una remediación operativa correcta requiere las pruebas de resultado correspondientes.