Microsoft Office 365 provides secure anywhere access to professional email, shared calendars, instant messaging (IM), video conferencing, document collaboration, etc. 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.
Azure Active Directory (Azure AD) is the directory behind Office 365 used to store user identities and other tenant properties. Just like the on-premises Active Directory stores the information for Exchange, SharePoint, Lync and your custom Line of Business (LOB) apps, Azure AD stores the information for Exchange Online, SharePoint Online, Skype for Business Online, etc., and any custom applications built in the Microsoft's cloud.
Through the pass-through authentication (PTA) feature, Azure AD provides organizations with the ability to directly authenticate against the organization's Active Directory, allowing their users to use their corporate credentials to access Azure AD/Office 365 and the services that they have been provisioned for, and without the need for complex network infrastructure such as the one required by AD FS (see Part 3, Part 4(bis), and Part 5) or for the on-premises passwords to exist in the cloud in any form (see Part 6 of this whitepaper for the password hash synchronization (PHS) feature).
Important note PTA does NOT support organizations using Alternate Login IDs. For more information on Alternate Login IDs, see article Configuring Alternate Login ID.
In addition, the seamless single sign-on (SSO) feature 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.
Note For more information, see blog post Introducing #AzureAD Pass-Through Authentication and Seamless Single Sign-on.
This document complements Part 1 and Part 2 of this whitepaper by providing an end-to-end walkthrough to rollout a working PTA and seamless SSO configuration for Azure AD/Office 365.
It doesn't provide an understanding of the different seamless sign-in deployment options with Azure AD/Office 365. This is specifically the intent of the aforementioned first part that covers all the key aspects the readers should understand to successfully achieve seamless sign-in with Azure AD/Office 365 for their organization.
To cover the aforementioned objectives, this document is organized in the following 4 sections:
These sections provide the information details necessary to (hopefully) successfully build a working environment for the scenario. They must be followed in order.
This document is thus intended for system architects and IT professionals who are interested in understanding the PTA and seamless SSO features of Azure AD/Office 365 from a hand-practice perspective.
By following the instructions outlined hereafter, you should be able to successfully prepare your on-premises test lab environment based on virtual machines (VMs) running in Azure to later deploy and configure the test environment, install and configure it.
In order to complete the document's walkthrough, you need an environment that consists of the following components for the Azure-based test lab infrastructure:
If you've already followed the walkthrough of Part 2, the DC1 and DC2 computers that pertain to the Azure-based test lab infrastructure should already be in place. If you haven't yet conducted this rollout, this is the time to do so.
The rest of this document makes the assumption that such an evaluation environment is in place. You don't need the ADFS1, ADFS2, WAP1, and WAP2 computers that are part of this lab environment. You can leave them turned off for the rest of this document.
The above Azure VMs will enable you to:
Note You must be logged on as a member of the Domain Admins group or a member of the Administrators group on each computer to complete the tasks described in this guide. If you cannot complete a task while you are logged on with an account that is a member of the Administrators group, try performing the task while you are logged on with an account that is a member of the Domain Admins group.
For illustration purposes, we've opted to configure the domain litware369.com (LITWARE369). You will have to choose in lieu of a domain name of yours. For checking purpose, you can for instance use the domain search capability provided by several popular domain name registrars.
Whenever a reference to litware369.com
is made in a procedure, it has to be replaced by the DNS domain name of your choice to reflect accordingly the change in naming. Likewise, any reference to LITWARE369 should be substituted by the NETBIOS domain name of your choice.
For the sake of simplicity, the same password "Pass@word1!?" is used throughout the procedures detailed in this document. This is neither mandatory nor recommended in a real-world scenario.
To perform all the tasks in this guide, we will use the local administrator account AzureAdmin or alternatively the LITWARE369 domain administrator account AzureAdmin for each VM, unless instructed otherwise.
See eponym section in Part 6 of this whitepaper.
See eponym section in Part 6 of this whitepaper.
See eponym section in Part 2 of this whitepaper.
This section provides a walkthrough on how to setup pass-through authentication (PTA) and seamless single sign-on (SSO) between the on-premises Active Directory (e.g. litware369.com) and the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com) to offer a seamless user experience to access cloud resources, for example an Office 365 Enterprise E3 subscription in our configuration.
For the sake of simplicity, and to set up the directory synchronization and the password hash synchronization between the on-premises infrastructure of our test lab environment in Azure and the litware369.onmicrosoft.com tenant in the cloud, we will leverage the single and unified wizard Azure Active Directory Connect (Azure AD Connect).
Azure AD Connect indeed provides a single and unified wizard that streamlines the overall onboarding process for both directory synchronization (single or multiple directories) AND single sign-on if you want to, and thus that automatically performs the following steps: download and setup of all the pre-requisites, download, setup and guided configuration of the synchronization engine, activation of the synchronization in the Azure AD tenant, setup, and/or configuration of AD FS, etc.
Azure AD Connect is 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 articles Integrating your on-premises identities with Azure Active Directory.
In the context of this part, Azure AD Connect is the delivery mechanism to install Azure AD Application Proxy which PTA uses. The Azure AD Application Proxy connector will be installed on the Azure AD Connect computer and will be registered to handle pass-through authentication traffic.
Important Note The Azure AD Application Proxy installed with Azure AD Connect will only work with Azure AD Connect, Azure AD Application Proxy connectors should be hosted on other servers.
This section walks you through the use of the single wizard Azure AD Connect on the DC1 computer to fully configure the Azure-based infrastructure from an identity perspective and establish the identity bridge between it and your Azure AD/Office 365 subscription.
It comprises the following eight steps:
The following subsections describe each of these steps in the context of our test lab environment.
Azure AD Connect is a single wizard that performs all the steps you would otherwise have to do manually to connect your Active Directory (and local directories if any) to Azure AD. Azure AD Connect will:
Note The Azure Active Directory PowerShell Module is regularly updated with new features and functionality. The above link should always point to the most current version of the module. For more information, see article Microsoft Azure Active Directory PowerShell Module Version Release History.
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 additional information, see article
Upgrade Windows Azure Active Directory Sync ("DirSync") and Azure Active Directory Sync ("Azure AD Sync").
To download the latest version of Azure AD Connect (e.g. version 1.1.380.0 at the time of this writing), proceed with the following steps:
http://www.microsoft.com/en-us/download/details.aspx?id=47594.
Before executing Azure AD Connect, you must know the credentials:
If you've followed in order all the steps outlined before, all the above prerequisites should be enforced at this stage. So you should be good to go.
To execute Azure AD Connect and configure your identity infrastructure, proceed with the following steps:
Username: admin@litware369.onmicrosoft.com
Password: Pass@word1!?
Click Next.
Username: LIWARE369\AzureAdmin
Password: Pass@word1!?
Click Add Directory.
Username: AzureAdmin
Password: Pass@word1!?
,
Note You may assume the synchronization process will automatically start at a later time if the check mark is removed. This is not correct as you will need to enable the task in Scheduled Tasks on the server where the synchronization tool is installed. After the task is enabled, synchronization occurs every 30 minutes by default.
Note Logs regarding the Azure AD Connect installation can be found in the %LocalAppData%\AADCONNECT folder. Likewise, issues with the Azure AD App Proxy connector installation are exposed in the Event Viewer log under "Application and Service Logs\Microsoft\AadApplicationProxy\Connector\Admin".
You may wish to add scale or refine your options right away, or after some time has passed.
To configure additional task, proceed with the following steps:
Let's see how to verify the synchronization on the Azure AD/Office 365 tenant.
A second connector can be installed for high availability purposes. This comprises the following steps:
Note For more information, see article What is Azure AD Pass-through Authentication.
Note A second connector can be installed for high availability purposes
To download the connector for PTA, proceed with the following steps:
PS C:\> AADApplicationProxyConnectorInstaller.exe REGISTERCONNECTOR="false" /q
To install and configure the connector for PTA, proceed with the following steps:
PS C:\> .\RegisterConnector.ps1 -modulePath "C:\Program Files\Microsoft AAD App Proxy Connector\Modules\" -moduleName "AppProxyPSModule" -Feature PassthroughAuthentication
When prompted, enter the credentials of your global admin Azure AD credentials:
Username: admin@litware369.onmicrosoft.com
Password: Pass@word1!?
Note As already outlined, issues with the Azure AD App Proxy connector installation are exposed in the Event Viewer log under "Application and Service Logs\Microsoft\AadApplicationProxy\Connector\Admin".
Seamless single sign-on (SSO) is an option that can be enabled in Azure AD Connect with either password (hash of) hash synchronization (PHS) (see Part 6 of this paper) or pass-through authentication (PTA). When enabled, users only need type their username and do not need not to type their password to sign in to Azure AD or other cloud services when they are on their corporate machines and connected on the corporate network.
For users to use seamless SSO in your environment, you need to ensure that they are:
If any of the above items are not present, such as the computer is off the corporate network and Active Directory is not available, then users will simply be prompted to enter their password as they would without seamless SSO.
Note For more information, see article What is Single Sign On (SSO) (preview).
By default, browsers will not attempt sending credentials to web servers unless the URL is defined in the Intranet zone. In so far as the URLs used for seamless SSO in Azure AD contain a period because they are globally routable hostnames, they have to be explicitly added to the computer's Intranet zone, so that the browser will automatically send the currently logged in user's credentials in the form of a Kerberos ticket to Azure AD.
The easiest way to add the required URLs to the Intranet zone is to simply create a group policy in Active Directory or use an existing one.
Proceed with the following steps:
PS C:\> gpmc.msc
A Group Policy Management window brings up.
To verify the synchronization on the Azure AD tenant, proceed with the following steps:
Note If Azure Active Directory is not listed, click More Services, type "Azure", and the select Azure Active Directory.
To verify the "same sign-on" with the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com), proceed with the following steps:
If pass-through authentication (PTA) is correctly set up, your credentials are passed to the on-premises Active Directory forest, and, if verified, you should have a seamless access to the signed in user settings in the Office 365 portal.
No tiles are displayed for the online apps. This is expected for the test user as in fact you have not assigned a license to the test user.
To verify the seamless single sign-on (SSO) with the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com), proceed with the following steps:
If seamless single sign-on (SSO) is correctly set up, you should have a seamless access to the signed in user settings in the Office 365 portal.
No tiles are displayed for the online apps. This is expected for the test user as in fact you have not assigned a license to the test user.
When troubleshooting pass-through authentication (PTA), there are a few different categories of problems that can occur. Depending on the type of problem you may need to look in different places.
Note For more information, see article What is Azure AD Pass-through Authentication.
To resolves connector issues, you can start investigating the followings:
Note For more information, see article Troubleshoot Application Proxy.
C:\Users\AzureAdmin\AppData\Local\AADConnect\Trace-YYYYMMDD-XXXXXX.log
-or-
C:\Programdata\Microsoft\Microsoft AAD Application Proxy Connector\Trace
To resolves authentication and Kerberos issues, you can start investigating the followings:
XML filter can be used to get relevant information about PTA Connector in the security Event
<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[EventData[Data[@Name='ProcessName'] and (Data='C:\Program Files\Microsoft AAD App Proxy Connector\ApplicationProxyConnectorService.exe')]]</Select> </Query> </QueryList>
As the PTA feature uses the Azure AD Application Proxy connector for all requests, we expect most errors to come from network configuration problems. If there is a firewall in the path, make sure that it's open so that the connector can make HTTPS (TCP) requests to the Azure AD Application Proxy. The connector uses a series of ports together with subdomains that are part of the high-level domains msappproxy.net and servicebus.windows.net. Make sure to open the following ports to outbound traffic.
Note For more information, see article Enable Application Proxy in the Azure portal.
A tool to help checking for network problems can be downloaded at http://aka.ms/aadapConnectorTroubleshoot :
It is important to make sure the client is correctly configured for seamless SSO including the following:
Note For more information, see article What is Single Sign On (SSO) (preview).
C:\> "klist purge"
If you have been able to confirm the above requirements, you can review the console logs of the browser for additional information. The console logs can be found under developer tools. This will help you determine the potential problem.
Every time a user logs in with single sign on an entry is recorded in the event log of the domain controller, if success auditing is enabled. To find these events, you can review the Event logs for the security Event 4769 associated with computer account AzureADSSOAcc$.
The filter below finds all security events associated with the computer account:
<QueryList> <Query Id="0" Path="Security"> <Select Path="Security">*[EventData[Data[@Name='ServiceName'] and (Data='AZUREADSSOACC$')]]</Select> </Query> <QueryList>
You are now in a position to further test the environment.
Pass-through authentication (PTA) is supported via web browser based clients and Office clients that support modern authentication.
For clients that are not support such as legacy Office clients, Exchange active sync (i.e. native email clients on mobile devices), customers are encouraged to use the modern authentication equivalent.
This not only allows the PTA feature, but also allows for conditional access to be applied, such as multi-factor authentication.
Let's illustrate a typical PTA flow.
Figure 1 Pass-through authentication flow
The seamless SSO feature is supported via web browser based clients and Office clients that support modern authentication on computers that are capable of Kerberos authentication, such as Windows.
The following table provides details of the browser based clients on various operating systems.
Table 1 Supported clients per OS/Browsers
Operating systems |
Internet Explorer |
Chrome |
Firefox |
Edge |
Windows 10 |
Yes |
Yes |
Yes* |
No |
Windows 8.1 |
Yes |
Yes |
Yes* |
N/A |
Windows 8 |
Yes |
Yes |
Yes* |
N/A |
Windows 7 |
Yes |
Yes |
Yes* |
N/A |
Mac OS/X |
N/A |
N/A |
N/A |
N/A |
* Requires separate configuration
Modern authentication is an OAuth-based authentication stack used by Office 2013/2016 client applications against Office 365. This enables sign-in features such as Multi-Factor Authentication (MFA), SAML 2.0-based third-party identity providers with Office 2013/2016 client applications, smart card and certificate-based authentication, and it removes the need for Outlook to use the basic authentication protocol.
From a technical implementation standpoint, the Active Directory Authentication Library (ADAL) replaces for Windows clients the Microsoft Online Sign-in Assistant (SIA).
Let's illustrate a typical seamless SSO flow.
Figure 2 Seamless SSO flow
First the user attempts to access a resource that trusts security tokens issued from Azure AD, such as SharePoint Online (SPO) for Office 365. SharePoint Online then redirects the user to authenticate against Azure AD. The user is then invited to provide their username so that Azure AD can establish if the seamless SSO feature is enabled for their organization. Assuming seamless SSO is enabled for the organization, the following occurs:
Seamless SSO is an opportunistic feature, which means that if it fails for some reason, the user simply need only enter their password on the sign-in page as usual.
This last section of this document provides and introduction to Azure Active Directory Connect Health (Azure AD Connect Health). This cloud based service in the
new Azure Portal helps you monitor and gain insight into health, performance and login activity of your on-premises identity infrastructure. It thus offers you the ability to view alerts, performance, usage patterns, configuration settings, enables you to maintain a reliable Azure AD connection, and much more.
Azure AD Connect Health represents a key part of our effort to help you monitor and secure your cloud and on-premises identity infrastructure.
Note For more information, see article Monitor your on-premises identity infrastructure and synchronization services in the cloud.
Note Azure AD Connect Health is a feature of the Azure AD Premium P1 edition. For a description of this edition below and a comparison table, see article Azure Active Directory editions.
This section walks you through the process of configuring this service for your existing on-premises deployment as per this document. The process consists in the following five steps:
The following subsections describe in the context of our test lab environment each of these steps.
Like before, and unless noticed otherwise, all the instructions should be done on the DC1 computer.
To get started with and use the Azure AD Connect Health service, proceed with the following tasks:
Username: admin@litware369.onmicrosoft.com
Password: Pass@word1!?
Click Next.
Note If you do not have an Azure Active Directory Premium P1 license, you will need one to use Azure AD Connect Health as previously noticed. See article What is Microsoft Azure Active Directory licensing?. You can sign-up for a trial at https://portal.office.com/Signup/Signup.aspx?OfferId=01824d11-5ad8-447f-8523-666b0848b381.
Once created, you can now access the Azure AD Connect Health Portal that allows you to view alerts, performance monitoring, and usage analytics. Upon first accessing Azure AD Connect Health, a first blade is presented.
In order to see any data in your instance of Azure AD Connect Health, you will need to install the Azure AD Connect Health agents on your targeted servers, for example the six computers in our configuration. This is the purpose of the next sections.
The Azure AD Connect Health agent for Sync is installed as part of the Azure AD Connect installation (version 1.0.9125.0 or higher). So this is already completed with our prior installation and configuration of Azure AD Connect (version 1.1.380.0 in our configuration). See section Integrating your on-premises AD forest(s) with your Azure AD/Office 365 tenant.
To verify the agent has been installed, look for the following services on the DC1 computer. If you completed the configuration, they should already be running:
Note For more information, see article Azure AD Connect Health Agent Installation.
To download the latest version of health agent for AD DS, proceed with the following steps:
To download the latest version of health agent for AD DS, proceed with the following steps:
As stated, an elevated PowerShell command prompt is then launched to execute the following command while the initial command prompt closes:
Register-AzureADConnectHealthADDSAgent
Executing Elevated PowerShell Command: Register-AzureADConnectHealthADDSAgent 2017-01-05 10:37:00.735 ProductName: Microsoft Azure AD Connect Health agent for AD DS, FileVersion: UTC Time: 2017-01-05 10:37:00Z 2017-01-05 10:37:00.893 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADH/ 2017-01-05 10:37:00.893 AdHybridHealthServiceUri: https://adds.aadconnecthealth.azure.com/ 2017-01-05 10:37:03.098 AHealthServiceApiVersion: 2014-01-01 2017-01-05 10:43:28.828 Detecting AdDomainService roles... 2017-01-05 10:43:29.562 Detected the following role(s) for litware369.com: 2017-01-05 10:43:29.562 Active Directory Domain Services 2017-01-05 10:43:34.915 Aquiring Monitoring Service certificate using tenant.cert 2017-01-05 10:43:42.506 Successfully aquired and stored Monitoring Service certificate: Subject=CN=DC c-4be2-9b86-5b3513ecb22e, OU=Microsoft ADFS Agent, Issuer=CN=Microsoft PolicyKeyService Certificate A nt=25E0F7EE2D344DF31888B7E223795DFD29D4DFBF 2017-01-05 10:43:42.521 Fetched and stored agent credentials successfully... 2017-01-05 10:43:44.432 Started agent services successfully... Test-AzureADConnectHealthConnectivity completed successfully... 2017-01-05 10:44:02.807 Agent registration completed successfully. Detailed log file created in temporary directory: C:\Users\AzureAdmin.LITWARE369\AppData\Local\Temp\2\AdHealthAddsAgentConfiguration.2017-01-05_10-37-00.log PS C:\Users\AzureAdmin.LITWARE369\Downloads>
These services should be started automatically and the agent will be now monitoring and gathering data.
Note For more information, see article Azure AD Connect Health Agent Installation.
At this stage, you should now be in position to monitor your on-premises deployment.
To now use the Azure AD Connect Health service, proceed with the following tasks:
Username: admin@litware369.onmicrosoft.com
Password: Pass@word1!?
Note For more information on the various health topics (alerts, performance monitoring, usage analytics, properties, etc.), see articles Azure AD Connect Health Operations, Using Azure AD Connect Health for sync, Using Azure AD Connect Health with AD FS, and Using Azure AD Connect Health with AD DS.