Condividi tramite

Federazione

  • Articolo

Si applica a: Exchange Server 2013

Gli Information worker spesso devono collaborare con i destinatari esterni, quali fornitori, partner e clienti, e condividere le informazioni sulla disponibilità. La federazione in Microsoft Exchange Server 2013 contribuisce a tali sforzi di collaborazione. La Federazione fa riferimento all'infrastruttura di trust sottostante che supporta la condivisione federata, un metodo semplice per gli utenti per condividere le informazioni relative al calendario con i destinatari in altre organizzazioni esterne federate. Per ulteriori informazioni sulla condivisione federata, vedere Condivisione.

Importante

Questa funzionalità di Exchange Server 2013 non è completamente compatibile con Office 365 utilizzato da 21Vianet in Cina e potrebbe essere soggetta a limitazioni. Per altre informazioni, vedere Office 365 gestito da 21Vianet.

Terminologia chiave

L'elenco seguente definisce i componenti principali associati alla federazione in Exchange 2013.

  • Application Identifier (AppID):numero univoco generato dal sistema di autenticazione Microsoft Entra per identificare le organizzazioni di Exchange. L'AppID viene generato automaticamente quando si crea un trust federativo con il sistema di autenticazione Microsoft Entra.

  • token di delega: token SAML (Security Assertion Markup Language) emesso dal sistema di autenticazione Microsoft Entra che consente agli utenti di un'organizzazione federata di essere considerati attendibili da un'altra organizzazione federata. Un token di delega contiene l'indirizzo di posta elettronica dell'utente, un identificatore non modificabile e le informazioni associate all'azione per la quale è stato emesso il token.

  • organizzazione federata esterna: un'organizzazione esterna di Exchange che ha stabilito un trust federativo con il sistema di autenticazione Microsoft Entra.

  • condivisione federata: gruppo di funzionalità di Exchange che sfruttano un trust federativo con il sistema di autenticazione Microsoft Entra per funzionare tra le organizzazioni di Exchange, incluse le distribuzioni di Exchange cross-premise. Queste funzionalità vengono utilizzate per effettuare le richieste di autenticazione tra i server per conto degli utenti di più organizzazioni Exchange.

  • dominio federato: dominio autorevole accettato aggiunto all'identificatore dell'organizzazione (OrgID) per un'organizzazione di Exchange.

  • Stringa di crittografia a prova di dominio: stringa protetta da crittografia usata da un'organizzazione di Exchange per fornire la prova che l'organizzazione è proprietaria del dominio usato con il sistema di autenticazione Microsoft Entra. La stringa viene generata automaticamente quando si utilizza la procedura guidata Abilita relazione di trust federativa oppure può essere generata utilizzando il cmdlet Get-FederatedDomainProof.

  • Criteri di condivisione federata: criteri a livello di organizzazione che abilitano e controllano la condivisione delle informazioni di calendario stabilita dall'utente e da persona a persona.

  • federazione: accordo basato su trust tra due organizzazioni di Exchange per raggiungere uno scopo comune. Con la federazione, entrambe le organizzazioni desiderano che le asserzioni di autenticazione di una siano riconosciute anche dall'altra.

  • trust federativo: relazione con il sistema di autenticazione Microsoft Entra che definisce i componenti seguenti per l'organizzazione di Exchange:

    • Spazio dei nomi dell'account

    • Identificatore dell'applicazione (AppID)

    • Identificare dell'organizzazione (OrgID)

    • Domini federati

    Per configurare la condivisione federata con altre organizzazioni di Exchange federate, è necessario stabilire un trust federativo con il sistema di autenticazione Microsoft Entra.

  • organizzazione non federata: organizzazioni che non hanno un trust federativo stabilito con il sistema di autenticazione Microsoft Entra.

  • Identificatore dell'organizzazione (OrgID): definisce quali domini accettati autorevoli configurati in un'organizzazione sono abilitati per la federazione. Solo i destinatari con indirizzi di posta elettronica con domini federati configurati nell'OrgID vengono riconosciuti dal sistema di autenticazione Microsoft Entra e possono usare le funzionalità di condivisione federata. L'OrgID è dato dalla combinazione di una stringa predefinita e il primo dominio accettato selezionato per la federazione nella procedura guidata Abilita relazione di trust federativa. Ad esempio, se si specifica il dominio federato contoso.com come dominio primario SMTP dell'organizzazione, lo spazio dei nomi account FYDIBOHF25SPDLT.contoso.com verrà automaticamente creato come OrgID per la relazione di trust federativa.

  • relazione organizzativa: relazione uno-a-uno tra due organizzazioni federate di Exchange che consente ai destinatari di condividere informazioni sulla disponibilità del calendario. Una relazione dell'organizzazione richiede un trust federativo con il sistema di autenticazione Microsoft Entra e sostituisce la necessità di usare trust tra foreste o domini di Active Directory tra organizzazioni di Exchange.

  • Microsoft Entra sistema di autenticazione: servizio di identità gratuito basato sul cloud che funge da gestore di trust tra organizzazioni federate di Microsoft Exchange. Il suo compito è quello di emettere i token di delega per i destinatari di Exchange quando questi richiedono informazioni su destinatari in altre organizzazioni Exchange federate. Per altre informazioni, vedere Microsoft Entra ID.

Microsoft Entra sistema di autenticazione

Il sistema di autenticazione Microsoft Entra, un servizio gratuito basato sul cloud offerto da Microsoft, funge da trust broker tra l'organizzazione locale di Exchange 2013 e altre organizzazioni federate di Exchange 2010 ed Exchange 2013. Se si vuole configurare la federazione nell'organizzazione di Exchange, è necessario stabilire un trust federativo una tantum con il sistema di autenticazione Microsoft Entra, in modo che possa diventare un partner federativo con l'organizzazione. Con questa attendibilità, gli utenti autenticati da Active Directory (noti come provider di identità) ricevono token di delega SAML (Security Assertion Markup Language) dal sistema di autenticazione Microsoft Entra. Questi token di delega consentono agli utenti di un'organizzazione di Exchange federata di essere considerati attendibili da un'altra organizzazione di Exchange federata. Con il sistema di autenticazione Microsoft Entra che funge da gestore di trust, le organizzazioni non devono stabilire più relazioni di trust individuali con altre organizzazioni e gli utenti possono accedere alle risorse esterne usando un'esperienza Single Sign-On (SSO). Per altre informazioni, vedere MICROSOFT ENTRA ID.

Relazione di trust federativa

Per usare le funzionalità di condivisione federata di Exchange 2013, è necessario stabilire un trust federativo tra l'organizzazione di Exchange 2013 e il sistema di autenticazione Microsoft Entra. Stabilire un trust federativo con il sistema di autenticazione Microsoft Entra scambia il certificato di sicurezza digitale dell'organizzazione con il sistema di autenticazione Microsoft Entra e recupera il certificato del sistema di autenticazione Microsoft Entra e i metadati della federazione. È possibile stabilire un trust federativo usando la procedura guidata Abilita trust federativo nell'interfaccia di amministrazione di Exchange o il cmdlet New-FederationTrust in Exchange Management Shell. Un certificato autofirmato viene creato automaticamente dalla procedura guidata Abilita trust federativo e viene usato per firmare e crittografare i token di delega dal sistema di autenticazione Microsoft Entra che consentono agli utenti di essere considerati attendibili dalle organizzazioni federate esterne. Per informazioni dettagliate sui requisiti dei certificati, vedere Requisiti del certificato per la federazione più avanti in questo argomento.

Quando si crea un trust federativo con il sistema di autenticazione Microsoft Entra, viene generato automaticamente un identificatore di applicazione (AppID) per l'organizzazione di Exchange e fornito nell'output del cmdlet Get-FederationTrust. L'AppID viene usato dal sistema di autenticazione Microsoft Entra per identificare in modo univoco l'organizzazione di Exchange. Viene usato anche dall'organizzazione di Exchange per fornire la prova che l'organizzazione è proprietaria del dominio da usare con il sistema di autenticazione Microsoft Entra. Questa operazione viene eseguita tramite la creazione di un record di testo TXT nella zona DNS pubblico di ogni dominio federato.

Identificatore di organizzazione federata

L'identificatore di organizzazione federativa (OrgID) definisce quali dei domini accettati autorevoli configurati nell'organizzazione vengono abilitati per la federazione. Solo i destinatari con indirizzi di posta elettronica con domini accettati configurati in OrgID vengono riconosciuti dal sistema di autenticazione Microsoft Entra e possono usare le funzionalità di condivisione federata. Quando si crea un nuovo trust federativo, viene creato automaticamente un OrgID con il sistema di autenticazione Microsoft Entra. Questo OrgID è dato dalla combinazione di una stringa predefinita e il primo dominio accettato selezionato come dominio condiviso primario nella procedura guidata. Ad esempio, nella procedura guidata Modifica domini abilitati alla condivisione, se si specifica il dominio federato contoso.com come dominio condiviso primario dell'organizzazione, lo spazio dei nomi account FYDIBOHF25SPDLT.contoso.com verrà automaticamente creato come OrgID per la relazione di trust federativa per la propria organizzazione di Exchange.

Sebbene, generalmente, rappresenti il dominio SMTP primario per l'organizzazione di Exchange, non è necessario che questo sottodominio sia un dominio accettato nell'organizzazione di Exchange e non è richiesto alcun record di proprietà TXT DNS (Domain Name System). Il solo requisito necessario è che i domini accettati selezionati per la federazione siano limitati ad un massimo di 32 caratteri. L'unico scopo di questo sottodominio è quello di fungere da spazio dei nomi federato per il sistema di autenticazione Microsoft Entra per gestire identificatori univoci per i destinatari che richiedono token di delega SAML. Per ulteriori informazioni sui token SAML, vedere Attestazioni e token SAML

È possibile aggiungere o rimuovere domini accettati dalla relazione di trust federativa in qualsiasi momento. Se si desidera abilitare o disabilitare tutte le funzionalità di condivisione federata nell'organizzazione, è sufficiente abilitare o disabilitare l'OrgID per la relazione di trust federativa.

Importante

Se si modifica l'OrgID, i domini accettati o l'AppID utilizzato per la relazione di trust federativa, vengono coinvolte tutte le funzionalità di federazione nell'organizzazione. Questo influenza anche qualsiasi organizzazione di Exchange federata esterna, incluse le configurazioni di distribuzione ibrida e di Exchange Online. Si consiglia di notificare a tutti i partner federati esterni qualsiasi modifica a queste impostazioni di configurazione della relazione di trust federativa.

Esempio di federazione

Due organizzazioni di Exchange, Contoso, Ltd. e Fabrikam, Inc., vogliono che gli utenti siano in grado di condividere le informazioni sulla disponibilità del calendario tra loro. Ogni organizzazione crea un trust federativo con il sistema di autenticazione Microsoft Entra e configura lo spazio dei nomi dell'account per includere il dominio usato per il dominio dell'indirizzo di posta elettronica dell'utente.

I dipendenti di Contoso utilizzano uno dei seguenti domini di indirizzi di posta elettronica: contoso.com, contoso.co.uk, o contoso.ca. I dipendenti di Fabrikam utilizzano uno dei seguenti domini degli indirizzi di posta elettronica: fabrikam.com, fabrikam.org, o fabrikam.net. Entrambe le organizzazioni si assicurano che tutti i domini di posta elettronica accettati siano inclusi nello spazio dei nomi dell'account per il trust federativo con il sistema di autenticazione Microsoft Entra. Piuttosto che richiedere una complessa foresta Active Directory o una configurazione di trust del dominio tra le due organizzazioni, entrambe le organizzazioni configurano una relazione di organizzazione l'una con l'altra per abilitare la condivisione delle informazioni sulla disponibilità.

La figura seguente illustra la configurazione di federazione tra Contoso, Ltd. e Fabrikam, Inc.

Esempio di condivisione federata

Trust federativi e condivisione federativa.

Requisiti di certificato per la federazione

Per stabilire un trust federativo con il sistema di autenticazione Microsoft Entra, è necessario creare e installare un certificato autofirmato o un certificato X.509 firmato da un'autorità di certificazione (CA) nel server Exchange 2013 usato per creare l'attendibilità. Si consiglia vivamente di utilizzare un certificato autofirmato, che può essere creato automaticamente e installato utilizzando la procedura guidata Abilita relazione di trust federativa nell'interfaccia di amministrazione di Exchange. Questo certificato viene utilizzato solo per firmare e crittografare la condivisione federata e viene richiesto solo un certificato per la relazione di trust federativa. Exchange 2013 distribuisce automaticamente il certificato ad altri server Exchange 2013 nell'organizzazione.

Se si desidera utilizzare un certificato X.509 firmato da un CA esterno, il certificato deve rispondere ai seguenti requisiti:

  • CA attendibile: se possibile, il certificato SSL (Secure Sockets Layer) X.509 deve essere emesso da una CA attendibile da Windows Live. È tuttavia possibile utilizzare certificati rilasciati da autorità di certificazione che non sono attualmente certificate da Microsoft. Per un elenco aggiornato delle autorità di certificazione attendibili, vedere Autorità di certificazione radice disponibile nell'elenco locale per le relazioni di trust federative.

  • Identificatore della chiave del soggetto: il certificato deve avere un campo identificatore della chiave del soggetto. La maggior parte dei certificati X.509 rilasciati da autorità di certificazione commerciali ha questo identificativo.

  • Provider del servizio di crittografia CryptoAPI (CSP): il certificato deve usare un provider di servizi di crittografia CryptoAPI. Certificati che utilizzano Cryptography API: I provider di Next Generation (CNG) non sono supportati per la federazione. Se si utilizza Exchange per creare una richiesta di certificato, viene utilizzato un provider CryptoAPI. Per ulteriori informazioni, vedere Cryptography API: Next Generation.

  • Algoritmo di firma RSA: il certificato deve usare RSA come algoritmo di firma.

  • Chiave privata esportabile: la chiave privata usata per generare il certificato deve essere esportabile. È possibile specificare l'esportabilità della chiave privata quando si crea la richiesta di certificato utilizzando la procedura guidata Nuovo certificato di Exchange nell'interfaccia di amministrazione di Exchange in EMC o il cmdlet New-ExchangeCertificate in Shell.

  • Certificato corrente: il certificato deve essere corrente. Per creare una relazione di trust federativa, non è possibile utilizzare un certificato scaduto o revocato.

  • Utilizzo avanzato della chiave: il certificato deve includere il tipo di utilizzo avanzato della chiave (EKU) Autenticazione client (1.3.6.1.5.5.7.3.2). Questo tipo di utilizzo viene usato per provare la propria identità come computer remoto. Se si utilizza Interfaccia di amministrazione di Exchange o Shell per generare la richiesta di certificato, questo tipo di utilizzo è incluso per impostazione predefinita.

Nota

Siccome non viene utilizzato per l'autenticazione, il certificato non dispone di alcun nome del soggetto né di alcun requisito per il nome alternativo del soggetto. È possibile utilizzare un certificato con un nome del soggetto equivalente al nome host, al nome di dominio o a qualsiasi altro nome.

Transizione a un nuovo certificato

Il certificato utilizzato per creare la relazione di trust federativa viene designato come certificato corrente. Tuttavia, potrebbe essere necessario installare ed utilizzare un nuovo certificato per relazione di trust federativa periodicamente. Ad esempio, potrebbe essere necessario utilizzare un nuovo certificato se il certificato corrente scade o per rispondere ad un nuovo requisito dell'azienda o di protezione. Per garantire un passaggio diretto a un nuovo certificato, è necessario installare il nuovo certificato sul server Exchange 2013 e configurare la relazione di trust federativa per designarlo come nuovo certificato. Exchange 2013 distribuisce automaticamente il nuovo certificato ad altri server Exchange 2013 dell'organizzazione. In base alla topologia di Active Directory, la distribuzione del certificato potrebbe richiedere alcuni minuti. È possibile verificare lo stato del certificato utilizzando il cmdlet Test-FederationTrustCertificate in Shell.

Una volta verificato lo stato di distribuzione del certificato, è possibile configurare il trust per passare al nuovo certificato. Dopo il passaggio, il certificato corrente viene designato come certificato precedente, mentre quello nuovo viene designato come certificato corrente. Il nuovo certificato viene pubblicato nel sistema di autenticazione Microsoft Entra e tutti i nuovi token scambiati con il sistema di autenticazione Microsoft Entra vengono crittografati usando il nuovo certificato.

Nota

Questo processo di transizione del certificato viene utilizzato solo dalla federazione. Se si utilizza lo stesso certificato per altre funzionalità di Exchange 2013 per cui sono necessari i certificati, è necessario considerare i requisiti delle funzionalità quando si intende ottenere, installare o passare a un nuovo certificato.

Considerazioni sul firewall per la federazione

Le funzionalità di federazione richiedono l'accesso in uscita a Internet tramite HTTPS per i server Cassette postali e Accesso client dell'organizzazione. È necessario consentire l'accesso HTTPS in uscita (porta 443 per TCP) da tutti i server Accesso client di Exchange 2013 dell'organizzazione.

Affinché un'organizzazione esterna possa avere accesso alle informazioni sulla disponibilità dell'organizzazione, è necessario pubblicare un server Accesso client su Internet. Ciò richiede l'accesso HTTPS in ingresso da Internet al server Accesso client. I server Accesso client dei siti di Active Directory che non dispongono di un server Accesso client pubblicato su Internet possono utilizzare i server Accesso client di altri siti di Active Directory accessibili da Internet. I server Accesso client non pubblicati su Internet devono disporre dell'URL esterno della directory virtuale dei servizi Web impostata con l'URL visibile alle organizzazioni esterne.