Introduzione
Gli oggetti archiviati in Active Directory possono diventare obsoleti, danneggiati o orfani a causa di conflitti di replica.
Questo articolo è incentrato sugli oggetti attendibili che possono essere identificati dal bit "INTERDOMAIN_TRUST_ACCOUNT" nell'attributo userAccountControl . Per informazioni dettagliate su questo bit, vedere userAccountControl Bits.
Sintomi
Le relazioni di trust sono rappresentate in Active Directory da quanto segue:
-
Un account utente affisso da un carattere $ finale.
-
Oggetto TDO (Trusted Domain Object) archiviato nel contenitore System della partizione di directory di dominio.
La creazione di trust duplicati consente di creare due oggetti con nomi di account di Gestione account di sicurezza duplicati. Nel secondo oggetto SAM risolve il conflitto rinominando l'oggetto in $DUPLICATE-<Account RID>. L'oggetto duplicato non può essere eliminato e diventa "orfano".
Nota Si dice che un oggetto Active Directory sia "orfano" quando rappresenta un oggetto figlio in tempo reale archiviato in Active Directory il cui contenitore padre non è presente. Il termine viene talvolta usato anche per fare riferimento a un oggetto non aggiornato o danneggiato in Active Directory che non può essere eliminato con il normale flusso di lavoro.
Esistono due scenari di trust obsoleti principali:
-
Scenario 1: considerare attendibile l'utente in stato di conflitto
Può essere necessario eliminare un utente attendibile in scenari in cui sono presenti due foreste e in precedenza è stato creato un trust tra i domini di tali foreste. La prima volta che è stato creato l'attendibilità, si è verificato un problema che impediva la replica. Un amministratore potrebbe aver trasferito o sequestrato il ruolo Flexible Single Master Operation (FSMO) del controller di dominio primario (PDC) e creato nuovamente l'attendibilità in un altro controller di dominio.
Successivamente, quando viene ristabilita la replica di Active Directory, i due utenti attendibili verranno replicati nello stesso controller di dominio, causando un conflitto di denominazione. All'oggetto utente attendibile verrà assegnato un DN in conflitto (CNF); Per esempio:
CN=contoso$\0ACNF:a6e22a25-f60c-4f07-b629-64720c6d8b08,CN=Users,DC=northwindsales,DC=com
Anche il nome samAccountName verrà visualizzato ingrandito:
$DUPLICATE-3159f
L'oggetto senza conflitto di nomi apparirebbe normale e funzionerà correttamente. È possibile rimuovere e ricreare l'attendibilità.
-
Scenario 2: considera attendibile l'utente orfano
Analogamente allo scenario 1, potrebbe essere necessario modificare o eliminare un utente attendibile se il partner attendibile non esiste più, ma l'utente attendibile è ancora nel database di Active Directory. In genere, la password per questi account sarà obsoleta, causando la segnalazione dell'account da parte degli strumenti di analisi della sicurezza.
Messaggi di errore quando un amministratore tenta di modificare gli attributi di un trust
Non è possibile modificare gli attributi di chiave o eliminare l'oggetto utente con attendibilità orfana. Dopo il tentativo di modificare gli attributi che proteggono l'oggetto, viene visualizzato l'errore seguente:
|
Finestra di dialogo di errore |
Messaggio di errore |
 |
Operazione non riuscita. Codice errore: 0x209a L'accesso all'attributo non è consentito perché l'attributo è di proprietà di Security Accounts Manager (SAM). 0000209A: SvcErr: DSID-031A1021, problema 5003 (WILL_NOT_PERFORM), dati 0 |
Quando un amministratore tenta di rimuovere l'oggetto, non riesce con 0x5 di errore, che equivale a "Accesso negato". In alternativa, l'oggetto di trust in conflitto potrebbe non essere visualizzato nello snap-in "Domini e trust" di Active Directory.
|
Finestra di dialogo di errore |
Messaggio di errore |
 |
Operazione non riuscita. Codice errore: 0x5 Accesso negato. 00000005:SecErr:DSID-031A11ED,problema 4003 (INSUFF_ACCESS_RIGHTS), dati 0. |
Causa
Questo problema si verifica perché gli oggetti attendibili sono di proprietà del sistema e possono essere modificati o eliminati solo dagli amministratori che usano il MMC Domini e trust di Active Directory. Questa funzionalità è da progettazione.
Risoluzione
Dopo aver installato gli aggiornamenti di Windows del 14 maggio 2024 nei controller di dominio che eseguono Windows Server 2019 o una versione successiva di Windows Server, è ora possibile eliminare account attendibili orfani usando l'operazione schemaUpgradeIn Gmail. A tale scopo, esegui la procedura seguente:
-
Identificare un account utente di trust orfano nel dominio. Ad esempio, questo output da LDP.exe; mostra un flag userAccountControl di 0x800 che identifica l'utente attendibile:
Espansione della base ' CN=northwindsales$,CN=Users,DC=contoso,DC=com'... Ottenere 1 voce: Dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com …
primaryGroupID: 513 = ( GROUP_RID_USERS ); pwdLastSet: 27/4/2013 10:03:05 PM Coordinated Universal Time; sAMAccountName: NORTHWINDSALES$; sAMAccountType: 805306370 = ( TRUST_ACCOUNT ); userAccountControl: 0x820 = ( PASSWD_NOTREQD | INTERDOMAIN_TRUST_ACCOUNT) ;…
-
Se necessario, aggiungere un account di amministratore di dominio dal dominio degli account attendibili obsoleti al gruppo "Amministratori dello schema" nel dominio radice della foresta. L'account usato per l'eliminazione deve disporre dell'accesso al controllo "Control-Schema-Master" direttamente nella radice della replica NC schema E deve essere in grado di accedere al controller di dominio con l'account orfano.
-
Verificare che gli aggiornamenti di Windows del 14 maggio 2024 o versione successiva siano installati in un controller di dominio scrivibile nel dominio degli account attendibili obsoleti.
-
Accedere a tale controller di dominio con un account amministratore dello schema. Se è stato aggiunto un account al gruppo "Amministratori dello schema" nel passaggio 2, usare tale account.
-
Preparare un file di importazione LDIFDE per modificare SchemaUpgradeIn Gradual ed eliminare l'oggetto.Ad esempio, il testo seguente potrebbe essere incollato in un file di importazione LDIFDE per eliminare l'oggetto identificato nel passaggio 1:
Dn: changetype: modifica add: SchemaUpgradeIn Progress SchemaUpgradeIn Progress: 1 -
dn: CN=northwindsales$,CN=Users,DC=contoso,DC=com changetype: delete
Suggerimenti sulla sintassi LDIFDE:
-
La linea con un solo trattino ("-") è vitale, poiché termina la serie di modifiche sotto il tipo di modifica.
-
Anche la linea vuota dopo la linea con il trattino è essenziale, perché mostra LDIFDE che tutte le modifiche sull'oggetto sono completate e le modifiche devono essere approvate.
-
-
Importare il file LDIFDE usando la sintassi seguente:
ldifde /i /f nameOfLDIFFileCreatedInStep5.txt /j
Note
-
Il parametro /i indica un'operazione di importazione.
-
Il parametro /f seguito da un nome file indica il file contenente le modifiche.
-
Il parametro /j seguito da un percorso logfile scriverà un ldif.log e un file ldif.err con i risultati dell'aggiornamento, se la procedura ha funzionato e, in caso contrario, l'errore che si è verificato durante la mod.
-
Specificando un punto (".") con il parametro /j scriveranno i log nella directory di lavoro corrente.
-
-
Se necessario, rimuovere l'amministratore di dominio precedentemente aggiunto al passaggio 2 dal gruppo "Amministratori dello schema".
