Esporta (0) Stampa
Espandi tutto

Gestire le identità per gli ambienti ibridi a foresta singola con l'autenticazione locale

Pubblicato: gennaio 2014

Aggiornamento: agosto 2014

Si applica a: Windows Server 2012 R2

Gli utenti aziendali hanno l'esigenza di usare le applicazioni residenti nel cloud da qualsiasi luogo e da qualsiasi dispositivo, ma non sono in grado di farlo perché non è disponibile un meccanismo di autenticazione. Il reparto IT aziendale deve permettere agli utenti di eseguire l'autenticazione per queste applicazioni cloud e allo stesso tempo ha l'esigenza di controllare in tempo reale chi è autorizzato ad accedere a tali applicazioni.

Questa guida fornisce indicazioni specifiche su come integrare una directory locale con una directory cloud per fare in modo che le applicazioni che risiedono nel cloud siano facilmente accessibili da parte degli utenti, ovunque si trovino e da qualunque dispositivo. Questo obiettivo viene raggiunto mediante l'autenticazione locale. Per un esempio sull'uso dell'autenticazione cloud, vedere Gestire le identità per ambienti ibridi a foresta singola mediante l'autenticazione cloud.

Problema locale

Contenuto della guida alla soluzione:

Questa sezione descrive lo scenario, il problema e gli obiettivi per un'organizzazione di esempio.

L'organizzazione è un'azienda di grandi dimensioni con uffici in tutto il mondo, tra cui America del Nord, Sud America, Europa e Asia. I team di ricerca e sviluppo (R&D) operano principalmente in Europa e America del Nord. Sviluppano le formule che verranno usate dai centri di produzione ubicati soprattutto in Asia.

Per lo sviluppo di nuove formule o il miglioramento di quelle esistenti, i team R&D collaborano a stretto contatto eseguendo test standardizzati simili nelle sedi in America del Nord ed Europa e condividendo poi i risultati. I risultati vengono quindi finalizzati e vengono sviluppate le nuove formule. Queste formule sono considerate segreti commerciali e sono coperte da brevetto. Al termine di questo procedimento, le formule vengono inviate agli stabilimenti per l'avvio della produzione.

Attualmente, se un membro del team R&D vuole condividere i risultati con le controparti in altre aree della società o inviare una formula a uno degli stabilimenti in Asia, il team usa la tecnologia UFS (Encrypting File System) per crittografare i file da inviare tramite posta elettronica, che il destinatario provvederà a decrittografare.

Questo processo presenta problemi di diverso tipo per l'organizzazione:

  • Privacy: i dati trasmessi tramite posta elettronica, anche se sono crittografati, sono comunque soggetti a tentativi di attacco su Internet. Inoltre, molti dipendenti accedono alla posta elettronica da dispositivi personali e non è garantito che siano protetti.

  • Integrità: il certificato EFS usato per crittografare i file deve essere esportato e inviato a destinazione. L'invio di questi certificati tramite posta elettronica rappresenta un rischio per la loro integrità.

  • Riservatezza: spesso viene usato uno stesso certificato per crittografare i risultati dei test e le formule. I dipendenti presso gli impianti di produzione potranno decrittografare i risultati se ne ricevono una copia per errore.

Per affrontare queste problematiche, l'organizzazione ha deciso di configurare Office 365 SharePoint nel cloud e di usarlo come portale per la condivisione dei risultati dei test e delle formule. L'organizzazione intende però usare la propria istanza locale di Active Directory come provider di autenticazione e non prevede di usare l'autenticazione cloud.

L'organizzazione dispone di un provider di autenticazione, l'istanza locale di Active Directory, che al momento non è in grado di autenticare i dipendenti nei nuovi siti di Office 365 SharePoint che saranno ospitati in Azure.

Problema generale che l'organizzazione vuole risolvere:

In che modo un architetto di sistema o un amministratore IT può fornire agli utenti un'identità comune per l'accesso alle risorse locali e basate sul cloud? E come fa a gestire queste identità e mantenere sincronizzate le informazioni in diversi ambienti senza usare troppe risorse IT?

Per fornire l'accesso ai siti di SharePoint dell'organizzazione sarà necessario poter autenticare i dipendenti con un provider di autenticazione, ovvero l'istanza locale di Active Directory. Inoltre, l'organizzazione vuole consentire l'accesso solo ai dipendenti dei reparti R&D e produzione che richiedono l'accesso ai siti. Attualmente sono gli unici che avranno bisogno di accedere ai siti.

Dopo avere valutato le opzioni disponibili, si decide che è possibile sfruttare l'istanza esistente di Active Directory Federation Services (ADFS) per usare l'autenticazione locale con Azure. L'organizzazione ha configurato ADFS diversi anni fa. Questo consentirà di risparmiare tempo e denaro, dato che il personale IT ha già familiarità con ADFS.

La dirigenza ha autorizzato l'acquisto degli abbonamenti a Office 365 e delle sottoscrizioni di Azure. A questo punto gli amministratori di Active Directory devono configurare la propria istanza di Azure AD e federarla con l'istanza locale di Active Directory.

Gli amministratori di Active Directory devono poter sfruttare l'istanza locale di Active Directory per popolare l'istanza di Azure AD e devono essere in grado di farlo rapidamente. Successivamente, gli amministratori di Active Directory devono federare l'istanza locale di Active Directory con Azure AD. Inoltre, per l'organizzazione è importante che i dipendenti che accedono ai siti di SharePoint dispongano di un'esperienza Single Sign-On e che possano accedere ai siti solo dopo avere effettuato l'accesso alla rete aziendale. L'organizzazione preferisce che questi siti non siano accessibili da computer o dispositivi esterni. L'organizzazione desidera poter disabilitare rapidamente gli utenti che fuoriescono dall'organico aziendale, in modo che non possano accedere al sito di SharePoint dopo la disabilitazione dei relativi account. Infine, l'organizzazione vorrebbe poter personalizzare la pagina di accesso affinché gli utenti sappiano di eseguire l'accesso a un sito aziendale.

Gli obiettivi dell'organizzazione per la soluzione con identità ibrida sono:

  • Possibilità di configurare rapidamente la sincronizzazione con l'istanza locale di Active Directory.

  • Possibilità di controllare chi e cosa viene sincronizzato con Azure AD.

  • Possibilità di offrire Single Sign-On (SSO). Ricezione di avvisi in caso di inattività della sincronizzazione o della funzionalità Single Sign-On

  • Possibilità di limitare l'accesso ai soli utenti dei reparti R&D e produzione che accedono da una posizione locale sicura.

  • Possibilità di impedire l'accesso in tempo reale alle risorse cloud nel caso in cui un utente lasci l'organizzazione.

  • Possibilità di ottenere rapidamente la pulizia e la corretta gestione dei sistemi di identità locali in modo che possano essere usati come fonte per Azure AD.

  • Possibilità di personalizzare la pagina di accesso in modo che presenti un'identità aziendale.

In questa sezione viene illustrato il progetto di soluzione per il problema descritto nella sezione precedente e vengono presentate alcune considerazioni generali sulla relativa progettazione.

Grazie ad Azure AD, l'organizzazione è in grado di integrare l'istanza locale di Active Directory con l'istanza di Azure AD. Questa istanza verrà quindi usata per reindirizzare gli utenti alla pagina di accesso di ADFS, in cui viene rilasciato un token che sarà presentato ad Azure AD e viene effettuata l'autenticazione.

Soluzione locale

Nella tabella seguente sono elencati gli elementi che fanno parte della soluzione e viene descritto il motivo della scelta.

 

Elemento del progetto di soluzione Perché è incluso nella soluzione?

Strumento di sincronizzazione di Azure Active Directory

Consente di sincronizzare gli oggetti della directory locale con Azure AD. Per una panoramica di questa tecnologia, vedere Roadmap sulla sincronizzazione della directory.

Active Directory Federation Services

Questa funzionalità di Windows Server 2012 R2 è un servizio token di sicurezza che usa Active Directory come archivio identità. Il servizio token di sicurezza di ADFS può rilasciare token di sicurezza al chiamante mediante vari protocolli, tra cui OAuth, WS-Trust, WS-Federation e Security Assertion Markup Language (SAML) 2.0. Per una panoramica di questa tecnologia, vedere Panoramica di ADFS (Active Directory Federation Services).

Strumento IdFix per la correzione degli errori di DirSync

Consente ai clienti di identificare e correggere la maggior parte degli errori di sincronizzazione degli oggetti nelle foreste di Active Directory. Per una panoramica di questa tecnologia, vedere la pagina di download dello strumento IdFix per la correzione degli errori di DirSync.

ADFS è una funzionalità di Windows Server 2012 R2 che consente la federazione tra l'istanza locale di Active Directory e Azure AD. Questa funzionalità permette agli utenti di accedere ai servizi Azure AD, ad esempio Office 365, Intune e CRM Online, attraverso un'esperienza Single Sign-On. In questo modo gli utenti potranno usufruire di un processo Single Sign-On che usa l'istanza locale di Active Directory come provider di autenticazione.

Lo strumento IdFix per la correzione degli errori di DirSync consente di individuare e correggere gli oggetti identità e i relativi attributi in un ambiente Active Directory locale in preparazione della migrazione. In questo modo è possibile identificare rapidamente i problemi che possono verificarsi durante la sincronizzazione prima di avviare il processo. Sulla base di queste informazioni è possibile apportare modifiche all'ambiente tali da evitare questi errori.

Questo progetto è consigliato perché consente di realizzare gli obiettivi di progettazione dell'organizzazione. Esistono due modi per fornire l'autenticazione per le risorse basate su Azure: autenticazione cloud o autenticazione locale tramite un servizio token di sicurezza.

Una delle problematiche principali dell'organizzazione è quella di avere la possibilità di impedire in tempo reale a un utente che ha lasciato l'azienda di accedere alle risorse basate sul cloud. L'uso dello strumento di sincronizzazione di Azure Active Directory e dell'autenticazione cloud comportano un ritardo fino a tre ore. In altri termini, se si disabilita un account utente in locale, l'applicazione della modifica in Azure può richiedere fino a tre ore. Questo invece non accade se l'utente deve tornare nell'ambiente locale ed eseguire l'autenticazione. Se un account utente viene disabilitato in locale, non potrà ricevere un token e non sarà autorizzato ad accedere alle risorse cloud.

L'organizzazione richiede la possibilità di fornire accesso Single Sign-On. Questa richiesta può essere soddisfatta solo mediante la federazione dell'istanza locale di Active Directory con Azure AD.

La pagina di accesso può essere personalizzata solo se si usa ADFS e la personalizzazione di ADFS.

Per implementare la soluzione è possibile eseguire i passaggi descritti in questa sezione. Verificare la corretta esecuzione di ogni passaggio prima di procedere al successivo.

  1. Preparare l'accesso Single Sign-On

    Nella fase preparatoria è necessario assicurarsi che l'ambiente soddisfi i requisiti per la funzionalità Single Sign-On e verificare che i tenant di Active Directory e Active AD siano impostati in modo da essere compatibili con requisiti Single Sign-On. Per altre informazioni, vedere Preparazione dell'accesso Single Sign-On.

  2. Configurare il servizio token di sicurezza locale, ovvero ADFS

    Dopo avere preparato l'ambiente per l'accesso Single Sign-On, è necessario configurare una nuova infrastruttura ADFS locale per fornire l'accesso Single Sign-On al servizio cloud agli utenti di Active Directory locali e remoti. Se nell'ambiente di produzione è presente ADFS, è possibile usarlo per la distribuzione di Single Sign-On anziché configurare una nuova infrastruttura, purché sia supportato da Azure AD. Per altre informazioni su come iniziare a configurare un servizio token di sicurezza ADFS, seguire la procedura indicata in Elenco di controllo: Utilizzo di ADFS per implementare e gestire l'accesso Single Sign-On.

  3. Installare Windows PowerShell per Single Sign-On con ADFS

    Il modulo Azure AD per Windows PowerShell è disponibile come download per la gestione dei dati dell'organizzazione in Azure AD. Questo modulo installa un set di cmdlet in Windows PowerShell da eseguire per configurare l'accesso Single Sign-On ad Azure AD e quindi a tutti i servizi cloud per i quali si dispone di una sottoscrizione. Per altre informazioni, vedere Installazione di Windows PowerShell per l'acceso Single Sign-On con ADFS.

  4. Configurare una relazione di trust tra ADFS e Azure AD

    È necessario stabilire una relazione di trust tra Azure AD e l'istanza locale di Active Directory. Ogni dominio di cui si desidera impostare la federazione deve essere aggiunto come dominio con accesso Single Sign-On o convertito da dominio standard in dominio con accesso Single Sign-On. Quando si aggiunge o si converte un dominio, viene configurata una relazione di trust tra ADFS e Azure AD. Per altre informazioni, vedere Configurazione di un trust tra ADFS e Windows Azure AD.

  5. Preparazione della sincronizzazione della directory

    Verificare i requisiti di sistema, creare le autorizzazioni appropriate e tenere conto delle considerazioni relative alle prestazioni. Per altre informazioni, vedere Preparazione della sincronizzazione della directory. Al termine di questo passaggio, assicurarsi di disporre di un foglio di lavoro compilato recante le opzioni di progettazione della soluzione selezionate.

  6. Attivare la sincronizzazione della directory

    Attivare la sincronizzazione della directory per l'azienda. Per altre informazioni, vedere Attivazione della sincronizzazione della directory. Al termine di questo passaggio, verificare che le funzionalità siano configurate.

  7. Configurare il computer di sincronizzazione della directory

    Installare lo strumento di sincronizzazione di Azure AD. Se lo strumento è già stato installato, è possibile apprendere informazioni sull'aggiornamento, la disinstallazione o lo spostamento in un altro computer. Per altre informazioni, vedere Configurazione del computer di sincronizzazione della directory. Al termine di questo passaggio, verificare che le funzionalità siano configurate.

  8. Sincronizzazione delle directory personali

    Eseguire una sincronizzazione iniziale e verificare che i dati vengano sincronizzati correttamente. Verrà anche descritto come configurare lo strumento di sincronizzazione di Azure AD per impostare la sincronizzazione periodica e come forzare la sincronizzazione della directory. Per altre informazioni, vedere Utilizzo della configurazione guidata per la sincronizzazione delle directory. Al termine di questo passaggio, verificare che le funzionalità siano configurate.

  9. Attivazione degli utenti sincronizzati

    Attivare gli utenti nel portale di Office 365 affinché possano usare i servizi sottoscritti. A questo scopo occorre assegnare loro una licenza per l'uso di Office 365. È possibile eseguire queste operazioni singolarmente o in blocco. Per altre informazioni, vedere Attivazione degli utenti sincronizzati. Al termine di questo passaggio, verificare che le funzionalità siano configurate. Tenere presente che questo passaggio è facoltativo ed è richiesto solo se si usa Office 365.

  10. Verificare la soluzione.

    Dopo la sincronizzazione degli utenti, testare l'accesso a http://myapps.microsoft.com. Si dovrebbe venire reindirizzati alla pagina di accesso di ADFS. Dopo l'accesso e dopo l'autenticazione dell'utente in ADFS, l'utente verrà reindirizzato nuovamente a http://myapps.microsoft.com. Verranno visualizzate le applicazioni di Office 365 di cui si dispone. Un utente normale può effettuare l'accesso senza la necessità di una sottoscrizione di Azure.

Il documento è risultato utile?
(1500 caratteri rimanenti)
Grazie per i commenti inviati.
Mostra:
© 2015 Microsoft