Introducción
Los objetos almacenados en Active Directory pueden quedar obsoletos, dañados o huérfanos debido a conflictos de replicación.
Este artículo se centra en objetos de confianza que se pueden identificar por el bit "INTERDOMAIN_TRUST_ACCOUNT" en el atributo userAccountControl . Para obtener información detallada sobre este bit, consulte userAccountControl Bits.
Síntomas
Las relaciones de confianza se representan en Active Directory de la siguiente manera:
-
Una cuenta de usuario fija por un carácter $ final.
-
Un objeto de dominio de confianza (TDO) almacenado en el contenedor system de la partición del directorio de dominio.
La creación de confianzas duplicadas creará dos objetos que tengan nombres de cuenta duplicados del Administrador de cuentas de seguridad (SAM). En el segundo objeto, SAM resuelve el conflicto cambiando el nombre del objeto a $DUPLICATE<Account RID>. El objeto duplicado no se puede eliminar y queda "huérfano".
Nota Se dice que un objeto de Active Directory está "huérfano" cuando representa un objeto secundario activo almacenado en Active Directory cuyo contenedor principal falta. El término también se usa a veces para hacer referencia a un objeto obsoleto o dañado de Active Directory que no se puede eliminar mediante el flujo de trabajo normal.
Hay dos escenarios principales de confianza obsoleta:
-
Escenario 1: Confiar en el usuario en el estado de conflicto
Es posible que un usuario de confianza tenga que eliminarse en escenarios en los que hay dos bosques y anteriormente se creó una confianza entre dominios en esos bosques. Cuando se creó la confianza por primera vez, se produjo un problema que impedía la replicación. Un administrador puede haber transferido o incautado el rol de operación maestra única flexible (FSMO) del controlador de dominio principal (PDC) y haber creado la confianza de nuevo en otro controlador de dominio (DC).
Más adelante, cuando se restablezca la replicación de Active Directory, los dos usuarios de confianza replicarán en el mismo DC, lo que provocará un conflicto de nomenclatura. Al objeto de usuario de confianza se le asignará un conflicto (CNF)-mangled DN; por ejemplo:
CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com
El samAccountName también aparecerá como "mangled":
$DUPLICATE-3159f
El objeto sin el conflicto de nombres aparecería normal y funcionaba correctamente. Es posible quitar y volver a crear la confianza.
-
Escenario 2: Confiar en usuarios huérfanos
De forma similar al escenario 1, es posible que sea necesario editar o eliminar un usuario de confianza si el partner de confianza y confianza ya no existe, pero el usuario de confianza sigue estando en la base de datos de Active Directory. Por lo general, la contraseña de estas cuentas será antigua, lo que provocará que dicha cuenta se marque mediante herramientas de análisis de seguridad.
Mensajes de error cuando un administrador intenta editar los atributos de una confianza
No es posible cambiar los atributos clave ni eliminar el objeto de usuario de confianza huérfano. El siguiente error se produce después de intentar cambiar los atributos que protegen el objeto:
|
Cuadro de diálogo Error |
Mensaje de error |
 |
Error en la operación. Código de error: 0x209a 0000209A: SvcErr: DSID-031A1021, problema 5003 (WILL_NOT_PERFORM), datos 0 |
Cuando un administrador intenta quitar el objeto, se produce un error con el 0x5 de error, que es el equivalente a "Acceso denegado". O bien, el objeto de confianza en conflicto podría no aparecer en el complemento "Dominios y confianzas" de Active Directory.
|
Cuadro de diálogo Error |
Mensaje de error |
 |
Error en la operación. Código de error: 0x5
|
Causa
Este problema se produce porque los objetos de confianza son propiedad del sistema y solo pueden modificarlos o eliminarlos los administradores que usen la consola MMC Dominios y confianzas de Active Directory. Esta funcionalidad es por diseño.
Solución
Después de instalar las actualizaciones de Windows del 14 de mayo de 2024 en controladores de dominio que ejecutan Windows Server 2019 o una versión posterior de Windows Server, ahora es posible eliminar cuentas de confianza huérfanas mediante la operación schemaUpgradeInProgress. Para ello, siga estos pasos:
-
Identifique una cuenta de usuario de confianza huérfana en su dominio. Por ejemplo, esta salida de LDP.exe; muestra una marca userAccountControl de 0x800 que identifica al usuario de confianza:
Expandiendo base ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
Obtención de 1 entradas:
Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
…primaryGroupID: 513 = ( GROUP_RID_USERS );
pwdLastSet: 27/4/2013 10:03:05 p.m. Hora universal coordinada;
sAMAccountName: NORTHWINDSALES$;
sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
;… -
Si es necesario, agregue una cuenta de administrador de dominio del dominio de cuentas de confianza obsoletas al grupo "Administradores de esquema" del dominio raíz del bosque. (La cuenta utilizada para la eliminación debe tener el acceso de control "Control-Schema-Master" directamente en la raíz de la réplica del esquema NC Y debe poder iniciar sesión en el DC que contiene la cuenta huérfana).
-
Asegúrese de que las actualizaciones de Windows del 14 de mayo de 2024 o posteriores se instalan en un controlador de dominio que se pueda escribir en el dominio de cuentas de confianza obsoletas.
-
Inicie sesión en ese controlador de dominio con una cuenta de administrador de esquema. Si agregó una cuenta al grupo "Administradores de esquema" en el paso 2, use esa cuenta.
-
Preparar un archivo de importación LDIFDE para modificar SchemaUpgradeInProgress y eliminar el objeto.
Por ejemplo, el texto siguiente podría pegarse en un archivo de importación LDIFDE para eliminar el objeto identificado en el paso 1:Dn:
tipo de cambio: modificar
agregar: SchemaUpgradeInProgress
SchemaUpgradeInProgress: 1
-dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
tipo de cambio: eliminarSugerencias sobre la sintaxis de LDIFDE:
-
La línea con solo un guión ("-") es vital, ya que termina la serie de cambios en el tipo de cambio "modificar".
-
La línea vacía después de la línea con el guión también es vital, ya que muestra LDIFDE que todas las modificaciones en el objeto se han completado y los cambios deben confirmarse.
-
-
Importe el archivo LDIFDE con la siguiente sintaxis:
ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j
Notas
-
El parámetro /i indica una operación de importación.
-
El parámetro /f seguido de un nombre de archivo indica el archivo que contiene los cambios.
-
El parámetro /j seguido de una ruta de logfile escribirá un archivo ldif.log y un archivo ldif.err con los resultados de la actualización, si el procedimiento funcionó y, si no, el error que se produjo durante el mod.
-
Especificar un punto (".") con el parámetro /j escribirá los registros en el directorio de trabajo actual.
-
-
Si es necesario, quite el administrador de dominio agregado anteriormente en el paso 2 del grupo "Administradores de esquema".
