Grupo Pre-Windows 2000 Compatible Access Active Directory

¿Qué es el grupo Pre-Windows 2000 Compatible Access?

El grupo Pre-Windows 2000 Compatible Access en Active Directory puede conceder un acceso amplio de lectura al directorio, pero los atributos que puede leer quien realiza la llamada dependen de las ACE del objeto. «Lectura en todo el directorio» no significa que todos los secretos sean legibles, y la pertenencia no garantiza la enumeración LDAP anónima. Microsoft documenta tanto las comprobaciones de acceso a objetos como una restricción LDAP independiente. Requisitos de acceso de las funciones de administración de red, restricciones de LDAP anónimo.

Pre-Windows 2000 Compatible Access es el grupo de seguridad integrado identificado por S-1-5-32-554, ubicado bajo CN=Builtin en el dominio. Microsoft lo describe como un mecanismo de compatibilidad para clientes Windows NT 4.0 y anteriores, con acceso de lectura a información de usuarios y grupos. No está protegido por AdminSDHolder, y la tabla de grupos de Microsoft indica que no se puede mover fuera de su contenedor predeterminado. Revise sus miembros en lugar de eliminar o reubicar el grupo. Grupos de seguridad de Active Directory.

Una investigación útil plantea cuatro preguntas: qué entidades de seguridad son miembros, qué permisos reciben, qué interfaz acepta sus solicitudes y qué aplicaciones siguen necesitando esas lecturas. Mantenga esas respuestas separadas en el registro del cambio. El número de miembros aporta la primera pista; no resuelve las otras tres preguntas.

Defina los criterios de éxito de la revisión antes de cambiar el acceso. Para una vía anónima innecesaria, el resultado deseado es una reducción documentada de esa vía mientras las funciones autenticadas necesarias siguen funcionando. Para una cuenta de servicio, puede consistir en sustituir permisos amplios de compatibilidad por un acceso verificado a los atributos que realmente solicita. Para una dependencia sin resolver, el resultado puede ser una excepción con un responsable y un plan de pruebas. Son resultados operativos propuestos, no observaciones sobre su dominio ni una afirmación de que toda pertenencia sea explotable.

La pertenencia inicial depende de la creación del dominio

La especificación del protocolo vincula la pertenencia inicial al sistema operativo del primer controlador de dominio y al modo de permisos seleccionado por el administrador. Documenta estos casos. MS-ADTS 6.1.1.4.12.14.

Decir «Everyone siempre es el valor predeterminado» pierde esta distinción. La guía de Microsoft sobre acceso de aplicaciones también explica que añadir un DC Windows Server 2003 a un dominio Windows 2000 existente no cambia la selección de compatibilidad anterior. Por tanto, un dominio actualizado puede conservar una elección antigua. KB331951: aplicaciones e información de autorización.

Utilice este historial para interpretar una línea de base, no para aprobar cada miembro actual. Un valor predeterminado histórico puede haber dejado de responder a una necesidad del negocio, mientras que una incorporación posterior puede dar soporte a una aplicación. La lista actual no permite saber quién añadió una entrada ni por qué. Registre «origen desconocido» cuando los registros de despliegue y los registros de cambios conservados no respondan a esa pregunta.

Funcionamiento: pertenencia, ACE y controles de protocolo

Everyone por sí solo no es Anonymous

Los requisitos NetAPI de Microsoft exigen explícitamente la pertenencia de Anonymous para acceder de forma anónima a la información de grupos: el token anónimo normal no incluye el SID de Everyone. El comportamiento de Windows 2000 y la anulación EveryoneIncludesAnonymous=1 son excepciones documentadas en la misma página. En un sistema moderno con el comportamiento normal del token, Everyone por sí solo no equivale a Anonymous Logon. La pertenencia explícita de Anonymous proporciona una vía de autorización, sujeta a las demás restricciones de la interfaz. Requisitos de acceso de las funciones de administración de red.

El acceso de lectura y la enumeración tienen sus propias condiciones. NetQueryDisplayInformation devuelve información que quien realiza la llamada puede leer; exige List Contents sobre el objeto Domain y Enumerate Entire SAM Domain sobre el objeto SAM Server del contenedor System. Es una vía concreta de permisos que investigar, no una promesa de que cualquier cliente de red pueda listar todos los objetos. NetQueryDisplayInformation.

LDAP tiene un control independiente

Windows Server 2003 introdujo un bloqueo predeterminado de las operaciones LDAP anónimas más allá de los enlaces y las búsquedas rootDSE. El séptimo carácter de dsHeuristics, establecido en 2, anula ese bloqueo; las operaciones siguen necesitando permisos ACL. Añadir Anonymous a este grupo no cambia ese atributo. A la inversa, comprobar el control LDAP no demuestra la seguridad de otra interfaz de enumeración. KB326690: operaciones LDAP anónimas.

Para ese mecanismo independiente, lea el acceso LDAP anónimo y el control dsHeuristics. Ese artículo trata la configuración LDAP y la verificación de enlaces y búsquedas. Aquí el tema es la vía de autorización del grupo de compatibilidad. Utilice el artículo enlazado para investigar ese control y valide las decisiones técnicas con la documentación de Microsoft.

De dónde proceden los permisos de lectura heredados

El descriptor de seguridad predeterminado de Domain-DNS publicado contiene permisos para RU. La referencia de cadenas SID de Microsoft define RU como el alias de Pre-Windows 2000 Compatible Access. Este extracto procede de la sección Windows 2000 Server de la página. Muestra permisos en la raíz y heredables; compare la versión correspondiente y la DACL real de su dominio antes de basarse en él. Clase Domain-DNS, cadenas SID.

(A;CI;LC;;;RU)
(A;;RC;;;RU)
(OA;CIIO;RPLCLORC;;bf967aba-0de6-11d0-a285-00aa003049e2;RU)
(OA;CIIO;RPLCLORC;;bf967a9c-0de6-11d0-a285-00aa003049e2;RU)

En SDDL, A y OA son formas de ACE de permiso; CI indica herencia de contenedores e IO solo herencia. RP significa Read Property, LC List Children, LO List Object y RC Read Control. La máscara de derechos y los indicadores de herencia son campos separados, por lo que una entrada heredada específica de objeto no debe interpretarse como un permiso sin restricciones sobre la propia raíz. Cadenas ACE.

Los dos GUID de clases heredadas identifican User y Group. Computer es una subclase de User: incluya los equipos en la revisión, sin inventar una ACE específica para Computer en este extracto. Las referencias de las clases publican descriptores predeterminados versionados; la entrada antigua de User no demuestra que todos los usuarios actuales tengan una DACL idéntica. Clase User, clase Group, clase Computer.

El descriptor completo de Domain-DNS también incluye ACE de lectura de conjuntos de propiedades de User. La referencia Sam-Server muestra por separado una entrada RU con RPLCLORC. Estos valores predeterminados explican vías que medir; no sustituyen la inspección de la herencia, las entradas explícitas y los objetos protegidos de un dominio real. Descriptor Domain-DNS, clase Sam-Server.

Medir el grupo real y los permisos de lectura

Los ejemplos siguientes adaptan parámetros documentados de cmdlets y la sintaxis de dsacls. No se han ejecutado contra un dominio. Sustituya el servidor y los nombres distinguidos ficticios por valores resueltos en su entorno. Ejecútelos desde una estación de administración adecuada, con las herramientas y los permisos de lectura necesarios. Conserve por separado la salida y los errores de cada comando para que una búsqueda fallida no pueda hacerse pasar por un resultado sin problemas.

Paso 1: capturar los miembros directos

Empiece por el nombre inglés conocido cuando exista. Este ejemplo adapta los parámetros Identity y Server documentados de la cmdlet de pertenencia. Get-ADGroupMember.

Get-ADGroupMember -Identity "Pre-Windows 2000 Compatible Access" -Server "dc01.contoso.com"

Después identifique el grupo integrado por su SID estable y solicite la propiedad sin procesar member. El ejemplo de Get-ADGroup de Microsoft utiliza este patrón con otro SID integrado; esta adaptación lo sustituye por el SID 554. Get-ADGroup.

Get-ADGroup -Identity "S-1-5-32-554" -Properties member -Server "dc01.contoso.com"

Utilice esa identidad también para la vista de pertenencia directa. La cmdlet acepta un SID como Identity. Opciones de identidad de Get-ADGroupMember.

Get-ADGroupMember -Identity "S-1-5-32-554" -Server "dc01.contoso.com"

Compare los miembros resueltos con las referencias sin procesar, especialmente cuando falle la resolución de identidades especiales o entidades de seguridad externas. Registre el DN y el SID del grupo, el DC consultado y la identidad de cada miembro. Un error de resolución no equivale a un grupo vacío. Investigue el objeto referenciado antes de sacar una conclusión o preparar una retirada.

Conserve esta vista directa para compararla con el recuento de miembros del collector. -Recursive plantea otra pregunta: la cmdlet recorre la jerarquía del grupo para devolver miembros sin objetos secundarios. Una revisión recursiva registrada por separado puede ayudar a investigar entidades de seguridad anidadas, pero no debe sustituir silenciosamente la línea de base directa. Comportamiento recursivo de Get-ADGroupMember.

En el registro de evidencias propuesto, etiquete explícitamente la búsqueda correcta, la búsqueda fallida y la referencia sin resolver. Conserve los valores originales sin procesar junto con sus anotaciones. Esto permite revisar comparaciones posteriores: un nombre para mostrar que desaparece puede deberse a una diferencia de resolución, mientras que un valor de pertenencia sin procesar que cambia merece investigación. Evite que un informe con un formato cómodo sea la única evidencia conservada, especialmente si otro revisor tendrá que reproducir la decisión.

Paso 2: inspeccionar la raíz y descendientes representativos

Con el DN de un objeto y sin opciones de modificación, dsacls muestra las ACE del objeto. La herramienta también puede cambiar permisos, así que conserve la forma de solo lectura presentada aquí. La referencia de Microsoft exige un símbolo del sistema elevado y permiso Read sobre el objeto de destino. Estos cuatro comandos son adaptaciones con objetos ficticios. Referencia Dsacls.

dsacls "DC=contoso,DC=com"

dsacls "CN=Alice,OU=Users,DC=contoso,DC=com"

dsacls "CN=AppReaders,OU=Groups,DC=contoso,DC=com"

dsacls "CN=PC01,OU=Computers,DC=contoso,DC=com"

Para cada muestra, registre el destinatario de los permisos, el tipo de permiso o denegación, los derechos, la herencia, el ámbito de clase y el ámbito del conjunto de propiedades. Identifique las entradas del SID 554 aunque el nombre para mostrar esté localizado. Incluya objetos utilizados por las aplicaciones revisadas y ejemplos con distintas configuraciones de herencia. Un único objeto de usuario ordinario es una muestra, no un resultado de acceso efectivo de todo el dominio.

La distinción importa para la escritura diferida de contraseñas: Microsoft documenta los permisos necesarios en la raíz y los permisos heredados de los descendientes, y después pide a los administradores inspeccionar los permisos efectivos de la cuenta del conector. Leer una DACL y probar la operación de quien realiza la llamada responden a preguntas distintas. Utilice ambos métodos al validar una dependencia. Permisos de escritura diferida de contraseñas.

Paso 3: elaborar un registro de dependencias

Para cada entidad de seguridad conservada, proponga un registro con su responsable, aplicación y versión, identidad que realiza la llamada, atributos solicitados, protocolo, objetos de destino y prueba funcional. Incluya el fallo que justificaría una reversión. Un nombre de cuenta que se parezca al de un producto es una pista para investigar, no una prueba de una acción del instalador.

Esta revisión también difiere de la de Everyone y Authenticated Users en grupos privilegiados de AD. Ese artículo examina identidades amplias situadas directamente en grupos privilegiados y la pertenencia privilegiada permanente. Aquí el papel documentado del grupo es autorizar lecturas por compatibilidad; no convierta su número de miembros en una afirmación de pertenencia administrativa directa.

Detección: establecer el estado y supervisar cambios de pertenencia

Combine el inventario basado en SID con un historial de cambios. La documentación de eventos de seguridad de Microsoft sitúa 4732 y 4733 en Audit Security Group Management, con un evento por cada miembro añadido o retirado. Pueden generarse en controladores de dominio, servidores miembros y estaciones de trabajo; seleccione los registros de DC pertinentes para el grupo del dominio. Evento 4732, evento 4733.

Una regla de supervisión propuesta debería hacer coincidir TargetSid con S-1-5-32-554, conservar MemberSid y los campos del sujeto, y comparar los cambios con el trabajo aprobado. Comparar SID evita depender de un nombre de grupo traducido. Pruebe la correspondencia de campos en su canal de recopilación antes de considerar que la regla proporciona cobertura. Los nombres de campo proceden de los ejemplos XML de eventos; esta regla es una propuesta operativa, no una detección SIEM desplegada. Campos del evento 4732.

Estos eventos registran cambios de pertenencia. No muestran qué atributos se leyeron, no descubren todas las dependencias de aplicaciones ni confirman una enumeración anónima correcta. La ausencia de eventos no permite concluir nada sin una directiva de auditoría, recopilación y retención que funcionen. Combine los registros con el estado guardado y las pruebas funcionales autorizadas, en lugar de tratar cualquiera de ellos como una evaluación completa del acceso.

Corrección: retirar el acceso innecesario por etapas (Remediation)

Este es un proceso de cambio propuesto a partir de los mecanismos documentados, no una instrucción universal de Microsoft de vaciar el grupo. Conserve el estado anterior, pruebe las dependencias y cambie miembros seleccionados. La pertenencia es un cambio de un grupo del dominio: llamarlo «piloto de OU» no limita a una OU el efecto de retirar un miembro.

Paso 1: separar los valores históricos predeterminados de la deriva posterior

Utilice el inventario por SID y los valores de member sin procesar anteriores. Compárelos con los registros disponibles de creación y actualización, y clasifique las entradas como valores predeterminados explicados, incorporaciones de aplicaciones documentadas o pertenencia sin explicación. Someta cada categoría a la misma revisión de necesidad actual. La tabla de pertenencia inicial explica el origen; no exime de revisión. Especificación de pertenencia MS-ADTS.

Paso 2: resolver las dependencias documentadas antes de retirar miembros

Las fuentes siguientes aportan dependencias concretas y alternativas que investigar. Respete sus límites en lugar de extenderlas a todos los despliegues de acceso remoto o sincronización.

Fuentes: solución de problemas de VPN NT4, registrar un NPS, acceso TGGAU, permisos de escritura diferida de contraseñas.

El registro de NPS no demuestra un requisito de Anonymous. Para TGGAU, la alternativa Windows Authorization Access necesita su propia verificación de permisos: la guía de Microsoft distingue los dominios nuevos de los dominios en modo mixto y actualizados en los que no se concedió automáticamente al grupo el acceso necesario. No lo sustituya por un grupo privilegiado solo para hacer desaparecer un error de acceso denegado. TGGAU y WAA.

La guía de Entra Connect advierte explícitamente de problemas de escritura diferida cuando falta Authenticated Users, especialmente con versiones antiguas. Su sección SAM-server también distingue los permisos directos de Authenticated Users del acceso a través de este grupo. Esta dependencia documentada impide recomendar de forma general retirar todas las identidades amplias. Solución de problemas de escritura diferida.

Exchange sigue sin estar demostrado como origen automático de pertenencia aquí. El apéndice B indica que instalar Exchange puede crear cuentas y grupos adicionales en Builtin y Users; no establece incorporaciones automáticas al SID 554 ni versiones afectadas. Trate las entradas con nombres de Exchange y los dispositivos especializados como cuestiones que requieren evidencias específicas del producto y pruebas funcionales. Apéndice B.

Paso 3: simular una retirada seleccionada

Priorice la investigación de Anonymous, después de Everyone con el comportamiento real del token, y de cuentas sin una necesidad confirmada. Conserve Authenticated Users hasta entender sus dependencias. Elija el miembro resuelto exacto y ensaye en un dominio de pruebas representativo antes de programar el cambio del dominio de producción.

La adaptación siguiente utiliza identificadores SID documentados y -WhatIf. Simula la retirada de Anonymous; no es un comando ejecutado para este artículo. Valide primero la entidad de seguridad resuelta. Remove-ADGroupMember.

Remove-ADGroupMember -Identity "S-1-5-32-554" -Members "S-1-5-7" -Server "dc01.contoso.com" -WhatIf

Tras las pruebas y la decisión de cambio del administrador, realice únicamente la retirada seleccionada con la confirmación normal. La cmdlet documenta el comportamiento de confirmación; evite un bucle que vacíe el grupo o suprima la revisión de cada miembro. Una vista previa con -WhatIf no realiza la retirada ni demuestra que tendría éxito; no puede predecir el comportamiento de las aplicaciones tras un cambio real. Parámetros de retirada y confirmación.

Paso 4: verificar el funcionamiento, los permisos y el historial del cambio

Proponga una ventana de cambio del dominio, un miembro cada vez, con un responsable de reversión designado. Vuelva a leer la pertenencia en los DC utilizados por los servicios afectados después de la replicación y repita las operaciones autorizadas de la aplicación en el contexto de seguridad pertinente. La guía de Microsoft sobre escritura diferida trata específicamente los retrasos de replicación y el uso de un DC preferido al corregir permisos. Consideraciones sobre replicación.

Revise los errores de acceso de aplicaciones y el evento 4733 para la retirada prevista; supervise 4732 para las incorporaciones, incluida una reversión controlada. Si el funcionamiento empeora, restaure solo la pertenencia modificada mediante el proceso de recuperación aprobado e investigue la dependencia. No prescriba una duración arbitraria de supervisión ni un reinicio universal de los DC: la instrucción de reinicio del documento de VPN NT4 pertenece a su escenario histórico concreto. 4733, 4732, escenario NT4.

Cómo detecta EtcSec esta configuración

La comprobación de etc-collector PRE_WINDOWS_2000_ACCESS está implementada en ad/groups/membership/pre-windows-2000-access.go:24. El Detect() revisado convierte a minúsculas el CN y el SAMAccountName de cada grupo y selecciona el primer grupo cuyo nombre contiene pre-windows 2000 compatible access. Su Count es len(targetGroup.Members): se cuentan todos los miembros recopilados, incluidos Authenticated Users y las cuentas de aplicaciones. El catálogo revisado lo clasifica como Medium con peso 1.

La función devuelve un hallazgo incluso si no encuentra ningún grupo coincidente o el recuento es cero. Los detalles y el grupo afectado solo se incluyen si IncludeDetails está habilitado, se encontró un grupo y el recuento es positivo. Estas afirmaciones describen la implementación revisada, no una auditoría ejecutada contra su dominio.

La comprobación no verifica los SID del grupo o de sus miembros, no inspecciona las ACE, no lee dsHeuristics, no expande pertenencias anidadas en esta función ni prueba el acceso de una aplicación. La coincidencia de subcadenas en inglés puede omitir nombres localizados y seleccionar un nombre coincidente no deseado; la falta de datos de entrada también puede producir cero. Utilice las mediciones basadas en SID para contextualizar la señal. Un recuento positivo no demuestra la pertenencia de Anonymous, y cero no demuestra que todas las vías de lectura estén restringidas.

COMPUTER_PRE_WINDOWS_2000 está explícitamente fuera del ámbito y de las etiquetas de este artículo. Su Detect(), revisado por separado en ad/computers/other/pre-windows-2000.go:43, compara valores no vacíos de OperatingSystem con Windows 95|Windows 98, sin distinguir mayúsculas de minúsculas. No inspecciona los miembros ni los permisos de este grupo.

Cierre la revisión con los hechos establecidos: identidades resueltas, vías ACL inspeccionadas, restricciones de protocolo comprobadas, dependencias probadas y cambios seleccionados supervisados. El detector de pertenencia ayuda a priorizar ese trabajo; las evidencias determinan qué acceso puede retirarse sin comprometer el funcionamiento.