Introducere
Obiectele stocate în Active Directory pot deveni învechite, deteriorate sau solitare din cauza conflictelor de reproducere.
Acest articol se concentrează pe obiecte de încredere care pot fi identificate prin bitul "INTERDOMAIN_TRUST_ACCOUNT" din atributul userAccountControl . Pentru informații detaliate despre acest bit, consultați bitii userAccountControl.
Simptome
Relațiile de încredere sunt reprezentate în Active Directory prin următoarele:
-
Un cont de utilizator aplicat printr-un caracter la final $ .
-
Un obiect de domeniu de încredere (TDO) stocat în containerul sistem al partiției directorului de domeniu.
Crearea de autorizări dublate va crea două obiecte care au nume de cont SAM (Security Account Manager) dublate. Pe al doilea obiect, SAM rezolvă conflictul redenumind obiectul pentru a $DUPLICATE<>Account RID . Imposibil de șters obiectul dublat și devine "solitar".
Notă Se spune că un obiect Active Directory este "orfan" atunci când reprezintă un obiect fiu live stocat în Active Directory al cărui container părinte lipsește. Termenul este utilizat uneori și pentru a face referire la un obiect învechit sau deteriorat din Active Directory care nu poate fi șters utilizând fluxul de lucru normal.
Există două scenarii de încredere învechite principale:
-
Scenariul 1: Acordați încredere utilizatorului în starea de conflict
Poate fi necesar ca un utilizator de încredere să fie șters în scenariile în care există două păduri și s-a creat anterior o încredere între domeniile din acele păduri. Când a fost creată pentru prima dată încrederea, a apărut o problemă care împiedica reproducerea. Este posibil ca un administrator să fi transferat sau să fi preluat rolul de operațiune flexibilă de controler de domeniu (PDC) flexibilă unică (FSMO) și să fi creat din nou încrederea pe un alt controler de domeniu (DC).
Mai târziu, când reproducerea Active Directory este restabilită, cei doi utilizatori de încredere se vor reproduce în același DC, provocând un conflict de denumire. Obiectului utilizator de încredere i se va atribui un DN în unghi de conflict (CNF); de exemplu:
CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com
SamAccountName va apărea, de asemenea, în unghi:
$DUPLICATE-3159f
Obiectul fără conflict de nume ar apărea normal și ar funcționa corect. Este posibil să eliminați și să creați din nou încrederea.
-
Scenariul 2: Acordați încredere utilizatorului orfan
La fel ca în Scenariul 1, poate fi necesară editarea sau ștergerea unui utilizator de încredere dacă partenerul de încredere și de încredere nu mai există, dar utilizatorul de încredere se află încă în baza de date Active Directory. De obicei, parola pentru aceste conturi va fi veche, făcând ca acel cont să fie semnalizat de instrumentele de scanare de securitate.
Mesaje de eroare atunci când un administrator încearcă să editeze atributele unei autorizări
Nu este posibil să modificați atributele cheie sau să ștergeți obiectul solitar de utilizator de încredere. Următoarea eroare este dată după încercarea de a modifica atributele care protejează obiectul:
|
Error dialog box |
Mesaj de eroare |
 |
Operația nu a reușit. Cod de eroare: 0x209a 0000209A: SvcErr: DSID-031A1021, problemă 5003 (WILL_NOT_PERFORM), date 0 |
Atunci când un administrator încearcă să elimine obiectul, acesta nu reușește, având eroarea 0x5, care este echivalentă cu "Acces refuzat". Sau obiectul de încredere în conflict poate să nu apară în utilitarul de completare snap-in Active Directory "Domenii și autorizări".
|
Error dialog box |
Mesaj de eroare |
 |
Operația nu a reușit. Cod de eroare: 0x5
|
Cauza
Această problemă apare deoarece obiectele de încredere sunt deținute de sistem și pot fi modificate sau șterse numai de administratorii care utilizează MMC Active Directory Domains și Trusts. Această funcționalitate este proiectată.
Rezolvarea
După ce instalați actualizările Windows din 14 mai 2024 pe controlerele de domeniu care rulează Windows Server 2019 sau o versiune mai recentă de Windows Server, acum este posibil să ștergeți conturile de încredere solitare utilizând operațiunea schemaUpgradeInProgress. Pentru a face acest lucru, urmați acești pași:
-
Identificați un cont de utilizator solitar de încredere din domeniul dvs. De exemplu, acest rezultat din LDP.exe; afișează o semnalizare userAccountControl a 0x800 care identifică utilizatorul de încredere:
Se extinde baza ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'...
Se obțin 1 intrări:
Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
…primaryGroupID: 513 = ( GROUP_RID_USERS );
pwdLastSet: 27.04.2013 10:03:05 ORA universală;
sAMAccountName: NORTHWINDSALES$;
sAMAccountType: 805306370 = ( TRUST_ACCOUNT );
userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT )
;… -
Dacă este necesar, adăugați un cont de administrator de domeniu din domeniul de conturi de încredere învechit la grupul "Administratori schemă" din domeniul rădăcină al pădurii. (Contul utilizat pentru ștergere trebuie să aibă acces de control "Control-schemă-coordonator" direct în rădăcina reproducerii SCHEMA NC ȘI trebuie să se poată conecta la DC care deține contul solitar.)
-
Asigurați-vă că actualizările Windows din 14 mai 2024 sau mai recente sunt instalate pe un DC scriere din domeniul de conturi de încredere învechit.
-
Conectați-vă la acel DC cu un cont de administrator de schemă. Dacă ați adăugat un cont la grupul "Administratori schemă" la Pasul 2, utilizați acel cont.
-
Pregătiți un fișier de import LDIFDE pentru a modifica SchemaUpgradeInProgress și a șterge obiectul.
De exemplu, textul de mai jos poate fi lipit într-un fișier de import LDIFDE pentru a șterge obiectul identificat în Pasul 1:Dn:
changetype: modify
adăugare: SchemaUpgradeInProgress
SchemaUpgradeInProgress: 1
-dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com
tip modificare: ștergereIndicii pentru sintaxa LDIFDE:
-
Linia cu o cratimă ("-") este vitală, deoarece oprește seria de modificări de sub tipul de modificare "modify".
-
Linia goală de după linia cu cratima este, de asemenea, vitală, deoarece arată LDIFDE că toate modificările obiectului sunt finalizate și modificările ar trebui să fie comise.
-
-
Importați fișierul LDIFDE utilizând următoarea sintaxă:
ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j
Note
-
Parametrul /i indică o operațiune de import.
-
Parametrul /f urmat de un nume de fișier indică fișierul care conține modificările.
-
Parametrul /j urmat de o cale logfile va scrie un ldif.log și un fișier ldif.err cu rezultatele actualizării, dacă procedura a funcționat și, dacă nu, eroarea care a apărut în timpul mod.
-
Specificarea unui punct (".") cu parametrul /j va scrie jurnalele în directorul de lucru curent.
-
-
Dacă este necesar, eliminați administratorul de domeniu care a fost adăugat anterior la Pasul 2 din grupul "Administratori de schemă".
