Fronteras de confianza de Configuration Manager: mapa de autoridad

Por qué la ubicación en una OU no establece las fronteras de confianza de Configuration Manager

Las fronteras de confianza de Configuration Manager siguen la autoridad administrativa: quién puede cambiar un componente de gestión, qué recursos puede controlar un operador y dónde una identidad de instalación tiene derechos locales. El nombre distinguido de un equipo AD es una prueba de inventario útil, pero moverlo a una OU llamada Management no responde a esas preguntas.

Empiece por el equipo candidato y siga su autoridad hacia los demás sistemas. ¿Es un servidor de sitio, un host SMS Provider, otro sistema de sitio o simplemente un cliente administrado con un nombre de producto en su descripción? ¿Qué personas e identidades de servicio lo administran? ¿A qué sistemas pueden llegar esas identidades? La revisión de una frontera está incompleta hasta que el mismo registro conecte la infraestructura de gestión con sus destinos reales.

El modelo de administración por tiers de Active Directory y las sesiones administrativas aporta los principios generales de separación. Esta revisión añade un mapa de autoridad específico del producto. Mantenga ambos conectados: una convención de OU puede facilitar el despliegue de directivas, pero no sustituye las pruebas sobre quién controla Configuration Manager o los sistemas que administra.

Cómo funciona: acceso al proveedor, autoridad sobre la base de datos y alcance sobre los destinos

Microsoft describe capas de seguridad distintas. El SMS Provider expone el acceso a la base de datos del sitio mediante WMI y el servicio de administración. El acceso al proveedor y los permisos sobre los objetos administrados son cuestiones diferentes. Local System y el usuario de instalación de Configuration Manager tienen autoridad predeterminada sobre todos los objetos de la base de datos del sitio; los demás usuarios administrativos se rigen por la administración basada en roles de la consola. Los roles, los ámbitos de seguridad y las colecciones definen conjuntamente lo que un usuario puede ver y administrar. Estas distinciones proceden de los fundamentos de seguridad de Configuration Manager.

Para la revisión, registre tres rutas por separado:

• Control de la infraestructura: identidades capaces de administrar el host del proveedor, el servidor de sitio o la infraestructura de la base de datos.
• Administración del producto: entidades de seguridad cuyos permisos asignados permiten operaciones sobre determinados objetos de Configuration Manager y colecciones de destino.
• Autoridad de instalación: cuentas con derechos en los sistemas donde el producto instala un cliente o un componente de sistema de sitio.

Este es un modelo de evaluación, no una afirmación de que todos los operadores de Configuration Manager tengan administración de Windows sin restricciones. Para cada ruta, determine la operación concedida y el recurso afectado. No convierta la capacidad de consultar al proveedor en la conclusión de que esa identidad puede desplegar en todos los dispositivos.

La referencia de cuentas de Configuration Manager de Microsoft ofrece distinciones concretas. SMS Admins es un grupo local en los equipos del proveedor; sus permisos WMI pueden inspeccionarse con el complemento MMC WMI Control. El RBAC sigue determinando el acceso a los objetos de la consola. La client push installation account requiere pertenecer a Administrators local en los clientes de destino, no a Domain Admin; si no hay una cuenta configurada, el sitio intenta usar su cuenta de equipo. La site system installation account, que es independiente, requiere permisos administrativos locales y el derecho de usuario de acceso a la red en los sistemas de sitio de destino. La network access account sirve para acceder a recursos, no como contexto de ejecución de software, actualizaciones o secuencias de tareas.

Estas cuentas merecen filas separadas incluso cuando la misma identidad AD desempeña más de una función. Una etiqueta como «cuenta de servicio» oculta la diferencia entre descargar contenido y administrar un destino. A la inversa, nombres de cuenta distintos no establecen separación si reciben derechos equivalentes sobre las mismas máquinas.

Detección: construir la matriz de autoridad a partir de las pruebas del producto

Paso 1: confirmar la función real del candidato

Conserve el hallazgo LDAP, el DN del equipo, el campo de inventario que coincidió y la fecha de revisión. Pida al responsable del producto que identifique la función real del candidato y su sitio asociado. Contraste esa respuesta con la configuración desplegada del producto y el inventario de hosts. Si solo es un cliente, registre por qué coincidió con la heurística; no invente un rol de gestión para justificar el hallazgo.

Para un componente de gestión confirmado, enumere los hosts del proveedor y de la base de datos de los que depende, las identidades de instalación y los responsables administrativos. Marque como desconocidas las relaciones sin resolver. Un inventario que omite un proveedor o un sistema de sitio remoto puede hacer que un ámbito de gestión supuestamente limitado parezca más seguro de lo que es.

Paso 2: leer conjuntamente los roles, los ámbitos y las colecciones asignadas

Siga el procedimiento de configuración de la administración basada en roles de Microsoft. En la consola, abra Administration > Security > Administrative Users, seleccione la entidad de seguridad y abra Properties. Inspeccione Security Roles y Security Scopes, incluida la asociación configurada entre roles, ámbitos y colecciones. Para inspeccionar los permisos de un rol sobre los objetos, vaya a Administration > Security > Security Roles, seleccione el rol, abra Properties y elija la pestaña Permissions.

Para la autoridad sobre colecciones, revise los permisos del rol sobre el objeto Collection y las colecciones asignadas al usuario administrativo. Incluya las colecciones limitadas por esas colecciones asignadas. Microsoft también identifica el Role-based administration and auditing tool para auditar usuarios, colecciones y ámbitos.

Use esas vistas como pruebas, no solo como capturas de nombres descriptivos. Registre los identificadores, las acciones permitidas pertinentes, las asignaciones mediante grupos y los dispositivos miembros utilizados en la revisión. Cuando cambia la pertenencia, el mapa de autoridad necesita otra revisión. Una colección llamada «Servers» no establece que todos sus miembros pertenezcan al nivel de confianza previsto.

Paso 3: inspeccionar la configuración de instalación y los derechos locales en los destinos

El procedimiento de despliegue de clientes Windows de Microsoft indica la ruta de consola: Administration > Site Configuration > Sites, seleccione el sitio y después Client Installation Settings > Client Push Installation. Inspeccione la pestaña Accounts y los ajustes de instalación automática, los tipos de sistemas seleccionados y la selección de controladores de dominio de la pestaña General. El procedimiento también documenta la instalación por inserción iniciada para un dispositivo o una colección individual.

Lea esta configuración antes de iniciar cualquier instalación. Una selección de destinos configurada constituye una prueba sobre el flujo de instalación; inspeccione por separado dónde cada identidad posee realmente derechos administrativos locales. Distinga la client push installation account configurada, el recurso a la cuenta de equipo y la site system installation account.

Registre por separado las verificaciones correctas y fallidas. Si no puede comprobarse la pertenencia a grupos locales en un destino, márquelo como desconocido. No infiera la ausencia de derechos a partir de un host no disponible, ni derechos sobre todas las máquinas a partir de una comprobación correcta en un único dispositivo representativo.

Paso 4: conectar las entidades de seguridad con los sistemas administrados

Construya una fila por ruta de autoridad. Lo siguiente es una plantilla de revisión, no un entorno descubierto ni un conjunto de permisos predeterminados:

Lea la tabla de izquierda a derecha: entidad de seguridad → rol/cuenta → sitio/colección → sistemas administrados. Después pregunte qué fila une niveles de confianza previamente separados. Revise las asignaciones combinadas en lugar de considerar cada rol de forma aislada. Conserve una entrada separada para un conjunto de destinos desconocido; una celda vacía nunca debe significar silenciosamente «sin acceso».

Corrección: alinear la autoridad antes de cambiar la ubicación en OU (Remediation)

Paso 1: decidir la frontera prevista y conservar el estado de referencia

Con los responsables de infraestructura e identidades, defina qué sistemas administrados deben agruparse y qué rutas administrativas deben permanecer separadas. Compare esa frontera prevista con cada fila de la matriz. Registre el motivo de cada discrepancia, su responsable y las pruebas necesarias para cerrarla.

Conserve las asignaciones de roles existentes, la configuración de instalación, los miembros de los conjuntos de destino y las dependencias operativas antes de los cambios. Elija un piloto que contenga tanto un destino previsto como un sistema que deba permanecer fuera de la autoridad del operador. Planifique una prueba funcional aprobada y una reversión para cada cambio.

Paso 2: reducir los permisos del producto mediante la consola admitida

Use las propiedades del usuario administrativo ya revisadas para ajustar las asociaciones pertinentes de rol, ámbito y colección. Cuando los roles existentes concedan autoridad excesiva, use el procedimiento de roles personalizados documentado por Microsoft: copie un rol en Administration > Security > Security Roles, inspeccione sus permisos sobre los objetos y asigne solo los permisos necesarios. Los permisos de los roles integrados no pueden editarse. Estas operaciones están cubiertas por el procedimiento de configuración de la administración basada en roles.

El cambio debe eliminar una operación no deseada concreta o una relación con un destino. Verifique que la administración prevista sigue funcionando y que el sistema excluido está fuera de la autoridad concedida. Mantenga la administración de infraestructura en la revisión; reducir una asignación de consola por sí sola no resuelve una ruta independiente de administración del host o de la base de datos.

Paso 3: separar la autoridad de instalación cuando su alcance cruza la frontera

Para cada identidad de instalación, compare sus derechos locales verificados con el conjunto de destinos previsto. Proponga identidades separadas con ámbitos adecuados cuando una cuenta abarque varios niveles de confianza. Compruebe la cuenta configurada en el producto y los permisos concedidos en cada destino; cambiar solo un lado deja la revisión incompleta.

La referencia de cuentas de Microsoft recomienda denegar explícitamente el inicio de sesión interactivo local a la client push installation account. También documenta una secuencia de sustitución: crear una cuenta con otro nombre, añadirla a la lista configurada, permitir la replicación AD y retirar después la cuenta anterior. Trátelo como una migración coordinada con verificación de derechos en los destinos, no como una instrucción para purgar cuentas o grupos. La identidad de instalación de sistemas de sitio requiere su propia revisión de destinos. Siga los requisitos documentados de las cuentas para la función realmente utilizada.

Paso 4: conciliar ubicación en OU, sesiones administrativas y flujos

Solo cuando el mapa de autoridad sea coherente deben compararse la ubicación en OU, la delegación, las directivas y los puntos de entrada administrativos con el diseño previsto. Considere conjuntamente los hosts de gestión y las personas y cuentas que los controlan. Mover un objeto de equipo no puede corregir una cuenta que conserva derechos sobre un conjunto de destinos no previsto.

Revise el transporte como un control independiente. Las comprobaciones GPO del transporte de metadatos WSUS abordan la protección de esa conexión; no establecen quién puede administrar el SMS Provider ni qué puede controlar una identidad de instalación. Conserve ambas revisiones, con pruebas y conclusiones separadas.

Paso 5: cerrar los hallazgos con pruebas y conservar las excepciones

Reconstruya la matriz después del piloto y del despliegue posterior. Para cada fila modificada, adjunte la nueva asignación, los miembros actuales del conjunto de destinos, las pruebas pertinentes de derechos locales y el resultado funcional. Una excepción debe identificar la operación necesaria, los sistemas afectados, el responsable, las medidas compensatorias y un desencadenante de revisión. Un permiso sin resolver o un destino inaccesible sigue siendo desconocido.

Defina los desencadenantes de otra revisión: un nuevo host del proveedor, sistema de sitio, asignación de colección, identidad de instalación o nivel de confianza administrado. Una decisión sobre la frontera sigue siendo defendible solo mientras el mapa de autoridad que la sustenta coincida con el entorno desplegado.

Cómo detecta EtcSec este caso

La comprobación etc-collector revisada es ANSSI_R49_R50_MGMT_CATEGORIZATION, en el commit del colector 15fc6399c215eabc415c370b762303cfcd7a353a. Es una heurística de inventario y nombres, no una auditoría de autorización de Configuration Manager.

Un equipo se convierte en candidato cuando su DN coincide con una entrada de mgmt_systems, que es opcional, o cuando la combinación en minúsculas de SAMAccountName, DNSHostName, Description y OperatingSystem contiene uno de estos marcadores: sccm, configmgr, wsus, mecm, defender, atp, mdatp, intune, jamf, ansible, salt, puppet, chef, tanium, bigfix, crowdstrike, carbonblack o sentinelone.

Produce un hallazgo para los candidatos cuyo DN en minúsculas no contiene ninguno de ou=tier0, ou=tier-0, ou=tier1, ou=tier-1, ou=admin, ou=mgmt u ou=management. Son pruebas de subcadenas, no una validación de los controles reales de una OU. Si ningún candidato falla esa prueba, Detect() devuelve nil.

La lista opcional mgmt_systems procede de tier0_groups.yaml. Si ese archivo no existe, no se carga ninguna personalización, la lista está vacía y solo se aplican las heurísticas de nombres, sin advertencia. Si el archivo no puede leerse o su YAML está mal formado, el motor escribe una advertencia en stderr y continúa con los valores predeterminados. Una entrada DN explícita añade un candidato; no establece autoridad del producto ni sustituye la prueba de subcadenas de OU.

El proveedor LDAP aporta los campos de inventario de los equipos. Esta comprobación no recopila permisos del SMS Provider, autoridad sobre la base de datos del sitio, asignaciones RBAC, colecciones de destino ni derechos de cuentas de instalación. El nombre de un cliente puede coincidir; un sistema de gestión realmente potente puede pasar inadvertido; un nombre de OU puede satisfacer la prueba de subcadenas sin imponer aislamiento.

Use el hallazgo para iniciar la revisión de autoridad. Resuelva la cuestión arquitectónica con las pruebas del producto y de los destinos en la matriz, conservando incógnitas y excepciones incluso cuando la heurística de nombres ya no informe de un hallazgo.