KB5040758: Elavult, sérült vagy árva megbízhatósági objektum törlése az Active Directoryban

Ismertető

Az Active Directoryban tárolt objektumok elavulttá, sérülté vagy árvává válhatnak replikációs ütközések miatt.

Ez a cikk a userAccountControl attribútum "INTERDOMAIN_TRUST_ACCOUNT" bitje által azonosítható megbízhatósági objektumokra összpontosít. Erről a bitről részletes információt a userAccountControl Bits című témakörben talál.

Tünetek

A megbízhatósági kapcsolatokat a következők képviselik az Active Directoryban:

• Egy záró $ karakterrel rögzített felhasználói fiók.

• A tartományi címtárpartíció rendszertárolójában tárolt megbízható tartományi objektum (TDO).

Ismétlődő megbízhatósági kapcsolatok létrehozásakor két objektum jön létre, amelyek duplikált Security Account Manager- (SAM-) fióknevekkel rendelkeznek. A második objektumon a SAM úgy oldja fel az ütközést, hogy átnevezi az objektumot $DUPLICATE–<fiók relatív azonosítójának>. A duplikált objektum nem törölhető, és "árva" lesz.

Két elsődleges elavult megbízhatósági forgatókönyv létezik:

• 1. forgatókönyv: A felhasználó megbízhatósága ütközési állapotban

  Előfordulhat, hogy egy megbízhatósági felhasználót törölni kell olyan esetekben, amikor két erdő van, és korábban megbízhatósági kapcsolatot hoztak létre az erdők tartományai között. A megbízhatósági kapcsolat első létrehozásakor probléma lépett fel, amely megakadályozta a replikációt. Előfordulhat, hogy egy rendszergazda áthelyezte vagy lefoglalta az elsődleges tartományvezérlő (PDC) rugalmas egy főkiszolgálói művelet (FSMO) szerepkörét, és újból létrehozta a megbízhatósági kapcsolatot egy másik tartományvezérlőn (DC).

  Később, amikor az Active Directory-replikáció újra létrejön, a két megbízható felhasználó ugyanabba a tartományvezérlőre replikálódik, ami elnevezési ütközést okoz. A megbízhatósági felhasználói objektumhoz ütközés (CNF)-mangled DN lesz hozzárendelve; például:

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

  A samAccountName elem is megjelenik:

  $DUPLICATE-3159f

  A névütközés nélküli objektum normálnak tűnik, és megfelelően működik. A megbízhatósági kapcsolat eltávolítható és újból létrehozható.

• 2. forgatókönyv: Árva felhasználó megbízhatósága

  Az 1. forgatókönyvhöz hasonlóan szükség lehet egy megbízható felhasználó szerkesztésére vagy törlésére, ha a megbízhatósági és megbízhatósági partner már nem létezik, de a megbízhatósági felhasználó továbbra is az Active Directory-adatbázisban van. Ezeknek a fiókoknak a jelszava általában régi lesz, ezért a biztonsági ellenőrző eszközök megjelölik a fiókot.

Hibaüzenetek, amikor egy rendszergazda megpróbálja szerkeszteni egy megbízhatóság attribútumait

Nem lehet módosítani a kulcsattribútumokat, vagy törölni az árva megbízható felhasználói objektumot. Az objektumot védő attribútumok módosításának megkísérlése után a következő hibaüzenet jelenik meg:

Hiba párbeszédpanel	Hibaüzenet
	A művelet nem sikerült. Hibakód: 0x209a Az attribútumhoz való hozzáférés nem engedélyezett, mert az attribútum tulajdonosa a Security Accounts Manager (SAM). 0000209A: SvcErr: DSID-031A1021, probléma: 5003 (WILL_NOT_PERFORM), data 0

Amikor egy rendszergazda megpróbálja eltávolítani az objektumot, az 0x5 hibával hiúsul meg, ami a "Hozzáférés megtagadva" kifejezésnek felel meg. Vagy előfordulhat, hogy az ütköző megbízhatósági objektum nem jelenik meg az Active Directory "Tartományok és megbízhatóságok" beépülő moduljában.

Hiba párbeszédpanel	Hibaüzenet
	A művelet nem sikerült. Hibakód: 0x5 A hozzáférés megtagadva. 00000005:SecErr:DSID-031A11ED,problem 4003 (INSUFF_ACCESS_RIGHTS), data 0.

A jelenség oka

Ez a probléma azért fordul elő, mert a megbízhatósági objektumok a rendszer tulajdonában vannak, és csak az Active Directory Domains and Trusts MMC-t használó rendszergazdák módosíthatják vagy törölhetik őket. Ez a funkció szándékos.

Megoldás

Miután telepítette a 2024. május 14-i Windows-frissítéseket a Windows Server 2019 vagy a Windows Server újabb verzióját futtató tartományvezérlőkre, a schemaUpgradeInProgress művelettel törölheti az árva megbízhatósági fiókokat. Ehhez kövesse a következő lépéseket:

1. Azonosíthat egy árva megbízható felhasználói fiókot a tartományban. Ez a kimenet például LDP.exe; a 0x800 userAccountControljelölője, amely azonosítja a megbízhatósági felhasználót:

   A ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
   1 bejegyzés beolvasása:
   Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   …

   primaryGroupID: 513 = ( GROUP_RID_USERS );
   pwdLastSet: 4/27/2013 10:03:05 PM Koordinált egyetemes idő;
   sAMAccountName: NORTHWINDSALES$;
   sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
   userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
   ;…

2. Ha szükséges, adjon hozzá egy tartományi rendszergazdai fiókot az elavult megbízhatósági fiókok tartományából az erdő gyökértartományának "Sémagazdák" csoportjához. (A törléshez használt fióknak rendelkeznie kell a "Control-Schema-Master" vezérlő hozzáféréssel közvetlenül a séma NC-replikájának gyökerében, és képesnek kell lennie bejelentkezni az árva fiókot tartalmazó tartományvezérlőre.)

3. Győződjön meg arról, hogy a 2024. május 14-i vagy újabb Windows-frissítések egy írható tartományvezérlőre vannak telepítve az elavult megbízhatósági fiókok tartományában.

4. Jelentkezzen be a tartományvezérlőre sémaadminisztrátori fiókkal. Ha a 2. lépésben hozzáadott egy fiókot a "Sémagazdák" csoporthoz, használja ezt a fiókot.

5. Készítse elő az LDIFDE importálási fájlt a SchemaUpgradeInProgress módosításához és az objektum törléséhez.
   
   Az alábbi szöveg beilleszthető például egy LDIFDE-importáló fájlba az 1. lépésben azonosított objektum törléséhez:

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

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

   Tippek az LDIFDE szintaxishoz:

   • A csak kötőjelet ("-") tartalmazó sor létfontosságú, mivel leállítja a módosítássorozatot a "módosítás" típus alatt.

   • A kötőjelet tartalmazó sor utáni üres sor is létfontosságú, mivel az LDIFDE azt mutatja, hogy az objektum összes módosítása befejeződött, és a módosításokat véglegesíteni kell.

6. Importálja az LDIFDE-fájlt a következő szintaxissal:

   ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j

   Jegyzetek

   • Az /i paraméter importálási műveletet jelez.

   • Az /f paraméter és egy fájlnév jelzi a módosításokat tartalmazó fájlt.

   • A /j paraméter, majd egy logfile elérési útja egy ldif.log és egy ldif.err fájlt ír a frissítés eredményeivel, az eljárás működött-e, és ha nem, akkor a mod során bekövetkezett hiba.

   • Pont (".") megadása A /j paraméterrel a naplókat az aktuális munkakönyvtárba írja.

7. Ha szükséges, távolítsa el a 2. lépésben korábban hozzáadott tartományi rendszergazdát a "Sémagazdák" csoportból.