Del via

DirSync with Single Sign-On

  • Artikkel

Updated: June 25, 2015

Applies To: Azure, Office 365, Power BI, Windows Intune

Single sign-on, also called identity federation, is a hybrid-based directory integration scenario of Azure Active Directory that you can implement when you want to simplify your user’s ability to seamlessly access cloud services, such as Office 365 or Microsoft Intune, with their existing Active Directory corporate credentials. Without single sign-on, your users would need to maintain separate user names and passwords for your online and on-premises accounts.

An STS enables identity federation, extending the notion of centralized authentication, authorization, and SSO to Web applications and services located virtually anywhere, including perimeter networks, partner networks, and the cloud. When you configure an STS to provide single sign-on access with a Microsoft cloud service, you will be creating a federated trust between your on-premises STS and the federated domain you’ve specified in your Azure AD tenant.

Azure AD supports single sign-on scenarios that use either of the following security token services:

  • Active Directory Federation Services (AD FS)

  • Shibboleth Identity Provider

  • Third-party identity providers

The following diagram illustrates how your on-premises Active Directory and your STS server farm interact with the Azure AD authentication system to provide access to one or more cloud services. When you set up single sign-on, you establish a federated trust between your STS and the Azure AD authentication system. Local Active Directory users obtain authentication tokens from your on-premises STS that redirect the users’ requests through the federated trust. This allows your users to seamlessly access the cloud services you’ve subscribed to without needing to sign in with different credentials.

Directory sync with single sign-on scenario

Benefits of implementing this scenario

There is a clear benefit to users when you implement single sign-on: it lets them use their corporate credentials to access the cloud service that your company has subscribed to. Users don’t have to sign in again and remember multiple passwords.

In addition to the user benefits, there are many benefits to administrators:

  • Policy control: The administrator can control account policies through Active Directory, which gives the administrator the ability to manage password policies, workstation restrictions, lock-out controls, and more, without having to perform additional tasks in the cloud.

  • Access control: The administrator can restrict access to the cloud service so that the services can be accessed through the corporate environment, through online servers, or both.

  • Reduced support calls: Forgotten passwords are a common source of support calls in all companies. If users have fewer passwords to remember, they are less likely to forget them.

  • Security: User identities and information are protected because all of the servers and services used in single sign-on are mastered and controlled on-premises.

  • Support for strong authentication: You can use strong authentication (also called two-factor authentication) with the cloud service. However, if you use strong authentication, you must use single sign-on. There are restrictions on the use of strong authentication. If you plan to use AD FS for your STS, see Configuring Advanced Options for AD FS 2.0 for more information.

How this scenario impacts your user’s cloud-based sign-on experience

A user’s experience with single sign-on varies based on how the user’s computer is connected to your company’s network, what operating system the user’s computer is running, and how the administrator has configured their STS infrastructure to interact with Azure AD.

The following describes user experiences with single sign-on from within the network:

  • Work computer on a corporate network: When users are at work and signed in to the corporate network, single sign-on enables them to access the cloud service without signing in again.

If the user is connecting from outside your company’s network or accessing services from particular devices or applications, such as in the following situations, you must deploy an STS proxy. If you plan to use AD FS for your STS, see Checklist: Use AD FS to implement and manage single sign-on for more information about how to set up an AD FS proxy.

  • Work computer, roaming: Users who are logged on to domain-joined computers with their corporate credentials, but who are not connected to the corporate network (for example, a work computer at home or at a hotel), can access the cloud service.

  • Home or public computer: When the user is using a computer that is not joined to the corporate domain, the user must sign in with their corporate credentials to access the cloud service.

  • Smart phone: On a smart phone, to access the cloud service such as Microsoft Exchange Online using Microsoft Exchange ActiveSync, the user must sign in with their corporate credentials.

  • Microsoft Outlook or other email clients: The user must sign in with their corporate credentials to access their email if they are using Outlook or an email client that is not part of Office; for example, an IMAP or POP client.

    If you are using Shibboleth as your STS, make sure to install the Shibboleth Identity Provider ECP extension in order for single sign-on to work with a smart phone, Microsoft Outlook or other clients. For more information, see Configure Shibboleth for use with single sign-on.

Ready to implement this scenario for your organization?

If so, we recommend that you start by following the steps provided in Single sign-on roadmap.

See Also

Concepts

Directory integration
Determine which directory integration scenario to use