Preparare l'accesso Single Sign-On
Aggiornato: 25 giugno 2015
Si applica a: Azure, Office 365, Power BI, Windows Intune
Nota
Questo argomento potrebbe non essere completamente applicabile agli utenti di Microsoft Azure in Cina. Per altre informazioni sul servizio di Azure in Cina, vedere windowsazure.cn.
Per prepararsi all'accesso Single Sign-On, effettuare i seguenti passaggi:
Passaggio 1: Esaminare i requisiti per l'accesso Single Sign-On
Passaggio 2: Preparare Active Directory
Passaggio 1: Esaminare i requisiti per l'accesso Single Sign-On
Per implementare questa soluzione SSO, è necessario soddisfare i seguenti requisiti:
Avere distribuito e eseguito Active Directory in Windows Server 2003 R2, Windows Server 2008, Windows Server 2008 R2, Windows Server 2012 o Windows Server 2012 R2 con un livello funzionale di modalità mista o nativa.
Se si intende utilizzare ADFS come STS, è necessario effettuare una delle seguenti operazioni:
Scaricare, installare e distribuire AD FS 2.0 in un server Windows Server 2008 o Windows Server 2008 R2. Inoltre, se gli utenti si connetteranno dall'esterno della rete aziendale, è necessario distribuire un proxy AD FS 2.0.
Installare il servizio ruolo ADFS in un server Windows Server 2012 o Windows Server 2012 R2.
Se si prevede di utilizzare il provider di identità Shibboleth come STS, è necessario installarlo e prepararlo in modo che sia operativo.
Importante
Microsoft supporta questa esperienza di accesso Single Sign-On come integrazione di un servizio cloud Microsoft, ad esempio Microsoft Intune o Office 365, con il provider di identità Shibboleth già installato e operativo. Poiché Shibboleth è un prodotto di terze parti, Microsoft non fornisce alcun supporto per i problemi e le domande relativi a distribuzione, configurazione, risoluzione dei problemi o procedure consigliate per questo provider di identità. Per altre informazioni sul provider di identità Shibboleth, vedere https://go.microsoft.com/fwlink/?LinkID=256497.
In base al tipo di servizio token di sicurezza che verrà configurato, usare il modulo Microsoft Azure Active Directory per Windows PowerShell per stabilire un trust federato tra il servizio token di sicurezza locale e Azure AD.
Installare gli aggiornamenti necessari per le sottoscrizioni ai servizi cloud Microsoft per essere certi che gli utenti eseguano gli aggiornamenti più recenti di Windows 7, Windows Vista o Windows XP. Alcune funzionalità potrebbero non funzionare correttamente senza le versioni appropriate di sistemi operativi, browser e software. Per altre informazioni, vedere Appendice A: Esaminare i requisiti software.
Passaggio 2: Preparare Active Directory
Active Directory deve avere determinate impostazioni configurate per funzionare correttamente con l'accesso Single Sign-On. In particolare, è necessario che il nome dell'entità utente (UPN), noto anche come nome di accesso utente, sia configurato in modo specifico per ciascun utente.
Nota
Per preparare l'ambiente Active Directory per l'accesso Single Sign-On, è consigliabile eseguire Microsoft Deployment Readiness Tool. Questo strumento esamina l'ambiente Active Directory e fornisce un report che include informazioni su se si è pronti o meno per configurare l'accesso Single Sign-On. In caso di valutazione negativa, elenca le modifiche necessarie a preparare l'accesso Single Sign-On. Ad esempio, analizza la disponibilità di UPN degli utenti verificandone il formato.
In base al singolo dominio, potrebbe essere necessario effettuare le seguenti operazioni:
Impostare un UPN conosciuto dall'utente.
Verificare che il suffisso di dominio UPN appartenga al dominio che si è scelto di configurare per l'accesso Single Sign-On.
Registrare il dominio scelto per la federazione come dominio pubblico con un registrar o all'interno dei propri server DNS pubblici.
Per creare upn, seguire le istruzioni nell'argomento di Active Directory Aggiungere suffissi nome entità utente. Tenere presente che gli UPN utilizzati per l'accesso Single Sign-On possono contenere solo lettere, numeri, punti, trattini e caratteri di sottolineatura.
Se il nome di dominio di Active Directory non è un dominio Internet pubblico ,ad esempio termina con un suffisso ".local", è necessario impostare un UPN per avere un suffisso di dominio con un nome di dominio Internet che può essere registrato pubblicamente. È consigliabile utilizzare un nome familiare agli utenti, ad esempio il relativo dominio di posta elettronica.
Se la sincronizzazione di Active Directory è già stata impostata, l'UPN dell'utente potrebbe non corrispondere all'UPN locale dell'utente definito in Active Directory. Per risolvere questo problema, rinominare l'UPN dell'utente usando il cmdlet Set-MsolUserPrincipalName nel modulo Microsoft Azure Active Directory per Windows PowerShell.