Domande frequenti su Azure AD Multi-Factor Authentication

Con il server Multi-Factor Authentication i dati utente vengono archiviati solo nei server locali. Nel cloud non vengono archiviati dati utente persistenti. Quando l'utente esegue l'autenticazione a due fattori, il server Multi-Factor Authentication invia i dati al servizio cloud Azure AD Multi-Factor Authentication per l'autenticazione. La comunicazione tra il server Multi-Factor Authentication e il servizio cloud Multi-Factor Authentication avviene tramite Secure Sockets Layer (SSL) o Transport Layer Security (TLS) sulla porta 443 in uscita.

Quando le richieste di autenticazione vengono inviate al servizio cloud, vengono raccolti dati per i report di autenticazione e uso. I campi di dati seguenti sono inclusi nei log di verifica in due passaggi:

• ID univoco: nome utente o ID del server Multi-Factor Authentication locale
• Nome e cognome: facoltativo
• Indirizzo di posta elettronica: facoltativo
• Numero di telefono: quando si esegue una chiamata vocale o l'autenticazione tramite SMS
• Token del dispositivo: quando si esegue l'autenticazione con l'app per dispositivi mobili
• Modalità di autenticazione
• Risultato dell'autenticazione
• Nome del server Multi-Factor Authentication
• IP del server Multi-Factor Authentication
• IP client: se disponibile

I campi facoltativi possono essere configurati nel server Multi-Factor Authentication.

Il risultato della verifica (esito positivo o rifiuto) e il motivo di eventuali rifiuti vengono archiviati insieme con i dati di autenticazione. Questi dati sono disponibili nei report di autenticazione e uso.

Per altre informazioni, vedere Residenza dei dati e dati dei clienti per Azure AD Multi-Factor Authentication.

Negli Stati Uniti vengono usati i codici brevi SMS seguenti:

• 97671
• 69829
• 51789
• 99399

In Canada vengono usati i codici brevi SMS seguenti:

• 759731
• 673801

Non viene garantito l'invio di richieste Multi-Factor Authentication tramite telefono o SMS sempre dallo stesso numero. Nell'interesse degli utenti, Microsoft può aggiungere o rimuovere codici brevi in qualsiasi momento per eseguire modifiche di route e migliorare il recapito degli SMS.

I codici brevi non sono supportati in paesi o aree geografiche diversi da Stati Uniti e Canada.

Fatturazione

Le risposte alla maggior parte delle domande sulla fatturazione sono disponibili nella pagina dei prezzi di Multi-Factor Authentication o nella documentazione relativa a versioni e piani di consumo di Azure AD Multi-Factor Authentication.

No, alle aziende non vengono addebitati i costi delle singole telefonate o degli SMS inviati agli utenti tramite Azure AD Multi-Factor Authentication. Se si usa un provider di autenticazione MFA con un accordo basato sul numero di autenticazioni, verranno fatturate le singole autenticazioni ma non il metodo usato.

Potrebbero essere addebitate agli utenti le chiamate telefoniche o gli SMS che ricevono, in base al loro servizio telefonico personale.

La fatturazione si basa sul numero di utenti configurati per usare Multi-Factor Authentication, indipendentemente dal fatto che abbiano eseguito la verifica in due passaggi in quel mese.

Quando si crea un provider di MFA per utente o per autenticazione, la sottoscrizione di Azure dell'organizzazione viene fatturata mensilmente in base all'utilizzo. Questo modello di fatturazione è simile a quello applicato da Azure per l'utilizzo di macchine virtuali e App Web.

Quando si acquista una sottoscrizione per Azure AD Multi-Factor Authentication, l'organizzazione paga solo la tariffa relativa alla licenza annuale per ogni utente. Questo tipo di fatturazione viene applicata alle licenze MFA e ai bundle Microsoft 365, Azure AD Premium o Enterprise Mobility + Security.

Per altre informazioni, vedere l'articolo su come ottenere Azure AD Multi-Factor Authentication.

Le impostazioni predefinite per la sicurezza possono essere abilitate nel livello gratuito di Azure AD. Con le impostazioni predefinite per la sicurezza, tutti gli utenti vengono abilitati per l'autenticazione a più fattori con l'app Microsoft Authenticator. Non è possibile usare la verifica tramite SMS o telefono con le impostazioni predefinite per la sicurezza, ma solo l'app Microsoft Authenticator.

Per altre informazioni, vedere Cosa sono le impostazioni predefinite per la sicurezza?

Se l'organizzazione acquista MFA come servizio autonomo con fatturazione in base al consumo, il modello di fatturazione viene scelto quando si crea un provider di MFA. Dopo la creazione del provider di MFA non è più possibile cambiare il modello di fatturazione.

Se il provider di Multi-Factor Authentication non è collegato a un tenant di Azure AD o si collega il nuovo provider di Multi-Factor Authentication a un diverso tenant di Azure AD, le impostazioni utente e le opzioni di configurazione non vengono trasferite. Inoltre, i server Azure MFA esistenti devono essere riattivati usando le credenziali di attivazione generate tramite il nuovo provider di MFA. La riattivazione dei server MFA per collegarli al nuovo provider di MFA non inciderà sull'autenticazione con chiamata telefonica e SMS, ma le notifiche dell'app mobile smetteranno di funzionare per tutti gli utenti fino a quando riattiveranno l'app mobile.

Per altre informazioni sui provider di MFA, vedere Introduzione all'uso di un provider di Azure Multi-Factor Authentication.

In alcuni casi, sì.

Se la directory include un provider di Azure Multi-Factor Authentication per utente, è possibile aggiungere licenze MFA. Gli utenti con licenza non vengono conteggiati nella fatturazione in base al consumo per utente. Gli utenti senza licenza possono comunque essere abilitati per MFA tramite il provider di MFA. Se si acquistano e assegnano licenze per tutti gli utenti configurati per l'uso di Multi-Factor Authentication, è possibile eliminare il provider di Azure Multi-Factor Authentication. Se in futuro si avranno più utenti che licenze, sarà sempre possibile creare un altro provider di MFA per utente.

Se la directory include un provider di Multi-Factor Authentication per autenticazione, viene sempre fatturata ogni autenticazione, fintanto che il provider di MFA è collegato alla sottoscrizione. È possibile assegnare le licenze MFA agli utenti, ma verrà comunque fatturata ogni richiesta di verifica in due passaggi, che provenga o meno da un utente con assegnata una licenza di autenticazione a più fattori.

Se l'organizzazione usa un modello di fatturazione in base al consumo, è possibile usare Azure Active Directory ma non è obbligatorio. Se il provider di MFA non è collegato a un tenant di Azure AD, è possibile distribuire il server di Azure Multi-Factor Authentication in locale.

Quando si usa il modello di licenza, è necessario usare Azure Active Directory in quanto le licenze vengono aggiunte al tenant di Azure AD quando vengono acquistate e assegnate agli utenti nella directory.

Chiedere agli utenti di provare fino a cinque volte in 5 minuti per ricevere una telefonata o un SMS per l'autenticazione. Microsoft usa più provider per la distribuzione di chiamate e messaggi SMS. Se questo approccio non funziona, aprire un caso di supporto per proseguire con la risoluzione dei problemi.

Le app di sicurezza di terze parti possono anche bloccare l'SMS o la telefonata del codice di verifica. Se si usa un'app di sicurezza di terze parti, provare a disabilitare la protezione e quindi richiedere l'invio di un altro codice di verifica MFA.

Se la procedura precedente non funziona, verificare se gli utenti sono configurati per più di un metodo di verifica. Provare di nuovo a eseguire l'accesso, ma selezionando un altro metodo di verifica nella pagina di accesso.

Per altre informazioni, vedere la guida alla risoluzione dei problemi per gli utenti finali.

È possibile reimpostare l'account utente chiedendo all'utente stesso di ripetere il processo di registrazione. Altre informazioni sulla gestione delle impostazioni utente e dispositivo con Azure AD Multi-Factor Authentication nel cloud.

L'amministratore può eliminare tutte le password di app dell'utente per impedire eventuali accessi non autorizzati. Dopo aver sostituito il dispositivo, l'utente potrà ricrearle. Altre informazioni sulla gestione delle impostazioni utente e dispositivo con Azure AD Multi-Factor Authentication nel cloud.

Se l'organizzazione usa ancora client legacy ed è stato consentito l'uso delle password di app, gli utenti non possono eseguire l'accesso a questi client legacy con il loro nome utente e password. Devono invece impostare le password di app. Gli utenti devono cancellare (eliminare) le informazioni di accesso, riavviare l'app e quindi accedere con il proprio nome utente e password di app anziché le password normali.

Se l'organizzazione non ha client legacy, è consigliabile non consentire agli utenti di creare password di app.

Il recapito degli SMS non è garantito in quanto sussistono fattori non controllabili che possono influire sull'affidabilità del servizio. Questi fattori includono il paese o l'area geografica di destinazione, il gestore di telefonia mobile e la qualità del segnale.

Le app di sicurezza di terze parti possono anche bloccare l'SMS o la telefonata del codice di verifica. Se si usa un'app di sicurezza di terze parti, provare a disabilitare la protezione e quindi richiedere l'invio di un altro codice di verifica MFA.

Se agli utenti capita spesso di non ricevere in modo affidabile gli SMS, suggerire loro di usare il metodo basato sull'app Microsoft Authenticator o sulla telefonata. Microsoft Authenticator può ricevere notifiche sia su rete cellulare che Wi-Fi. L'app per dispositivi mobili può generare codici di verifica anche in caso di totale assenza di segnale. L'app Microsoft Authenticator è disponibile per Android, iOS e Windows Phone.

In alcuni casi sì.

Per SMS unidirezionali con Azure MFA Server 7.0 o versione successiva, è possibile configurare il timeout impostando una chiave del Registro di sistema. Dopo l'invio dell'SMS dal servizio cloud MFA, a MFA Server viene restituito il codice di verifica (o passcode monouso). MFA Server archivia il codice in memoria per 300 secondi per impostazione predefinita. Se l'utente non immette il codice dopo 300 secondi, l'autenticazione viene negata. Usare questa procedura per modificare l'impostazione di timeout predefinita:

1. Passare a HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Creare una chiave DWORD del Registro di sistema denominata pfsvc_pendingSmsTimeoutSeconds e impostare il tempo, in secondi, per cui il server Azure MFA dovrà archiviare i passcode monouso.

Se gli utenti non rispondono all'SMS entro il periodo di timeout definito, l'autenticazione viene negata.

Non è possibile configurare l'impostazione di timeout per SMS unidirezionali con Azure AD MFA nel cloud, inclusi l'adattatore AD FS o l'estensione Server dei criteri di rete. Azure AD archivia il codice di verifica per 180 secondi.

Se si usa il server Azure MFA, è possibile importare token OATH TOPT di terze parti e quindi usarli per la verifica in due passaggi.

È possibile usare token ActiveIdentity che siano token OATH TOTP se si inserisce la chiave privata in un file CSV e lo si importa nel server Azure Multi-Factor Authentication. I token OATH possono essere usati con Active Directory Federation Services (AD FS), con l'autenticazione basata su moduli di Internet Information Server (IIS) e con il servizio RADIUS (Remote Authentication Dial-In User Service), a condizione che il sistema client possa accettare l'input dell'utente.

È possibile importare token OATH TOTP di terze parti con i formati seguenti:

• Portable Symmetric Key Container (PSKC)
• CSV se il file contiene un numero di serie, una chiave privata in formato Base 32 e un intervallo di tempo

Sì, ma se si usa Windows Server 2012 R2 o versione successiva è possibile proteggere i Servizi Terminal solo usando Gateway Desktop remoto.

Le modifiche della sicurezza in Windows Server 2012 R2 hanno variato le modalità di connessione del server di Azure Multi-Factor Authentication al pacchetto di sicurezza dell'autorità di protezione locale in Windows Server 2012 e versioni precedenti. Per le versioni di Servizi terminal in Windows Server 2012 o versioni precedenti è possibile proteggere un'applicazione con l'autenticazione di Windows. Se si usa Windows Server 2012 R2, è necessario Gateway Desktop remoto.

Quando vengono effettuate chiamate MFA tramite la rete telefonica pubblica, queste vengono a volte indirizzate su un gestore che non supporta l'ID chiamante. A causa di questo comportamento del gestore, l'ID chiamante non è garantito, anche se il sistema di autenticazione a più fattori lo invia sempre.

Esistono diversi motivi per cui agli utenti potrebbe essere chiesto di registrare le informazioni di sicurezza:

• L'utente è stato abilitato per MFA dall'amministratore in Azure AD, ma non ha informazioni di sicurezza registrate per il proprio account.
• L'utente è stato abilitato per la reimpostazione password self-service in Azure AD. Le informazioni di sicurezza lo aiuteranno a reimpostare la password in futuro, se dovesse dimenticarla.
• L'utente ha eseguito l'accesso a un'applicazione che prevede un criterio di accesso condizionale per richiedere MFA e non ha eseguito in precedenza la registrazione per MFA.
• L'utente sta registrando un dispositivo con Azure AD (inclusa l'aggiunta ad Azure AD) e l'organizzazione richiede MFA per la registrazione del dispositivo, ma l'utente non è stato registrato in precedenza per MFA.
• L'utente sta generando Windows Hello for Business in Windows 10 (che richiede MFA) e non ha eseguito in precedenza la registrazione per MFA.
• L'organizzazione ha creato e attivato un criterio di registrazione MFA che è stato applicato all'utente.
• L'utente è stato registrato in precedenza per MFA, ma ha scelto un metodo di verifica che un amministratore ha poi disabilitato. Pertanto l'utente deve eseguire di nuovo la registrazione MFA per scegliere un nuovo metodo di verifica predefinito.

Chiedere all'utente di completare la procedura seguente per rimuovere l'account da Microsoft Authenticator e quindi aggiungerlo di nuovo:

1. Passare al profilo nel portale di Azure e accedere con un account aziendale.
2. Selezionare Verifica aggiuntiva di sicurezza.
3. Rimuovere l'account esistente dall'app Microsoft Authenticator.
4. Fare clic su Configurae seguire le istruzioni per riconfigurare Microsoft Authenticator.

L'errore 0x800434D4L si verifica quando si prova ad accedere a un'applicazione diversa da un browser, installata in un computer locale, che non funziona con account che richiedono la verifica in due passaggi.

Una soluzione alternativa per questo errore consiste nel disporre di account utente separati per le operazioni correlate all'amministrazione e per quelle non amministrative. In un secondo momento è possibile collegare le cassette postali tra l'account amministratore e l'account non amministratore in modo da poter accedere a Outlook usando l'account non amministratore. Per altri dettagli su questa soluzione, vedere come consentire a un amministratore di aprire e visualizzare il contenuto della cassetta postale di un utente.

Errore 1073741715 = Errore di accesso dello stato :> tentativo di accesso non valido. Ciò è dovuto a un nome utente o a un'autenticazione non valida.

Un motivo plausibile per questo errore: se le credenziali primarie immesse sono corrette, potrebbe verificarsi una mancata corrispondenza tra la versione NTLM supportata nel server MFA e il controller di dominio. Il server MFA supporta solo NTLMv1 (LmCompatabilityLevel=1 thru 4) e non NTLMv2 (LmCompatabilityLevel=5).

Passaggi successivi

Se la risposta alla propria domanda non è inclusa in questa pagina, sono disponibili le opzioni di supporto seguenti:

• Cercare nella Knowledge Base del supporto tecnico Microsoft le soluzioni ai problemi tecnici comuni.
• Cercare ed esplorare le domande tecniche e le risposte della community oppure porre domande personalizzate in Azure Active Directory Q&A.
• Contattare un tecnico Microsoft tramite il supporto per il server Azure MFA. Quando si contatta Microsoft, è utile includere il maggior numero possibile di informazioni relative al problema. Tali informazioni includono la pagina in cui viene visualizzato l'errore, il codice dell'errore specifico, l'ID della sessione specifico e l'ID dell'utente che visualizza l'errore.
• I clienti legacy di PhoneFactor che hanno domande o necessitano di assistenza per reimpostare una password possono usare l'indirizzo di posta elettronica phonefactorsupport@microsoft.com per aprire una richiesta di assistenza.