Spostare l'autenticazione dell'applicazione Azure Active Directory

Azure Active Directory (Azure AD) offre una piattaforma di identità universale che offre a persone, partner e clienti una singola identità per accedere alle applicazioni e collaborare da qualsiasi piattaforma e dispositivo. Azure AD dispone di una suite completa di funzionalità di gestione delle identità. Standardizzare l'autenticazione e l'autorizzazione dell'applicazione Azure AD offre questi vantaggi.

Suggerimento

Questo articolo è scritto per un pubblico di sviluppatori. Project manager e amministratori che pianificano di spostare un'applicazione in Azure AD valutare la possibilità di leggere Migrazione dell'autenticazione dell'applicazione Azure AD.

Vantaggi di Azure AD

Se si usa una directory locale che contiene account utente, è probabile che siano presenti molte applicazioni in cui gli utenti eseguono l'autenticazione. Ognuna di queste app è configurata per consentire agli utenti di accedere usando le proprie identità.

Gli utenti possono anche eseguire l'autenticazione direttamente con Active Directory locale. Active Directory Federation Services (AD FS) è un servizio di gestione delle identità locale basato su standard. Estende la possibilità di usare la funzionalità Single Sign-On (SSO) tra partner commerciali attendibili in modo che gli utenti non siano tenuti ad accedere separatamente a ogni applicazione. Questa è nota come identità federata.

Molte organizzazioni hanno software come servizio (SaaS) o app line-of-business personalizzate federate direttamente a AD FS, insieme alle app Microsoft 365 e Azure AD basate su AD FS.

Applicazioni connesse direttamente in locale

Importante

Per aumentare la sicurezza delle applicazioni, l'obiettivo è avere un unico set di controlli e criteri di accesso in tutti gli ambienti locali e cloud.

Applicazioni connesse tramite Azure AD

Tipi di app di cui eseguire la migrazione

La migrazione di tutta l'autenticazione delle applicazioni in Azure AD è una procedura ottimale, in quanto offre un singolo piano di controllo per la gestione delle identità e degli accessi.

Le applicazioni possono usare protocolli moderni o legacy per l'autenticazione. Quando si pianifica la migrazione a Azure AD, è consigliabile eseguire prima la migrazione delle app che usano protocolli di autenticazione moderni, ad esempio SAML e Open ID Connessione. Queste app possono essere riconfigurate per l'autenticazione con Azure AD tramite un connettore incorporato dalla raccolta app Azure o registrando l'applicazione in Azure AD. Le app che usano protocolli meno recenti possono essere integrate usando Application Proxy.

Per altre informazioni, vedere:

Processo di migrazione

Durante il processo di spostamento dell'autenticazione dell'app Azure AD, testare le app e la configurazione. È consigliabile continuare a usare gli ambienti di test esistenti per i test di migrazione quando si passa all'ambiente di produzione. Se un ambiente di test non è attualmente disponibile, è possibile configurarne uno usando Servizio app di Azure o Macchine virtuali di Azure,a seconda dell'architettura dell'applicazione.

È possibile scegliere di configurare un tenant di test separato Azure AD in cui sviluppare le configurazioni dell'app.

Il processo di migrazione potrebbe essere simile al seguente:

Fase 1 : stato corrente: l'app di produzione esegue l'autenticazione con AD FS

Fase 1 della migrazione

Fase 2: (facoltativo) Puntare un'istanza di test dell'app al tenant Azure AD test

Aggiornare la configurazione in modo che l'istanza di test dell'app punti a un tenant Azure AD test e apportare le modifiche necessarie. L'app può essere testata con gli utenti nel tenant Azure AD test. Durante il processo di sviluppo, è possibile usare strumenti come Fiddler per confrontare e verificare richieste e risposte.

Se non è possibile configurare un tenant di test separato, ignorare questa fase e puntare un'istanza di test dell'app al tenant Azure AD di produzione, come descritto nella fase 3 riportata di seguito.

Fase 2 della migrazione

Fase 3: puntare un'istanza di test dell'app al tenant Azure AD produzione

Aggiornare la configurazione in modo che l'istanza di test dell'app punti al tenant Azure AD di produzione. È ora possibile eseguire test con gli utenti nel tenant di produzione. Se necessario, vedere la sezione di questo articolo sulla transizione degli utenti.

Fase 3 della migrazione

Fase 4: puntare l'app di produzione al tenant Azure AD produzione

Aggiornare la configurazione dell'app di produzione in modo che punti al tenant Azure AD di produzione.

Fase 4 della migrazione

Le app che eseguono l'AD FS possono usare gruppi di Active Directory per le autorizzazioni. Usare Azure AD Connessione sincronizzazione per sincronizzare i dati di identità tra l'ambiente locale e Azure AD prima di iniziare la migrazione. Verificare i gruppi e l'appartenenza prima della migrazione in modo che sia possibile concedere l'accesso agli stessi utenti durante la migrazione dell'applicazione.

App line-of-business

Le app line-of-business sono quelle sviluppate dall'organizzazione o quelle che sono un prodotto in pacchetto standard. Ad esempio, le app create Windows Identity Foundation e SharePoint app (non SharePoint Online).

Le app line-of-business che usano OAuth 2.0, OpenID Connessione o WS-Federation possono essere integrate con Azure AD come registrazioni dell'app. Integrare app personalizzate che usano SAML 2.0 o WS-Federation come applicazioni non della raccolta nella pagina delle applicazioni aziendali nel portale di Azure.

Accesso Single Sign-On basato su SAML

Le app che usano SAML 2.0 per l'autenticazione possono essere configurate per l'accesso Single Sign-On (SSO) basato su SAML. Con l'accesso SSO basato su SAML è possibile eseguire il mapping degli utenti a ruoli applicazione specifici in base alle regole definite nelle attestazioni SAML.

Per configurare un'applicazione SaaS per l'accesso SSO basato su SAML, vedere Avvio rapido: Configurare l'accesso Single Sign-Onbasato su SAML.

Screenshot dell'utente SAML SSO

Molte applicazioni SaaS hanno un'esercitazione specifica dell'applicazione che illustra la configurazione per l'accesso SSO basato su SAML.

Esercitazione sull'app

La migrazione di alcune app può essere eseguita facilmente. Le app con requisiti più complessi, ad esempio attestazioni personalizzate, possono richiedere una configurazione aggiuntiva in Azure AD e/o Azure AD Connessione. Per informazioni sui mapping di attestazioni supportati, vedere Procedura: Personalizzare le attestazioni generate nei token per un'app specifica in un tenant (anteprima).

Tenere presenti le limitazioni seguenti quando si esegue il mapping degli attributi:

  • Non tutti gli attributi che possono essere emessi in AD FS vengono visualizzati in Azure AD come attributi da generare nei token SAML, anche se tali attributi sono sincronizzati. Quando si modifica l'attributo, nell'elenco a discesa Valore vengono visualizzati i diversi attributi disponibili in Azure AD. Controllare Azure AD Connessione configurazione degli argomenti di sincronizzazione per assicurarsi che un attributo obbligatorio, ad esempio samAccountName, sia sincronizzato con Azure AD. È possibile usare gli attributi di estensione per generare qualsiasi attestazione che non fa parte dello schema utente standard in Azure AD.
  • Negli scenari più comuni, per un'app sono necessarie solo l'attestazione NameID e altre attestazioni dell'ID utente comuni. Per determinare se sono necessarie attestazioni aggiuntive, esaminare le attestazioni che si sta emettendo AD FS.
  • Non tutte le attestazioni possono essere rilasciate, poiché alcune attestazioni sono protette in Azure AD.
  • La possibilità di usare i token SAML crittografati è ora disponibile in anteprima. Vedere Procedura: personalizzare le attestazioni rilasciate nel token SAML per le applicazioni aziendali.

App SaaS (Software as a Service)

Se gli utenti azionano app SaaS come Salesforce, ServiceNow o Workday e sono integrati con AD FS, si usa l'accesso federato per le app SaaS.

La maggior parte delle applicazioni SaaS può essere configurata in Azure AD. Microsoft ha molte connessioni preconfigurate alle app SaaS nella raccolta di app Azure AD, semplificando la transizione. Le applicazioni SAML 2.0 possono essere integrate con Azure AD tramite la raccolta di app Azure AD o come applicazioni non della raccolta.

Le app che usano OAuth 2.0 o OpenID Connessione possono essere integrate in modo analogo con Azure AD registrazioni delle app. Le app che usano protocolli legacy possono usare Azure AD Application Proxy per l'autenticazione con Azure AD.

Per eventuali problemi con l'onboarding delle app SaaS, è possibile contattare l'alias di supporto di Integrazione applicazioni SaaS.

Certificati di firma SAML per l'accesso SSO

I certificati di firma sono una parte importante di qualsiasi distribuzione SSO. Azure AD crea i certificati di firma per stabilire l'accesso SSO federato basato su SAML alle applicazioni SaaS. Dopo aver aggiunto applicazioni della raccolta o non della raccolta, si configurerà l'applicazione aggiunta usando l'opzione SSO federato. Vedere Gestire i certificati per l'accesso Single Sign-On federato in Azure Active Directory.

Crittografia dei token SAML

Sia AD FS che Azure AD la crittografia dei token, ovvero la possibilità di crittografare le asserzioni di sicurezza SAML che passano alle applicazioni. Le asserzioni vengono crittografate con una chiave pubblica e decrittografate dall'applicazione ricevente con la chiave privata corrispondente. Quando si configura la crittografia dei token, si caricano i file di certificato X.509 per fornire le chiavi pubbliche.

Per informazioni sulla Azure AD di token SAML e su come configurarla, vedere Procedura: Configurare Azure AD di token SAML.

Nota

La crittografia dei token è una funzionalità Premium di Azure Active Directory (Azure AD). Per altre informazioni sulle edizioni, le funzionalità e i prezzi di Azure AD, vedere Prezzi di Azure Active Directory.

App e configurazioni che possono essere spostate oggi

Attualmente è possibile spostare facilmente le app SAML 2.0 che usano il set standard di elementi di configurazione e attestazioni. Questi elementi standard sono:

  • Nome entità utente
  • Indirizzo di posta elettronica
  • Nome specificato
  • Surname
  • Un attributo alternativo come NameID SAML, ad esempio l'attributo Mail, il prefisso di posta elettronica, l'ID dipendente o gli attributi dell'estensione 1-15 di Azure AD oppure l'attributo SamAccountName locale. Per altre informazioni, vedere Modifica dell'attestazione NameIdentifier.
  • Attestazioni personalizzate.

Di seguito sono richiesti passaggi di configurazione aggiuntivi per eseguire la migrazione Azure AD:

App e configurazioni attualmente non supportate in Azure AD

Attualmente non è possibile eseguire la migrazione delle app che richiedono determinate funzionalità.

Funzionalità del protocollo

Attualmente non è possibile eseguire la migrazione delle app che richiedono le funzionalità di protocollo seguenti:

  • Supporto per il modello WS-Trust ActAs

  • Risoluzione artefatto SAML

  • Verifica della firma delle richieste SAML firmate

    Nota

    Le richieste firmate vengono accettate, ma la firma non viene verificata.

    Dato che Azure AD restituisce il token solo agli endpoint preconfigurati nell'applicazione, la verifica della firma probabilmente non è necessaria nella maggior parte dei casi.

Attestazioni nelle funzionalità del token

Attualmente non è possibile eseguire la migrazione delle app che richiedono le attestazioni seguenti nelle funzionalità del token.

  • Attestazioni da archivi di attributi diversi dalla directory Azure AD, a meno che i dati non vengano sincronizzati con Azure AD. Per altre informazioni, vedere panoramica dell'API Azure AD di sincronizzazione.
  • Rilascio di attributi a più valori della directory. Ad esempio, al momento non è possibile rilasciare un'attestazione multivalore per gli indirizzi proxy.

Eseguire il mapping delle impostazioni dell AD FS app a Azure AD

La migrazione richiede la valutazione del modo in cui l'applicazione è configurata in locale e quindi il mapping di tale configurazione Azure AD. AD FS e Azure AD presentano un funzionamento simile, di conseguenza i concetti relativi alla configurazione degli identificatori e degli URL di accesso, disconnessione e trust si applicano in entrambi i casi. Documentare AD FS di configurazione delle applicazioni in modo che sia possibile configurarle facilmente in Azure AD.

Eseguire il mapping delle impostazioni di configurazione dell'app

La tabella seguente descrive alcuni dei mapping più comuni delle impostazioni tra un'AD FS attendibilità della relying party e l Azure AD Enterprise appliazione:

  • AD FS: trovare l'impostazione nel AD FS attendibilità della relying party per l'app. Fare clic con il pulsante destro del relying party e scegliere Proprietà.
  • Azure AD: l'impostazione viene configurata all'interno portale di Azure nelle proprietà SSO di ogni applicazione.
Impostazione di configurazione AD FS Come configurare in Azure AD Token SAML
URL di accesso dell'app

URL per l'accesso dell'utente all'app in un flusso SAML avviato da un provider di servizi.

N/A Aprire Configurazione SAML di base dall'accesso basato su SAML N/A
URL di risposta dell'app

URL dell'app dal punto di vista del provider di identità (IdP). Il provider di identità invia qui l'utente e il token dopo che l'utente ha eseguito l'accesso al provider di identità. Questo è noto anche come endpoint consumer di asserzione SAML.

Selezionare la scheda Endpoint Aprire Configurazione SAML di base dall'accesso basato su SAML Elemento destination nel token SAML. Valore di esempio: https://contoso.my.salesforce.com
URL di disconnessione dell'app

Si tratta dell'URL a cui vengono inviate le richieste di pulizia di disconnessione quando un utente si disconnette da un'app. Il provider di identità invia la richiesta di disconnessione dell'utente anche da tutte le altre app.

Selezionare la scheda Endpoint Aprire Configurazione SAML di base dall'accesso basato su SAML N/A
Identificatore dell'app

Si tratta dell'identificatore dell'app dal punto di vista del provider di identità. Come identificatore viene usato spesso il valore dell'URL di accesso, ma non sempre. A volte l'app lo chiama "ID entità".

Selezionare la scheda Identificatori Aprire Configurazione SAML di base dall'accesso basato su SAML Mappe all'elemento Audience nel token SAML.
Metadati di federazione dell'app

Questo è il percorso dei metadati di federazione dell'app. Viene usata dal provider di identità per aggiornare automaticamente specifiche impostazioni di configurazione come gli endpoint o i certificati di crittografia.

Selezionare la scheda Monitoraggio N/D. Azure AD non supporta l'utilizzo diretto dei metadati di federazione dell'applicazione. È possibile importare manualmente i metadati della federazione. N/A
Identificatore utente/ID nome

Attributo usato per indicare in modo univoco l'identità utente da Azure AD o AD FS all'app. Questo attributo è in genere l'UPN o l'indirizzo di posta elettronica dell'utente.

Regole attestazione. Nella maggior parte dei casi, la regola attestazioni e viene ese un'attestazione con un tipo che termina con NameIdentifier. È possibile trovare l'identificatore sotto l'intestazione Attributi utente e Attestazioni. Per impostazione predefinita, viene usato l'UPN Mappe all'elemento NameID nel token SAML.
Altre attestazioni

Esempi di altre informazioni sulle attestazioni comunemente inviate dal provider di identità all'app includono nome, cognome, indirizzo di posta elettronica e appartenenza al gruppo.

In AD FS sono riportate come altre regole attestazioni per la relying party. È possibile trovare l'identificatore sotto l'intestazione Attributi utente & attestazioni. Selezionare Visualizza e modifica tutti gli altri attributi utente. N/A

Eseguire il mapping delle impostazioni del provider di identità (IdP)

Configurare le applicazioni in modo che puntino Azure AD rispetto AD FS per l'accesso SSO. In questo caso, ci stiamo concentrando sulle app SaaS che usano il protocollo SAML. Tuttavia, questo concetto si estende anche alle app line-of-business personalizzate.

Nota

I valori di configurazione per Azure AD il modello in cui l'ID tenant di Azure sostituisce {tenant-id} e l'ID applicazione sostituisce {application-id}. Queste informazioni sono disponibili nel portale di Azure in Azure Active Directory > proprietà:

  • Selezionare ID directory per visualizzare l'ID tenant.
  • Selezionare ID applicazione per visualizzare l'ID applicazione.

A livello di alto livello, eseguire il mapping dei seguenti elementi di configurazione delle app SaaS chiave Azure AD.

Elemento Valore di configurazione
Autorità emittente del provider di identità https: / /sts.windows.net/{tenant-id}/
URL di accesso del provider di identità https://login.microsoftonline.com/{tenant-id}/saml2
URL disconnessione provider di identità https://login.microsoftonline.com/{tenant-id}/saml2
Percorso dei metadati della federazione https://login.windows.net/{tenant-id}/federationmetadata/2007-06/federationmetadata.xml?appid={application-id}

Eseguire il mapping delle impostazioni SSO per le app SaaS

Le app SaaS devono sapere dove inviare le richieste di autenticazione e come convalidare i token ricevuti. La tabella seguente descrive gli elementi per configurare le impostazioni SSO nell'app e i relativi valori o posizioni all'interno di AD FS e Azure AD

Impostazione di configurazione AD FS Come configurare in Azure AD
URL di accesso IdP

URL di accesso del provider di identità dal punto di vista dell'app (in cui l'utente viene reindirizzato per l'accesso).

L AD FS url di accesso è il nome AD FS servizio federativo seguito da "/adfs/ls/".

ad esempio https://fs.contoso.com/adfs/ls/

Sostituire {tenant-id} con l'ID tenant.

Per le app che usano il protocollo SAML-P: https://login.microsoftonline.com/{tenant-id}/saml2

Per le app che usano il WS-Federation seguente: https://login.microsoftonline.com/{tenant-id}/wsfed

URL di disconnessione IdP

URL di disconnessione del provider di identità dal punto di vista dell'app (in cui l'utente viene reindirizzato quando sceglie di disconnettersi dall'app).

L'URL di disconnessione è lo stesso dell'URL di accesso o lo stesso URL con "wa=wsignout1.0" aggiunto. ad esempio https://fs.contoso.com/adfs/ls/?wa=wsignout1.0 Sostituire {tenant-id} con l'ID tenant.

Per le app che usano il protocollo SAML-P:

https://login.microsoftonline.com/{tenant-id}/saml2

Per le app che usano il WS-Federation seguente: https://login.microsoftonline.com/common/wsfederation?wa=wsignout1.0

Certificato di firma del token

Il provider di identità usa la chiave privata del certificato per firmare i token emessi. Verifica che il token provenga dallo stesso provider di identità per cui è stato configurato il trust nell'app.

Il certificato per la firma di token di AD FS si trova in Certificati in Gestione AD FS. Trovarlo nell'portale di Azure nelle proprietà di Single Sign-On dell'applicazione sotto l'intestazione SAML Signing Certificate. da dove può essere scaricato per il caricamento nell'app.

Se l'applicazione ha più di un certificato, è possibile trovare tutti i certificati nel file XML dei metadati della federazione.

Identificatore/"autorità di emittente"

Identificatore del provider di identità dal punto di vista dell'app (talvolta denominato "ID autorità di emittente").

Nel token SAML il valore viene visualizzato come elemento Issuer.

L'identificatore per AD FS è in genere l'identificatore del servizio federativo in Gestione AD FS in > Modifica Servizio federativo proprietà. ad esempio http://fs.contoso.com/adfs/services/trust Sostituire {tenant-id} con l'ID tenant.

https: / /sts.windows.net/{tenant-id}/

Metadati della federazione IdP

Percorso dei metadati di federazione disponibili pubblicamente del provider di identità. Alcune app usano i metadati di federazione come alternativa alla configurazione di URL, identificatore e certificato per la firma di token eseguita singolarmente dall'amministratore.

Trovare l'URL AD FS metadati federativi in Gestione AD FS in Endpoint > servizio > metadati > tipo: Metadati federazione. ad esempio https://fs.contoso.com/FederationMetadata/2007-06/FederationMetadata.xml Il valore corrispondente per Azure AD segue il modello https://login.microsoftonline.com/{TenantDomainName}/FederationMetadata/2007-06/FederationMetadata.xml . Sostituire {TenantDomainName} con il nome del tenant nel formato "contoso.onmicrosoft.com".

Per altre informazioni, vedere Metadati della federazione.

Rappresentare AD FS criteri di sicurezza in Azure AD

Quando si sposta l'autenticazione dell'app Azure AD, creare mapping dai criteri di sicurezza esistenti alle varianti equivalenti o alternative disponibili in Azure AD. Assicurarsi che questi mapping possano essere esere esequisindo gli standard di sicurezza richiesti dai proprietari dell'app semplifica notevolmente il resto della migrazione dell'app.

Per ogni esempio di regola, viene illustrato l'aspetto della regola in AD FS, il codice equivalente del linguaggio delle regole AD FS e come viene eseguito il mapping a Azure AD.

Eseguire il mapping delle regole di autorizzazione

Di seguito sono riportati esempi di vari tipi di regole di autorizzazione in AD FS e il modo in cui vengono mappate Azure AD.

Esempio 1: Consentire l'accesso a tutti gli utenti

Consentire l'accesso a tutti gli utenti in AD FS:

Screenshot che mostra la finestra di dialogo Configura Sign-On con SAML.

Il mapping viene eseguito Azure AD in uno dei modi seguenti:

  1. Impostare Assegnazione utente obbligatoria su No.

    modificare i criteri di controllo di accesso per le app SaaS

    Nota

    L'impostazione assegnazione utente necessaria su richiede che gli utenti siano assegnati all'applicazione per ottenere l'accesso. Se impostato su No, tutti gli utenti hanno accesso. Questa opzione non controlla ciò che gli utenti vedono nell'App personali esperienza.

  2. Nella scheda Utenti e gruppi assegnare l'applicazione al gruppo automatico Tutti gli utenti. È necessario abilitare Gruppi dinamici nel tenant Azure AD per la disponibilità del gruppo predefinito Tutti gli utenti.

    App SaaS personali in Azure AD

Esempio 2: Consentire un gruppo in modo esplicito

Autorizzazione esplicita del gruppo in AD FS:

Screenshot che mostra la finestra di dialogo Modifica regola per la regola di attestazione Consenti amministratori di dominio.

Per eseguire il mapping di questa regola Azure AD:

  1. Nel portale di Azurecreare un gruppo di utenti che corrisponde al gruppo di utenti da AD FS.

  2. Assegnare le autorizzazioni dell'app al gruppo:

    Aggiungere un'assegnazione

Esempio 3: Autorizzare un utente specifico

Autorizzazione esplicita dell'utente AD FS:

Screenshot che mostra la finestra di dialogo Modifica regola per la regola Consenti un'attestazione utente specifica con un tipo di attestazione in ingresso S I D primario.

Per eseguire il mapping di questa regola Azure AD:

  • Nel portale di Azureaggiungere un utente all'app tramite la scheda Aggiungi assegnazione dell'app, come illustrato di seguito:

    App SaaS personali in Azure

Eseguire il mapping delle regole di autenticazione a più fattori

Una distribuzione locale di Multi-Factor Authentication (MFA) e AD FS funziona ancora dopo la migrazione perché si è federati con AD FS. Tuttavia, valutare la possibilità di eseguire la migrazione alle funzionalità MFA incorporate di Azure collegate ai flussi di lavoro di Azure AD di accesso condizionale di Azure.

Di seguito sono riportati esempi di tipi di regole di autenticazione a più fattori in AD FS e come è possibile eseguire il mapping di Azure AD in base a condizioni diverse.

Impostazioni delle regole MFA in AD FS:

Screenshot che mostra le condizioni per Azure A D nel portale di Azure.

Esempio 1: Applicare l'autenticazione a più fattori in base a utenti/gruppi

Il selettore utenti/gruppi è una regola che consente di applicare l'autenticazione a più fattori per gruppo (SID gruppo) o per utente (SID primario). Oltre alle assegnazioni di utenti/gruppi, tutte le caselle di controllo aggiuntive nell'interfaccia utente di configurazione di AD FS MFA funzionano come regole aggiuntive che vengono valutate dopo l'applicazione della regola di utenti/gruppi.

Specificare le regole di autenticazione a più fattori per un utente o un gruppo in Azure AD:

  1. Creare un nuovo criterio di accesso condizionale.

  2. Selezionare Assegnazioni. Aggiungere gli utenti o i gruppi per cui si vuole applicare l'autenticazione a più fattori.

  3. Configurare le opzioni di Controllo di accesso come illustrato di seguito:

    Screenshot che mostra il riquadro Concedi in cui è possibile concedere l'accesso.

Esempio 2: Applicare l'autenticazione a più fattori per i dispositivi non registrati

Specificare le regole di autenticazione a più fattori per i dispositivi non registrati in Azure AD:

  1. Creare un nuovo criterio di accesso condizionale.

  2. Impostare Assegnazioni su Tutti gli utenti.

  3. Configurare le opzioni di Controllo di accesso come illustrato di seguito:

    Screenshot che mostra il riquadro Concedi in cui è possibile concedere l'accesso e specificare altre restrizioni.

Quando si imposta l'opzione Per più controlli su Richiedi uno dei controlli selezionati , significa che se una delle condizioni specificate dalla casella di controllo viene soddisfatta dall'utente, all'utente viene concesso l'accesso all'app.

Esempio 3: Applicare l'autenticazione a più fattori in base alla posizione

Specificare le regole di autenticazione a più fattori in base alla posizione di un utente in Azure AD:

  1. Creare un nuovo criterio di accesso condizionale.

  2. Impostare Assegnazioni su Tutti gli utenti.

  3. Configurare percorsi denominati in Azure AD. In caso contrario, la federazione dall'interno della rete aziendale è attendibile.

  4. Configurare le regole condizioni per specificare i percorsi per cui si vuole applicare l'autenticazione a più fattori.

    Screenshot che mostra il riquadro Percorsi per le regole condizioni.

  5. Configurare le opzioni di Controllo di accesso come illustrato di seguito:

    Eseguire il mapping dei criteri di controllo di accesso

Eseguire il mapping degli attributi di emit come regola attestazioni

Creare attributi come regola attestazioni in AD FS:

Screenshot che mostra la finestra di dialogo Modifica regola per Generare attributi come attestazioni.

Per eseguire il mapping della regola Azure AD:

  1. Nel portale di Azureselezionare Enterprise applicazioni e quindi Single Sign-On per visualizzare la configurazione dell'accesso basato su SAML:

    Screenshot che mostra la pagina Single Sign-On per l'Enterprise applicazione.

  2. Selezionare Modifica (evidenziato) per modificare gli attributi:

    Questa è la pagina per modificare gli attributi utente e le attestazioni

Eseguire il mapping dei criteri di controllo di accesso predefiniti

Criteri di controllo di accesso predefiniti in AD FS 2016:

Azure AD controllo di accesso integrato

Per implementare criteri predefiniti in Azure AD, usare un nuovo criterio di accesso condizionale e configurare i controlli di accesso oppure usare progettazione criteri personalizzati in AD FS 2016 per configurare i criteri di controllo di accesso. L'Editor regole include un elenco completo di opzioni Consenti e Tranne che consentono di effettuare tutti i tipi di permutazioni.

Azure AD di controllo di accesso

In questa tabella sono elencate alcune opzioni utili per l'autorizzazione e l'Azure AD.

Opzione Come configurare l'opzione Permit in Azure AD? Come configurare l'opzione Except in Azure AD?
Da specifico rete Mappe percorso denominato in Azure AD Usare l'opzione Escludi per i percorsi attendibili
Da specifico gruppi Impostare un'assegnazione di utenti/gruppi Usare l'opzione Escludi in Utenti e gruppi
Da dispositivi con livello di attendibilità specifico Impostare questa opzione dal controllo Stato dispositivo in Assegnazioni -> condizioni Usare l'opzione Escludi in Condizione di stato del dispositivo e Includi tutti i dispositivi
Con attestazioni specifiche nella richiesta Non è possibile eseguire la migrazione di questa impostazione Non è possibile eseguire la migrazione di questa impostazione

Ecco un esempio di come configurare l'opzione Escludi per i percorsi attendibili nel portale di Azure:

Screenshot del mapping dei criteri di controllo di accesso

Transizione degli utenti da AD FS a Azure AD

Sincronizzare AD FS gruppi in Azure AD

Quando si esegue il mapping delle regole di autorizzazione, le app che eseguono l'AD FS possono usare gruppi di Active Directory per le autorizzazioni. In tal caso, usare Azure AD Connessione per sincronizzare questi gruppi con Azure AD prima di eseguire la migrazione delle applicazioni. Assicurarsi di verificare i gruppi e l'appartenenza prima della migrazione in modo da poter concedere l'accesso agli stessi utenti durante la migrazione dell'applicazione.

Per altre informazioni, vedere Prerequisiti per l'uso degli attributi del gruppo sincronizzati da Active Directory.

Configurare il provisioning automatico degli utenti

Alcune applicazioni SaaS supportano la possibilità di effettuare il provisioning degli utenti al primo accesso all'applicazione. In Azure AD il provisioning delle app si riferisce alla creazione automatica di identità utente e ruoli nel cloud (SaaS) a cui gli utenti devono accedere. Gli utenti di cui viene eseguita la migrazione hanno già un account nell'applicazione SaaS. È necessario effettuare il provisioning di tutti i nuovi utenti aggiunti dopo la migrazione. Testare il provisioning di app SaaS dopo la migrazione dell'applicazione.

Sincronizzare gli utenti esterni in Azure AD

Gli utenti esterni esistenti possono essere impostati in due modi AD FS:

  • Utenti esterni con un account locale all'interno dell'organizzazione: questi account continuano a essere utilizzati nello stesso modo in cui funzionano gli account utente interni. Questi account utente esterni hanno un nome di principio all'interno dell'organizzazione, anche se il messaggio di posta elettronica dell'account può puntare esternamente. Quando si procede con la migrazione, è possibile sfruttare i vantaggi offerti da Azure AD B2B eseguendo la migrazione di questi utenti per usare la propria identità aziendale quando tale identità è disponibile. In questo modo si semplifica il processo di accesso per tali utenti, in quanto vengono spesso connessi con il proprio accesso aziendale. Anche l'amministrazione dell'organizzazione è più semplice, perché non è necessario gestire gli account per gli utenti esterni.
  • Identità esterne federate: se attualmente si sta federazionendo con un'organizzazione esterna, è necessario adottare alcuni approcci:

Indipendentemente dalla configurazione degli utenti esterni esistenti, probabilmente hanno autorizzazioni associate al proprio account, nell'appartenenza a gruppi o in autorizzazioni specifiche. Valutare se è necessario eseguire la migrazione o la pulizia di queste autorizzazioni. Gli account all'interno dell'organizzazione che rappresentano un utente esterno devono essere disabilitati dopo la migrazione dell'utente a un'identità esterna. Il processo di migrazione deve essere discusso con i partner commerciali, in quanto potrebbe verificarsi un'interruzione della possibilità di connettersi alle risorse.

Eseguire la migrazione e testare le app

Seguire il processo di migrazione descritto in dettaglio in questo articolo. Passare quindi al portale di Azure per verificare se la migrazione è stata completata.

Seguire queste istruzioni:

  1. Selezionare Enterprise Applicazioni Tutte le > applicazioni e trovare l'app nell'elenco.
  2. Selezionare Gestisci > utenti e gruppi per assegnare almeno un utente o un gruppo all'app.
  3. Selezionare Gestisci accesso > condizionale. Esaminare l'elenco di criteri e assicurarsi di non bloccare l'accesso all'applicazione con criteri di accesso condizionale.

A seconda di come si configura l'app, verificare che l'accesso Single Sign-On funzioni correttamente.

Tipo di autenticazione Test
OAuth/OpenID Connessione Selezionare Enterprise applicazioni > autorizzazioni e assicurarsi di avere acconsentito all'applicazione nelle impostazioni utente per l'app.
SSO basato su SAML Usare il pulsante Test saml Impostazioni disponibile in Single Sign-On.
Password-Based SSO Scaricare e installare l'estensione Per l'accesso sicuro di MyApps. - Questa estensione consente di avviare qualsiasi app cloud dell'organizzazione che richiede l'uso di un processo SSO.
Proxy dell'applicazione Assicurarsi che il connettore sia in esecuzione e assegnato all'applicazione. Per ulteriore assistenza, Application Proxy alla risoluzione dei problemi.

Nota

I cookie dell'ambiente AD FS precedente vengono mantenuti nei computer degli utenti. Questi cookie possono causare problemi con la migrazione, in quanto gli utenti potrebbero essere indirizzati all'ambiente di accesso AD FS precedente rispetto al nuovo Azure AD accesso. Potrebbe essere necessario cancellare i cookie del browser utente manualmente o usando uno script. È anche possibile usare il System Center Configuration Manager o una piattaforma simile.

Risolvere problemi

Se si verificano errori nel test delle applicazioni di cui è stata eseguita la migrazione, la risoluzione dei problemi può essere il primo passaggio prima di eseguire il rollback alle relying party AD FS esistenti. Vedere Come eseguire il debug dell'accesso Single Sign-On basato su SAML alle applicazioni in Azure Active Directory.

Eseguire il rollback della migrazione

Se la migrazione non riesce, è consigliabile lasciare le relying party esistenti nei server AD FS e rimuovere l'accesso alle relying party. Ciò consente un fallback rapido, se necessario, durante la distribuzione.

Comunicazione dei dipendenti

Anche se la finestra di interruzione pianificata può essere minima, è comunque consigliabile pianificare la comunicazione proattiva di questi tempi ai dipendenti durante il passaggio dal AD FS al Azure AD. Assicurarsi che l'esperienza dell'app abbia un pulsante di feedback o puntatori al supporto per problemi.

Al termine della distribuzione, è possibile informare gli utenti della corretta distribuzione e ricordare loro i passaggi da eseguire.

  • Indicare agli utenti di usare App personali accedere a tutte le applicazioni di cui è stata eseguita la migrazione.
  • Ricordare agli utenti che potrebbe essere necessario aggiornare le impostazioni di MFA.
  • Se Self-Service la reimpostazione della password, gli utenti potrebbero dover aggiornare o verificare i metodi di autenticazione. Vedere MFA e modelli di comunicazione dell'utente finale SSPR.

Comunicazione con utenti esterni

Questo gruppo di utenti è in genere il più critico in caso di problemi. Ciò vale soprattutto se il proprio stato di sicurezza determina un set diverso di regole di accesso condizionale o profili di rischio per i partner esterni. Assicurarsi che i partner esterni siano a conoscenza della pianificazione della migrazione al cloud e di avere un intervallo di tempo durante il quale sono invitati a partecipare a una distribuzione pilota che testa tutti i flussi univoci per la collaborazione esterna. Infine, assicurarsi che sia possibile accedere al supporto in caso di problemi.

Passaggi successivi