Protección contra eliminación accidental: revisar las OU de AD

Qué hace la protección contra eliminación accidental de OU de AD

La protección contra eliminación accidental de OU de AD es una salvaguarda que debe revisarse antes de limpiar el directorio. Una unidad organizativa puede contener identidades y formar parte de una jerarquía administrativa de la que dependen otros equipos. Antes de eliminar o reorganizar esa jerarquía, determine qué OU deben conservarse, quién es responsable de la decisión y si los permisos reales del directorio proporcionan la protección prevista.

La referencia de Set-ADOrganizationalUnit de Microsoft describe ProtectedFromAccidentalDeletion como una propiedad booleana: cuando es true, el objeto no puede eliminarse sin cambiar la propiedad. Es una salvaguarda basada en permisos, más que un bloqueo inmutable. Los administradores que pueden retirar la protección siguen necesitando una decisión operativa revisada.

Esta guía práctica se revisó el 4 de octubre de 2026 con Microsoft Learn y el código fuente del recolector identificado más abajo. Todos los comandos son ejemplos documentales para el lector, no operaciones ejecutadas en el dominio de un cliente. Aquí no se afirma haber realizado ninguna eliminación, restauración ni comprobación satisfactoria de la protección.

Cómo funciona: permisos, valores de creación y recuperación

La protección se representa mediante permisos Deny

La protección utiliza dos permisos Deny para Everyone, identificado por el SID S-1-1-0: Delete y Delete Subtree. Las indicaciones para prevenir eliminaciones accidentales de Microsoft describen ACE Deny para DELETE y DELETE TREE en el objeto. También describen una denegación complementaria de DELETE CHILD en el elemento principal. Revise el objeto y su elemento principal cuando el comportamiento de los permisos no esté claro; no equipare una sola ACE coincidente con una evaluación completa de los permisos efectivos.

En Active Directory Users and Computers, active Advanced Features para mostrar la pestaña Object y su casilla de protección. Para revisar los permisos, inspeccione las entradas avanzadas de la pestaña Security, su destinatario, los derechos denegados y su ámbito. Las indicaciones de prevención citadas anteriormente documentan la casilla y el modelo de permisos subyacente. Conserve un registro de las entradas pertinentes en lugar de basarse únicamente en una captura de pantalla de una casilla marcada.

La distinción importa al comparar herramientas. Una propiedad extendida presenta una vista administrativa de la protección, mientras que un detector puede reconocer solo un subconjunto de las representaciones de permisos. Una revisión de ACL también debe considerar el elemento principal y el ámbito de cada entrada. Si esas observaciones discrepan, conserve la discrepancia e investíguela antes de cambiar los permisos.

La protección predeterminada al crear no audita las OU existentes

El ejemplo 1 de New-ADOrganizationalUnit crea una OU protegida sin establecer explícitamente el parámetro de protección. El ejemplo 2 crea explícitamente una OU sin protección con $False. Por tanto, un valor de creación predeterminado actual no establece el estado de las OU antiguas, migradas o modificadas posteriormente. Su protección puede ser distinta y debe leerse.

Nuestra guía de contenedores predeterminados y redirección utiliza esa protección implícita al crear OU de destino para redircmp y redirusr. Trata de la ubicación y el ámbito de las directivas de grupo. Revisar las salvaguardas contra eliminación de una OU existente es una tarea independiente; el ejemplo de creación no aporta un inventario ni una aprobación para la limpieza.

La prevención y la recuperación responden a preguntas diferentes

La protección pretende evitar una operación accidental. Las copias de seguridad y la recuperación de objetos abordan lo que ocurre después de perder datos. Las indicaciones sobre Recycle Bin de Microsoft explican que solo los objetos eliminados después de su habilitación pueden recuperarse mediante esa función. Compruebe por separado el estado real de la función y la preparación para la recuperación.

Nuestra guía de recuperación de bosques de Active Directory y validación de copias de seguridad explica la selección de copias, las pruebas de restauración y los límites de Recycle Bin. Úsela para la revisión complementaria de recuperación. Ni una OU protegida ni la disponibilidad de Recycle Bin demuestran que se haya validado una recuperación del bosque. Del mismo modo, preparar la recuperación no justifica dejar una OU de producción sin protección sin una excepción aceptada.

Detección: inventariar de forma independiente y leer la DACL

1. Establecer una recopilación satisfactoria y delimitada

Utilice un equipo de administración autorizado con el módulo PowerShell de Active Directory. Registre el dominio, el servidor consultado, la hora de recopilación, el contexto de las credenciales y el ámbito de búsqueda. Una lectura fallida o parcial debe figurar en las pruebas como un problema de recopilación sin resolver. No clasifique un objeto que no pueda leerse como desprotegido ni interprete un resultado vacío como un inventario completo.

El siguiente ejemplo para el lector adapta los parámetros documentados Filter y Properties de Get-ADOrganizationalUnit. Solicita explícitamente la propiedad extendida:

Get-ADOrganizationalUnit -Filter * -Properties ProtectedFromAccidentalDeletion

Elija el dominio y el servidor previstos en lugar de aceptar silenciosamente los valores predeterminados del equipo de administración. Learn también documenta Server, SearchBase y SearchScope para definir ese contexto. El comando anterior es un punto de partida para el inventario, no una garantía de exhaustividad en todo el bosque ni una instrucción para modificar cada resultado.

Para cada OU leída correctamente, conserve su nombre distintivo y su GUID de objeto junto con el valor de la propiedad. Añada el equipo de negocio o infraestructura responsable, la finalidad prevista y cualquier propuesta de decisión de limpieza. El equipo responsable es un dato de entrada para la revisión; no suponga que un atributo o un nombre de OU demuestra quién puede aprobar su eliminación.

2. Leer los permisos independientemente del recolector

Para un objeto concreto, el siguiente ejemplo solicita tanto la propiedad de protección como el descriptor de seguridad mediante el mismo mecanismo documentado Properties. El DN de Fabrikam es un marcador ficticio que debe sustituirse por el destino revisado:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Inspeccione la DACL del descriptor de seguridad devuelto con una herramienta autorizada de administración del directorio, o use la vista avanzada de Security en Active Directory Users and Computers. Confirme Everyone mediante su SID en lugar de depender de un nombre mostrado localizado. Examine las denegaciones Delete y Delete Subtree, si se aplican al objeto y los permisos pertinentes del elemento principal. Conserve las pruebas de permisos en bruto o exportadas cuando estén disponibles.

Esta lectura independiente debe conservar las entradas Deny. Reutilizar la lista de ACL filtrada del recolector reproduce exactamente la limitación investigada. Si falla el acceso al descriptor, registre el fallo y obtenga el acceso de lectura adecuado mediante el proceso habitual de administración. El valor de una propiedad y una lectura fallida de la DACL deben seguir siendo distinguibles.

3. Conciliar los hallazgos con las pruebas del directorio

Compare el inventario del recolector con el inventario administrativo leído correctamente. Utilice los identificadores de objetos y los DN reales para investigar las discrepancias. Una diferencia de escritura o de mayúsculas y minúsculas debe motivar una conciliación, en lugar de decidir que dos registros describen necesariamente objetos diferentes. Conserve los valores originales para explicar la búsqueda del recolector sensible a mayúsculas y minúsculas.

Un hallazgo no proporciona una cronología de ataque ni un historial de eliminación. No deduzca un compromiso, una intención maliciosa ni un incidente consumado a partir de esta señal de configuración. Si se ha producido una eliminación real, su investigación y recuperación necesitan pruebas independientes.

Remediación: proteger las OU seleccionadas y delimitar las excepciones de limpieza (Remediation)

1. Decidir el estado previsto con el responsable

Empiece por el inventario conciliado. Identifique las OU de producción que deben conservarse, las jerarquías de preparación, las excepciones de migración y los objetos propuestos para eliminación. Pida al equipo responsable que confirme las dependencias y los objetos exactos cubiertos por el cambio. Una OU aparentemente vacía no constituye por sí misma una solicitud de limpieza aprobada.

Registre las pruebas actuales de la propiedad y la DACL, el responsable de la decisión, el identificador de destino, el estado previsto y el método de verificación. Revise quién puede cambiar los permisos pertinentes. La protección no sustituye esa revisión administrativa, una copia de seguridad utilizable ni un plan de recuperación de objetos. Si la recopilación o la responsabilidad siguen siendo inciertas, mantenga el asunto abierto en lugar de convertir la incertidumbre en un cambio masivo.

2. Habilitar la protección en una OU conservada y aprobada

Este ejemplo para el lector utiliza los parámetros documentados Identity y ProtectedFromAccidentalDeletion de Set-ADOrganizationalUnit, estableciendo el booleano en true para un destino ficticio. Es un ejemplo de modificación dirigida, no una recomendación de canalizar todo el inventario hacia un cambio:

Set-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -ProtectedFromAccidentalDeletion $True

Aplique el cambio únicamente al objeto revisado mediante el flujo de administración autorizado. Guarde cualquier error y el resultado real de la operación. Una solicitud para establecer un valor es una prueba diferente de una actualización satisfactoria del directorio. Cuando falle un cambio, investigue el acceso y el contexto de destino antes de volver a intentarlo o ampliar los permisos.

3. Volver a leer el objeto y sus permisos pertinentes

Después de un cambio satisfactorio, recupere el destino de nuevo de forma independiente:

Get-ADOrganizationalUnit -Identity 'OU=UserAccounts,DC=FABRIKAM,DC=COM' -Properties ProtectedFromAccidentalDeletion,nTSecurityDescriptor

Confirme la propiedad e inspeccione la DACL utilizando el contexto de recopilación registrado. Conserve las pruebas anteriores y posteriores, así como cualquier discrepancia pendiente. Si otro servidor forma parte del plan de verificación, registre esa lectura por separado en lugar de suponer que todas las vistas del directorio ya son idénticas. Cierre el cambio únicamente conforme a las pruebas de aceptación previstas.

No intente una eliminación en producción para demostrar que la protección funciona. Esta guía exige una lectura de comprobación satisfactoria y una revisión de permisos; no prescribe una prueba destructiva. Un recuento del recolector que no cambie tampoco basta para declarar que esta modificación ha fracasado, dado el defecto del proveedor descrito más abajo.

4. Limitar la retirada de protección a la operación aprobada

La referencia Set de Microsoft incluye un ejemplo con $false para retirar la protección. Ese cambio corresponde únicamente a una decisión de limpieza o migración aprobada por separado. Registre el destino preciso, el motivo, el operador y el periodo de la excepción. Evite retirar las salvaguardas de toda una jerarquía solo para simplificar una operación.

Después del trabajo aprobado, vuelva a aplicar la protección a los objetos conservados que se hubieran exceptuado temporalmente y repita la revisión de la propiedad y la DACL. Si el objeto se eliminó intencionadamente, conserve las pruebas de aprobación y de la operación; no queda ningún objeto al que restablecer la protección. Una limpieza abandonada o fallida no debe dejar silenciosamente las OU conservadas sin su salvaguarda prevista.

Cómo detecta EtcSec este problema

La comprobación revisada de etc-collector es OU_UNPROTECTED, en public/internal/audit/detectors/ad/advanced/other/ou-unprotected.go:24. El detector y el proveedor LDAP se leyeron en el commit b767fc1ef7ea4cf52d797d5aea1dd4c2d3d07d7c; también se inspeccionó el mismo comportamiento pertinente en el HEAD del recolector 42bfefbace3189588e76ff291c39e100c6a603a0.

El detector construye un conjunto de DN de objetos protegidos a partir de las entradas de ACL suministradas. Una entrada solo cumple los requisitos cuando su tipo coincide con el nombre de tipo exacto ACCESS_DENIED, su destinatario es S-1-1-0 y su máscara de acceso contiene DELETE (0x10000). La comparación del nombre de tipo utiliza strings.EqualFold, por lo que ignora las mayúsculas y minúsculas en esa comparación; ACCESS_DENIED_OBJECT es un tipo distinto y no cumple los requisitos.

A continuación, busca cada ou.DN inventariado en ese conjunto mediante la clave de cadena ObjectDN. Esa coincidencia de DN distingue mayúsculas y minúsculas. Las OU sin coincidencia contribuyen al Count de un único hallazgo Low. El hallazgo se devuelve incluso con recuento cero; las entidades OU afectadas solo se añaden cuando se solicitan detalles y el recuento es positivo.

Pese al comentario más amplio sobre Delete y Delete Subtree, el predicado no comprueba DELETE_TREE (0x40). Tampoco comprueba el DELETE CHILD del elemento principal, los indicadores de ámbito de las ACE ni los derechos efectivos de eliminación. Una denegación Delete que cumpla los requisitos basta para su conjunto protegido, por lo que el predicado del detector por sí solo no puede validar la salvaguarda completa.

El proveedor impide una detección fiable de extremo a extremo en esta ruta revisada. En public/internal/providers/ldap/acl_parser.go:276, parseACE solo conserva ACE Allow. Las líneas 297-300 devuelven nil para tipos distintos de ACCESS_ALLOWED y ACCESS_ALLOWED_OBJECT, eliminando las ACE Deny que espera este detector. Con esa entrada filtrada, su conjunto protegido puede permanecer vacío y el recuento puede abarcar todas las OU inventariadas, incluidas OU que realmente están protegidas.

Se trata de una limitación de recopilación que exige una comprobación independiente de la propiedad y la DACL, no de una medición fiable de la falta de protección. Corregir el proveedor corresponde al equipo del recolector y queda fuera del ámbito de este artículo. No se afirma ningún éxito de detección de extremo a extremo ni ningún recuento de clientes.