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 single sign-on feature, Azure AD provides organizations with the ability to authenticate against the organization's Active Directory (or other identity repositories), allowing their users to use their corporate credentials to access Azure AD/Office 365 and the services that they have been provisioned for.
As previously noticed, this document complements the third part entitled Azure AD/Office 365 seamless Single Sign-in – Part 3 by providing an end-to-end walkthrough to rollout a working single sign-on configuration for Azure AD/Office 365 with AD FS.
This document doesn't provide a full description of AD FS in Windows Server 2012 R2. It doesn't provide neither guidance for setting up and configuring AD FS in a production environment nor a complete technical reference for AD FS.
Note For information on AD FS, please refer to the product documentation, and the dedicated AD FS Q&A forum.
It doesn't neither provide an understanding of the different single sign-on deployment options with Azure AD/Office 365, 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. This is specifically the intent of the aforementioned first part that covers all the key aspects the readers should understand to successfully achieve single sign-on with Azure AD/Office 365 for their organization.
To cover the aforementioned objectives, this document is organized in the following 3 sections:
These sections provide the information details necessary to (hopefully) successfully build a working environment for the scenario. They must be followed in order.
Identity federation − also known as (cross-domain) single sign-on − in general is a broad topic, with many facets, depths of understanding, protocols, standards, tokens, etc. This paper addresses the single sign-on topic only from the Azure AD/Office 365 perspective and from both conceptual and technical levels.
This document is thus intended for system architects and IT professionals who are interested in understanding this capability 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:
Note Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft TechNet Windows Server 2012 R2 homepage.
If you've already followed the walkthrough of Part 2, all the components that pertains to the above Azure-based test lab infrastructure should already be in place with the six VMs running Windows Server 2012 R2. 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.
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 2 of this whitepaper.
To finalize the configuration of the domain controllers in our test lab environment, you will need to create a group Managed Service Account (gSMA).
A gMSA account will be required during the AD FS installation and configuration. The benefit of using a gMSA is its auto-negotiated password update feature.
To create the gMSA account, proceed with the following steps:
PS C:\> Get-KdsRootKey
PS C:\> Add-KdsRootKey –EffectiveTime (Get-Date).AddHours(-10)
Guid
----
99490123-7d38-c01e-05c7-539224fa88ea
PS C:\>
PS C:\> New-ADServiceAccount FsGmsa -DNSHostName adfs.litware369.com -ServicePrincipalNames http/adfs.litware369.com
The AD FS farm is constituted by the ADFS1 and ADFS2 computers along with the internal load balancer.
This section walks you through the deployment of the primary federation server on the ADFS1 computer with the following steps:
Note For more information, see article Windows Server 2012 R2 AD FS Deployment Guide.
Important note You must have domain administrator permissions to deploy the AD FS role service.
The following subsections describe each of these steps in the context of our test lab environment.
The AD FS role service will require a server SSL/TLS certificate. The certificate MUST have the following attributes:
Note For more information about setting up SSL/TLS certificates, see article Configure SSL/TLS on a Web site in the domain with an Enterprise CA.
To issue the SSL/TLS certificate, proceed with the following steps:
PS C:\> Get-Certificate -Template SSLCertificates -SubjectName CN=adfs.litware369.com
`
–DnsName adfs.litware369.com, enterpriseregistration.litware369.com -CertStoreLocation cert:\LocalMachine\My<
Status Certificate Request
------ ----------- -------
Issued [Subject]…
PS C:\> _
Note If you have not configured a new certificate template (e.g. the SSLCertificates in our configuration), you can use the WebServer certificate template in lieu of in the above command.
Note For more information, see article AD CS Administration Cmdlets in Windows PowerShell.
PS C:\> dir Cert:\LocalMachine\My
Directory: Microsoft.PowerShell.Security\Certificate::LocalMachine\My
Thumbprint Subject
---------- -------
FADB4FDF7C5006D45011B5E9DF0C2DA8C624FD2F DC=Windows Azure CRP Certificate Generator
3361995F9929C7269886A9DC276122B493D3C4A5 CN=8848a529-9d69-4049-8469-8218547a61e2
12D5C5C12A4E432061B383ACCBA17241ADE0CE02 DC=Windows Azure CRP Certificate Generator
1FA2AE7473841BAFCB2460735EE3EF4CAE22F6C0 CN=adfs.litware369.com
PS C:\> _
The certificates are listed by their thumbprint in the Local Computer\My Store. We will be later interested in the thumbprint of the newly issued certificate, i.e. the one whose CN equals adfs.litware369.com, for example in our configuration: 1FA2AE7473841BAFCB2460735EE3EF4CAE22F6C0.
To install and configure the AD FS role service, proceed with the following steps:
PS C:\> Install-windowsfeature adfs-federation –IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Federation Services}
WARNING: To finish configuring this server for the federation server role using Windows PowerShell, see
http://go.microsoft.com/fwlink/?LinkId=224868.
PS C:\> _
PS C:\> Import-Module ADFS
PS C:\> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" | Select-Object `
-First 1).Thumbprint
PS C:\> Install-AdfsFarm –CertificateThumbprint $certificateThumbprint -FederationServiceDisplayName "Litware369" `
-FederationServiceName "adfs.litware369.com" –GroupServiceAccountIdentifier "LITWARE369\FsGmsa$"
WARNING: The root key for the group Managed Service Account was created at 1/3/2017 9:39:52 AM. If you have more than
one domain controller in your Active Directory forest, the key may not yet have replicated to all domain controllers
and therefore the service may not successfully install or start. To avoid service startup problems, wait 10 hours to
ensure the key has replicated to all DCs before completing the Active Directory Federation Services Configuration
Wizard, executing Install-AdfsFarm or Add-AdfsFarmNode on any other servers in your network, or restarting any AD FS
service.
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\> _
Important note The '$' at the end of the gMSA account is required.
Note If this is NOT the first time you run this command, add –OverwriteConfiguration.
As discussed in the first part of the whitepaper, 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. Attributes of the device can then be retrieved from AD to drive conditional access to authorize issuance of security tokens for the targeted applications. Windows 8.1, Android 4.0+, 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 DRS along with WAP can join devices that use Workplace Join from any Internet-connected location.
Note For more information, see article Join to Workplace from Any Device for SSO and Seamless Second Factor Authentication Across Company Applications.
The DRS capability has to be initialized and enabled on the AD FS farm.
To enable the DRS capability on the ADFS1 computer, proceed with the following steps:
PS C:\> Initialize-ADDeviceRegistration -ServiceAccountName "LITWARE369\FsGmsa$"
PS C:\> Initialize-ADDeviceRegistration
This command will prepare Active Directory to host Device Registration Service in the current forest.
Do you want to continue with this operation?
[Y] Yes [A] Yes to All [N] No [L] No to All [S] Suspend [?] Help (default is "Y"): Y
WARNING: The Active Directory forest has been prepared for Device Registration. To use the AD FS Device Registration
Service, run the Enable-AdfsDeviceRegistration cmdlet on each node in your AD FS farm.
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\> _
PS C:\> Enable-AdfsDeviceRegistration
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\> _
You should see a message about device registration being successful.
Note For more information, see article Step 5: Configure a federation server with Device Registration Service.
This section walks you through the deployment of the secondary federation server on the ADFS2 computer with the following steps:
The following subsections describe each of these steps in the context of our test lab environment.
As mentioned earlier, the AD FS role service will require a server SSL/TLS certificate. To import the certificate previously issued on the ADFS1 computer, proceed with the following steps:
To install and configure the AD FS role service on the ADFS2 computer, proceed with the following steps:
PS C:\> Install-windowsfeature adfs-federation –IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Federation Services}
WARNING: To finish configuring this server for the federation server role using Windows PowerShell, see
http://go.microsoft.com/fwlink/?LinkId=224868.
PS C:\>
PS C:\> Import-Module ADFS
PS C:\> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" | Select-Object -First 1).Thumbprint
PS C:\> Add-AdfsFarmNode -GroupServiceAccountIdentifier "LITWARE369\FsGmsa$" `
-PrimaryComputerName "adfs1.litware369.com" –CertificateThumbprint $certificateThumbprint
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\>
Important note The '$' at the end of the gMSA account is required.
Note If this is NOT the first time you run this command, add –OverwriteConfiguration.
As mentioned before, the DRS capability has to be initialized and enabled on the AD FS farm.
To enable the DRS capability on the ADFS2 computer, from the previous elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt, run the following command:
PS C:\> Enable-AdfsDeviceRegistration
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\> _
You should see a message about device registration being successful.
Note For more information, see article Step 5: Configure a federation server with Device Registration Service.
Depending upon how Internet Explorer is configured you will either be prompted to provide credentials or be automatically signed-in.
Before testing the configuration, if you want to have users be automatically signed-in, you will then need to configure your browser settings to trust the AD FS farms by adding your federation service name (for example in our configuration, https://adfs.liteware369.com) to the browser's local intranet zone. This will enable seamless sign-in using Windows Integrated Authentication (WIA).
To test the AD FS configuration, proceed with the following steps:
https://adfs.litware369.com/federationmetadata/2007-06/federationmetadata.xml
If in your browser window you can see the federation server metadata without any TLS errors or warnings, your federation server is operational.
https://adfs.litware369.com/adfs/services/trust/mex
https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.aspx
This displays the AD FS sign-in page where you can sign in with the domain credentials.
To test the AD FS farm high availability, shutdown the AD FS federation servers in the AD FS farm one at a time and check that you can still access AD FS with each computer offline: ADFS1 and ADFS2. This will test the failure of losing one of the servers in the internal load balancer.
At this stage, you are now setup with a highly available AD FS solution for all internal users of the LITWARE369 domain. Let's setup the Web Application Proxy (WAP) farm so that the external users have access too.
The WAP farm is constituted by the WAP1 and WAP2 computers along with the Internet load balancer.
To prepare the first server in the WAP farm, proceed with the following steps in order:
The following subsections describe each of these steps in the context of our test lab environment.
The WAP servers need to make contact back to the AD FS servers, So, you need to tell the WAP servers how to get to them. The simplest way of doing this consists in editing the local HOSTS file on the WAP1 computer. Keep in mind that we don't have connectivity or the ability to route to the internal IP address, so we need to route to the external IP of the internal load balancer that holds the two AD FS computers ADFS1 and ADFS2.
To update the HOSTS file, proceed with the following steps:
10.0.0.200 adfs.litware369.com
The default web site will require a server SSL/TLS certificate. The certificate MUST have the following attributes:
For demonstration purpose, you can issue such a SSL/TLS certificate with the test lab certification authority litware369-DC2-CA as illustrated hereafter.
You can instead use a SSL/TLS certificate issued from a public certification authority is required. The exact method depends on the chosen public certification authority. Please refer to their instructions.
With the exception of the SSL/TLS certificate import into the Local Computer\My Store on the WAP1 computer, the rest of the suggested configuration doesn't differ from the one illustrated in this document.
To issue the SSL/TLS certificate with the test lab certification authority, proceed with the following steps:
PS C:\> Get-Certificate -Template SSLCertificates -SubjectName CN=www.litware369.com –DnsName adfs.litware369.com, enterpriseregistration.litware369.com, www.litware369.com -CertStoreLocation cert:\LocalMachine\My
Status Certificate Request
------ ----------- -------
Issued [Subject]…
PS C:\> _
Note If you haven't previously configured a new certificate template (e.g. the SSLCertificates in our configuration), you can use the WebServer certificate template in lieu of in the above command.
To install the Web Server (IIS) role service on the WAP1 computer, from the previous Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt, run the following command:
PS C:\> Install-windowsfeature web-server –IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Common HTTP Features, Default Document, D...
PS C:\> _
To configure HTTPS on the default web site, proceed with the following steps:
PS C:\> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https
PS C:\> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match "CN\=www.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443
IP Address Port Host Name Store Sites
---------- ---- --------- ----- -----
0.0.0.0 443 MY Default Web Site
PS C:\> _
The Web Application Proxy (WAP) is the proxy for AD FS in Windows Server 2012 R2.
Note For more information, see the article Web Application Proxy Overview as well as the section Deploying Federation Server Proxies of the Windows Server 2012 R2 AD FS Deployment Guide also available on Microsoft TechNet.
To install and configure the Web Application Proxy role service, proceed with the following steps:
PS C:\> Install-WindowsFeature Web-Application-Proxy –IncludeManagementTools
Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {RAS Connection Manager Administration Kit...
WARNING: To finish configuring this server for the Web Application Proxy role service using Windows PowerShell, see
http://go.microsoft.com/fwlink/?LinkId=294322.
PS C:\> _
PS C:\> $domain = "litware369.com"
PS C:\> $password = "Pass@word1!?" | ConvertTo-SecureString -asPlainText -Force
PS C:\> $username = "$domain\AzureAdmin"
PS C:\> $credential = New-Object System.Management.Automation.PSCredential($username,$password)
PS C:\> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" | Select-Object -First 1).Thumbprint
PS C:\> Install-WebApplicationProxy -FederationServiceTrustCredential $credential -CertificateThumbprint $certificateThumbprint -FederationServiceName "adfs.litware369.com"
Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success
PS C:\> _
Note For more information, see article Web Application Proxy Cmdlets.
This section walks you through the deployment of the web application proxy on the WAP2 computer with the following steps:
The following subsections describe each of these steps in the context of our test lab environment.
As mentioned earlier, the Web Application proxy (WAP) role service will require a server SSL/TLS certificate. To import the certificate previously issued on the WAP1 computer, proceed with the following steps:
To install and configure the Web Server (IIS) role service on the WAP2 computer, proceed as per eponym section § Installing and configuring the Web Server (IIS) role service for the WAP1 computer.
To configure HTTPS on the default web site on the WAP2 computer, proceed as per eponym section § Configuring HTTPS on the default web site for the WAP1 computer.
To deploy the Web Application Proxy (WAP) on the WAP2 computer, proceed as per eponym section § Deploying the Web Application Proxy (WAP) for the WAP1 computer.
The Internet facing WAP farm is able to throttle requests coming from the Internet if the latency between the WAP farm and the AD FS farm increases beyond a certain threshold. Based on this feature, the WAP farm will reject external client authentication requests if the AD FS farm is overloaded as detected by the latency between the WAP farm and the AD FS farm to service authentication requests from Azure AD/Office 365.
It is closely related to a similar algorithm employed for congestion control in TCP known as Additive Increase Multiplicative Decrease (AIMD). The implemented solution works by using a congestion window represented by a pool of tokens that it leases out to each incoming request to the WAP farm.
In a high latency DMZ network or a highly loaded WAP environment, it is possible for authentication requests to be rejected even if the AD FS farm can satisfy these requests successfully based on the default settings that control this algorithm.
In such an environment, we strongly recommend modifying the settings to be less aggressive by performing the following steps:
<congestionControl latencyThresholdInMSec="8000" minCongestionWindowSize="64" enabled="true" />
C:\> net stop adfssrv
C:\> net start adfssrv
To verify that you can successfully authenticate against the federation server on the Internet, proceed with the following steps:
Note If the SSL/TLS certificate used in the configuration has not been issued by a public certification authority, you will need to add the test lab certification authority Litware369-DC2-CA root certificate in the trusted root certification authorities of your local computer.
As before, this displays the AD FS sign-in page where you can sign in with the domain credentials.
To test the WAP farm high availability, shutdown the WAP servers in the WAP farm one at a time and check that you can still access the above AD FS IdpInitiatedSignOn.aspx page with each computer offline: WAP1 and WAP2. This will test the failure of losing one of the servers in the Internet load balancer.
At this stage, the base configuration is now complete.
To avoid spending your credit when you don't work on the test lab environment, you can shut down the six VMs (DC1, DC2, ADFS1, ADFS2, WAP1, and WAP2) when you don't work on the test lab.
To shut down the VMs of the test lab environment, proceed with the following steps:
To resume working on the test lab environment, you will then need to start the six VMs that constitute it.
To start the VMs of the test lab environment, proceed with the following steps:
This section provides a walkthrough on how to setup single sign-on 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 federation 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.
This section walks you through the use of the single wizard Azure AD Connect on the ADFS1 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 five 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 more information, see articles
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.
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.
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.
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 single sign-on with the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com), proceed with the following steps:
Note
If you turn on HTTP tracing on IE or observe the traffic via a tool like the Telerik Fiddler HTTP trace application, you can see that the login.microsoftonline.com URL is calling GetUserRealm as part of the home realm discovery (HRD) process. You will also notice that their results show the AD FS endpoint information.
If single sign-on is correctly set up, you should be automatically redirected to the AD FS farm, and then redirected back to the Office portal where you're first invited to provide more information.
At the end of the process, 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.
You are now in a position to further test the environment.
This last section of this document provides and introduction to Azure Active Directory Connect Health (Azure AD Connect Health). This cloud based service in thenew 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 ADFS1 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 FS, proceed with the following steps:
In order to gather data and analyze, the health agent for AD FS needs the information in the AD FS Audit Logs. These logs are not enabled by default.
Note This only applies to the AD FS farm, for example the ADFS1 and ADFS2 computers in our configuration. You do not need to enable auditing on WAP farm, i.e. the WAP1 and WAP2 computers in our configuration.
To enable AD FS auditing and locate the AD FS audit logs, proceed with the following steps:
PS C:\> auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable
Click OK.
You're ready to install and configure the Azure AD Connect Health agents on the AD FS and WAP farms.
Before installing the health agents on your targeted servers, you must ensure that you've prior completed all the related requirements. If you've strictly followed in order the instructions provided as part of this document, you should normally fulfill all of them.
To install and configure the Azure AD Connect Health Agent, 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-AzureADConnectHealthADFSAgent
Executing Elevated PowerShell Command: Register-AzureADConnectHealthADFSAgent
2017-01-05 11:44:19.753 ProductName: Azure AD Connect Health AD FS Agent, FileVersion: 2.6.491.0, Current UTC Time: 201
7-01-05 11:44:19Z
2017-01-05 11:44:19.787 AHealthServiceUri (ARM): https://management.azure.com/providers/Microsoft.ADHybridHealthService/
2017-01-05 11:44:19.8 AdHybridHealthServiceUri: https://s1.adhybridhealth.azure.com/
2017-01-05 11:44:20.692 AHealthServiceApiVersion: 2014-01-01
2017-01-05 11:46:08.255 Detecting AdFederationService roles...
2017-01-05 11:46:08.395 Detected the following role(s) for adfs.litware369.com:
2017-01-05 11:46:08.395 AD FS 2012 R2 Federation Server
2017-01-05 11:46:10.83 Aquiring Monitoring Service certificate using tenant.cert
2017-01-05 11:46:14.047 Successfully aquired and stored Monitoring Service certificate: Subject=CN=ADFS1, CN=2971a9f9-454c-4be2-9b86-5b3513ecb22e, OU=Microsoft ADFS Agent, Issuer=CN=Microsoft PolicyKeyService Certificate Authority, Thumbprint=36F02B42A25D4BF0B6DD326FD9CDF7868A88124D
2017-01-05 11:46:14.066 Fetched and stored agent credentials successfully...
2017-01-05 11:46:17.645 Started agent services successfully...
Test-AzureADConnectHealthConnectivity completed successfully...
WARNING: 2017-01-05 11:46:29.343 Agent registration completed with warning(s).
WARNING: 2017-01-05 11:46:29.343 Log file
C:\Users\AzureAdmin.LITWARE369\AppData\Local\Temp\2\AdHealthAdfsAgentConfiguration.2017-01-05_11-44-19.log contains
more information regarding the warning(s).
To review installation steps and requirements, please visit:
http://go.microsoft.com/fwlink/?LinkID=518643
Detailed log file created in temporary directory:
C:\Users\AzureAdmin.LITWARE369\AppData\Local\Temp\2\AdHealthAdfsAgentConfiguration.2017-01-05_11-44-19.log
To retry configuration, type:
Register-AzureADConnectHealthADFSAgent
Detailed log file created in temporary directory:
C:\Users\AzureAdmin.LITWARE369\AppData\Local\Temp\2\AdHealthAdfsAgentConfiguration.2017-01-05_11-44-19.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.
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.