Microsoft Office 365 provides secure anywhere access to professional email, shared calendars, instant messaging (IM), video conferencing, and document collaboration.
It represents the cloud version of the Microsoft communication and collaboration products with the latest version of the Microsoft desktop suite for businesses of all sizes. Office 365 indeed notably includes:
The programs of the Office suite can be deployed easily in a click-to-run mode on a Windows computer, either directly from the Office 365 portal or from the local network with your own management tool.
Note For more information, see the Microsoft TechNet article Getting started guide for deploying Office 365 ProPlus.
Note For additional information on Office 365 in addition to the content of this paper, please refer to the Office 365 Community web site (blogs, forums, wikis, etc.).
With the exception of Internet sites for anonymous access created with SharePoint Online, users must be authenticated when accessing above services in Office 365.
Azure Active Directory (Azure AD) is the directory behind Office 365 used to store user identities and other tenant properties by Office 365. Just like the on-premises Active Directory stores the information for Exchange, SharePoint, Skype for Business and your custom LOB Apps, Azure AD stores the information for Exchange Online, SharePoint Online, Skype for Business Online and any custom applications build in the Microsoft's cloud.
Through the availability of multiple seamless sign-in options that come with the supported identity models, Azure AD provides organizations with an open choice and eventually the ability to authenticate in accordance their own requirements, allowing their users - regardless of the subsequent implementation choice driven by the chosen identity model - to benefit from a seamless sign-experience to access Azure AD/Office 365 and the services that they have been provisioned for.
Thus, users that are on the internal corporate network or connected through a VPN will have seamless access to Azure AD/Office 365. If users are accessing Azure AD/Office 365 from home or from any computer not connected to the corporate network, they will also still have access to Azure AD/Office 365 using their corporate credentials. Such a user sign-in experience is awaited by many organizations:
Note Not all type of mobile devices are using EAS, some are using Exchange Web Services (EWS) instead. For more information, see the web site Office for Mobile Devices.
Built on existing Microsoft documentation and knowledge base articles, this paper further presents the supported identity models of Azure AD/Office 365 along with the associated seamless sign-in deployment options.
For that purpose, this document:
, so that Azure AD/Office 365 projects can be more easily completed, and consequently enabling customers to realize the full potential of the Microsoft offerings in the cloud.
This document provides neither guidance for setting up and configuring the discussed seamless sign-in deployment options in a production environment – beyond highlighting key scenarios - nor a complete technical reference for Azure AD Connect, AD FS, or any other technology, product or service being mentioned as part of this document.
Finally, this document doesn't provide a complete end-to-end walkthrough to rollout a working Azure AD/Office 365 configuration to test and evaluate the seamless sign-in deployment options. This is the purpose of the remaining Part 2, Part 4, Part 4bis, Part 5, Part 6, and Part 7 of this whitepaper.
To cover the aforementioned objectives, this document adopts an organization according to the following themes, each of them being addressed in the following sections:
This document is thus intended for system architects and IT professionals who are interested in understanding this seamless sign-in capabilities of Azure AD/Office 365.
With the exception of Internet sites for anonymous access created with SharePoint Online, users must be authenticated when accessing services in Office 365.
For that purpose, Azure AD/Office 365 basically offer two types of identities:
Note With the optional directory synchronization, the user IDs mastered on-premises can be synchronized to the service/cloud in the form of cloud identities.
Considering the above, users can gain access to Azure AD/Office 365 by authenticating to their Azure AD/Office 365 user accounts, either through a prompt to provide valid credentials or through a single sign-on process. Once authenticated, users' identities refer to the user names associated with the Azure AD/Office 365 accounts. Considering the above, we have three main identity models available plus their variants in terms of seamless sign-in options that may be offered:
The above identity models unsurprisingly affect the user experience, the administrative requirements, the deployment considerations, and the capabilities using Office 365: one should note that each identity model layers on the previous one (except the first one) and that the last two models result in hybrid identities.
Thus, one of the very first question that arises is to how to smoothly integrate/bridge the organization's existing on-premises identity infrastructure with Azure AD/Office 365 optimally at no additional administration cost and with a user experience as seamless as possible.
In order to make the best choice regarding your own environment, objectives, needs and constraints, you should have a basic understanding of the underlying mechanisms, their requirements along with the user and administrative related sign-in and management experiences.
Regarding the above identity model breakdown, the notion of an "identity bridge" between the on-premises environment and Azure AD/Office 365 can be split down in two parts:
Azure AD/Office 365 comes with the Azure Active Directory Connect (Azure AD Connect) tool, a single and unified wizard that streamlines and automates the overall onboarding process for directory synchronization with the on-premises directories.
This single sign-on option requires to set up a standard-based identity federation trust relationship between the on-premises environment (typically with AD FS) and Azure AD/Office 365. The (perceived) complexity of identity federation as well as the additional cost implied by the related infrastructure on-premises, has refrained some organizations to implement the single sign-on feature of Azure AD/Office 365.
Consequently, the Azure AD Connect capabilities offer in turn alternative solutions a seamless sign-in experience without necessarily relying on identity federation: The password (hash of) hash synchronization (PHS) and the pass-through authentication (PTA) feature indeed offer relevant alternatives in many situations
The objective of the next sections consequently aims at discussing all the supported identity models and highlighting the sign-on options available, the technical considerations that pertains to them in order to give you all the key points for a decision, which is not always straightforward since some capabilities also depends on the Azure AD edition, for instance the password write-back in the Premium P1 and P2 editions.
Note For a description of the available editions of Azure AD, see article Azure Active Directory editions. For more information on usage model, see article Azure Active Directory Pricing. For information on the usage constraints and other service limits for the Azure AD service per edition, see article Azure subscription and service limits, quotas, and constraints.
In order to allow you to choose the best model for your organization, the three different identity models are considered along with their variants if any in ascending order from a complexity prospective – and from set of capabilities prospective: the simplest approach that fulfills your objectives, needs and constraints is always the best.
At the end of the section, you should be in a position to relevantly assess the best identity model that applies to your own specific situation.
Note There is from now on a much richer bibliography on the subject coming directly from the Microsoft product groups that is available on Microsoft team blogs, MSDN or Microsoft TechNet. Relevant references are indicated throughout the reading.
The first model is indubitably the simplest one: the user's identity (account) is created in Azure AD with an associated password. As the model's name indicates and as already stated above, the identity only resides in the cloud.
Users sign in with their cloud identity. Cloud identities are authenticated using traditional challenge/response, where users type in their username - for example johndoe@litware369.com for the Litware369 (fictitious) company's Azure AD domain used later throughout this whitepaper for illustration purposes - and the related password. Authentication happens in the cloud and these credentials can be validated by Azure AD. Users are always prompted for credentials.
The cloud identity has no direct correlation with another identity repository. As mentioned above, users have two IDs:
If users belong to an organization using Active Directory on-premises, the on-premises username can be the same (johndoe@litware369.com) even if it qualifies in this case the on-premises identity. Remember that the two identity repositories are distinct. Consequently, users are prompted for credentials even when already logged into their AD domain when accessing Azure AD/Office 365. (These credentials can be cached locally to help reduce subsequent prompts.)
Figure 1 Cloud Identity model
The main benefit of this model is that, as soon as the users' cloud identity is created in Azure AD/Office 365, users can access to all services that have been assigned to them: there is no deployment or integration footprint with an existing on-premises infrastructure to deal with.
In addition, enhanced security features such as multi-factor authentication are natively offered by the cloud platform and thus immediately available.
However, the direct drawback is that the cloud identities have to be separately created and managed. While, for a small number of accounts, cloud identities can be manually managed from the Office 365 portal or the Azure management portal, there is a need to rely on some automation process like, for example, PowerShell scripts for a larger population.
Furthermore, IT professionals will have to manage the password policy both in cloud and on-premises. The cloud identities password policy is stored in the cloud in Azure AD. Password reset has to be managed for on-premises and cloud IDs and hence the users have to change the password as per the policy for both.
So, in this model, users cannot benefit from a seamless sign-in experience with corporate logon or on-premises applications as no password synchronization is in place. The user is responsible for managing the passwords in both directories.
Furthermore, users will probably have more difficulties to deal with another password potentially implying additional and costly help desk operations (except if you additionally subscribed to the Azure AD Basic and Premium editions that both allow self-service password reset and make you users aware of this capability).
Nevertheless, this cloud identity model could represent a suitable choice if you want to benefit very quickly from Azure AD/Office 365 and provided that:
-or-
One of the interest of this very simple model resides in the fact that it enables you to later transition to a more integrated identity model without losing the investment in the cloud identities already created.
This second model allows to keep the on-premises directory in sync with Azure AD/Office 365. It thus provides a real integration with the on-premises directory by synchronizing identities and groups to the Azure AD.
Azure AD Connect is now the one stop shop for connecting your on-premises directories to Azure AD, whether you are evaluating, piloting, or in production.
Note For more information, see article Integrating your on-premises identities with Azure Active Directory.
Azure AD Connect is the best way to connect your on-premises directory with Azure AD and Office 365. Azure AD Connect is replacing DirSync and Azure AD Sync and these two older sync engines are deprecated from April 13, 2016 reaching end of support April 13,2017.
Note For more information, see article Upgrade Windows Azure Active Directory Sync ("DirSync") and Azure Active Directory Sync ("Azure AD Sync").
Important note Customers using DirSync or Azure AD Sync will continue to synchronize after April 13, 2017 but they not be able to receive support for their synchronization tool. They must upgrade to the latest version of Azure AD Connect in order to receive support.
Important note Customers running Azure AD Connect 1.0.x.0 also received the message to upgrade to the latest version of Azure AD Connect in order to receive support. Microsoft recommends customers to stay current with Azure AD Connect releases. For a full list of fixes and improvements over the time of Azure AD Connect, see article Azure AD Connect: Version Release History.
Note Azure AD Connect can be deployed either on-premises or in Microsoft Azure to benefit from a better site availability without any footprint on on-premises hardware.
Figure 2 Synchronized Identity model
One of the benefits is that it enables controlling and managing the corporate user accounts in the traditional way through the Active Directory Users and Computers snap-in. Typical administration tasks involving user accounts, contacts, and groups provisioning, de-provisioning, group membership modifications, account deactivation are performed on the on-premises Active Directory and seamlessly replicated to Azure AD within a 30 minutes' delay.
Note For more information, see blog post Azure AD Connect 1.1 is now GA – Faster sync times, automatic upgrades and more!.
There is no manual configuration that you need to be concerned with, everything can be configured via a wizard. This one piece really does provide seamless user management between the on-premises and Azure AD/Office 365 environments.
The synchronization engine of Azure AD Connect not only provides today a simplified guided configuration experience. It also synchronization of multiple on-premises AD forests. Beyond these key characteristics, Azure AD Connect offer a rich set of sync capabilities such as:
and, with the Azure AD Premium P1 or P2 editions, also a rich set of write-back capabilities with the ability to enable:
Note For more information, see whitepaper Azure AD & Windows 10: better Together for Work and School.
Moreover, Azure AD Connect also offer the option to synchronize user passwords from an on-premises Active Directory to a cloud-based Azure AD/Office 365 tenant, which leads us with the next variant: The Password Hash Synchronization (PHS).
Note Additional capabilities are going to be available such as the support for a mixture of directories (Active Directory, LDAP directory, SQL database, and others), the ability to remap and transform existing on-premises attributes, or the support for write-back scenarios like self-service group management (Azure AD Premium (P1 and P2) editions only).
Password Hash Synchronization (PHS) is a feature of Azure AD Connect to retrieve the user account password hashes from an on-premises Active Directory and replicate a digest of this hash to a cloud-based Azure AD/Office 365 tenant.
Figure 3 Synchronized Identity model with the PHS feature
Note From a security standpoint, the password information that is replicated in Azure AD is the result of a one-way function (SHA-256) applied to the user's password hash stored in an encrypted form, which means that, even if this secret leaks, it cannot be used to access to any resource on your corporate internal network. For a detailed description of the password synchronization mechanism, see blog post AAD Password Sync, Encryption and FIPS compliance.
This feature enables end-users to sign into Azure AD services, such as Office 365, Dynamics 365, Intune, and Azure AD Domain Services, using the same password they're using to sign in to their organization's on-premises Active Directory.
Note For more information, see article Implementing password synchronization with Azure AD Connect sync.
Such a feature provides a "same sign-on" experience, where users sign in to their corporate machine and Azure AD/Office 365 with the same credentials. To provide a better experience, a password change is replicated within 2 minutes. Moreover, after a successful authentication, the users can be optionally asked for a multifactor authentication (MFA) in the cloud.
With the PHS feature, this synchronized identity model provides seamless sign-in user experience while requiring a minimal investment from an administrative perspective. With such a tradeoff, it constitutes the preferred option for most organizations with possibly the pass-through authentication (PTA) feature covered hereafter.
Moreover, in addition to the PHS feature, the seamless single sign-on (SSO) feature currently in public preview as the time of this writing allows end-users to only need to type their username and not their password to sign in to Azure AD/Office 365 or other cloud apps and services when they are on their corporate machines and connected on the organization's corporate network.
The seamless SSO feature leverages the Windows Integrated Authentication (WIA) capabilities and the Kerberos protocol.
Note For more information, see article What is Single Sign On (SSO) (preview).
A second variant of the synchronized identity model is offered via the Azure AD pass-through authentication (PTA) if you're reluctant to sync the (hash of) hash of the passwords with your Azure AD/Office 365 tenant.
So, the PTA feature currently in public preview as the time of this writing provides a simple solution for having password validation for Azure AD/Office 365 performed against the organization's identity infrastructure, without the need for complex network infrastructure or for the on-premises passwords to exist in the cloud in any form (hash of hash). Such a feature provides another "same sign-on" experience.
Note For more information, see blog post Introducing #AzureAD Pass-Through Authentication and Seamless Single Sign-on and article What is Azure AD Pass-through Authentication.
Important note The PTA feature does NOT support organizations using Alternate Login IDs. For more information on Alternate Login IDs, see article Configuring Alternate Login ID.
The PTA feature that can be configured via Azure AD Connect leverages for that purpose a simple on-premises agent that listens for password validation requests. Once a request comes in, the agent retrieves the username and password and validates the credential against the on-premises Active Directory infrastructure. The validation occurs over standard Windows APIs. An on-premises domain controller then evaluates the request and returns a response to the agent, which in turn returns this to Azure AD. Azure AD then evaluates the response and responds to the user as appropriate, for example by issuing a security token for the intended service or asking for a multifactor authentication (MFA) in the cloud.
Figure 4 Synchronized Identity model with the PTA feature
Furthermore, with this approach, IT professionals will have to manage the password policy only on-premises. The organization's identity infrastructure stores and controls the password policy. Password reset occurs for on-premises IDs only.
From a technical implementation perspective, the above agent corresponds to the lightweight connector initially introduced by the Azure AD Application Proxy capability of Azure AD Premium P1.
This connector can be easily deployed to multiple machines to provide high availability and load balancing. Since all communications are outbound only, there is no requirement for a DMZ or for the connector to be installed in a DMZ.
Moreover, in addition to the PTA feature, and in the same way it is available for the PHS feature, you can optionally set up with Azure AD Connect the seamless SSO.
Finally, the federated identity model is built on top of the synchronized identity model and adds the identity federation dimension. As already noticed, this model indeed requires to setup a standard-based federation trust relationship and thus to deploy AD FS or a supported third party identity provider solution (see later in this document).
Directory synchronization is a requirement for this model in order to keep the on-premises identity infrastructure in sync with the Azure AD/Office 365 tenant.
Figure 5 Federated Identity model
Users sign in with corporate ID for access to online and corporate services. Unlike the previous identity model, authentication always occurs on-premises against the organization's identity infrastructure and users get true single sign-on (SSO). For example, in the context of this paper, AD FS queries Active Directory for authenticating users and then delivers a (signed) security token as a proof of a successful authentication to allow access to the Azure AD/Office 365 tenant.
In comparison, with the PHS feature and the so-called "same sign-on" experience with the previous synchronized identity model, users will have to re-enter at least once the same on-premises credentials when accessing Azure AD/Office 365.
Support for on-premises multi-factor authentication (MFA) can be provided if such a solution is deployed on-premises. In comparison, with both the PHS and the PTA features, only a support for multi-factor authentication (MFA) in the cloud can be provided.
Furthermore, and like with the PTA feature, IT professionals will have to manage the password policy only on-premises and hence will not need to separately worry about password reset for federated identities. The organization's identity infrastructure stores and controls the password policy. Password reset occurs for on-premises IDs only.
Nevertheless, implementing this model requires to both deploy, operate, and maintain a highly available fault-tolerant federation infrastructure to deliver the federation service. This service is indeed critical as every access to Azure AD/Office 365 is based on security tokens that need to be issued by an AD FS – or a supported third-party identity provider - infrastructure after a successful authentication. In case the Security Token Service (STS) becomes unavailable, the possibility to fallback to password sync is offered by Azure AD.
Since the synchronized identity (with the PHS or the PTA features plus the seamless SSO feature) and the federated identity models appear to be very close in terms of both capabilities and end-user experience, and the former is easier to deploy without the requirement for a highly available fault-tolerant federation infrastructure, what could be the reasons if any to finally opt for the federated identity model in lieu of synchronized identity model?
Reasons for choosing this model generally correspond to a series of (more) advanced scenarios and relate to the following three distinct areas that are detailed in the next sections:
Note To give credit where credit is due, this analysis takes its inspiration from the blog post Choosing a sign-in model for Office 365, written by Paul Andrew, product manager on the Office 365 team.
The core recommendation is straightforward and pure common sense: choose the synchronized identity model with the PHS or the PTA features unless you have to deal with one or more of the following scenarios.
If your organization has already an identity federation infrastructure in place that is used to provide single sign-on for internal, partner applications, cloud-hosted SaaS, etc., the third model obviously enables to further extend this infrastructure for accessing Azure AD/Office 365 thanks to the single sign-on feature:
Note As previously mentioned, Azure AD Connect provides a single and unified wizard that streamlines the overall onboarding process for directory synchronization and single sign-on, and that automatically performs the following steps: download and setup of all the pre-requisites, download, setup and guided configuration of the synchronization, activation of the sync in the Azure AD tenant, setup, and/or configuration of AD FS, etc. (See section § Simplifying the onboarding process later in this document).
Note The Azure Active Directory Connect Health (Azure AD Connect Health) cloud based service in the Azure portal helps you monitor and gain insight into health, performance and login activity of your on-premises identity infrastructure. As such, it offers you the ability to view alerts, performance, usage patterns, configuration settings, enables you to maintain a reliable connection to Azure AD and much more.
The currently available release in GA not only focusses on AD FS (i.e. Azure AD Connect Health for AD FS) but also on sync to allow you to monitor and gain insights into the sync service of Azure AD Connect (i.e. Azure AD Connect Health for sync). In addition, the monitoring of the AD DS infrastructure is now available in public preview (i.e. Azure AD Connect Health for AD DS).
Azure AD Connect Health is a feature of the Azure AD Premium P1 and P2 editions and represents a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure. For more information, see article Monitor your on-premises identity infrastructure and synchronization services in the cloud.
Important note Directory synchronization feature that can be part of the third party solution is not tested as part of the program.
Note The whitepaper Azure AD/Office 365 Single Sign-on with Shibboleth 2 illustrates the configuration of the single sign-on feature with Shibboleth 2 and the SAML 2.0 protocol.
Note For more information, see article Windows Azure Active Directory Connector for FIM 2010 R2 Quick Start Guide.
However, Microsoft recommends that you do NOT implement a new deployment using this connector. This solution is superseded by Azure AD Connect.
Note Among the missing capabilities, this connector does not provide password hash sync support. So a federation infrastructure or the PTA feature will still be required for a seamless sign-in experience. And to enable the latter, you will need Azure AD Connect to loop the loop...
Following are some illustrations of the policy requirements that could make a good case for the federated identity model:
Note The password hash stored in the on-premises Active Directory database is not replicated as it is in Azure AD. The synchronization engine rather re-hashes it to a SHA256 hash before transmitting it securely to Azure AD where in turn it is encrypted before being stored in the cloud database. As a result, even if the SHA256 hash of the initial hash is stolen, it could not be used as an attempt to connect to the on-premises network. For detailed information about password hash replication and protection, see blog post AAD Password Sync, Encryption and FIPS compliance.
Note For more information, see article Configuring Client Access Policies.
AD FS in Windows Server 2012 R2 (and in Windows Server 2016) further enhances this access control mechanism based on multiple factors, including user, network location, device (AD Workplace Join), and authentication data. This is made possible by a greater variety of claim types available for the issuance authorization claim rules. Thus AD FS allows to enforce conditional access control based on user identity or group membership, network location, device (whether it is workplace joined), and the authentication state (whether multifactor authentication was performed), etc.
Note The AD Workplace Join capability allows users to join their devices with the organization's workplace to access company resources and services. When a device is joined by Workplace Join, it becomes a known device and attributes of the device can be retrieved from AD to drive conditional access for the purpose of authorizing issuance of security tokens for applications. Windows 8.1, Windows RT 8.1, Android (Samsung), and iOS 6+ devices can be joined by using Workplace Join.
Workplace Join is made possible by Device Registration Service (DRS) that is included with AD FS. When a device is joined by Workplace Join, DRS provisions a device object in AD and sets a certificate on the consumer device that is used to represent the device identity. DRS is meant to face both internal and external resources. Organizations that deploy both DRS along with WAP can join devices that use Workplace Join from any Internet-connected location.
For more information, see article Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.
Note The Azure Device Registration Service (Azure DRS) enables Workplace Join and register devices in Azure AD in lieu of on-premises with DRS. The registered devices can then be used in the conditional access policies that are available in AD FS similarly to what can be achieved through the deployment of DRS. For more information, see article Setting up on-premises conditional access using Azure Active Directory Device Registration.
Note For additional information on conditional access control, see article Manage Risk with Conditional Access Control.
Note For more information, see article Azure Active Directory Identity Protection.
Note Things are unfortunately not so simple in the federated identity model in so far as, for example with AD FS, IT professionals must take into account i) a potential replication delay between the Active Directory domain controllers, i.e. the DC where the administrative action is performed and the DC that is query by the AD FS STS, and ii) the lifetime of security tokens. Conversely, the PHS feature offers the ability to prohibit for a user the access to Azure AD/Office 365 almost immediately by resetting their password on-premises as password reset is synchronized to Azure AD within 2 minutes.
However, the PTA feature in the synchronized identity model offers the same reliance on Active Directory for the same benefit and even more without the lifetime of security tokens.
Following are some illustrations of the technical requirements that also make a good case for the federated identity model:
Note As an alternate option, customization capabilities are available in the Azure AD Basic and Premium P1 and P2 editions that allow to adapt the sign-in page to fit your company branding, with your own logo, illustration and sign-in text. In addition, these two editions also offer a user password reset portal that allows users who have already registered their mobile phone numbers and alternate email addresses, to reset their password by themselves. Moreover, the password write back capability included with Azure AD Connect – that requires the Premium P1 or P2 editions of Azure AD – allows to synchronize passwords back to the on-premises Active Directory giving users the capability to manage their passwords from the cloud.
For more information, see articles Add company branding to your sign-in and Access Panel pages and Customizing Password Management to fit your organization's needs.
Following Table 2 aims at suggesting a decision matrix to synthetize the above considerations regarding the discussed identity models.
Table 2 Decision matrix
Synchronized identity model | Federated identity model | ||
I need to… | PHS | PTA | |
Sync new user, contact, and group accounts created in my on-premises AD to the cloud in a single-forest scenario | ü | ü | ü |
Sync new user, contact, and group accounts created in my on-premises AD to the cloud in a multi-forest scenario | ü | ü | ü |
Enable users to sign in with the same identity and password | ü | ü | ü |
Immediately disable user accounts | ü* | ü | ü |
Enable cloud-based multi-factor authentication solutions | ü | ü | ü |
Enable self-service password reset with AD write-back option | ü | ü | ü |
Customize the user sign-in page to Azure AD/Office 365 | ü | ü | ü |
Enable users to sign in once using corporate credentials without password caching | ü** | ü** | ü |
Enable use of on-premises third-party multi-factor authentication solutions | ü | ||
Do not replicate password hashes to the cloud | ü | ü | |
Restrict access based on location or group membership | ü*** | ü*** | ü |
Allow authentication with non-MS identity providers | ü | ||
Enable SSO for SaaS applications, hybrid applications, etc. | ü** | ü | |
Audit users sign-in to Azure AD/Office 365 | ü**** | ü**** | ü |
* Using user password reset
** With seamless SSO and on the corporate network
*** Using Azure AD conditional access. Requires a Premium P1 or P2 editions of Azure AD
**** Using Azure AD Identity Protection. Requires a Premium P2 edition of Azure AD
The above identity models are configured with the Azure AD Connect tool.
Once configured, you can also change the sign-in option with Azure AD Connect by launching the wizard again and selecting Configure, and then Change user sign-in.
As part of the same series of documents on Azure AD/Office 365 seamless sign-in, the second part Build a base configuration for an evaluation environment deals with an end-to-end walkthrough to rollout a working base configuration in an Azure-based test lab environment. As such, it describes as its name suggests the essential steps required to configure a base configuration to test the various above discussed identity models. By:
you will have a common starting point to test and evaluate the identity models, and leverage for that purpose the same baseline for a typical on-premises environment. Windows Server 2012 R2 and Windows Server 2016 are both featured so that you can pick up the version that best corresponds to your environment and/or fulfils your requirements.
Through its support for standard protocols, Active Directory Federation Services (AD FS) provides claims-based (Web) single sign-on (a.k.a. identity federation) with Azure AD, and related online services such as the Microsoft Office 365 offering and its Web application and rich client applications.
The third part Understand single sign-on (SSO) with AD FS in Windows Server 2012 R2 is intended as an overview document for further understanding the federated identity model with AD FS, how to enable single sign-on using corporate Active Directory credentials and AD FS to Azure AD/Office 365, and the different configuration elements to be aware of for such deployment.
The fourth part Implement single sign-on (SSO) with AD FS in Windows Server 2012 R2 further illustrates how to deploy it onto the above base configuration with Azure AD Connect.
It provides a complete end-to-end walkthrough to rollout a fully operational configuration in Azure with AD FS in Windows Server 2012 R2, and leverages, for that purpose, the base configuration depicted and established in the second part for a test lab environment.
The fifth part Implement single sign-on (SSO) with AD FS in Windows Server 2016 covers the same considerations with Windows Server 2016.
The sixth part Understand and implement PHS and seamless SSO covers discusses the Password hash synchronization (PHS) model. It illustrates how to enable PHS and seamless SSO using corporate Active Directory credentials to access Azure AD/Office 365, and the different configuration elements to be aware of for such deployment. This document also provides a complete end-to-end walkthrough to rollout a fully operational configuration in Azure. It also leverages for that purpose the above base configuration.
Finally, the seventh and final part Understand and implement PTA and seamless SSO discusses the PTA model.