Sincronizzare la directory con Single Sign-On

Aggiornato: 25 giugno 2015

Si applica a: Azure, Office 365, Power BI, Windows Intune

L'accesso Single Sign-On, detto anche federazione delle identità, è uno scenario di integrazione di directory basato su ibrido di Azure Active Directory che è possibile implementare quando si vuole semplificare la possibilità dell'utente di accedere facilmente ai servizi cloud, ad esempio Office 365 o Microsoft Intune, con le credenziali aziendali di Active Directory esistenti. Senza Single Sign-On, gli utenti devono mantenere nomi utente e password distinti per l'account online e l'account locale.

Un servizio token di sicurezza consente la federazione delle identità, estendendo la nozione di autenticazione, autorizzazione e accesso SSO centralizzati alle applicazioni Web e ai servizi situati virtualmente ovunque, tra cui reti perimetrali, reti partner e cloud. Quando si configura un servizio token di sicurezza per l'accesso Single Sign-On a un servizio Microsoft Cloud, si crea un trust federativo tra il servizio token di sicurezza locale e il dominio federato specificato nel tenant di Azure AD.

Azure AD supporta gli scenari di Single Sign-On in cui viene usato uno dei seguenti servizi token di sicurezza:

• Active Directory Federation Services (ADFS)

• Provider di identità Shibboleth

• Provider di identità di terze parti

Nella seguente figura viene illustrata l'interazione di Active Directory locale e della server farm del servizio token di sicurezza con il sistema di autenticazione di Azure AD per garantire l'accesso a uno o più servizi cloud. Quando si configura l'accesso Single Sign-On, si stabilisce un trust federato tra il servizio token di sicurezza e il sistema di autenticazione di Azure AD. Gli utenti locali di Active Directory ottengono dal servizio token di sicurezza locale i token di autenticazione che ne reindirizzano le richieste attraverso il trust federato. Questo permette agli utenti di accedere ai servizi cloud sottoscritti dalla società senza dover accedere con credenziali diverse.

Vantaggi dell'implementazione di questo scenario

Quando si implementa l'accesso Single Sign-On, gli utenti possono usare le credenziali aziendali per accedere al servizio cloud sottoscritto dall'azienda. Gli utenti non dovranno ripetere l'accesso e ricordare più password.

Oltre ai vantaggi per gli utenti, offre numerosi vantaggi per gli amministratori:

• Controllo dei criteri: L'amministratore può controllare i criteri degli account tramite Active Directory, che offre all'amministratore la possibilità di gestire criteri password, restrizioni della workstation, controlli di blocco e altro ancora, senza dover eseguire attività aggiuntive nel cloud.

• Controllo di accesso: L'amministratore può limitare l'accesso al servizio cloud in modo che i servizi possano essere accessibili tramite l'ambiente aziendale, tramite server online o entrambi.

• Chiamate di supporto ridotte: Le password dimenticate sono una fonte comune di chiamate di supporto in tutte le aziende. se gli utenti devono ricordare un numero minore di password, è meno probabile che le dimentichino.

• Sicurezza: Le identità utente e le informazioni sono protette perché tutti i server e i servizi usati nell'accesso Single Sign-On vengono gestiti e controllati in locale.

• Supporto per l'autenticazione avanzata: È possibile usare l'autenticazione avanzata (detta anche autenticazione a due fattori) con il servizio cloud. In tal caso, però, sarà necessario usare l'accesso Single Sign-On. L'utilizzo dell'autenticazione avanzata è soggetto a restrizioni. Se si prevede di usare AD FS per il servizio token di sicurezza, vedere Configuring Advanced Options for AD FS 2.0 (Configurazione delle opzioni avanzate per AD FS 2.0) per altre informazioni.

Effetti di questo scenario sull'esperienza di accesso dell'utente basata sul cloud

L'esperienza di un utente con Single Sign-On varia in base alla modalità di connessione del relativo computer alla rete della società, al sistema operativo in esecuzione nel computer dell'utente e al modo in cui l'amministratore ha configurato l'infrastruttura del servizio token di sicurezza per interagire con Azure AD.

Di seguito viene descritta l'esperienza dell'utente con l'accesso Single Sign-On eseguito all'interno della rete aziendale:

• Computer aziendale in una rete aziendale: quando gli utenti sono al lavoro e hanno eseguito l'accesso alla rete aziendale, l'accesso Single Sign-On consente loro di accedere al servizio cloud senza eseguire di nuovo l'accesso.

Se l'utente si connette dall'esterno della rete della società o accede ai servizi da dispositivi o applicazioni particolari, come nelle seguenti situazioni, è necessario distribuire un proxy servizio token di sicurezza. Se si prevede di usare AD FS per il servizio token di sicurezza, vedere Elenco di controllo: Usare AD FS per implementare e gestire l'accesso Single Sign-On per altre informazioni su come configurare un proxy AD FS.

• Computer di lavoro, roaming: Gli utenti connessi a computer aggiunti a un dominio con le proprie credenziali aziendali, ma che non sono connessi alla rete aziendale (ad esempio, un computer aziendale a casa o in un hotel), possono accedere al servizio cloud.

• Home o computer pubblico: Quando l'utente usa un computer che non è aggiunto al dominio aziendale, l'utente deve accedere con le proprie credenziali aziendali per accedere al servizio cloud.

• Smart phone: In uno smartphone, per accedere al servizio cloud, ad esempio Microsoft Exchange Online usando Microsoft Exchange ActiveSync, l'utente deve accedere con le proprie credenziali aziendali.

• Microsoft Outlook o altri client di posta elettronica: l'utente deve accedere con le proprie credenziali aziendali per accedere alla posta elettronica se utilizza Outlook o un client di posta elettronica che non fa parte di Office, ad esempio un client IMAP o POP.

  Se si utilizza Shibboleth come servizio token di sicurezza, assicurarsi di installare l'estensione ECP del provider di identità Shibboleth per garantire il funzionamento di Single Sign-On con smartphone, Microsoft Outlook o altri client. Per altre informazioni, vedere Configurare Shibboleth per l'uso con Single Sign-On.

Si è pronti per implementare questo scenario per l'organizzazione?

In questo caso, è consigliabile iniziare seguendo la procedura descritta in Roadmap per l'accesso Single Sign-On.

Vedere anche

Concetti

Integrazione della directory
Determinare lo scenario di integrazione della directory da usare