Condividi tramite

Risoluzione dei problemi: Protezione password di Microsoft Entra locale

  • Articolo

Dopo la distribuzione di Microsoft Entra Password Protection, potrebbe essere necessaria la risoluzione dei problemi. Questo articolo illustra in dettaglio alcuni passaggi comuni per la risoluzione dei problemi.

L'agente del controller di dominio non riesce a individuare un proxy nella directory

Il sintomo principale di questo problema è la presenza di 30,017 eventi nel registro eventi amministrativi dell'agente del controller di dominio.

La causa consueta di questo problema è che un proxy non è stato registrato. Se un proxy è registrato, potrebbe verificarsi un certo ritardo a causa della latenza di replica di Active Directory fino a quando un determinato agente del controller di dominio non è in grado di visualizzare tale proxy.

L'agente del controller di dominio non è in grado di comunicare con un server proxy

Il sintomo principale di questo problema è 30,018 eventi nel registro eventi dell'agente del controller di dominio Admin. Questo problema può avere diverse possibili cause:

  • L'agente DC si trova in una parte isolata della rete che non consente la connettività di rete ai proxy registrati. Questo problema può essere non dannoso, purché altri agenti del controller di dominio possano comunicare con il/i proxy per scaricare i criteri delle password da Azure. Dopo il download, questi criteri vengono ottenuti dal controller di dominio isolato tramite la replica dei file di criteri nella condivisione sysvol.

  • La macchina host del proxy blocca l'accesso al mapper dell'endpoint RPC (porta 135)

    Il programma di installazione di Microsoft Entra Password Protection Proxy crea automaticamente una regola in ingresso di Windows Firewall che consente l'accesso alla porta 135. Se questa regola viene eliminata o disabilitata in un secondo momento, gli agenti del controller di dominio non riescono a comunicare con il servizio proxy. Se Windows Firewall predefinito è disabilitato al posto di un altro prodotto firewall, è necessario configurare tale firewall per consentire l'accesso alla porta 135.

  • Il computer host del proxy sta bloccando l'accesso all'endpoint RPC (dinamico o statico) a cui è in ascolto il servizio proxy.

    Il programma di installazione di Microsoft Entra Password Protection Proxy crea automaticamente una regola in entrata per Windows Firewall che consente l'accesso a tutte le porte in entrata ascoltate dal servizio Proxy di protezione password di Microsoft Entra. Se questa regola viene eliminata o disabilitata in un secondo momento, gli agenti del controller di dominio non riescono a comunicare con il servizio proxy. Se il firewall predefinito di Windows è disabilitato per usare un altro prodotto firewall, è necessario configurare quel firewall per consentire l'accesso a tutte le porte in ingresso ascoltate dal servizio Proxy di protezione password di Microsoft Entra. Questa configurazione può essere resa più specifica se il servizio proxy è configurato per l'ascolto su una porta RPC statica specifica (usando il cmdlet Set-AzureADPasswordProtectionProxyConfiguration).

  • La macchina host proxy non è configurata per consentire ai controller di dominio di accedere alla macchina. Questo comportamento viene controllato tramite l'assegnazione dei privilegi utente "Accedere a questo computer dalla rete". A tutti i controller di dominio in tutti i domini della foresta devono essere concessi questo privilegio. Questa impostazione è spesso vincolata come parte di una maggiore protezione avanzata della rete.

Il servizio proxy non è in grado di comunicare con Azure

  1. Verificare che il computer proxy abbia connettività agli endpoint elencati nei requisiti di distribuzione .

  2. Assicurarsi che la foresta e tutti i server proxy siano registrati sotto lo stesso tenant di Azure.

    È possibile controllare questo requisito eseguendo i cmdlet di PowerShell Get-AzureADPasswordProtectionProxy e Get-AzureADPasswordProtectionDCAgent, quindi confrontare la proprietà AzureTenant di ogni elemento restituito. Per il corretto funzionamento, il nome del tenant segnalato deve essere lo stesso in tutti gli agenti DC e i server proxy.

    Se esiste una condizione di mancata corrispondenza della registrazione del tenant di Azure, questo problema può essere risolto eseguendo i cmdlet di PowerShell Register-AzureADPasswordProtectionProxy e/o Register-AzureADPasswordProtectionForest in base alle esigenze, assicurandosi di usare le credenziali dello stesso tenant di Azure per tutte le registrazioni.

L'agente del controller di dominio non è in grado di crittografare o decrittografare i file dei criteri password

La protezione password di Microsoft Entra ha una dipendenza critica dalla funzionalità di crittografia e decrittografia fornita dal servizio di distribuzione delle chiavi Microsoft. Gli errori di crittografia o decrittografia possono manifestarsi con vari sintomi e avere diverse possibili cause.

  • Verificare che il servizio KDS sia abilitato e funzionante in tutti i controller di dominio di Windows Server 2012 e versioni successive in un dominio.

    Per impostazione predefinita, la modalità di avvio del servizio KDS è configurata come Manuale (Avvio trigger). Questa configurazione significa che la prima volta che un client tenta di usare il servizio, viene avviato su richiesta. Questa modalità di avvio del servizio predefinita è accettabile per il funzionamento di Microsoft Entra Password Protection.

    Se la modalità di avvio del servizio KDS è configurata su Disabilitato, questa configurazione deve essere corretta prima che Microsoft Entra Password Protection funzioni correttamente.

    Un semplice test per questo problema consiste nell'avviare manualmente il servizio KDS, tramite la console MMC di gestione dei servizi o usando altri strumenti di gestione( ad esempio, eseguire "net start kdssvc" da una console del prompt dei comandi). Si prevede che il servizio KDS venga avviato correttamente e rimanga in esecuzione.

    La causa principale più comune per cui il servizio KDS non è in grado di essere avviato è che l'oggetto controller di dominio Active Directory si trova all'esterno dell'Unità Organizzativa dei controller di dominio predefiniti. Questa configurazione non è supportata dal servizio KDS e non è una limitazione imposta da Microsoft Entra Password Protection. La correzione per questa condizione consiste nello spostare l'oggetto controller di dominio in una posizione sotto l'unità organizzativa predefinita dei controller di dominio.

  • Modifica del formato del buffer crittografato KDS non compatibile da Windows Server 2012 R2 a Windows Server 2016

    Una correzione di sicurezza KDS è stata introdotta in Windows Server 2016 che modifica il formato dei buffer crittografati KDS. Questi buffer talvolta non riescono a decrittografare in Windows Server 2012 e Windows Server 2012 R2. La direzione inversa va bene. I buffer crittografati da KDS in Windows Server 2012 e Windows Server 2012 R2 vengono sempre decrittografati correttamente in Windows Server 2016 e versioni successive. Se i controller di dominio nei domini di Active Directory eseguono una combinazione di questi sistemi operativi, possono essere segnalati occasionalmente dei guasti nella decrittografia della protezione password di Microsoft Entra. Non è possibile stimare con precisione i tempi o i sintomi di questi errori in base alla natura della correzione della sicurezza. Inoltre, dato che non è deterministico che Microsoft Entra Password Protection DC Agent su cui controller di dominio crittografa i dati in un determinato momento.

    Non esiste una soluzione alternativa per questo problema diverso da non eseguire una combinazione di questi sistemi operativi incompatibili nei domini di Active Directory. In altre parole, è consigliabile eseguire solo i controller di dominio Windows Server 2012 e Windows Server 2012 R2 oppure è consigliabile eseguire solo i controller di dominio Windows Server 2016 e versioni successive.

L'agente DC pensa che la foresta non sia stata registrata.

Il sintomo di questo problema è rappresentato da 30.016 eventi che vengono registrati nel canale DC Agent\Admin che riporta in parte:

The forest hasn't been registered with Azure. Password policies can't be downloaded from Azure unless this is corrected.

Esistono due possibili cause per questo problema.

  • La foresta non è stata registrata. Per risolvere il problema, eseguire il comando Register-AzureADPasswordProtectionForest come descritto nei requisiti di distribuzione .
  • La foresta è registrata, ma l'agente del controller di dominio non è in grado di decrittografare i dati di registrazione della foresta. Questo caso ha la stessa causa principale del problema #2 elencato nella sezione , dove l'agente del controller di dominio non è in grado di crittografare o decrittografare i file delle politiche delle password. Un modo semplice per confermare questa teoria è che questo errore si verificherà solo sugli agenti DC che girano su controller di dominio Windows Server 2012 o Windows Server 2012R2, mentre gli agenti DC che operano su controller di dominio Windows Server 2016 e successivi funzionano normalmente. La soluzione alternativa è la stessa: aggiornare tutti i controller di dominio a Windows Server 2016 o versione successiva.

Le password deboli vengono accettate ma non dovrebbero essere accettate.

Questo problema può avere diverse cause.

  • I tuoi agenti DC stanno eseguendo una versione del software di anteprima pubblica che è scaduta. Verifica il software dell'agente del controller di dominio di anteprima pubblica è scaduto.

  • Gli agenti DC non possono scaricare una policy o non sono in grado di decrittografare le policy esistenti. Verificare le possibili cause negli articoli precedenti.

  • La modalità di applicazione della politica della password è ancora impostata su Controlla. Se questa configurazione è attiva, riconfigurarla per imporre l'utilizzo del portale di protezione password di Microsoft Entra. Per altre informazioni, vedere Modalità di funzionamento.

  • I criteri password sono disabilitati. Se questa configurazione è attiva, riconfigurarla in modo che sia abilitata tramite il portale di protezione password di Microsoft Entra. Per altre informazioni, vedere Modalità di funzionamento.

  • Non hai installato il software agente DC su tutti i controller di dominio nel dominio. In questa situazione, è difficile garantire che i client Windows remoti puntino a un particolare controller di dominio durante un'operazione di modifica della password. Se pensi di aver individuato con successo un particolare controller di dominio in cui è installato il software agente, puoi verificarlo ricontrollando il registro eventi dell'amministratore dell'agente del controller di dominio: indipendentemente dal risultato, c'è almeno un evento per documentare l'esito della convalida della password. Se non è presente alcun evento per l'utente la cui password viene modificata, è probabile che la modifica della password sia stata elaborata da un controller di dominio diverso.

    Come test alternativo, provare a impostare o modificare le password accedendo direttamente a un domain controller su cui è installato il software dell'agente del controller di dominio. Questa tecnica non è consigliata per i domini di Active Directory di produzione.

    Sebbene la distribuzione incrementale del software dell'agente DC sia supportata, soggetta a queste limitazioni, Microsoft consiglia vivamente di installare il software dell'agente DC su tutti i domain controller di un dominio il prima possibile.

  • L'algoritmo di convalida delle password può effettivamente funzionare come previsto. Vedere Come vengono valutate le password.

Ntdsutil.exe non riesce a impostare una password DSRM debole

Active Directory convalida sempre una nuova password della Modalità di ripristino dei Servizi di Directory per assicurarsi che soddisfi i requisiti di complessità delle password del dominio; questa convalida utilizza anche le DLL di filtro delle password, come Microsoft Entra Password Protection. Se la nuova password DSRM viene rifiutata, viene visualizzato il messaggio di errore seguente:

C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
        WIN32 Error Code: 0xa91
        Error Message: Password doesn't meet the requirements of the filter dll's

Quando Microsoft Entra Password Protection registra gli eventi di convalida della password per una password DSRM di Active Directory, ci si aspetta che i messaggi del registro degli eventi non includano il nome utente. Questo comportamento si verifica perché l'account DSRM è un account locale che non fa parte del dominio Active Directory effettivo.

La promozione della replica del controller di dominio non riesce a causa di una password DSRM debole

Durante il processo di promozione del controller di dominio, la nuova password della modalità di ripristino dei servizi directory viene inviata a un controller di dominio esistente nel dominio per la convalida. Se la nuova password DSRM viene rifiutata, viene visualizzato il messaggio di errore seguente:

Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password doesn't meet a requirement of the password filter(s). Supply a suitable password.

Proprio come nella questione precedente, qualsiasi evento relativo all'esito della convalida delle password di Microsoft Entra Password Protection avrà nomi utente vuoti per questo scenario.

L'abbassamento di livello del controller di dominio non riesce a causa di una password amministratore locale debole

È possibile declassare un controller di dominio che sta ancora eseguendo il software dell'agente DC. Gli amministratori devono tuttavia tenere presente che il software agente del controller di dominio continua ad applicare la politica corrente delle password durante la procedura di demozione. La nuova password dell'account amministratore locale (specificata come parte dell'operazione di abbassamento di livello) viene convalidata come qualsiasi altra password. Microsoft consiglia di scegliere password sicure per gli account Amministratore locale come parte della procedura di rimozione di un Domain Controller.

Una volta completato il declassamento e riavviato il controller di dominio, che funziona nuovamente come un normale server membro, il software agente del controller di dominio torna a operare in modalità passiva. Può quindi essere disinstallato in qualsiasi momento.

Avvio in modalità di ripristino dei servizi directory

Se il controller di dominio viene avviato in modalità ripristino servizi directory, la DLL del filtro password dell'agente del controller di dominio rileva questa condizione e determina la disabilitazione di tutte le attività di convalida o imposizione delle password, indipendentemente dalla configurazione dei criteri attualmente attiva. La DLL del filtro password dell'agente del controller di dominio registra un evento di avviso 10023 nel registro eventi di amministrazione, ad esempio:

The password filter dll is loaded but the machine appears to be a domain controller that is booted into Directory Services Repair Mode. All password change and set requests are automatically approved. No further messages are logged until after the next reboot.

Il software agente per DC di anteprima pubblica è scaduto

Durante il periodo di anteprima pubblica di Microsoft Entra Password Protection, il software agente del controller del dominio è stato programmato in modo fisso per cessare l'elaborazione delle richieste di convalida delle password nelle date seguenti:

  • La versione 1.2.65.0 ha interrotto l'elaborazione delle richieste di convalida delle password il 1° settembre 2019.
  • Versione 1.2.25.0 e quelle precedenti hanno interrotto l'elaborazione delle richieste di convalida delle password il 1° luglio 2019.

Con l'avvicinarsi della scadenza, tutte le versioni limitate dell'agente DC emettono un evento 10021 nel registro degli eventi amministrativi dell'agente DC al momento dell'avvio, simile a questo:

The password filter dll has successfully loaded and initialized.

The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll no longer processes passwords. Please contact Microsoft for a newer supported version of the software.

Expiration date:  9/01/2019 0:00:00 AM

This message won't be repeated until the next reboot.

Una volta superata la scadenza, tutte le versioni a tempo limitato dell'Agente DC generano un evento 10022 nel registro eventi di amministrazione dell'Agente DC al momento dell'avvio, simile al seguente:

The password filter dll is loaded but the allowable trial period has expired. All password change and set requests are automatically approved. Please contact Microsoft for a newer supported version of the software.

No further messages are logged until after the next reboot.

Poiché la scadenza viene controllata solo al primo avvio, potresti non vedere questi eventi fino a molto dopo che la scadenza del calendario è passata. Una volta riconosciuta la scadenza, non si verificano effetti negativi né sul controller di dominio né sull'ambiente più ampio, ad eccezione del fatto che tutte le password vengono approvate automaticamente.

Importante

Microsoft consiglia di aggiornare immediatamente gli agenti del controller di dominio di anteprima pubblica scaduti alla versione più recente.

Un modo semplice per individuare gli agenti del controller di dominio presenti nell'ambiente che devono essere aggiornati è eseguire il cmdlet Get-AzureADPasswordProtectionDCAgent, ad esempio:

PS C:\> Get-AzureADPasswordProtectionDCAgent

ServerFQDN            : bpl1.bpl.com
SoftwareVersion       : 1.2.125.0
Domain                : bpl.com
Forest                : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC          : 8/1/2019 10:00:00 PM
AzureTenant           : bpltest.onmicrosoft.com

Per questo articolo, il campo SoftwareVersion è ovviamente la proprietà chiave da esaminare. È anche possibile usare il filtro di PowerShell per filtrare gli agenti DC che sono già alla o sopra la versione di riferimento richiesta, ad esempio:

PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}

Il software Microsoft Entra Password Protection Proxy non ha una limitazione di tempo in nessuna versione. Microsoft consiglia comunque di aggiornare sia i controller di dominio che gli agenti proxy alle versioni più recenti man mano che vengono rilasciati. Il cmdlet Get-AzureADPasswordProtectionProxy può essere usato per trovare gli agenti proxy che richiedono aggiornamenti, come nell'esempio sopra per gli agenti DC.

Per ulteriori dettagli sulle specifiche procedure di aggiornamento, fare riferimento a Aggiornamento del DC agent e Aggiornamento del servizio proxy.

Bonifica di emergenza

Se si verifica una situazione in cui il servizio agente del controller di dominio causa problemi, il servizio agente del controller di dominio potrebbe essere arrestato immediatamente. La DLL del filtro password dell'agente del controller di dominio tenta comunque di chiamare il servizio non in esecuzione e registra gli eventi di avviso (10012, 10013), ma tutte le password in ingresso vengono accettate durante tale periodo. Il servizio agente di DC può quindi essere configurato anche tramite Servizi di Controllo Windows con un tipo di avvio "Disabilitato" in base alle esigenze.

Un'altra misura di correzione è quella di impostare la modalità Abilita su No nel portale di protezione password di Microsoft Entra. Dopo che la politica aggiornata è stata scaricata, ogni servizio agente del controller di dominio passa a una modalità di quiescenza in cui tutte le password vengono accettate as-is. Per altre informazioni, vedere Modalità di funzionamento.

Rimozione

Se si decide di disinstallare il software di protezione password di Microsoft Entra e di rimuovere tutti gli stati correlati dai domini e dalla foresta, questa attività può essere eseguita seguendo questa sequenza di passi:

Importante

È importante eseguire questi passaggi in ordine. Se un'istanza del servizio Proxy viene lasciata in esecuzione, ricrea periodicamente il suo oggetto "serviceConnectionPoint". Se qualsiasi istanza del servizio agente del controller di dominio viene lasciata in esecuzione, essa ricrea periodicamente il suo oggetto serviceConnectionPoint e lo stato sysvol.

  1. Disinstallare il software proxy da tutti i computer. Questo passaggio non richiede un riavvio.

  2. Disinstallare il software DC Agent da tutti i controller di dominio. Questo passaggio richiede un riavvio.

  3. Rimuovere manualmente tutti i punti di connessione del servizio proxy in ogni contesto di denominazione del dominio. Il percorso di questi oggetti può essere individuato con il comando di PowerShell di Active Directory seguente:

    $scp = "serviceConnectionPoint"
$keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Non omettere l'asterisco ("*") alla fine del valore della variabile $keywords.

    Gli oggetti risultanti trovati tramite il comando Get-ADObject possono quindi essere inviati tramite pipe a Remove-ADObjecto eliminati manualmente.

  4. Rimuovere manualmente tutti i punti di connessione dell'agente del controller di dominio in ogni contesto di denominazione del dominio. Può essere presente un oggetto di questi per ogni controller di dominio nella foresta, a seconda di quanto ampiamente è stato distribuito il software. Il percorso di tale oggetto può essere individuato con il comando di PowerShell di Active Directory seguente:

    $scp = "serviceConnectionPoint"
$keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }

    Gli oggetti risultanti trovati tramite il comando Get-ADObject possono quindi essere inviati tramite pipe a Remove-ADObjecto eliminati manualmente.

    Non omettere l'asterisco ("*") alla fine del valore della variabile $keywords.

  5. Rimuovere manualmente lo stato di configurazione a livello di foresta. Lo stato di configurazione della foresta viene mantenuto in un contenitore nel contesto di denominazione della configurazione di Active Directory. Può essere individuato ed eliminato come segue:

    $passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
Remove-ADObject -Recursive $passwordProtectionConfigContainer

  6. Rimuovere manualmente tutti gli stati correlati a sysvol eliminando manualmente la cartella seguente e tutto il relativo contenuto:

    \\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection

    Se necessario, questo percorso può anche essere accessibile localmente in un determinato controller di dominio; il percorso predefinito sarà simile al seguente:

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    Questo percorso è diverso se la condivisione sysvol è configurata in un percorso non predefinito.

Test di salute con i cmdlet di PowerShell

Il modulo AzureADPasswordProtection di PowerShell include due cmdlet correlati alla salute che controllano che il software sia installato e funzionante. È consigliabile eseguire questi cmdlet dopo aver configurato una nuova distribuzione, periodicamente e quando viene esaminato un problema.

Ogni singolo test di integrità restituisce un risultato superato o non riuscito di base, oltre a un messaggio facoltativo in caso di errore. Nei casi in cui la causa di un errore non è chiara, cercare i messaggi del registro eventi di errore che potrebbero spiegare l'errore. Anche l'abilitazione dei messaggi di log di testo può essere utile. Per altre informazioni, vedere Monitor Microsoft Entra Password Protection.

Test di integrità proxy

Il cmdlet Test-AzureADPasswordProtectionProxyHealth supporta due test di integrità che possono essere eseguiti singolarmente. Una terza modalità consente l'esecuzione di tutti i test che non richiedono alcun input di parametro.

Verifica della registrazione proxy

Questo test verifica che l'agente proxy sia registrato correttamente con Azure ed è in grado di eseguire l'autenticazione in Azure. Un'esecuzione riuscita appare così:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Passed

Se viene rilevato un errore, il test restituisce un risultato non riuscito e un messaggio di errore facoltativo. Di seguito è riportato un esempio di possibile errore:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyProxyRegistration

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyRegistration Failed No proxy certificates were found - please run the Register-AzureADPasswordProtectionProxy cmdlet to register the proxy.

Verifica del proxy per la connettività end-to-end di Azure

Questo test è un superset del test -VerifyProxyRegistration. Richiede che l'agente proxy sia registrato correttamente con Azure, sia in grado di eseguire l'autenticazione in Azure e infine aggiunge un controllo che un messaggio possa essere inviato correttamente ad Azure, verificando così che la comunicazione end-to-end completa funzioni.

Una corsa di successo vede il seguente aspetto:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -VerifyAzureConnectivity

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyAzureConnectivity Passed

Verifica di tutti i test tramite proxy

Questa modalità consente l'esecuzione bulk di tutti i test supportati dal cmdlet che non richiedono l'input del parametro. Una corsa riuscita appare in questo modo:

PS C:\> Test-AzureADPasswordProtectionProxyHealth -TestAll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyTLSConfiguration  Passed
VerifyProxyRegistration Passed
VerifyAzureConnectivity Passed

Verifica dello stato dell'agente del controller di dominio

Il cmdlet Test-AzureADPasswordProtectionDCAgentHealth supporta diversi test di integrità che possono essere eseguiti singolarmente. Una terza modalità consente l'esecuzione di tutti i test che non richiedono alcun input di parametro.

Test di integrità dell'agente del controller di dominio di base

I test seguenti possono essere eseguiti singolarmente e non accettano parametri. Una breve descrizione di ogni test è elencata nella tabella seguente.

Test di integrità dell'agente DC Descrizione
-VerifyPasswordFilterDll Verifica che la DLL del filtro password sia attualmente caricata ed è in grado di chiamare il servizio agente del controller di dominio (DC)
-VerificaRegistrazioneForesta Verifica che la foresta sia attualmente registrata
-VerificaCifraturaDecifratura Verifica che la crittografia e la decrittografia di base funzionino usando il servizio Microsoft KDS
-VerificaDominioUtilizzaDFSR Verifica che il dominio corrente usi DFSR per la replica della cartella Sysvol
-VerifyAzureConnectivity Verifica che la comunicazione end-to-end con Azure funzioni usando qualsiasi proxy disponibile

Di seguito è riportato un esempio del superamento del test -VerifyPasswordFilterDll e altri test riusciti hanno un aspetto simile:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyPasswordFilterDll

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyPasswordFilterDll Passed

Verifica dell'agente DC di tutti i test

Questa modalità consente l'esecuzione bulk di tutti i test supportati dal cmdlet che non richiedono l'input del parametro. Un'esecuzione riuscita si presenta così:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -TestAll

DiagnosticName             Result AdditionalInfo
--------------             ------ --------------
VerifyPasswordFilterDll    Passed
VerifyForestRegistration   Passed
VerifyEncryptionDecryption Passed
VerifyDomainIsUsingDFSR    Passed
VerifyAzureConnectivity    Passed

Test della connettività con server proxy specifici

Molte situazioni di risoluzione dei problemi comportano l'analisi della connettività di rete tra agenti del controller di dominio e proxy. Sono disponibili due test sanitari per concentrarsi su tali problemi in particolare. Questi test richiedono che venga specificato un server proxy specifico.

Verifica della connettività tra un agente del controller di dominio e un proxy specifico

Questo test convalida la connettività sul primo tratto di comunicazione dall'agente DC al proxy. Verifica che il proxy riceva la chiamata, ma non viene coinvolta alcuna comunicazione con Azure. Un'esecuzione riuscita appare così:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Passed

Ecco una condizione di errore di esempio in cui il servizio proxy in esecuzione nel server di destinazione viene arrestato:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyProxyConnectivity bpl2.bpl.com

DiagnosticName          Result AdditionalInfo
--------------          ------ --------------
VerifyProxyConnectivity Failed The RPC endpoint mapper on the specified proxy returned no results; please check that the proxy service is running on that server.

Verifica della connettività tra un agente del controller di dominio e Azure (usando un proxy specifico)

Questo test convalida la connettività end-to-end completa tra un agente del controller di dominio e Azure usando un proxy specifico. Un'esecuzione riuscita appare così:

PS C:\> Test-AzureADPasswordProtectionDCAgentHealth -VerifyAzureConnectivityViaSpecificProxy bpl2.bpl.com

DiagnosticName                          Result AdditionalInfo
--------------                          ------ --------------
VerifyAzureConnectivityViaSpecificProxy Passed

Passaggi successivi

domande frequenti su Microsoft Entra Password Protection

Per altre informazioni sugli elenchi globali e personalizzati di password escluse, vedere l'articolo Ban bad passwords