Questa sezione fornisce le risposte a molte domande frequenti sulla protezione password di Microsoft Entra.
Domande generali
quali indicazioni devono avere gli utenti su come scegliere una password sicura?
Le indicazioni correnti di Microsoft su questo argomento sono disponibili nella pagina Web a cui si accede tramite il collegamento seguente:
Microsoft Password Guidance (Indicazioni di Microsoft sulle password)
La protezione password di Microsoft Entra locale è supportata nei cloud non pubblici?
La protezione password di Microsoft Entra locale è supportata sia nei cloud globali che in Azure per enti pubblici di Azure.
L'interfaccia di amministrazione di Microsoft Entra consente la modifica della configurazione specifica di "Protezione password per Windows Server Active Directory" specifica in locale anche nei cloud non supportati; tali modifiche verranno mantenute, ma altrimenti non avranno mai effetto. La registrazione di foreste o agenti proxy locali non è supportata nei cloud non supportati e qualsiasi tentativo di registrazione di questo tipo non riuscirà.
Come è possibile applicare i vantaggi di Microsoft Entra Password Protection a un subset degli utenti locali?
Non supportato. Dopo la distribuzione e l'abilitazione, microsoft Entra Password Protection non discrimina: tutti gli utenti ricevono vantaggi di sicurezza uguali.
Qual è la differenza tra la modifica della password e l'impostazione o la reimpostazione della password?
La modifica della password avviene quando un utente sceglie una nuova password dopo aver dimostrato di conoscere quella vecchia. Ad esempio, viene eseguita una modifica della password quando un utente accede a Windows e gli viene richiesto di scegliere una nuova password.
L'impostazione della password, nota anche come reimpostazione della password, avviene quando un amministratore sostituisce la password di un account con una nuova password, ad esempio usando lo strumento di gestione Utenti e computer di Active Directory. Per questa operazione è richiesto un livello elevato di privilegi (in genere Amministratore di dominio) e la persona che esegue l'operazione in genere non conosce la vecchia password. Negli scenari di help desk viene spesso eseguita l'impostazione della password, ad esempio quando viene fornita assistenza a un utente che ha dimenticato la password. Verranno visualizzati eventi di impostazione delle password anche quando si crea per la prima volta un nuovo account utente con password.
Il funzionamento dei criteri di convalida della password è identico indipendentemente dal fatto che venga eseguita una modifica o un'impostazione della password. Il servizio Agente del controller di dominio di protezione password Di Microsoft Entra registra eventi diversi per indicare se è stata eseguita una modifica o un'operazione di impostazione della password. Vedere Monitoraggio e registrazione di Microsoft Entra Password Protection.
La protezione password di Microsoft Entra convalida le password esistenti dopo l'installazione?
No- La protezione password di Microsoft Entra può applicare i criteri password solo alle password non crittografate durante un'operazione di modifica o impostazione della password. Dopo l'accettazione di una password in Active Directory, vengono resi persistenti solo gli hash specifici del protocollo di autenticazione di tale password. La password non crittografata non viene mai salvata in modo permanente, pertanto Microsoft Entra Password Protection non può convalidare le password esistenti.
Dopo la distribuzione iniziale della protezione password di Microsoft Entra, tutti gli utenti e gli account inizieranno a usare una password convalidata dalla protezione password di Microsoft Entra perché le password esistenti scadono normalmente nel tempo. Se si preferisce, è possibile velocizzare questo processo impostando una scadenza manuale una tantum delle password degli account utente.
Gli account configurati con "Nessuna scadenza password" non verranno mai forzati a cambiare la password a meno che non venga impostata la scadenza manuale.
Perché vengono registrati eventi di rifiuto delle password duplicati quando si prova a impostare una password debole usando lo snap-in di gestione Utenti e computer di Active Directory?
Lo snap-in di gestione Utenti e computer di Active Directory proverà innanzitutto a impostare la nuova password usando il protocollo Kerberos. In caso di errore, lo snap-in effettuerà un secondo tentativo con un protocollo legacy (RPC SAM). Gli specifici protocolli usati non sono rilevanti. Se la nuova password è considerata debole da Microsoft Entra Password Protection, questo comportamento di snap-in comporterà la registrazione di due set di eventi di rifiuto per la reimpostazione della password.
Perché gli eventi di convalida password di Microsoft Entra Password Protection vengono registrati con un nome utente vuoto?
In Active Directory è possibile testare una password per verificare se supera i requisiti correnti di complessità delle password del dominio, ad esempio usando l'API NetValidatePasswordPolicy. Quando una password viene convalidata in questo modo, il test include anche la convalida da parte di prodotti basati su password-filter-dll, ad esempio Microsoft Entra Password Protection, ma i nomi utente passati a una determinata DLL di filtro password saranno vuoti. In questo scenario, Microsoft Entra Password Protection convaliderà comunque la password usando i criteri password attualmente in vigore e genererà un messaggio del registro eventi per acquisire il risultato, tuttavia il messaggio del registro eventi avrà campi di nome utente vuoti.
Ho utenti ibridi che tentano di modificare la password in Microsoft Entra ID e ricevono la risposta "Abbiamo visto la password troppe volte prima. Scegli qualcosa di più difficile da indovinare." In questo caso, perché non viene visualizzato un tentativo di convalida locale?
Quando un utente ibrido modifica la password in Microsoft Entra ID, indipendentemente dal fatto che tramite Microsoft Entra SSPR, MyAccount o un altro meccanismo di modifica della password di Microsoft Entra, la password viene valutata rispetto agli elenchi di password globali e personalizzate escluse nel cloud. Quando la password raggiunge Active Directory tramite il writeback delle password, è già stata convalidata in Microsoft Entra ID.
Le modifiche e le reimpostazioni delle password avviate in Microsoft Entra ID che non superano la convalida per gli utenti ibridi sono disponibili nei log di controllo di Microsoft Entra. Vedere Risolvere i problemi di reimpostazione della password self-service in Microsoft Entra ID.
È supportata l'installazione affiancata di Microsoft Entra Password Protection con altri prodotti basati su filtri password?
Sì. Il supporto per più DLL di filtro password registrato è una funzionalità di Base di Windows e non specifica per la protezione password di Microsoft Entra. Tutte le DLL di filtro password registrate devono concordare, prima che venga accettata una password.
Come è possibile distribuire e configurare la protezione password di Microsoft Entra nell'ambiente Active Directory senza usare Azure?
Non supportato. Microsoft Entra Password Protection è una funzionalità di Azure che supporta l'estensione in un ambiente Active Directory locale.
in che modo è possibile modificare il contenuto dei criteri a livello di Active Directory?
Non supportato. I criteri possono essere amministrati solo tramite l'interfaccia di amministrazione di Microsoft Entra. Vedere anche la domanda precedente.
perché è necessario il servizio DFSR per la replica di sysvol?
Il servizio Replica file (la tecnologia precedente a DFSR) include molti problemi noti e non è completamente supportato nelle versioni più recenti di Windows Server Active Directory. Non verrà eseguito alcun test della protezione password di Microsoft Entra nei domini configurati da FRS.
Per altre informazioni, vedere gli articoli seguenti:
The Case for Migrating sysvol replication to DFSR (Caso della migrazione della replica di sysvol a DFSR)
The End is Nigh for FRS (La fine è vicina per il servizio Replica file)
Se il dominio non usa già DFSR, è necessario eseguirne la migrazione per usare DFSR prima di installare Microsoft Entra Password Protection. Per altre informazioni, vedere il collegamento seguente:
Guida alla migrazione della replica SYSVOL: Replica da frs a replica DFS
Avviso
Il software microsoft Entra Password Protection DC Agent verrà attualmente installato nei controller di dominio nei domini che usano ancora FRS per la replica sysvol, ma il software non funzionerà correttamente in questo ambiente. Altri effetti collaterali negativi includono la mancata replica di singoli file e procedure di ripristino sysvol che sembrano completate ma che non riescono automaticamente a replicare tutti i file. È consigliabile eseguire la migrazione del dominio per usare DFSR il prima possibile, sia per i vantaggi intrinseci di DFSR che per sbloccare la distribuzione di Microsoft Entra Password Protection. Le versioni future del software verranno disabilitate automaticamente durante l'esecuzione in un dominio che usa ancora il servizio Replica file.
quanto spazio su disco è necessario alla funzionalità nella condivisione sysvol del dominio?
La quantità esatta di spazio usato dipende da fattori come il numero e la lunghezza dei token esclusi contenuti nell'elenco globale degli elementi esclusi Microsoft e nell'elenco personalizzato del singolo tenant, nonché dal sovraccarico della crittografia. Il contenuto di questi elenchi probabilmente aumenterà in futuro. Tenendo presente tale situazione, è ragionevole prevedere che per la funzionalità siano necessari almeno cinque (5) megabyte di spazio nella condivisione sysvol del dominio.
perché è necessario un riavvio per installare o aggiornare il software dell'agente del controller di dominio?
Questo requisito dipende dal comportamento di base di Windows.
è disponibile un modo per configurare un agente del controller di dominio per l'uso di un server proxy specifico?
No. Poiché il server proxy è senza stato, non ha importanza quale server proxy specifico venga usato.
È possibile distribuire il servizio proxy di protezione password di Microsoft Entra affiancato ad altri servizi, ad esempio Microsoft Entra Connessione?
Sì. Il servizio Proxy di protezione password Di Microsoft Entra e Microsoft Entra Connessione non devono mai entrare in conflitto direttamente tra loro.
Sfortunatamente, è stata rilevata un'incompatibilità tra la versione del servizio Microsoft Entra Connessione Agent Updater installata dal software Microsoft Entra Password Protection Proxy e la versione del servizio installato dal software proxy dell'applicazione Microsoft Entra. Questa incompatibilità può impedire al servizio Agent Updater di contattare Azure per ottenere gli aggiornamenti software. Non è consigliabile installare il proxy di protezione password Di Microsoft Entra e il proxy dell'applicazione Microsoft Entra nello stesso computer.
In quale ordine devono essere installati e registrati gli agenti e i proxy del controller di dominio?
Non è previsto un ordine specifico per l'installazione dell'agente proxy e dell'agente del controller di dominio e per la registrazione della foresta e del proxy.
La distribuzione di questa funzionalità può avere un impatto preoccupante sulle prestazioni dei controller di dominio?
Il servizio Agente controller di dominio di protezione password Microsoft Entra non dovrebbe influire significativamente sulle prestazioni del controller di dominio in una distribuzione di Active Directory integra esistente.
Per la maggior parte delle distribuzioni di Active Directory attive, le operazioni di modifica delle password rappresentano una piccola parte del carico di lavoro complessivo in un determinato controller di dominio. Ad esempio, si supponga l'esistenza di un dominio di Active Directory con 10000 account utente e criteri MaxPasswordAge impostati su 30 giorni. In media questo dominio vedrà 10000/30=~333 operazioni di modifica delle password ogni giorno, il che rappresenta un numero trascurabile di operazioni persino per un singolo controller di dominio. Considerare un potenziale scenario di caso peggiore, ovvero supporre che queste ~333 modifiche delle password in un singolo controller di dominio siano state effettuate nel giro di un'ora. Questo scenario, ad esempio, può verificarsi quando diversi dipendenti tornano tutti al lavoro il lunedì mattina. Anche in questo caso, si verificheranno ~333/60 minuti = sei modifiche di password al minuto, il che non costituisce comunque un carico significativo.
Tuttavia, se i controller di dominio correnti sono già in esecuzione a livelli limitati a prestazioni (ad esempio, il limite massimo rispetto a CPU, spazio su disco, I/O su disco e così via), è consigliabile aggiungere controller di dominio aggiuntivi o espandere lo spazio su disco disponibile, prima di distribuire questa funzionalità. Vedere anche la domanda precedente relativa all'uso dello spazio su disco per la condivisione sysvol.
Si vuole testare la protezione password di Microsoft Entra in pochi controller di dominio nel dominio. È possibile forzare le modifiche delle password utente a usare tali controller di dominio specifici?
No. È il sistema operativo client Windows a controllare quale controller di dominio viene usato quando un utente modifica la password. Il controller di dominio viene selezionato in base a fattori quali assegnazioni di sito e subnet di Active Directory, configurazione di rete specifica dell'ambiente e così via. La protezione password di Microsoft Entra non controlla questi fattori e non può influenzare il controller di dominio selezionato per modificare la password di un utente.
Un modo per raggiungere parzialmente questo obiettivo consiste nel distribuire la protezione password di Microsoft Entra in tutti i controller di dominio in un determinato sito di Active Directory. Questo approccio garantirà una copertura ragionevole per i client Windows assegnati al sito e, di conseguenza, anche per gli utenti che accedono a tali client e modificano le loro password.
Se si installa il servizio Agente controller di dominio di protezione password Di Microsoft Entra solo nel controller di dominio primario (PDC), verranno protetti anche tutti gli altri controller di dominio nel dominio?
No. Quando la password di un utente viene modificata in un determinato controller di dominio non primario, la password non crittografata non viene mai inviata al controller di dominio primario (questa è un'idea errata molto diffusa). Dopo che una nuova password viene accettata in un controller di dominio, quest'ultimo usa tale password per crearne i vari hash specifici del protocollo di autenticazione e quindi rende permanenti gli hash nella directory. La password non crittografata non diventa permanente. Gli hash aggiornati vengono poi replicati nel controller di dominio primario. Le password utente possono in alcune circostanze essere modificate direttamente nel controller di dominio primario, anche in questo caso in base a vari fattori come la topologia di rete e la struttura del sito di Active Directory. Vedere la domanda precedente.
In sintesi, la distribuzione del servizio agente del controller di dominio di protezione password di Microsoft Entra nel PDC è necessaria per raggiungere il 100% della copertura di sicurezza della funzionalità nel dominio. La distribuzione della funzionalità nel PDC non offre solo vantaggi per la protezione della password di Microsoft Entra per altri controller di dominio nel dominio.
Perché il blocco intelligente personalizzato continua a non funzionare anche dopo l'installazione degli agenti nell'ambiente Active Directory locale?
Il blocco intelligente personalizzato è supportato solo in Microsoft Entra ID. Le modifiche alle impostazioni di blocco intelligente personalizzate nell'interfaccia di amministrazione di Microsoft Entra non hanno alcun effetto sull'ambiente Active Directory locale, anche con gli agenti installati.
Un Management Pack di System Center Operations Manager è disponibile per la protezione password di Microsoft Entra?
No.
Perché Microsoft Entra ID continua a rifiutare le password deboli anche se i criteri sono stati configurati in modalità di controllo?
La modalità di controllo è supportata solo nell'ambiente Active Directory locale. L'ID Microsoft Entra è sempre in modalità "applica" in modo implicito quando valuta le password.
Gli utenti visualizzano il messaggio di errore di Windows tradizionale quando una password viene rifiutata da Microsoft Entra Password Protection. È possibile personalizzare questo messaggio di errore in modo che gli utenti sappiano cosa è realmente accaduto?
No. Il messaggio di errore visualizzato dagli utenti quando una password viene rifiutata da un controller di dominio viene controllato dal computer client, non dal controller di dominio. Questo comportamento si verifica se una password viene rifiutata dai criteri password di Active Directory predefiniti o da una soluzione basata su filtro password, ad esempio Microsoft Entra Password Protection.
Procedure di test delle password
È opportuno eseguire alcuni test di base con diverse password per convalidare il corretto funzionamento del software e comprendere meglio l'algoritmo di valutazione delle password. In questa sezione viene descritto un metodo per eseguire tale test che è progettato per produrre risultati ripetibili.
Perché è necessario seguire questa procedura? Sono diversi i fattori che rendono difficile eseguire test controllati e ripetibili delle password nell'ambiente Active Directory locale:
- I criteri password vengono configurati e resi persistenti in Azure e copie dei criteri vengono sincronizzate periodicamente dagli agenti del controller di dominio locali usando un meccanismo di polling. La latenza intrinseca in questo ciclo di polling può causare confusione. Ad esempio, se si configurano i criteri in Azure ma si dimentica di sincronizzarli con l'agente del controller di dominio, i test potrebbero non produrre i risultati previsti. L'impostazione hardcoded dell'intervallo di polling ne prevede l'esecuzione una volta all'ora, ma attendere un'ora tra una modifica e l'altra dei criteri non è una condizione ideale per uno scenario di test interattivo.
- Dopo la sincronizzazione di nuovi criteri password con un controller di dominio, si verificherà una maggiore latenza durante la replica in altri controller di dominio. Questi ritardi possono causare risultati imprevisti se si testa una modifica della password in un controller di dominio che non ha ancora ricevuto la versione più recente dei criteri.
- Se si testano le modifiche della password tramite un'interfaccia utente, è difficile fidarsi dei risultati. Ad esempio, è facile digitare erroneamente una password non valida in un'interfaccia utente, soprattutto perché la maggior parte delle interfacce utente password nasconde l'input dell'utente (ad esempio, ad esempio, Ctrl-Alt-Elimina -> Modifica interfaccia utente password).
- Non è possibile controllare rigorosamente il controller di dominio usato durante il test delle modifiche della password dai client aggiunti al dominio. Il sistema operativo client Windows seleziona un controller di dominio in base a fattori quali assegnazioni di sito e subnet di Active Directory, configurazione di rete specifica dell'ambiente e così via.
Per evitare questi problemi, la procedura seguente si basa sul test da riga di comando delle reimpostazioni della password durante l'accesso a un controller di dominio.
Avviso
Queste procedure devono essere usate solo in un ambiente di test perché tutte le modifiche e le reimpostazioni delle password in ingresso verranno accettate senza convalida mentre il servizio agente del controller di dominio è arrestato e anche per evitare i maggiori rischi derivanti dall'accesso a un controller di dominio.
La procedura seguente presuppone che l'agente del controller di dominio sia stato installato in almeno un controller di dominio, che abbia installato almeno un proxy e che abbia registrato sia il proxy che la foresta.
Accedere a un controller di dominio, in cui è installato il software dell'agente del controller di dominio e che è stato riavviato, usando le credenziali di amministratore di dominio o altre credenziali con privilegi sufficienti per creare account utente di test e reimpostare le password.
Aprire Visualizzatore eventi e passare al log eventi di amministrazione dell'agente del controller di dominio.
Aprire una finestra del prompt dei comandi con privilegi elevati.
Creare un account di test per l'esecuzione del test delle password
Esistono molti modi per creare un account utente, ma in questo caso è disponibile un'opzione della riga di comando per semplificare l'operazione durante cicli di test ripetitivi:
net.exe user <testuseraccountname> /add <password>Ai fini della discussione seguente, si supponga di aver creato un account di test denominato "ContosoUser", ad esempio:
net.exe user ContosoUser /add <password>Accedere all'interfaccia di amministrazione di Microsoft Entra come almeno un Amministrazione istrator di autenticazione.
Passare a Protezione dei metodi > di autenticazione Protezione > password.
Modificare i criteri di protezione password di Microsoft Entra in base alle esigenze per il test da eseguire. Ad esempio, è possibile decidere di configurare la modalità applicata o di controllo oppure di modificare l'elenco dei termini vietati nell'elenco delle password vietate personalizzate.
Sincronizzare i nuovi criteri arrestando e riavviando il servizio agente del controller di dominio.
È possibile eseguire questo passaggio in diversi modi. Un modo consiste nell'usare la console di amministrazione di Gestione servizi facendo clic con il pulsante destro del mouse sul servizio Agente del controller di dominio di protezione password Di Microsoft Entra e scegliendo "Riavvia". Un altro modo consiste nell'eseguire il passaggio dalla finestra del prompt dei comandi, come descritto di seguito:
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentControllare il Visualizzatore eventi per verificare che sia stato scaricato un nuovo criterio.
Ogni volta che il servizio agente del controller di dominio viene arrestato e avviato, dovrebbero essere visualizzati due eventi 30006 generati in rapida successione. Il primo evento 30006 sarà riferito ai criteri memorizzati nella cache su disco nella condivisione sysvol. Il secondo evento 30006 (se presente) deve includere una data dei criteri tenant aggiornata e, in tal caso, sarà riferito ai criteri scaricati da Azure. Il valore della data dei criteri tenant è attualmente codificato in modo da visualizzare il timestamp approssimativo con cui i criteri sono stati scaricati da Azure.
Se il secondo evento 30006 non viene visualizzato, è necessario risolvere il problema prima di continuare.
Gli eventi 30006 saranno simili all'esempio seguente:
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1Ad esempio, il passaggio dalla modalità applicata a quella di controllo comporta la modifica del flag AuditOnly (il criterio precedente con AuditOnly=0 è riferito alla modalità applicata). Le modifiche apportate all'elenco delle password vietate personalizzate non trovano riscontro direttamente nell'evento 30006 precedente (e non vengono registrate altrove per motivi di sicurezza). Il corretto download dei criteri da Azure dopo tale modifica includerà anche l'elenco modificato delle password vietate personalizzate.
Eseguire un test provando a reimpostare una nuova password nell'account utente di test.
È possibile eseguire questo passaggio dalla finestra del prompt dei comandi, come descritto di seguito:
net.exe user ContosoUser <password>Dopo aver eseguito il comando, è possibile ottenere altre informazioni sul risultato del comando cercando nel Visualizzatore eventi. Gli eventi relativi ai risultati di convalida delle password sono documentati nell'argomento Log eventi di amministrazione dell'agente del controller di dominio. Tali eventi verranno usati per convalidare il risultato del test in aggiunta all'output interattivo dei comandi net.exe.
Ad esempio, è possibile provare a impostare una password vietata dall'elenco globale Microsoft. Tenere presente che l'elenco non è documentato, ma è possibile testarla qui con un termine vietato noto. In questo esempio si presuppone che i criteri siano stati configurati in modalità applicata e che siano stati aggiunti zero termini all'elenco di password vietate personalizzate.
net.exe user ContosoUser PassWord The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements. More help is available by typing NET HELPMSG 2245.In base alla documentazione, dal momento che il test coincide con un'operazione di reimpostazione della password, dovrebbero essere visualizzati un evento 10017 e un evento 30005 per l'utente ContosoUser.
L'evento 10017 dovrebbe essere simile a questo esempio:
The reset password for the specified user was rejected because it did not comply with the current Azure password policy. Please see the correlated event log message for more details. UserName: ContosoUser FullName:L'evento 30005 dovrebbe essere simile a questo esempio:
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:A questo punto, è possibile provare con un altro esempio. Questa volta si proverà a impostare una password vietata dall'elenco delle password vietate personalizzate mentre i criteri sono in modalità di controllo. Questo esempio presuppone che sia stata eseguita la procedura seguente: è stato configurato il criterio in modalità di controllo, è stato aggiunto il termine "lachrymose" all'elenco personalizzato delle password escluse e i nuovi criteri risultanti sono stati sincronizzati con il controller di dominio eseguendo ciclicamente il servizio agente del controller di dominio come descritto in precedenza.
Impostare ora una variante della password vietata:
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.Tenere presente che questa volta il test è riuscito perché i criteri sono in modalità di controllo. Dovrebbero essere visualizzati un evento 10025 e un evento 30007 per l'utente ContosoUser.
L'evento 10025 dovrebbe essere simile a questo esempio:
The reset password for the specified user would normally have been rejected because it did not comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:L'evento 30007 dovrebbe essere simile a questo esempio:
The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:Continuare a testare varie password di propria scelta e a controllare i risultati nel Visualizzatore eventi usando le procedure descritte nei passaggi precedenti. Se è necessario modificare i criteri nell'interfaccia di amministrazione di Microsoft Entra, non dimenticare di sincronizzare i nuovi criteri con l'agente del controller di dominio come descritto in precedenza.
Sono state descritte le procedure che consentono di eseguire test controllati del comportamento di convalida delle password di Microsoft Entra Password Protection. La reimpostazione delle password utente dalla riga di comando direttamente in un controller di dominio può sembrare una soluzione insolita per eseguire tali test, ma, come descritto in precedenza, è progettata per produrre risultati ripetibili. Durante il test di varie password, tenere presente l'algoritmo di valutazione delle password perché può essere utile per spiegare i risultati non previsti.
Avviso
Dopo aver completato tutti i test, non dimenticare di eliminare gli account utente creati a scopo di test.
Contenuto aggiuntivo
I collegamenti seguenti non fanno parte della documentazione principale di Microsoft Entra Password Protection, ma possono essere una fonte utile di informazioni aggiuntive sulla funzionalità.
Microsoft Entra Password Protection è ora disponibile a livello generale.
Microsoft Entra Password Protection e Smart Lockout sono ora disponibili in anteprima pubblica.
Formazione per il supporto Tecnico Microsoft Premier\Unified disponibile
Se si è interessati a saperne di più su Microsoft Entra Password Protection e distribuirlo nell'ambiente in uso, è possibile sfruttare un servizio proattivo Microsoft disponibile per i clienti con un contratto di supporto Premier o Unified. Il servizio è denominato Microsoft Entra ID: Password Protection. Per altre informazioni, contattare il Customer Success Account Manager.
Passaggi successivi
Se si ha una domanda di protezione password di Microsoft Entra locale che non viene risposta qui, inviare un elemento di feedback di seguito - grazie!