Derechos AD de nombre DNS validado: revisar la ACE

Qué significan los derechos AD de nombre DNS validado

Los derechos AD de nombre DNS validado regulan una actualización restringida de dNSHostName en un objeto del directorio. Una ACE que contiene el GUID asociado justifica revisar una delegación. Antes de modificarla, determine quién recibe el permiso, si su máscara concede realmente la escritura validada, si se aplica al equipo y qué operación de aprovisionamiento lo necesita.

Microsoft identifica Validated-DNS-Host-Name mediante el GUID 72e39547-7b18-11d1-adef-00c04fd8d5cd. El permiso permite un nombre de host DNS coherente con las restricciones de nomenclatura del equipo y del dominio. No establece un permiso para editar una zona DNS ni demuestra que alguien haya redirigido tráfico.

El resultado útil de esta revisión es una decisión registrada: una delegación aprobada, una concesión innecesaria confirmada que debe eliminarse o una cuestión de recopilación o autorización sin resolver. Una lista de GUID coincidentes no basta para tomar esa decisión. Mantenga juntos la identidad del objeto de equipo, la ACE y el flujo de trabajo legítimo durante toda la investigación.

Cómo funciona: escritura validada frente a WriteProperty

La semántica de escritura validada de MS-ADTS distingue el acceso ordinario RIGHT_DS_WRITE_PROPERTY de las escrituras validadas. El acceso ordinario de escritura de propiedades permite valores admitidos por el esquema del atributo sin las comprobaciones adicionales de valores de la escritura validada. Una ACE de escritura validada combina el bit de máscara de acceso RIGHT_DS_WRITE_PROPERTY_EXTENDED con un GUID identificador en ObjectType; una ACE sin GUID ObjectType puede abarcar todas las escrituras validadas del objeto.

El GUID también es el identificador de esquema del atributo dNSHostName. Por tanto, el GUID por sí solo no permite distinguir una ACE limitada a escribir esa propiedad de otra limitada a su operación de escritura validada. Interprete conjuntamente la máscara y el ámbito.

Para la vía validada, MS-ADTS especifica las restricciones de dNSHostName: el objeto debe ser un equipo o un servidor, o una subclase; en AD DS, el nombre de host combina el sAMAccountName actual sin el signo de dólar final con el nombre DNS del contexto de nomenclatura del dominio o un valor permitido de msDS-AllowedDNSSuffixes. El solicitante debe tener el derecho de escritura validada. Revise estos datos de nomenclatura al evaluar la operación prevista.

Para investigar de forma más amplia el propietario y la DACL, utilice la revisión de la DACL y la propiedad de objetos de equipo. Esta revisión se centra en la autorización específica de escritura validada. Las transferencias de zona DNS y la configuración de actualizaciones dinámicas afectan a otra superficie; modificar una ACE de objeto de equipo no verifica esos ajustes de zona.

Detección: recopilar el objeto y revisar la ACE completa

Paso 1: establecer el límite de recopilación

Comience por el DN afectado y la población de equipos prevista. Registre el controlador de dominio, la hora de recopilación, las credenciales utilizadas para la lectura, la base de búsqueda y las OU excluidas, si las hay. Contraste la población con el ámbito previsto por el administrador. La lectura correcta de un objeto no establece nada sobre los equipos omitidos del inventario.

Utilice una estación de administración Windows con el módulo PowerShell ActiveDirectory para leer objetos. El siguiente ejemplo, basado en la documentación, utiliza los parámetros admitidos Identity, Server y Properties de Get-ADObject, con valores ilustrativos que debe sustituir para su entorno:

Get-ADObject -Identity "CN=APP01,OU=Servers,DC=example,DC=com" -Server "dc01.example.com" -Properties objectClass,sAMAccountName,dNSHostName,nTSecurityDescriptor

Confirme el DN y la clase devueltos antes de interpretar los permisos. Conserve el descriptor para una inspección detallada, junto con los valores de cuenta y nombre de host. No califique un descriptor no disponible como una DACL vacía. Registre por separado las lecturas fallidas y repítalas con una identidad de recopilación autorizada antes de sacar conclusiones sobre la cobertura.

Paso 2: inventariar la ACL

La referencia de Dsacls de Microsoft documenta cómo mostrar las ACE de un objeto proporcionando su DN entre comillas, sin opciones de modificación. Ejecútelo desde un símbolo del sistema Windows elevado con permisos de lectura del directorio:

dsacls "\\dc01.example.com\CN=APP01,OU=Servers,DC=example,DC=com"

Este es un ejemplo de sintaxis adaptado a un DN de equipo ilustrativo, no una comprobación ejecutada en un entorno. Inspeccione las entradas de permisos completas y utilice la pestaña Seguridad del objeto para revisar el ámbito en detalle cuando sea necesario. Registre el SID y la identidad resuelta de cada destinatario del permiso, el tipo de ACE, la máscara de acceso, ObjectType, el origen de herencia y la aplicabilidad. Conserve el descriptor original en lugar de guardar únicamente una vista filtrada del GUID.

Paso 3: resolver la máscara, el destinatario y la herencia

Las instrucciones de Microsoft sobre permisos de unión al dominio ilustran la ACE de escritura validada DNS con la máscara 0x00000008, denominada ACTRL_DS_SELF, y el GUID del nombre de host DNS. Ese nombre de máscara es distinto del destinatario denominado SELF: una cuenta de unión también puede recibir el bit de escritura validada. Compruebe si el bit pertinente está presente en la máscara recopilada; una máscara diferente o combinada necesita su propia interpretación.

MS-ADTS Checking Access explica Principal Self, SID S-1-5-10: en un objeto principal de seguridad, representa al principal de ese objeto y se sustituye por el SID del objeto durante la comprobación de acceso. El DC evalúa el contexto de seguridad del solicitante, el acceso solicitado y el descriptor correspondiente. Resolver un nombre para mostrar o ver una ACE de permiso no constituye esa evaluación completa.

Revise los destinatarios basados en grupos frente a la identidad real de unión o aprovisionamiento. Pregunte al propietario del flujo de trabajo qué identidad realiza cada paso y qué máquinas puede gestionar. No considere que un grupo cuyo nombre alude al despliegue demuestra que todos sus miembros necesitan acceso a todos los equipos.

Las reglas de herencia de Microsoft distinguen las ACE heredadas de las ACE que solo se heredan. Una entrada que solo se hereda no se aplica al objeto que la contiene. Siga el contenedor de origen y el ámbito de clase de objeto; evalúe la entrada tal como aparece en el equipo de destino, en lugar de suponer que una entrada del objeto padre tiene idéntica aplicabilidad en todas partes.

Paso 4: separar las pruebas esperadas, observadas y desconocidas

Utilice esta hoja de trabajo para cada equipo afectado. Es una plantilla de revisión, no un informe de resultados medidos:

Corrección: revisar el flujo de trabajo y después modificar la delegación (Remediation)

Paso 1: conservar la referencia inicial y establecer la necesidad

Guarde el descriptor original y la hoja de revisión. Acuerde la operación requerida con los propietarios de las máquinas y del aprovisionamiento antes de editar. Separe la creación de una cuenta de equipo nueva de la reutilización de una existente. Las instrucciones de Microsoft sobre unión al dominio incluyen el permiso de escritura validada DNS entre los derechos que necesita la identidad de unión al reutilizar una cuenta; por tanto, la presencia de ese derecho puede ser intencionada.

Para una excepción que se mantiene, registre el SID del destinatario, el derecho exacto, la población de objetos, el origen de herencia, la finalidad, el propietario y la fecha de revisión. Incluya las pruebas que respaldan esa decisión y las preguntas pendientes. Una excepción debe explicar por qué se necesita la delegación en estos equipos, en lugar de limitarse a indicar que el escáner la había señalado anteriormente.

Paso 2: eliminar o restringir la entrada innecesaria confirmada

Utilice la pestaña Seguridad del objeto para editar el permiso innecesario específico. Si es heredado, revise y corrija la delegación de origen con el propietario de la OU, comprobando los demás destinatarios antes de aplicar el cambio. Conserve los permisos necesarios para el flujo de trabajo restante y verifique el ámbito de la ACE resultante.

La documentación indica que dsacls /R elimina todas las ACE del destinatario especificado. No es adecuado para eliminar únicamente el acceso de escritura validada DNS de un destinatario que debe conservar otros permisos. No sustituya una edición de ACE revisada por la eliminación de todas las entradas de un destinatario, ni restablezca todo el descriptor de seguridad del objeto para hacer desaparecer un hallazgo.

Paso 3: verificar los permisos y la operación prevista

Vuelva a leer el equipo y su ACL en el DC elegido. Compare el descriptor resultante con la referencia inicial y documente exactamente qué entrada cambió. Confirme que el destinatario revisado ya no tiene la autorización efectiva no deseada mediante otra entrada aplicable. Para cambios heredados, tome una muestra de la población pertinente de destinatarios y verifique el límite previsto de clase de objeto.

Pruebe el flujo de trabajo aprobado de unión o aprovisionamiento en un equipo de prueba representativo, con la identidad delegada real. Registre qué operación se ejecutó, si tuvo éxito y los errores del directorio. En un miembro del dominio, la prueba de canal seguro de Microsoft ofrece una comprobación funcional adicional, ejecutada localmente en Windows PowerShell elevado:

Test-ComputerSecureChannel -Verbose

Esto comprueba la relación del miembro con el dominio; no establece que el aprovisionamiento del nombre de host funcione ni que la revisión de la ACL esté completa. Microsoft advierte que la cmdlet devuelve errores falsos positivos en controladores de dominio. Estas órdenes se citaron de la documentación, no se ejecutaron en un entorno de cliente.

Cómo detecta EtcSec este caso

La comprobación de etc-collector ACL_COMPUTER_WRITE_VALIDATED_DNS, revisada en el commit 15fc6399c215eabc415c370b762303cfcd7a353a, crea un conjunto de DN de equipos recopilados que no distingue mayúsculas de minúsculas. Conserva los registros ACLEntry cuyo ObjectType es igual a 72e39547-7b18-11d1-adef-00c04fd8d5cd y cuyo ObjectDN pertenece a ese conjunto. Count representa los equipos distintos afectados; cuando difiere, TotalInstances registra el número de entradas coincidentes.

Detect() no filtra SELF ni otros destinatarios, no comprueba la máscara de escritura validada, no evalúa la aplicabilidad de las entradas de solo herencia ni calcula derechos efectivos. Su salida es un punto de partida de inventario para la revisión anterior. La descripción del detector menciona la suplantación DNS y MITM, pero el predicado implementado no demuestra ninguno de esos resultados.

La recopilación también limita la interpretación. El proveedor LDAP solicita OWNER, GROUP y DACL con indicadores de descriptor de seguridad 0x07, sin la SACL. Omite los errores por objeto y los descriptores faltantes; en cambio, los errores de red interrumpen la llamada principal y pueden desencadenar una reconexión y un reintento. El analizador conserva las ACE de permiso estándar y de objeto, preservando la máscara, el estado heredado e InheritOnly, mientras excluye las ACE de denegación. El detector no utiliza esas distinciones para completar una comprobación de autorización.

GetComputers y su analizador proporcionan los DN utilizados para la unión de datos. Un inventario incompleto de equipos deja un ámbito incompleto del detector. Un resultado cero significa que no hay entradas coincidentes en los datos proporcionados, no que se hayan leído todos los equipos ni que ningún principal pueda modificar el atributo. Las entradas amplias de escritura validada sin este GUID específico también quedan fuera del predicado de coincidencia. Contraste los fallos de recopilación y el ámbito antes de aceptar un cero, y registre la decisión de autorización por separado del recuento del escáner.