KB5040758: Deleting a stale, corrupt, or orphaned Trust object in Active Directory

Introduction

Objects that are stored in Active Directory may become stale, corrupt, or orphaned caused by replication conflicts.

This article focuses on trust objects which can be identified by the “INTERDOMAIN_TRUST_ACCOUNT” bit in the userAccountControl attribute. For detailed information on this bit, see userAccountControl Bits.

Symptoms

Trust relationships are represented in Active Directory by the following:

• A user account affixed by a trailing $ character.

• A trusted domain object (TDO) stored in the System container of the domain directory partition.

Creating duplicate trusts will create two objects that have duplicate Security Account Manager (SAM) account names. On the second object, SAM resolves the conflict by renaming the object to $DUPLICATE-<Account RID>. The duplicate object cannot be deleted and becomes "orphaned."

There are two primary stale trust scenarios:

• Scenario 1: Trust user in conflict status

  A trust user may have to be deleted in scenarios where there are two forests and a trust was previously created between domains in those forests. When the trust was first created, there was a problem which prevented replication. An administrator may have transferred or seized the primary domain controller (PDC) Flexible Single Master Operation (FSMO) role and created the trust again on another domain controller (DC).

  Later, when the Active Directory replication is reestablished, the two trust users will replicate to the same DC, causing a naming conflict. The trust user object will be assigned a conflict (CNF)-mangled DN; for example:

  CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com

  The samAccountName will also appear mangled:

  $DUPLICATE-3159f

  The object without the name conflict would appear normal and function properly. It is possible to remove and recreate the trust.

• Scenario 2: Trust user orphaned

  Similarly as in Scenario 1, there may be a need to edit or delete a trust user if the trust and trust partner do not exist anymore, but the trust user is still in the Active Directory database. Typically, the password for these accounts will be old, causing that account to be flagged by security scanning tools.

Error messages when an Administrator tries to edit the attributes of a trust

It is not possible to change key attributes or delete the orphaned trust user object. The following error is given after attempting to change attributes that protect the object:

Error dialog box	Error message
	Operation failed. Error code: 0x209a Access to the attribute is not permitted because the attribute is owned by the Security Accounts Manager (SAM). 0000209A: SvcErr: DSID-031A1021, problem 5003 (WILL_NOT_PERFORM), data 0

When an administrator attempts to remove the object, it fails with error 0x5, which is the equivalent of “Access Denied.” Or the conflicted trust object might not appear in the Active Directory “Domains and Trusts” snap-in.

Error dialog box	Error message
	Operation failed. Error code: 0x5 Access is denied. 00000005:SecErr:DSID-031A11ED,problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.

Cause

This issue occurs because trust objects are owned by the system and can only be modified or deleted by administrators who use the Active Directory Domains and Trusts MMC. This functionality is by design.

Resolution

After installing the May 14, 2024 Windows Updates on domain controllers running Windows Server 2019 or a later version of Windows Server, it is now possible to delete orphaned trust accounts by using the schemaUpgradeInProgress operation. To do this, follow these steps:

1. Identify an orphaned trust user account in your domain. For example, this output from LDP.exe; shows a userAccountControl flag of 0x800 which identifies the trust user:

   Expanding base ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
   Getting 1 entries:
   Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   …

   primaryGroupID: 513 = ( GROUP_RID_USERS );
   pwdLastSet: 4/27/2013 10:03:05 PM Coordinated Universal Time;
   sAMAccountName: NORTHWINDSALES$;
   sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
   userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
   ;…

2. If necessary, add a domain administrator account from the stale trust accounts domain to the "Schema Admins" group in the forest root domain. (The account used for the deletion must have the “Control-Schema-Master” control access right on the root of the Schema NC replica AND must be able to logon to the DC holding the orphan account.)

3. Make sure that the May 14, 2024 or later Windows Updates are installed on a writeable DC in the stale trust accounts domain.

4. Logon to that DC with a Schema Administrator account. If you added an account to the "Schema Admins" group in Step 2, use that account.

5. Prepare an LDIFDE import file to modify SchemaUpgradeInProgress and delete the object.
   
   For example, the text below could be pasted into an LDIFDE import file to delete the object identified in Step 1:

   dn:
   changetype: modify
   add: SchemaUpgradeInProgress
   SchemaUpgradeInProgress: 1
   -

   dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   changetype: delete

   Hints on LDIFDE Syntax:

   • The line with only a hyphen ("-") is vital, as it terminates the series of changes under the "modify" changetype.

   • The empty line after the line with the hyphen is also vital, as it shows LDIFDE that all modifications on the object are completed and changes should be committed.

6. Import the LDIFDE file by using the following syntax:

   ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j

   Notes

   • The /i parameter indicates an import operation.

   • The /f parameter followed by a filename indicates the file containing the changes.

   • The /j parameter followed by a logfile path will write an ldif.log and an ldif.err file with the results of the update, whether the procedure worked, and if not, the error that occurred during the mod.

   • Specifying a period (“.”) with the /j parameter will write the logs in the current working directory.

7. If necessary, remove the domain administrator that was previously added in Step 2 from the "Schema Admins" group.