KB5040758: novecojuša, bojāta drošības kontroles objekta dzēšana pakalpojumā Active Directory

Ievads

Objekti, kas tiek glabāti pakalpojumā Active Directory, var kļūt novecojuši, bojāti vai bāreņrindņi, ko izraisa replicēšanas konflikti.

Šajā rakstā galvenā uzmanība ir pievērsta uzticības objektiem, kurus var noteikt "INTERDOMAIN_TRUST_ACCOUNT" bits userAccountControl atribūtā . Detalizētu informāciju par šo bitu versiju skatiet rakstā userAccountControl Bits.

Pazīmes

Uzticamības relācijas pakalpojumā Active Directory tiek attēlotas šādi:

• Lietotāja kontu ar beigu rakstzīmi $.

• Uzticams domēna objekts (TDO), kas glabājas domēna direktorija nodalījuma sistēmas konteinerā.

Izveidojot uzticamības dublikātus, tiks izveidoti divi objekti, kuriem ir drošības kontu pārvaldnieka (SAM) kontu nosaukumu dublikāti. Otrajā objektā SAM novērš konfliktu, pārdēvējot objektu, $DUPLICATE -<Account RID>. Objekta dublikātu nevar izdzēst un tas kļūst par "bāreņrindām".

Pastāv divi primārie novecojušu drošības kontroles scenāriji:

• 1. scenārijs. Uzticēties lietotājam konflikta statusā

  Uzticams lietotājs, iespējams, būs jāizdzēš scenārijos, kad ir divi meži un starp šiem mežiem iepriekš tika izveidota uzticamība. Kad uzticamība pirmo reizi tika izveidota, radās problēma, kas liedza replicēšanu. Administrators, iespējams, ir pārskaitis vai izveidojis primārā domēna kontrollera (PDC) elastīgo vienotās šablona operācijas (Single Master Operation — FSMO) lomu un no jauna izveidojis uzticēšanos citai domēna kontrollerim (DC).

  Vēlāk, kad Active Directory replicēšana tiek atjaunota, abi uzticamie lietotāji replicēs vienu un to pašu DC, izraisot nosaukumdošanas konfliktu. Uzticēšanās lietotāja objektam tiks piešķirts konflikts (CNF)-mangled DN. piemēram:

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

  SamAccountName arī izskatīsies kā mangled:

  $DUPLICATE-3159f

  Objekts bez nosaukuma konflikta būtu redzams kā parasts un darbojas pareizi. Ir iespējams noņemt un atkārtoti izveidot uzticamību.

• 2. scenārijs. Uzticēties lietotājam bez ierindības

  Tāpat kā 1. scenārijā, var būt nepieciešams rediģēt vai izdzēst uzticamu lietotāju, ja uzticēšanās un drošības kontroles partneris vairs nepastāv, bet drošības kontroles lietotājs joprojām ir Active Directory datu bāzē. Parasti šo kontu parole būs veca, tāpēc drošības skenēšanas rīki atzīmē šo kontu.

Kļūdu ziņojumi, ja administrators mēģina rediģēt uzticamības atribūtus

Nav iespējams mainīt atslēgas atribūtus vai izdzēst uzticamo lietotāja objektu bez izmaiņām. Pēc tam, kad mēģināt mainīt atribūtus, kas aizsargā objektu, tiek parādīts šāds kļūdas ziņojums:

Error dialog box	Kļūdas ziņojums
	Darbība neizdevās. Kļūdas kods: 0x209a Piekļuve atribūtam nav atļauta, jo atribūts pieder drošības kontu pārvaldniekam (SECURITY Accounts Manager — SAM). 0000209A: SvcErr: DSID-031A1021, problēma 5003 (WILL_NOT_PERFORM), dati 0

Ja administrators mēģina noņemt objektu, tam neizdodas kļūdas ziņojums 0x5, kas ir ekvivalents "Piekļuve liegta". Vai arī konfliktētais uzticamības objekts var neparādīties Active Directory pievienojumprogrammā "Domēni un uzticamības".

Error dialog box	Kļūdas ziņojums
	Darbība neizdevās. Kļūdas kods: 0x5 Piekļuve ir liegta. 00000005:SecErr:DSID-031A11ED,problēma 4003 (INSUFF_ACCESS_RIGHTS), dati 0.

Iemesls

Šī problēma rodas tāpēc, ka drošības kontroles objekti pieder sistēmai un tos var modificēt vai izdzēst tikai administratori, kuri izmanto Active Directory domēnus un uzticamības MMC. Šī funkcionalitāte ir ar nolūku.

Risinājums

Pēc 2024. gada 14. maija Windows atjauninājumu instalēšanas domēnu kontrolleros, kuros darbojas Windows Server 2019 vai jaunāka Windows Server versija, tagad ir iespējams dzēst bez elementiem uzticamos kontus, izmantojot operāciju schemaUpgradeInProgress. Lai to izdarītu, veiciet tālāk norādītās darbības.

1. Savā domēnā identificējiet neuzticamu lietotāju kontu. Piemēram, šī izvade no LDP.exe; Parāda grupas karodziņu userAccountControl0x800 kas identificē uzticamu lietotāju:

   Izvēršanas bāze ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
   1 ierakstu iegūšana:
   Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
   …

   primaryGroupID: 513 = ( GROUP_RID_USERS );
   pwdLastSet: 27.04.2013. 10:03:05 PM universālais koordinētais laiks;
   sAMAccountName: NORTHWINDSALES$;
   sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
   userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
   ;…

2. Ja nepieciešams, pievienojiet domēna administratora kontu no novecojuša drošības kontroles kontu domēna grupai "Shēmas administratori" meža saknes domēnā. (Kontam, kas tiek izmantots dzēšanai, ir jābūt "Control-Schema-Master" vadīklas piekļuvei tieši shēmas NC dublikāta saknē, UN tam ir jāpiesakās DC, turot bāreņrindņa kontu.)

3. Pārliecinieties, vai 2024. gada 14. maija vai jaunāka versija Windows atjauninājumi ir instalēti rakstāmā DC novecojušu drošības kontroles kontu domēnā.

4. Piesakieties šajā DC ar shēmas administratora kontu. Ja 2. darbības grupā "Shēmas administratori" esat pievienojis kontu, izmantojiet šo kontu.

5. Sagatavojiet importēšanas failu LDIFDE , lai modificētu schemaUpgradeInProgress un dzēstu objektu.
   
   Piemēram, tālāk esošo tekstu var ielīmēt LDIFDE importēšanas failā, lai izdzēstu objektu, kas identificēts 1. darbībā.

   Dn:
   changetype: modify
   pievienot: SchemaUpgradeInProgress
   SchemaUpgradeInProgress: 1
   -

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

   Ieteikumi par LDIFDE sintaksi:

   • Līnija ar tikai pārnesumzīmi ("-") ir svarīga, jo tā pārtrauc izmaiņu sēriju zem izmaiņu tipa "modificēt".

   • Tukšā rindiņa aiz tās rindiņas arī ir svarīga, jo tā parāda LDIFDE, ka visas objekta modifikācijas ir pabeigtas un ir jāveic izmaiņas.

6. Importējiet LDIFDE failu ar šādu sintaksi:

   ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j

   Piezīmes

   • Parametrs /i norāda importēšanas darbību.

   • Parametrs /f, kam seko faila nosaukums, norāda failu, kurā ir izmaiņas.

   • Parametrs /j, kam seko logfile ceļš, uzrakstiet ldif.log un ldif.err failu ar atjaunināšanas rezultātiem, vai procedūra darbojās un, ja tā nav, kļūda, kas radās modā.

   • Punkta norādīšana (".") ar parametru /j pierakstīs žurnālus pašreizējā darba direktorijā.

7. Ja nepieciešams, noņemiet domēna administratoru, kas iepriekš tika pievienots 2. darbībā, no grupas "Shēmas administratori".