KB5040758: Odstranění zastaralého, poškozeného nebo osamoceného objektu důvěryhodnosti ve službě Active Directory

Úvod

Objekty uložené ve službě Active Directory můžou být zastaralé, poškozené nebo osamocené v důsledku konfliktů replikace.

Tento článek se zaměřuje na objekty důvěryhodnosti, které lze identifikovat pomocí "INTERDOMAIN_TRUST_ACCOUNT" bit v atributu userAccountControl . Podrobné informace o tomto bitu najdete v tématu userAccountControl Bits.

Příznaky

Vztahy důvěryhodnosti jsou ve službě Active Directory reprezentovány následujícím způsobem:

• Uživatelský účet připevněný koncovým znakem $

• Objekt důvěryhodné domény (TDO) uložený v kontejneru System oddílu adresáře domény.

Při vytváření duplicitních vztahů důvěryhodnosti se vytvoří dva objekty, které mají duplicitní názvy účtů Správce zabezpečení účtů (SAM). U druhého objektu sam konflikt vyřeší přejmenováním objektu na $DUPLICATE-<účet RID>. Duplicitní objekt nelze odstranit a stane se "osamocený".

Existují dva primární scénáře zastaralé důvěryhodnosti:

• Scénář 1: Důvěřovat uživateli ve stavu konfliktu

  Uživatele vztahu důvěryhodnosti může být potřeba odstranit ve scénářích, kdy existují dvě doménové struktury a mezi doménami v těchto doménových strukturách se dříve vytvořil vztah důvěryhodnosti. Při prvním vytvoření vztahu důvěryhodnosti došlo k problému, který bránil replikaci. Správce možná přenesl nebo zmocnil roli FSMO (Flexible Single Master Operation) primárního řadiče domény (PDC) a znovu vytvořil vztah důvěryhodnosti na jiném řadiči domény.

  Později, až se replikace služby Active Directory obnoví, budou dva důvěryhodní uživatelé replikovat do stejného řadiče domény, což způsobí konflikt názvů. Objekt uživatele důvěryhodnosti bude přiřazen konfliktem (CNF) mangled DN; například:

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

  Zobrazí se také mangled samAccountName:

  $DUPLICATE-3159f

  Objekt bez konfliktu názvů by vypadal normálně a správně fungoval. Vztah důvěryhodnosti je možné odebrat a znovu vytvořit.

• Scénář 2: Osamocený vztah důvěryhodnosti uživatele

  Podobně jako ve scénáři 1 může být potřeba upravit nebo odstranit uživatele vztahu důvěryhodnosti, pokud už vztah důvěryhodnosti a partner vztahu důvěryhodnosti neexistuje, ale uživatel vztahu důvěryhodnosti je stále v databázi služby Active Directory. Heslo pro tyto účty bude obvykle staré, což způsobí, že tento účet bude označený nástroji pro kontrolu zabezpečení.

Chybové zprávy, když se správce pokusí upravit atributy vztahu důvěryhodnosti

Není možné změnit klíčové atributy ani odstranit osamocený objekt uživatele důvěryhodnosti. Následující chyba se zobrazí po pokusu o změnu atributů, které chrání objekt:

Dialogové okno Chyba	Chybová zpráva
	Operace se nezdařila. Kód chyby: 0x209a Přístup k atributu není povolený, protože atribut vlastní správce zabezpečení účtů (SAM). 0000209A: SvcErr: DSID-031A1021, problém 5003 (WILL_NOT_PERFORM), data 0

Když se správce pokusí objekt odebrat, selže s chybou 0x5, což je ekvivalent "Přístup odepřen". Nebo se konfliktní objekt důvěryhodnosti nemusí zobrazit v modulu snap-in Domény a vztahy důvěryhodnosti služby Active Directory.

Dialogové okno Chyba	Chybová zpráva
	Operace se nezdařila. Kód chyby: 0x5 Přístup byl odepřen. 00000005:SecErr:DSID-031A11ED,problém 4003 (INSUFF_ACCESS_RIGHTS), data 0.

Příčina

K tomuto problému dochází, protože objekty důvěryhodnosti jsou vlastněny systémem a mohou být změněny nebo odstraněny pouze správci, kteří používají domény služby Active Directory a vztahy důvěryhodnosti MMC. Tato funkce je záměrně.

Řešení

Po instalaci aktualizací Windows z 14. května 2024 na řadičích domény se systémem Windows Server 2019 nebo novější verzí Windows Serveru je teď možné odstranit osamocené účty důvěryhodnosti pomocí operace schemaUpgradeInProgress. Postupujte takto:

1. Identifikujte osamocený důvěryhodný uživatelský účet ve vaší doméně. Například tento výstup z LDP.exe; zobrazuje příznak userAccountControl0x800 , který identifikuje důvěryhodného uživatele:

   Rozbaluje se základna CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
   Získání 1 položek:
   Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   …

   primaryGroupID: 513 = ( GROUP_RID_USERS );
   pwdLastSet: 27.4.2013 22:03:05 Koordinovaný univerzální čas;
   sAMAccountName: NORTHWINDSALES$;
   sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
   userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
   ;…

2. V případě potřeby přidejte účet správce domény ze zastaralé domény důvěryhodných účtů do skupiny Schema Admins v kořenové doméně doménové struktury. (Účet použitý k odstranění musí mít přístupové právo Control-Schema-Master v kořenovém adresáři repliky síťového adaptéru schématu a musí být schopný se přihlásit k řadiči domény, který má osamocený účet.)

3. Ujistěte se, že jsou aktualizace Windows z 14. května 2024 nebo novější nainstalované na zapisovatelném řadiči domény se zastaralými důvěryhodnými účty.

4. Přihlaste se k ho řadiči domény pomocí účtu správce schémat. Pokud jste v kroku 2 přidali účet do skupiny Schema Admins, použijte tento účet.

5. Připravte soubor importu LDIFDE pro úpravu SchemaUpgradeInProgress a odstraňte objekt.
   
   Například následující text může být vložen do souboru importu LDIFDE a odstranit tak objekt identifikovaný v kroku 1:

   Dn:
   changetype: modify
   add: SchemaUpgradeInProgress
   SchemaUpgradeInProgress: 1
   -

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

   Rady k syntaxi LDIFDE:

   • Řádek s pouze spojovníkem ("-") je důležitý, protože ukončuje řadu změn pod změnou typu "modify".

   • Prázdný řádek za řádkem se spojovníkem je také důležitý, protože LDIFDE ukazuje, že všechny úpravy objektu jsou dokončeny a změny by měly být potvrzeny.

6. Importujte soubor LDIFDE pomocí následující syntaxe:

   ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j

   Poznámky

   • Parametr /i označuje operaci importu.

   • Parametr /f následovaný názvem souboru označuje soubor obsahující změny.

   • Parametr /j následovaný cestou souboru protokolu zapíše ldif.log a soubor ldif.err s výsledky aktualizace, zda postup fungoval, a pokud ne, chyba, ke které došlo během modu.

   • Zadání tečky (".") pomocí parametru /j zapíše protokoly do aktuálního pracovního adresáře.

7. V případě potřeby odeberte správce domény, který byl dříve přidaný v kroku 2, ze skupiny Schema Admins.