Utilizzo dell'autenticazione basata sulle attestazioni di AD FS con Outlook Web App ed EAC
Si applica a: Exchange Server 2013 SP1
Riepilogo:
Per le distribuzioni locali di Exchange 2013 Service Pack 1 (SP1), l'installazione e la configurazione di Active Directory Federation Services (AD FS) consentono ora di usare l'autenticazione basata sulle attestazioni di AD FS per connettersi a Outlook Web App ed EAC. È possibile integrare AD FS e l'autenticazione basata sulle attestazioni con Exchange 2013 SP1. L'uso dell'autenticazione basata sulle attestazioni sostituisce i metodi di autenticazione tradizionali, inclusi i seguenti:
- Autenticazione di Windows
- Autenticazione basata su form
- Autenticazione del digest
- Autenticazione di base
- Autenticazione certificati dei client Active Directory
L'autenticazione è il processo di conferma dell'identità di un utente. L'autenticazione convalida che l'utente sia quello che dichiara di essere. L'identità basata sulle attestazioni è un altro approccio all'autenticazione. L'autenticazione basata sulle attestazioni rimuove la gestione dell'autenticazione dall'applicazione (in questo caso, Outlook Web App ed EA) per semplificare la gestione degli account centralizzando l'autenticazione. Outlook Web App ed EAC non sono responsabili dell'autenticazione degli utenti, dell'archiviazione di account utente e password, della ricerca dei dettagli dell'identità utente o dell'integrazione con altri sistemi di identità. La centralizzazione dell'autenticazione consente di semplificare l'aggiornamento ai metodi di autenticazione in futuro.
Nota
OWA per i dispositivi non supporta l'autenticazione basata sulle attestazioni AD FS.
Sono disponibili più versioni di AD FS che possono essere usate, come riepilogato nella tabella seguente.
Versione di Windows Server | Installazione | Versione di AD FS |
---|---|---|
Windows Server 2008 R2 | Scaricare e installare AD FS 2.0, che è un componente Windows aggiuntivo. | ADFS 2.0 |
Windows Server 2012 | Installare il ruolo predefinito del server AD FS. | AD FS 2.1 |
Windows Server 2012 R2 | Installare il ruolo predefinito del server AD FS. | AD FS 3.0 |
Le attività che verranno eseguite qui si basano su Windows Server 2012 R2 che include il servizio ruolo AD FS.
Panoramica dei passaggi necessari:
Passaggio 1: Esaminare i requisiti del certificato per AD FS
Passaggio 2: Installare e configurare Active Directory Federation Services (AD FS)
Passaggio 4: Installare il servizio ruolo Application Proxy Web (facoltativo)
Passaggio 5: Configurare il servizio ruolo Application Proxy Web (facoltativo)
Passaggio 6: Pubblicare Outlook Web App ed EAC usando web Application Proxy (facoltativo)
Passaggio 7: Configurare Exchange 2013 per l'uso dell'autenticazione di AD FS
Passaggio 8: Abilitare l'autenticazione di AD FS nelle directory virtuali OWA ed ECP
Passaggio 9 - Riavviare o riciclare Internet Information Services (IIS)
Passaggio 10: Testare le attestazioni AD FS per Outlook Web App ed EAC
Informazioni aggiuntive che è possibile conoscere
Informazioni necessarie per iniziare
È necessario installare almeno server Windows Server 2012 R2 separati: uno come controller di dominio che usa Active Directory Domain Services (AD DS), un server Exchange 2013, un server Application Proxy Web e un server Active Directory Federation Services (AD FS). Verificare che tutti gli aggiornamenti siano installati.
Installare Active Directory Domain Services nel numero appropriato di server Windows Server 2012 R2 nell'organizzazione. È anche possibile usare notifiche in Server Manager>Dashboard per alzare di livello questo server a un controller di dominio.
Installare il numero appropriato di server Accesso client e Cassette postali per l'organizzazione. Verificare che tutti gli aggiornamenti siano installati, incluso SP1, in tutti i server Exchange 2013 nell'organizzazione. Per scaricare SP1, vedere Aggiornamenti per Exchange 2013.
La distribuzione di Application Proxy Web in un server richiede autorizzazioni di amministratore locale. È necessario distribuire AD FS in un server che esegue Windows Server 2012 R2 nell'organizzazione prima di poter distribuire Application Proxy Web.
Installare e configurare il ruolo AD FS e creare trust della relying party e regole attestazioni in Windows Server 2012 R2. A tale scopo, è necessario accedere con un account utente membro del gruppo Domain Admins, Enterprise Admins o Administrators locale.
Determinare le autorizzazioni necessarie per Exchange 2013 visualizzando le Autorizzazioni funzionalità.
È necessario avere le autorizzazioni necessarie per gestire Outlook Web App. Per visualizzare le autorizzazioni necessarie, vedere la voce "autorizzazioni Outlook Web App" nell'argomento Autorizzazioni per client e dispositivi mobili.
È necessario avere le autorizzazioni necessarie per la gestione di EAC. Per visualizzare le autorizzazioni necessarie, vedere la voce "Connettività dell'interfaccia di amministrazione di Exchange" nell'argomento Autorizzazioni dell'infrastruttura di Exchange e Shell .
È possibile utilizzare solo la Shell per eseguire alcune procedure. Per sapere come aprire Shell nell'organizzazione Exchange locale, vedere Open the Shell.
Per informazioni sui tasti di scelta rapida che è possibile utilizzare con le procedure in questo argomento, vedere Tasti di scelta rapida nell'interfaccia di amministrazione di Exchange.
Consiglio
Problemi? È possibile richiedere supporto nei forum di Exchange. Visitare i forum all'indirizzo Exchange Server.
Passaggio 1: Esaminare i requisiti del certificato per AD FS
I certificati svolgono un ruolo fondamentale nella protezione delle comunicazioni tra i server Exchange 2013 SP1; client Web come Outlook Web App e EAC, Windows Server 2012 server R2, inclusi i server Active Directory Federation Services (AD FS) e i server Application Proxy Web. I requisiti per i certificati variano a seconda che si stia configurando un server AD FS, un proxy AD FS o un server web Application Proxy. I certificati usati per i servizi AD FS, inclusi i certificati SSL e di firma dei token, devono essere importati nell'archivio Autorità di certificazione radice attendibili in tutti i server Exchange, AD FS e Web Application Proxy. L'identificazione personale per il certificato importato viene usata anche nei server Exchange 2013 SP1 quando si usa il cmdlet Set-OrganizationConfig .
In qualsiasi progettazione di AD FS, è necessario usare vari certificati per proteggere la comunicazione tra gli utenti su Internet e i server AD FS. Ogni server federativo deve avere un certificato di comunicazione del servizio o ssl (Secure Socket Layer) e un certificato di firma token prima che i server AD FS, i controller di dominio Active Directory e i server Exchange 2013 possano comunicare ed eseguire l'autenticazione. A seconda dei requisiti di sicurezza e budget, valutare attentamente quali certificati verranno ottenuti da una CA pubblica o da una CA aziendale. Se si vuole installare e configurare una CA radice o subordinata dell'organizzazione, è possibile usare Servizi certificati Active Directory. Per altre informazioni su Servizi certificati Active Directory, vedere Panoramica di Servizi certificati Active Directory.
Anche se AD FS non richiede l'emissione di certificati da parte di una CA, il certificato SSL (il certificato SSL usato anche per impostazione predefinita come certificato di comunicazione del servizio) deve essere considerato attendibile dai client AD FS. È consigliabile non usare certificati autofirmati. I server federativi usano un certificato SSL per proteggere il traffico dei servizi Web per le comunicazioni SSL con i client Web e con i proxy del server federativo. Poiché il certificato SSL deve essere considerato attendibile dai computer client, è consigliabile usare un certificato firmato da una CA attendibile. Tutti i certificati selezionati devono avere una chiave privata corrispondente. Dopo aver ricevuto un certificato da una CA (enterprise o pubblica), assicurarsi che tutti i certificati vengano importati nell'archivio Autorità di certificazione radice attendibili in tutti i server. È possibile importare i certificati nell'archivio con lo snap-in MMC Certificati o distribuire i certificati usando Servizi certificati Active Directory. Se il certificato importato scade, è importante importare manualmente un altro certificato valido.
Importante
Se si usa il certificato di firma del token autofirmati da AD FS, è necessario importare questo certificato nell'archivio Autorità di certificazione radice attendibili in tutti i server Exchange 2013. Se il certificato di firma del token autofirmati non viene usato e viene distribuito il Application Proxy Web, è necessario aggiornare la chiave pubblica nella configurazione Application Proxy Web e tutte le attendibilità della relying party di AD FS.
Quando si configura Exchange 2013 SP1, AD FS e Web Application Proxy, seguire queste raccomandazioni sui certificati:
Server cassette postali: i certificati usati nei server Cassette postali sono certificati autofirmati che vengono creati quando viene installato Exchange 2013. Poiché tutti i client si connettono a un server Cassette postali di Exchange 2013 tramite un server Accesso client di Exchange 2013, gli unici certificati che è necessario gestire sono quelli nei server Accesso client.
Server accesso client: è necessario un certificato SSL usato per le comunicazioni del servizio. Se il certificato SSL esistente include già il nome di dominio completo usato per configurare l'endpoint di attendibilità della relying party, non sono necessari certificati aggiuntivi.
AD FS: AD FS richiede due tipi di certificati:
Certificato SSL usato per le comunicazioni del servizio
- Nome soggetto: adfs.contoso.com (nome distribuzione AD FS)
- Nome alternativo soggetto (SAN): nessuno
Certificato di firma del token
- Nome soggetto: tokensigning.contoso.com
- Nome alternativo soggetto (SAN): nessuno
Nota
Quando si sostituisce il certificato di firma del token in AD FS, è necessario aggiornare eventuali attendibilità della relying party esistenti per usare il nuovo certificato di firma del token.
Application Proxy Web
Certificato SSL usato per le comunicazioni del servizio
- Nome soggetto: owa.contoso.com
- Nome alternativo soggetto (SAN): nessuno
Nota
Se l'URL esterno Application Proxy Web è uguale all'URL interno, è possibile riutilizzare il certificato SSL di Exchange qui.
Certificato SSL proxy AD FS
- Nome soggetto: adfs.contoso.com (nome distribuzione AD FS)
- Nome alternativo soggetto (SAN): nessuno
Certificato di firma del token: verrà copiato automaticamente da AD FS come parte della procedura seguente. Se viene usato, questo certificato deve essere considerato attendibile dai server Exchange 2013 nell'organizzazione.
Per altre informazioni sui certificati, vedere la sezione relativa ai requisiti dei certificati in Requisiti di AD FS .
Nota
Un certificato di crittografia SSL è ancora necessario per Outlook Web App ed EAC anche se si dispone di un certificato SSL per AD FS. Il certificato SSL viene usato nelle directory virtuali OWA ed ECP.
Passaggio 2: Installare e configurare Active Directory Federation Services (AD FS)
AD FS in Windows Server 2012 R2 offre funzionalità semplificate e protette per la federazione delle identità e l'accesso Single Sign-On (SSO) Web. AD FS include un servizio federativo che abilita l'autenticazione basata su attestazioni, l'accesso SSO Web basato su browser, il multifactoring e l'autenticazione basata su attestazioni. AD FS semplifica l'accesso a sistemi e applicazioni usando un meccanismo di autenticazione basata sulle attestazioni e autorizzazione di accesso per mantenere la sicurezza delle applicazioni.
Per installare AD FS in Windows Server 2012 R2:
Aprire Server Manager nella schermata Start o Server Manager sulla barra delle applicazioni sul desktop. Fare clic su Aggiungi ruoli e funzionalità nel menu Gestisci .
Sulla pagina Informazioni preliminari, fare clic su Avanti.
Nella pagina Seleziona tipo di installazione fare clic su Installazione basata su ruoli o basata su funzionalità e quindi fare clic su Avanti.
Nella pagina Seleziona server di destinazione fare clic su Seleziona un server dal pool di server, verificare che il computer locale sia selezionato e quindi fare clic su Avanti.
Nella pagina Selezione ruoli server fare clic su Active Directory Federation Services e quindi su Avanti.
Nella pagina Seleziona funzionalità fare clic su Avanti. I prerequisiti o le funzionalità necessari sono già selezionati. Non è necessario selezionare altre funzionalità.
Nella pagina Active Directory Federation Service (AD FS) fare clic su Avanti.
Nella pagina Conferma selezioni di installazione selezionare Riavvia automaticamente il server di destinazione, se necessario, e quindi fare clic su Installa.
Nota
Non chiudere la procedura guidata durante il processo di installazione.
Dopo aver installato i server AD FS necessari e aver generato i certificati necessari, è necessario configurare AD FS e quindi verificare che AD FS funzioni correttamente. È anche possibile usare l'elenco di controllo qui per configurare e configurare AD FS: Elenco di controllo: Configurazione di un server federativo.
Per configurare Active Directory Federation Services:
Nella finestra sotto Active Directory Federation Services della pagina Stato installazione fare clic su Configura il servizio federativo nel server. Verrà visualizzata la Configurazione guidata servizio federativo Active Directory.
Nella pagina iniziale fare clic su Crea il primo server federativo in una server farm federativa e quindi fare clic su Avanti.
Nella pagina Connetti ad Active Directory Domain Services specificare un account con diritti di amministratore di dominio per il dominio di Active Directory corretto a cui è aggiunto il computer e quindi fare clic su Avanti. Se è necessario selezionare un utente diverso, fare clic su Cambia.
Nella pagina Specifica proprietà servizio eseguire le operazioni seguenti e quindi fare clic su Avanti:
Importare il certificato SSL ottenuto in precedenza da Servizi certificati Active Directory o da una CA pubblica. Questo certificato è il certificato di autenticazione del servizio richiesto. Passare alla posizione del certificato SSL. Per informazioni dettagliate sulla creazione e l'importazione di certificati SSL, vedere Certificati server.
Immettere un nome per il servizio federativo( ad esempio, digitare adfs.contoso.com).
Per specificare un nome visualizzato per il servizio federativo, digitare il nome dell'organizzazione, ad esempio Contoso, Ltd.
Nella pagina Specifica account del servizio selezionare Usa un account utente di dominio esistente o un account del servizio gestito del gruppo e quindi specificare l'account GMSA (FsGmsa) creato al momento della creazione del controller di dominio. Includere la password dell'account e quindi fare clic su Avanti.
Nota
L'account del servizio gestito a livello globale (GMSA) è un account che deve essere creato quando si configura un controller di dominio. L'account GMSA è necessario durante l'installazione e la configurazione di AD FS. Se l'account non è ancora stato creato, eseguire il comando Windows PowerShell seguente. Crea l'account per il dominio contoso.com e il server AD FS:
Esegui il comando seguente:
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
In questo esempio viene creato un nuovo account GMSA denominato FsGmsa per il servizio federativo denominato adfs.contoso.com. Il nome del Servizio federativo è il valore visibile ai client.
New-ADServiceAccount FsGmsa -DNSHostName adfs.contoso.com -ServicePrincipalNames http/adfs.contoso.com
Nella pagina Specifica database di configurazione selezionare Crea un database in questo server usando Database interno di Windows e quindi fare clic su Avanti.
Nella pagina Opzioni di revisione verificare le selezioni di configurazione. Facoltativamente, è possibile usare il pulsante Visualizza script per automatizzare altre installazioni di AD FS. Scegliere Avanti.
Nella pagina Controlli prerequisiti verificare che tutti i controlli dei prerequisiti siano stati completati correttamente e quindi fare clic su Configura.
Nella pagina Stato installazione verificare che tutti gli elementi installati correttamente e quindi fare clic su Chiudi.
Nella pagina Risultati esaminare i risultati, verificare se la configurazione è stata completata correttamente e quindi fare clic su Passaggi successivi necessari per completare la distribuzione del servizio federativo.
I comandi Windows PowerShell seguenti eseguono la stessa operazione dei passaggi precedenti.
Import-Module ADFS
Install-AdfsFarm -CertificateThumbprint 0E0C205D252002D535F6D32026B6AB074FB840E7 -FederationServiceDisplayName "Contoso Corporation" -FederationServiceName adfs.contoso.com -GroupServiceAccountIdentifier "contoso\FSgmsa`$"
Per informazioni dettagliate e la sintassi, vedere Install-AdfsFarm.
Per verificare l'installazione: nel server AD FS aprire il Web browser e quindi passare all'URL dei metadati di federazione , https://adfs.contoso.com/federationmetadata/2007-06/federationmetadata.xml
ad esempio .
Passaggio 3: Creare un trust relying party e regole attestazioni personalizzate per Outlook Web App ed EAC
Per tutte le applicazioni e i servizi che si desidera pubblicare tramite Application Proxy Web, è necessario configurare un trust della relying party nel server AD FS. Per le distribuzioni con più siti di Active Directory che usano spazi dei nomi separati, è necessario aggiungere un trust relying party per Outlook Web App ed EAC per ogni spazio dei nomi.
EAC usa la directory virtuale ECP. È possibile visualizzare o configurare le impostazioni per EAC usando i cmdlet Get-EcpVirtualDirectory e Set-EcpVirtualDirectory . Per accedere a EAC, è necessario usare un Web browser e passare a http://server1.contoso.com/ecp
.
Nota
L'inclusione della barra / finale negli esempi di URL illustrati di seguito è intenzionale. È importante assicurarsi che sia i trust della relying party di AD FS che gli URI del gruppo di destinatari di Exchange siano identici. Ciò significa che i trust della relying party di AD FS e gli URI del gruppo di destinatari di Exchange devono avere o entrambi generare le barre finali negli URL. Gli esempi in questa sezione contengono gli url finali /dopo qualsiasi URL che termina con "owa" ( /owa/) o "ecp" (/ecp/).
Per Outlook Web App, per creare attendibilità della relying party usando lo snap-in Gestione AD FS in Windows Server 2012 R2:
In Server Manager, fare clic su Strumenti, quindi selezionare Gestione di Active Directory FS.
Nello snap-in AD FS, in AD FS\Relazioni di trust, fare clic con il pulsante destro del mouse su Attendibilità relying party e quindi scegliere Aggiungi attendibilità relying party per aprire la procedura guidata Aggiungi attendibilità relying party .
Nella pagina iniziale fare clic su Start.
Nella pagina Seleziona origine dati fare clic su Immettere manualmente i dati sulla relying party e quindi fare clic su Avanti.
Nella casella Nome visualizzato della pagina Specifica nome visualizzato digitare Outlook Web App e quindi in Note digitare una descrizione per l'attendibilità della relying party ( ad esempio Questo è un trust per https://mail.contoso.com/owa/) e quindi fare clic su Avanti.
Nella pagina Scegli profilo fare clic su Profilo AD FS e quindi su Avanti.
Nella pagina Configura certificato fare clic su Avanti.
Nella pagina Configura URL fare clic su Abilita supporto per il protocollo passivo WS-Federation, quindi in Relying party WS-Federation Passive protocol URL digitare
https://mail.contoso.com/owa/
e quindi fare clic su Avanti.Nella pagina Configura identificatori specificare uno o più identificatori per questa relying party, fare clic su Aggiungi per aggiungerli all'elenco e quindi fare clic su Avanti.
Nella pagina Configura autenticazione a più fattori ora selezionare Configura impostazioni di autenticazione a più fattori per l'attendibilità della relying party.
Nella pagina Configura autenticazione a più fattori verificare di non voler configurare le impostazioni di autenticazione a più fattori per l'attendibilità della relying party in questo momento e quindi fare clic su Avanti.
Nella pagina Scegli regole di autorizzazione rilascio selezionare Consenti a tutti gli utenti di accedere a questa relying party e quindi fare clic su Avanti.
Nella pagina Pronto per aggiungere Trust, rivedere le impostazioni, quindi scegliere Avanti per salvare le informazioni trust relying party.
Nella pagina Fine verificare che la finestra di dialogo Apri la finestra di dialogo Modifica regole attestazioni per l'attendibilità della relying party alla chiusura della procedura guidata non sia selezionata e quindi fare clic su Chiudi.
Per creare un trust della relying party per EAC, è necessario eseguire di nuovo questi passaggi e creare un secondo trust della relying party, ma invece di inserire Outlook Web App per il nome visualizzato, immettere EAC. Per la descrizione, immettere Questo è un trust per l'interfaccia di amministrazione di Exchange e l'URL del protocollo passivo WS-Federation relying party è https://mail.contoso.com/ecp
.
In un modello di identità basato sulle attestazioni, la funzione di Active Directory Federation Services (AD FS) come servizio federativo consiste nell'emettere un token che contiene un set di attestazioni. Le regole delle attestazioni regolano le decisioni relative alle attestazioni che AD FS rilascia. Le regole attestazioni e tutti i dati di configurazione del server vengono archiviati nel database di configurazione di AD FS.
È necessario creare due regole attestazioni:
- Active Directory SID utente
- Active Directory UPN
Per aggiungere le regole attestazione necessarie:
In Server Manager fare clic su Strumenti e quindi su Gestione AD FS.
Nell'albero della console, in AD FS\Relazioni di trust, fare clic su Trust provider di attestazioni o Attendibilità relying party e quindi fare clic sull'attendibilità della relying party per Outlook Web App.
Nella finestra Attendibilità relying party fare clic con il pulsante destro del mouse sul trust Outlook Web App e quindi scegliere Modifica regole attestazione.
Nella finestra Modifica regole attestazione fare clic su Aggiungi regola nella scheda Regole di trasformazione rilascio per avviare l'Aggiunta guidata regola attestazione trasformazione.
Nella pagina Seleziona modello di regola , in Modello regola attestazione selezionare Invia attestazioni usando una regola personalizzata nell'elenco e quindi fare clic su Avanti.
Nella pagina Configura regola immettere il nome della regola attestazione nel passaggio Scegli tipo di regola in Nome regola attestazione. Usare un nome descrittivo per la regola attestazione, ad esempio ActiveDirectoryUserSID. In Regola personalizzata immettere la sintassi del linguaggio delle regole attestazioni seguente per questa regola:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);
Nella pagina Configura regola fare clic su Fine.
Nella finestra Modifica regole attestazione fare clic su Aggiungi regola nella scheda Regole di trasformazione rilascio per avviare l'Aggiunta guidata regola attestazione trasformazione.
Nella pagina Seleziona modello di regola , in Modello regola attestazione selezionare Invia attestazioni usando una regola personalizzata nell'elenco e quindi fare clic su Avanti.
Nella pagina Configura regola immettere il nome della regola attestazione nel passaggio Scegli tipo di regola in Nome regola attestazione. Usare un nome descrittivo per la regola attestazione, ad esempio ActiveDirectoryUPN. In Regola personalizzata immettere la sintassi del linguaggio delle regole attestazioni seguente per questa regola:
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);
Fare clic su Fine.
Nella finestra Modifica regole attestazione fare clic su Applica e quindi su OK.
Ripetere i passaggi da 3 a 12 di questa procedura per l'attendibilità della relying party di EAC.
In alternativa, è possibile creare trust di entità di inoltro e regole attestazioni usando Windows PowerShell:
Creare i due file .txt IssuanceAuthorizationRules.txt e IssuanceTransformRules.txt.
Importare il contenuto in due variabili.
Eseguire i due cmdlet seguenti per creare i trust della relying party. In questo esempio verranno configurate anche le regole attestazioni.
IssuanceAuthorizationRules.txt contiene:
@RuleTemplate = "AllowAllAuthzRule" => issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value = "true");
IssuanceTransformRules.txt contiene:
@RuleName = "ActiveDirectoryUserSID" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid"), query = ";objectSID;{0}", param = c.Value);
@RuleName = "ActiveDirectoryUPN" c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory", types = ("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"), query = ";userPrincipalName;{0}", param = c.Value);
Eseguire i comandi seguenti:
[string]$IssuanceAuthorizationRules=Get-Content -Path C:\IssuanceAuthorizationRules.txt
[string]$IssuanceTransformRules=Get-Content -Path c:\IssuanceTransformRules.txt
Add-ADFSRelyingPartyTrust -Name "Outlook Web App" -Enabled $true -Notes "This is a trust for https://mail.contoso.com/owa/" -WSFedEndpoint https://mail.contoso.com/owa/ -Identifier https://mail.contoso.com/owa/ -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Add-ADFSRelyingPartyTrust -Name "Exchange admin center (EAC)" -Enabled $true -Notes "This is a trust for https://mail.contoso.com/ecp/" -WSFedEndpoint https://mail.contoso.com/ecp/ -Identifier https://mail.contoso.com/ecp/ -IssuanceTransformRules $IssuanceTransformRules -IssuanceAuthorizationRules $IssuanceAuthorizationRules
Passaggio 4: Installare il servizio ruolo Application Proxy Web (facoltativo)
Nota
I passaggi 4, passaggio 5 e 6 sono destinati agli utenti che vogliono pubblicare Exchange OWA ed ECP usando Application Proxy Web e che vogliono disporre di Application Proxy Web per eseguire l'autenticazione ad ADFS. Tuttavia, la pubblicazione di Exchange con Application Proxy Web non è necessaria, quindi è possibile passare al passaggio 7 se non si usa Application Proxy Web e si vuole che Exchange esegua l'autenticazione ad AD FS.
Web Application Proxy è un nuovo servizio ruolo di Accesso remoto in Windows Server 2012 R2. Web Application Proxy offre funzionalità proxy inverso per le applicazioni Web all'interno della rete aziendale per consentire agli utenti di molti dispositivi di accedervi dall'esterno della rete aziendale. Web Application Proxy preautentica l'accesso alle applicazioni Web usando Active Directory Federation Services (AD FS) e funziona anche come proxy AD FS. Anche se non è necessario Application Proxy Web, è consigliabile quando AD FS è accessibile ai client esterni. Tuttavia, l'accesso offline in Outlook Web App non è supportato quando si usa l'autenticazione di AD FS tramite Application Proxy Web. Per altre informazioni sull'integrazione con Application Proxy Web, vedere Installazione e configurazione di Application Proxy Web per la pubblicazione di applicazioni interne
Avviso
Non è possibile installare Application Proxy Web nello stesso server con AD FS installato.
Per distribuire Application Proxy Web, è necessario installare il ruolo del server di Accesso remoto con il servizio ruolo Application Proxy Web in un server che fungerà da server web Application Proxy. Per installare il servizio ruolo Application Proxy Web:
Nel server Application Proxy Web, in Server Manager fare clic su Gestisci e quindi su Aggiungi ruoli e funzionalità.
Nell'Aggiunta guidata ruoli e funzionalità fare clic tre volte su Avanti per accedere alla pagina Ruoli server.
Nella pagina Ruoli server selezionare Accesso remoto nell'elenco e quindi fare clic su Avanti.
Nella pagina Funzionalità fare clic su Avanti.
Nella pagina Accesso remoto, leggere le informazioni e fare clic su Avanti.
Nella pagina Servizi ruolo selezionare Web Application Proxy. Nella finestra Aggiunta guidata ruoli e funzionalità fare clic su Aggiungi funzionalità e quindi su Avanti.
Nella finestra Conferma fare clic su Installa. Se necessario, è anche possibile selezionare Riavvia automaticamente il server di destinazione.
Nella finestra di dialogo Stato installazione verificare che l'installazione sia stata completata correttamente e quindi fare clic su Chiudi.
Il cmdlet Windows PowerShell seguente esegue la stessa operazione dei passaggi precedenti.
Install-WindowsFeature Web-Application-Proxy -IncludeManagementTools
Passaggio 5: Configurare il servizio ruolo Application Proxy Web (facoltativo)
È necessario configurare Application Proxy Web per connettersi al server AD FS. Ripetere questa procedura per tutti i server che si desidera distribuire come server Application Proxy Web.
Per configurare il servizio ruolo Applicazione Web:
Nel server Application Proxy Web, in Server Manager fare clic su Strumenti e quindi su Gestione accesso remoto.
Nel riquadro Configurazione fare clic su Application Proxy Web.
Nel riquadro centrale della console gestione accesso remoto fare clic su Esegui configurazione guidata Application Proxy Web.
Nella configurazione guidata Application Proxy Web fare clic su Avanti nella finestra di dialogo Iniziale.
Nella pagina Server federativo eseguire le operazioni seguenti e quindi fare clic su Avanti:
Nella casella Nome servizio federativo immettere il nome di dominio completo (FQDN) del server AD FS , ad esempio adfs.contoso.com.
Nelle caselle Nome utente e Password digitare le credenziali di un account amministratore locale nei server AD FS.
Nella finestra di dialogo Certificato proxy AD FS, nell'elenco dei certificati attualmente installati nel server Application Proxy Web, selezionare il certificato da usare da Application Proxy Web per la funzionalità proxy AD FS e quindi fare clic su Avanti. Il certificato scelto qui deve essere quello il cui oggetto è il nome del servizio federativo (ad esempio, adfs.contoso.com).
Nella finestra di dialogo Conferma esaminare le impostazioni. Se necessario, è possibile copiare il cmdlet Windows PowerShell per automatizzare installazioni aggiuntive. Fare clic su Configura.
Nella finestra di dialogo Risultati verificare che la configurazione sia stata completata correttamente e quindi fare clic su Chiudi.
Il cmdlet Windows PowerShell seguente esegue la stessa operazione dei passaggi precedenti.
Install-WebApplicationProxy -CertificateThumprint 1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b -FederationServiceName adfs.contoso.com
Passaggio 6: Pubblicare Outlook Web App ed EAC usando Application Proxy Web (facoltativo)
Nel passaggio 3 sono stati creati trust di entità di inoltro delle attestazioni per Outlook Web App ed EAC ed è ora necessario pubblicare entrambe queste applicazioni. Prima di eseguire questa operazione, verificare che sia stata creata un'attendibilità della relying party e verificare di disporre di un certificato nel server di Application Proxy Web adatto per Outlook Web App ed EAC. Per tutti gli endpoint AD FS che devono essere pubblicati da Web Application Proxy, nella console di gestione di AD FS è necessario impostare l'endpoint su Proxy Abilitato.
Seguire la procedura per pubblicare Outlook Web App usando Application Proxy Web. Per EAC, ripetere questi passaggi. Quando si pubblica EAC, è necessario modificare il nome, l'URL esterno, il certificato esterno e l'URL back-end.
Per pubblicare Outlook Web App ed EAC usando Application Proxy Web:
Nel server Application Proxy Web fare clic su Application Proxy Web nella console gestione accesso remoto e quindi fare clic su Pubblica nel riquadro Attività.
Nella pagina iniziale della Pubblicazione guidata nuova applicazione fare clic su Avanti.
Nella pagina Preautenticazione fare clic su Active Directory Federation Services (AD FS) e quindi su Avanti.
Nell'elenco delle relying party della pagina Relying Party selezionare la relying party per l'applicazione che si vuole pubblicare e quindi fare clic su Avanti.
Nella pagina Impostazioni di pubblicazione eseguire le operazioni seguenti e quindi fare clic su Avanti:
Nella casella Nome immettere un nome descrittivo per l'applicazione. Questo nome viene usato solo nell'elenco delle applicazioni pubblicate nella console di Gestione accesso remoto. È possibile usare OWA ed EAC per i nomi.
Nella casella URL esterno immettere l'URL esterno per l'applicazione,
https://external.contoso.com/owa/
ad esempio per Outlook Web App ehttps://external.contoso.com/ecp/
per EAC.Nell'elenco Certificato esterno selezionare un certificato il cui nome soggetto corrisponde al nome host dell'URL esterno.
Nella casella URL server back-end immettere l'URL del server back-end. Si noti che questo valore viene immesso automaticamente quando si immette l'URL esterno ed è necessario modificarlo solo se l'URL del server back-end è diverso,
https://mail.contoso.com/owa/
ad esempio per Outlook Web App ehttps://mail.contoso.com/ecp/
per EAC.
Nota
I Application Proxy Web possono tradurre i nomi host negli URL, ma non possono tradurre i percorsi. È quindi possibile immettere nomi host diversi, ma è necessario immettere lo stesso percorso. Ad esempio, è possibile immettere un URL esterno di
https://external.contoso.com/app1/
e un URL del server back-end dihttps://mail.contoso.com/app1/
. Tuttavia, non è possibile immettere un URL esterno dihttps://external.contoso.com/app1/
e un URL del server back-end dihttps://mail.contoso.com/internal-app1/
.Nella pagina Conferma esaminare le impostazioni e quindi fare clic su Pubblica. È possibile copiare il comando Windows PowerShell per configurare altre applicazioni pubblicate.
Nella pagina Risultati verificare che l'applicazione sia stata pubblicata correttamente e quindi fare clic su Chiudi.
Il cmdlet Windows PowerShell seguente esegue le stesse attività della procedura precedente per Outlook Web App.
Add-WebApplicationProxyApplication -BackendServerUrl 'https://mail.contoso.com/owa/' -ExternalCertificateThumbprint 'E9D5F6CDEA243E6E62090B96EC6DE873AF821983' -ExternalUrl 'https://external.contoso.com/owa/' -Name 'OWA' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Outlook Web App'
Il cmdlet Windows PowerShell seguente esegue le stesse attività della procedura precedente per EAC.
Add-WebApplicationProxyApplication -BackendServerUrl 'https://mail.contoso.com/ecp/' -ExternalCertificateThumbprint 'E9D5F6CDEA243E6E62090B96EC6DE873AF821983' -ExternalUrl 'https://external.contoso.com/ecp/' -Name 'EAC' -ExternalPreAuthentication ADFS -ADFSRelyingPartyName 'Exchange admin center'
Dopo aver completato questi passaggi, Web Application Proxy eseguirà l'autenticazione di AD FS per i client Outlook Web App ed EAC e le connessioni verranno anche proxy a Exchange per loro conto. Non è necessario configurare Exchange stesso per l'autenticazione di AD FS, quindi procedere al passaggio 10 per testare la configurazione.
Passaggio 7: Configurare Exchange 2013 per l'uso dell'autenticazione di AD FS
Quando si configura AD FS per l'uso per l'autenticazione basata sulle attestazioni con Outlook Web App ed EAC in Exchange 2013, è necessario abilitare AD FS per l'organizzazione di Exchange. È necessario usare il cmdlet Set-OrganizationConfig per configurare le impostazioni di AD FS per l'organizzazione:
Impostare l'autorità di certificazione AD FS su
https://adfs.contoso.com/adfs/ls/
.Impostare gli URI di AD FS su
https://mail.contoso.com/owa/
ehttps://mail.contoso.com/ecp/
.Trovare l'identificazione personale del certificato di firma del token AD FS usando Windows PowerShell nel server AD FS e immettendo
Get-ADFSCertificate -CertificateType "Token-signing"
. Assegnare quindi l'identificazione personale del certificato di firma del token trovata. Se il certificato di firma del token AD FS è scaduto, l'identificazione personale del nuovo certificato di firma del token AD FS deve essere aggiornata usando il cmdlet Set-OrganizationConfig .
Eseguire i comandi seguenti in Exchange Management Shell.
$uris = @("https://mail.contoso.com/owa/","https://mail.contoso.com/ecp/")
Set-OrganizationConfig -AdfsIssuer "https://adfs.contoso.com/adfs/ls/" -AdfsAudienceUris $uris -AdfsSignCertificateThumbprint "88970C64278A15D642934DC2961D9CCA5E28DA6B"
Nota
Il parametro -AdfsEncryptCertificateThumbprint non è supportato per questi scenari.
Per informazioni dettagliate e sintassi, vedere Set-OrganizationConfig e Get-ADFSCertificate.
Passaggio 8: Abilitare l'autenticazione di AD FS nelle directory virtuali OWA ed ECP
Per le directory virtuali OWA ed ECP, abilitare l'autenticazione AD FS come unico metodo di autenticazione e disabilitare tutte le altre forme di autenticazione.
Avviso
È necessario configurare la directory virtuale ECP prima di configurare la directory virtuale OWA.
Configurare la directory virtuale ECP usando Exchange Management Shell. Nella finestra Shell eseguire il comando seguente.
Get-EcpVirtualDirectory | Set-EcpVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false
Configurare la directory virtuale OWA usando Exchange Management Shell. Nella finestra Shell eseguire il comando seguente.
Get-OwaVirtualDirectory | Set-OwaVirtualDirectory -AdfsAuthentication $true -BasicAuthentication $false -DigestAuthentication $false -FormsAuthentication $false -WindowsAuthentication $false -OAuthAuthentication $false
Nota
I comandi di Exchange Management Shell precedenti configurano le directory virtuali OWA ed ECP in ogni server Accesso client dell'organizzazione. Se non si desidera applicare queste impostazioni a tutti i server Accesso client, usare il parametro -Identity e specificare il server Accesso client. È probabile che si voglia applicare queste impostazioni solo ai server Accesso client dell'organizzazione con connessione Internet.
Per informazioni dettagliate e sintassi, vedere Get-OwaVirtualDirectory e Set-OwaVirtualDirectory o Get-EcpVirtualDirectory e Set-EcpVirtualDirectory.
Passaggio 9 - Riavviare o riciclare Internet Information Services (IIS)
Dopo aver completato tutti i passaggi necessari, incluse le modifiche alle directory virtuali di Exchange, è necessario riavviare Internet Information Services. A tale scopo, si può utilizzare uno dei seguenti metodi:
Uso di Windows PowerShell:
Restart-Service W3SVC,WAS -force
Usando una riga di comando: fare clic su Start, fare clic su Esegui, digitare
IISReset /noforce
e quindi fare clic su OK.Uso di Gestione Internet Information Server (IIS): in Server Manager>IIS fare clic su Strumenti e quindi su Gestione Internet Information Services (IIS). Nella finestra Gestione Internet Information Server (IIS) fare clic su Riavvia nel riquadro azioni in Gestisci server.
Passaggio 10: Testare le attestazioni AD FS per Outlook Web App ed EAC
Per testare le attestazioni AD FS per Outlook Web App:
Nel Web browser accedere a Outlook Web App ,
https://mail.contoso.com/owa
ad esempio .Nella finestra del browser, se viene visualizzato un errore di certificato, passare al sito Web Outlook Web App. Si dovrebbe essere reindirizzati alla pagina di accesso ad ADFS o alla richiesta di credenziali di ADFS.
Digitare il nome utente (dominio\utente) e la password, quindi fare clic su Accedi.
Outlook Web App verrà caricato nella finestra.
Per eseguire il test delle attestazioni per EAC:
Nel Web browser passare a
https://mail.contoso.com/ecp
.Nella finestra del browser, se viene visualizzato un errore di certificato, continuare con il sito Web ECP. Si dovrebbe essere reindirizzati alla pagina di accesso ad ADFS o alla richiesta di credenziali di ADFS.
Digitare il nome utente (dominio\utente) e la password, quindi fare clic su Accedi.
L'interfaccia di amministrazione di Exchange deve essere caricata nella finestra.
Informazioni aggiuntive che è possibile conoscere
Autenticazione a più fattori
Per le distribuzioni locali di Exchange 2013 SP1, la distribuzione e la configurazione di Active Directory Federation Services (AD FS) 2.0 tramite attestazioni significa che Outlook Web App ed EAC in Exchange 2013 SP1 possono supportare metodi di autenticazione a più fattori, ad esempio l'autenticazione basata su certificati, l'autenticazione o i token di sicurezza e l'autenticazione tramite impronta digitale. L'autenticazione a due fattori è spesso confusa con altre forme di autenticazione. L'autenticazione a più fattori richiede l'uso di due dei tre fattori di autenticazione. Questi fattori sono:
Qualcosa che solo l'utente conosce (ad esempio, la password, il PIN o il modello)
Qualcosa che solo l'utente ha (ad esempio, una scheda bancomat, un token di sicurezza, una smart card o un telefono cellulare)
Si tratta solo dell'utente (ad esempio, una caratteristica biometrica, ad esempio un'impronta digitale)
Per dettagli sull'autenticazione a più fattori in Windows Server 2012 R2, vedere Panoramica: Riduzione dei rischi con l'autenticazione a più fattori aggiuntiva per le applicazioni riservate e Guida dettagliata: Riduzione dei rischi con l'autenticazione a più fattori aggiuntiva per le applicazioni riservate.
Nella Windows Server 2012 servizio ruolo R2 AD FS, il servizio federativo funziona come servizio token di sicurezza, fornisce i token di sicurezza usati con le attestazioni e offre la possibilità di supportare l'autenticazione a più fattori. Il servizio federativo che genera token in base alle credenziali presenti. Quando l'archivio account ha verificato le credenziali dell'utente, le attestazioni per l'utente vengono generate in base alle regole del criterio di attendibilità e poi aggiunte a un token di sicurezza emesso dal client. Per informazioni sulle attestazioni, vedere Informazioni sulle attestazioni.
Co-Existing con altre versioni di Exchange
È possibile usare l'autenticazione di AD FS per Outlook Web App ed EAC quando nell'organizzazione sono distribuite più versioni di Exchange. Questo scenario è supportato solo per le distribuzioni di Exchange 2010 ed Exchange 2013 e solo se tutti i client si connettono tramite i server Exchange 2013 e tali server Exchange 2013 sono stati configurati per l'autenticazione ad AD FS.
Gli utenti con una cassetta postale in un server Exchange 2010 possono accedere alle cassette postali tramite un server Exchange 2013 configurato per l'autenticazione ad AD FS. La connessione client iniziale al server Exchange 2013 userà l'autenticazione AD FS. La connessione proxy al server Exchange 2010, tuttavia, userà Kerberos. Non è possibile configurare Exchange Server 2010 per l'autenticazione ad AD FS diretta.