Quando si configurano e gestiscono gli account utente, è possibile scegliere tra tre modelli di identità principali in Office 365:
Gestire gli account utente solo in Office 365. Non sono necessari server on-premise per gestire gli utenti; Tutto viene fatto nel cloud. |
Sincronizzare gli oggetti directory locali con Office 365 e gestire gli utenti in locale. È anche possibile sincronizzare le password in modo che gli utenti abbiano la stessa password in locale e nel cloud, ma dovranno eseguire nuovamente l'accesso per usare Office 365. |
Sincronizzare gli oggetti directory locali con Office 365 e gestire gli utenti in locale. Gli utenti hanno la stessa password in locale e nel cloud e non devono accedere di nuovo per usare Office 365. Questa operazione viene spesso definita Single Sign-On. |
È importante valutare attentamente il modello di identità da utilizzare per essere operativi. Pensa al tempo, alla complessità esistente e ai costi. Questi fattori sono diversi per ogni organizzazione; In questo argomento verranno esaminati questi concetti chiave per ogni modello di identità per semplificare la scelta dell'identità che si vuole usare per la distribuzione.
Se i requisiti cambiano, è anche possibile passare a un modello di identità diverso.
In questo modello è possibile creare e gestire gli utenti nel portale di Microsoft Office e archiviare gli account in Azure AD. Azure AD verifica le password. Azure AD è la directory cloud utilizzata da Office 365. Non sono necessari server on-premise: Microsoft gestisce tutto per te. Quando l'identità e l'autenticazione vengono gestite completamente nel cloud, è possibile gestire gli account utente e le licenze utente tramite il portale online Microsoft o i cmdlet di Windows PowerShell.
L'immagine seguente riepiloga come gestire gli utenti nel modello di identità cloud.
L'amministratore si connette al portale Microsoft Online in Microsoft Cloud Platform per creare o gestire utenti.
Le richieste di creazione o gestione vengono passate ad Azure AD.
Se si tratta di una richiesta di modifica, la modifica viene apportata e copiata nuovamente nel portale di Microsoft Office
I nuovi account utente e le modifiche apportate agli account utente esistenti vengono copiati nuovamente nel portale Microsoft Office.
Quando utilizzare Cloud Identity? L'identità cloud è una buona scelta se:
Se si dispone di un ambiente di directory esistente in locale, è possibile integrare Office 365 con la directory usando l'identità sincronizzata o l'accesso Single Sign-On e l'identità federata per creare e gestire gli utenti in Office 365.
In questo modello è possibile gestire l'identità dell'utente in un server locale e sincronizzare gli account e, facoltativamente, le password con il cloud. L'utente immette in locale la stessa password che immette nel cloud e, al momento dell'accesso, la password viene verificata da Azure AD. Questo modello usa uno strumento di sincronizzazione della directory per sincronizzare l'identità locale con Office 365.
Per configurare il modello di identità sincronizzato, è necessario disporre di una directory locale da cui eseguire la sincronizzazione ed è necessario installare uno strumento di sincronizzazione della directory. Prima di sincronizzare gli account, si eseguiranno alcuni controlli di coerenza nella directory locale.
Quando utilizzare identità sincronizzate o federate:
Questo modello: |
Funziona in queste situazioni: |
Identità sincronizzate |
Quando si dispone di una directory locale e si desidera sincronizzare gli account utente e, facoltativamente, le password. Se si sincronizzano anche le password, gli utenti useranno la stessa password per accedere alle risorse locali e a Office 365. Quando si vogliono identità federate, ma si esegue un progetto pilota di Office 365 o, per qualche altro motivo, non si è ancora pronti per dedicare tempo alla distribuzione dei server Active Directory Federation Services (ADFS). |
Identità federate |
Quando è necessario uno scenario avanzato, ad esempio: federazione, criteri o requisiti tecnici esistenti |
Il diagramma seguente mostra uno scenario di identità sincronizzata con sincronizzazione delle password. Lo strumento di sincronizzazione mantiene sincronizzate le identità degli utenti aziendali locali e nel cloud.
È possibile installare Microsoft Azure Active Directory Connect.
È possibile creare nuovi utenti nella directory locale.
Lo strumento di sincronizzazione controllerà periodicamente la directory locale per individuare eventuali nuove identità create. Effettua quindi il provisioning di queste identità in Azure AD, collega tra loro le identità locali e cloud, sincronizza le password e le rende visibili all'utente tramite il portale di Microsoft Office.
Quando si apportano modifiche agli utenti nella directory locale, tali modifiche vengono sincronizzate con Azure AD e rese disponibili tramite il portale di Microsoft Office.
Questo modello richiede un'identità sincronizzata, ma con una modifica a tale modello: la password utente viene verificata dal provider di identità locale. Ciò significa che non è necessario sincronizzare l'hash della password con Azure AD. Questo modello usa Active Directory Federation Services (ADFS) o un provider di identità di terze parti.
I motivi per l'utilizzo di un'identità federata includono:
Infrastruttura esistente
Requisiti tecnici
Requisiti delle policy
Il diagramma seguente mostra uno scenario di identità federata con un deployment ibrido on-premise e cloud. La directory locale in questo esempio è ADFS. Lo strumento di sincronizzazione mantiene sincronizzate le identità degli utenti aziendali locali e nel cloud.
Installazione di Azure Active Directory Connect Lo strumento di sincronizzazione consente di mantenere Azure AD aggiornato con le ultime modifiche apportate nella directory locale. Sarà necessario usare un'installazione personalizzata di Azure AD Connect per configurare l'accesso Single Sign-On.
È possibile creare nuovi utenti nell'Active Directory locale.
Lo strumento di sincronizzazione verificherà periodicamente la presenza di nuove identità create nel server Active Directory locale. Effettua quindi il provisioning di queste identità in Azure AD, collega le identità locali e cloud tra loro e le rende visibili all'utente tramite il portale di Microsoft Office.
Man mano che vengono apportate modifiche all'identità in Active Directory locale, tali modifiche vengono sincronizzate con Azure AD.
Queste modifiche sono rese disponibili tramite il portale di Microsoft Office.
Gli utenti federati accedono con ADFS.
ADFS genera un token di sicurezza che viene passato ad Azure AD. Il token viene verificato e convalidato e gli utenti sono quindi autorizzati per Office 365.