azure ad/office 365 seamless sign-in · web viewazure ad/office 365 seamless sign-in - part 4bis...

Azure AD/Office 365 seamless sign-inPart 4bis – Implement single sign-on (SSO) with AD FS in Windows Server 2012 R2

Microsoft FrancePublished: January 2017Version: 1.0

Authors: Philippe Beraud (Microsoft France)Contributors/Reviewers: Philippe Maurent (Microsoft Corporation)

For the latest information on Azure Active Directory, please see http://azure.microsoft.com/en-us/services/active-directory/

Copyright © 2017 Microsoft Corporation. All rights reserved.

Abstract: Through its support for standard protocols, Active Directory Federation Services (AD FS) provides claims-based (Web) single sign-on (also known as identity federation) with Azure Active Directory (Azure AD), and related services such has the Microsoft Office 365 offering and its Web application and rich client applications. In addition to the third part, which is intended to provide a better 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 document provides a complete end-to-end walkthrough to rollout a fully operational configuration in Azure.By following the steps outlined in this document you should be able to successfully configure your environment to deploy AD FS, setup Azure AD/Office 365 single sign-on, and start using it within your organization to provide a seamless sign-in experience for end-users accessing Azure AD/Office 365 resources.

Table of ContentsIMPORTANT NOTICE...........................................................................................INTRODUCTION..................................................................................................

OBJECTIVES OF THIS PAPER................................................................................................NON-OBJECTIVES OF THIS PAPER.........................................................................................ORGANIZATION OF THIS PAPER............................................................................................ABOUT THE AUDIENCE.......................................................................................................

SETTING UP THE BASE CONFIGURATION TEST LAB...............................................ACCESSING THE VARIOUS MACHINES OF THE TEST LAB ENVIRONMENT.........................................

SETTING UP SINGLE SIGN-ON WITH THE AZURE AD/OFFICE 365 TENANT................ISSUING A SSL/TLS CERTIFICATE........................................................................................DOWNLOADING AZURE AD CONNECT..................................................................................ENABLING MULTI-HOP SUPPORT IN WINRM..........................................................................EXECUTING AZURE AD CONNECT......................................................................................CONFIGURING ADDITIONAL TASKS......................................................................................VERIFYING THE SYNCHRONIZATION ON THE AZURE AD/OFFICE 365 TENANT..............................VERIFYING THE SINGLE SIGN-ON WITH THE AZURE AD/OFFICE 365 TENANT..............................TROUBLESHOOTING THE CONFIGURATION............................................................................

MONITORING YOUR ON-PREMISES DEPLOYMENT (OPTIONAL).............................GETTING STARTED WITH THE AZURE AD CONNECT HEALTH SERVICE........................................CONFIGURING AZURE AD CONNECT HEALTH FOR SYNC.........................................................CONFIGURING AZURE AD CONNECT HEALTH FOR AD FS......................................................CONFIGURING AZURE AD CONNECT HEALTH FOR AD DS......................................................USING THE AZURE AD CONNECT HEALTH SERVICE...............................................................

Important noticePart 3 provides an understanding of 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.By leveraging the Azure-based evaluation lab environment configured thanks to the guidance of Part 2, Part 4bis, i.e. this document, provides an instrumented end-to-end walkthrough to further familiarize yourself with both the installation and configuration of the related highly available infrastructure.It leverages Azure AD Connect to connect to Azure AD/Office 365 and build your AD FS highly available environment w/ an AD FS farm and a WAP farm.

Azure AD/Office 365 seamless sign-in 1

IntroductionMicrosoft Office 3651 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.

Objectives of this paperAs previously noticed, this document complements the third part entitled AZURE AD/OFFICE 365 SEAMLESS SINGLE SIGN-IN – PART 3 2 by providing an end-to-end walkthrough to rollout a working single sign-on configuration for Azure AD/Office 365 with AD FS.

Non-objectives of this paperThis 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 documentation3, and the dedicated AD FS Q&A forum4.

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.

Organization of this paperTo cover the aforementioned objectives, this document is organized in the following 3 sections:

SETTING UP THE BASE CONFIGURATION TEST LAB.

1 Microsoft Office 365: http://office.microsoft.com/en-us/business/2 AZURE AD/OFFICE 365 SEAMLESS SIGN-IN – PART 3: http://www.microsoft.com/en-us/download/details.aspx?id=363913 ACTIVE DIRECTORY FEDERATION SERVICES OVERVIEW: https://technet.microsoft.com/en-us/windows-server-docs/identity/active-directory-federation-services4 AD FS Q&A forum: http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads

2 Azure AD/Office 365 seamless sign-in - Part 4bis – Implement single sign-on (SSO) with AD FS in Windows Server 2012 R2

http://social.msdn.microsoft.com/Forums/en-US/Geneva/threads

https://technet.microsoft.com/en-us/windows-server-docs/identity/active-directory-federation-services

http://www.microsoft.com/en-us/download/details.aspx?id=36391


http://office.microsoft.com/en-us/business/

BY FOLLOWING THE INSTRUCTIONS OUTLINED HEREAFTER, YOU SHOULD BE ABLE TOSUCCESSFULLY PREPARE YOUR ON-PREMISES TEST LAB ENVIRONMENT BASED ON VIRTUALMACHINES (VMS) RUNNING IN AZURE TO LATER DEPLOY AND CONFIGURE THE TESTENVIRONMENT, INSTALL AND CONFIGURE IT. .

MONITORING YOUR ON-PREMISES DEPLOYMENT (OPTIONAL).These sections provide the information details necessary to (hopefully) successfully build a working environment for the scenario. They must be followed in order.

About the audienceIdentity 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.

Azure AD/Office 365 seamless sign-in - Part 4bis – Implement single sign-on (SSO) with AD FS in Windows Server 2012 R2 3

Setting up the base configuration test labBy 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:

AD DS Forest

Internal-sn Subnet(10.0.0.0/24)

DC1(10.0.0.101)

DC2 (10.0.0.102)

AD FS Farm

ADFS1 (10.0.0.201)

ADFS2 (10.0.0.202)

internal load balancer

(10.0.0.200)

DMZ-sn Subnet(10.0.1.0/24)

WAP Farm

Internet load balancer(IP public address)

WAP1 (10.0.1.101)

WAP2 (10.0.1.102)

Corporate boundary

AD DSAzure AD Connect

AD DSAD CS

AD FS

AD FS

WAP

WAP

Firewall Firewall

Perimeter networkInternet corporate network

Internet

Office 365Azure

Active Directory

Two computers running Windows Server 2012 R2 (named DC1 respectively DC2 by default) that will be configured as a domain controller with a test user and group accounts, and Domain Name System (DNS) servers. DC1 will host Azure AD Connect for the sync between the Azure-based test lab infrastructure and the Azure AD/Office 365 subscription. Alternatively, DC2 will be configured as an enterprise root certification authority (PKI server),

Two intranet member server running Windows Server 2012 R2 (named ADFS1 respectively ADFS2 by default) that will be configured as an AD FS farm.

Two Internet-facing member server running Windows Server 2012 R2 (named WAP1 respectively WAP2 by default) that is configured as Web servers for the Web Application Proxy (WAP) farm.

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 homepage5.

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:

Connect to the Internet to install updates, and access Internet resources in real time.

5 WINDOWS SERVER 2012 R2: http://technet.microsoft.com/en-US/windowsserver/hh534429


http://technet.microsoft.com/en-US/windowsserver/hh534429

Later configure them with Azure AD Connect to finally get a relevant Azure-based test infrastructure.

Remotely managed those using a Point-to-Site (P2S) connection and then Remote Desktop (RDP) connections by your computer that is connected to the Internet or your organization network.

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.

Create snapshots so that you can easily return to a desired configuration for further learning and experimentation.

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.

Accessing the various machines of the test lab environmentSee eponym section in Part 2 of this whitepaper.


Setting up single sign-on with the Azure AD/Office 365 tenantThis 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 6.

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 seven steps:

1. Issuing a SSL/TLS certificate.2. Issuing a SSL/TLS certificate.3. Enabling multi-hop support in WinRM.4. Enabling multi-hop support in WinRM.5. Configuring additional tasks.6. Verifying the synchronization on the Azure AD/Office 365 tenant.7. Verifying the single sign-on with the Azure AD/Office 365 tenant.

The following subsections describe each of these steps in the context of our test lab environment.

6 INTEGRATING YOUR ON-PREMISES IDENTITIES WITH AZURE ACTIVE DIRECTORY: https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect


https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect

Issuing a SSL/TLS certificateThe default web site will require a server SSL/TLS certificate. The certificate MUST have the following attributes:

Subject Name (CN): www.litware369.com Subject Alternative Name (DNS): adfs.litware369.com Subject Alternative Name (DNS): enterpriseregistration.litware369.com Subject Alternative Name (DNS): www.litware369.com

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:

1. Open a remote desktop connection on the DC1 computer. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINES OF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.1.101" for the WAP1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?" as password.

2. Open a Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt, and then run the following command:

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.


3. Export the issued certificate with its private key for later use with Azure AD Connect:

a. From the previous elevated Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt, and open mmc.exe.

b. Click File | Add/Remove Snap-in… Select Certificates in Available snap-ins and then click Add. A Certificates snap-in dialog opens up.

c. Select Computer account, click Next, and then click Finish. Click OK to close the dialog.

d. Right-click the www.litware369.com certificate, click All Tasks, and then click Export. The Certificate Export Wizard opens up.

e. Click Next, select Yes, export the private key, and then click Next.f. On Export File Format, leave Personal Information Exchange – PKCS

#12 (.PFX) selected, and then click Next. g. On Security, check Password, and type “Pass@word1!?” twice. Then click

Next.h. On File to Export, browse to the location to which you want to export the

SSL/TLS certificate. For File name, name the certificate file, for example "Litware369" in our configuration. Then click Next.

i. Click Finish to export the certificate. Click OK to close the dialog.

Downloading Azure AD ConnectAzure 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:

Install pre-requisites like the Azure Active Directory Module for Windows PowerShell (64-bit version)7 and Microsoft Online Services Sign-In Assistant8.

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 9.

Install and configure the sync engine, and enable directory synchronization in the customer's Azure tenant.

Configures either password sync (w/ optional seamless single sign-on), path-through authentication (w/ optional seamless single sign-on), or AD FS, depending on which sign-on option the customer prefers, and includes any required configuration in Azure.

Verifies everything is working.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.

7 Azure Active Directory Module for Windows PowerShell (64-bit version): http://go.microsoft.com/fwlink/p/?linkid=2362978 Microsoft Online Services Sign-In Assistant for IT Professionals: http://go.microsoft.com/fwlink/?LinkId=2861529 MICROSOFT AZURE ACTIVE DIRECTORY POWERSHELL MODULE VERSION RELEASE HISTORY: http://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx


http://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx

http://social.technet.microsoft.com/wiki/contents/articles/28552.microsoft-azure-active-directory-powershell-module-version-release-history.aspx

http://go.microsoft.com/fwlink/?LinkId=286152

http://go.microsoft.com/fwlink/p/?linkid=236297

http://go.microsoft.com/fwlink/p/?linkid=236297

Note For more information, see article UPGRADE WINDOWS AZURE ACTIVE DIRECTORY SYNC (“DIRSYNC”) AND AZURE ACTIVE DIRECTORY SYNC (“AZURE AD SYNC”) 10.

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:

1. Open a remote desktop connection on the DC1 computer. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINES OF THE TEST LAB ENVIRONMENT for the DC1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with “Pass@word1!?” as password.

2. Open a browsing session and navigate to:http://www.microsoft.com/en-us/download/details.aspx?id=47594

3. Click Download to download the Azure AD Connect MSI file (AzureADConnect.msi).

4. Click Save.

Enabling multi-hop support in WinRMBefore executing Azure AD Connect, we need to enable multi-hop support in Management (WinRM) for the delegation of user credentials across multiple remote computers. For that purpose, the multi-hop support functionality can use Credential Security Service Provider (CredSSP) for authentication.

Note For more information, see article MULTI-HOP SUPPORT IN WINRM 11.

Note For more information about CredSSP, see article CREDENTIAL SECURITY SUPPORT PROVIDER 12.

So, let’s configure CredSSP for second-hop remoting. To enable client-side CredSSP for WinRM on the DC1 computer, proceed with the following steps:

1. Open a remote desktop connection on the DC1 computer that will be also your sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.0.101" for the DC1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?” as password.

10 UPGRADE WINDOWS AZURE ACTIVE DIRECTORY SYNC (“DIRSYNC”) AND AZURE ACTIVE DIRECTORY SYNC (“AZURE AD SYNC”): https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-dirsync-deprecated11 Multi-Hop Support in WinRM: https://msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx12 Credential Security Support Provider: https://msdn.microsoft.com/en-us/library/windows/desktop/bb931352(v=vs.85).aspx


https://msdn.microsoft.com/en-us/library/windows/desktop/bb931352(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/windows/desktop/bb931352(v=vs.85).aspx

https://msdn.microsoft.com/en-us/library/ee309365(v=vs.85).aspx


https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-dirsync-deprecated

https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-dirsync-deprecated


PS C:> Enable-WSManCredSSP –Role Client –DelegateComputer adfs.fedws2012r2.litware369.com -Force

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/client/authlang : en-USBasic : trueDigest : trueKerberos : trueNegotiate : trueCertificate : trueCredSSP : true

PS C:>

To enable server-side CredSSP for WinRM, proceed with the following steps:1. Open a remote desktop connection on the ADFS1 computer that will be also your

sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.0.201" for the ADFS1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?” as password.


PS C:\> Enable-WSManCredSSP –Role Server -Force

cfg : http://schemas.microsoft.com/wbem/wsman/1/config/service/authlang : en-USBasic : falseKerberos : trueNegotiate : trueCertificate : falseCredSSP : trueCbtHardeningLevel : Relaxed

PS C:\ >


Executing Azure AD ConnectBefore executing Azure AD Connect, you must know the credentials:

1. A domain account that is local administrator on the aforementioned computers.2. Active Directory enterprise administrator credentials.3. Azure AD tenant global administrator 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:

1. Open a remote desktop connection on the DC1 computer that will be also your sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.0.101" for the DC1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?” as password.

2. Run AzureADConnect.msi to launch the wizard.

3. On the Welcome to Azure AD Connect page, check I agree to the license terms and privacy notice and click Continue.


4. On the Express Settings page, click Customize.

5. On the Install required components page, review the information, select any optional configuration that you require, although it’s okay to leave these unselected, and click Install.


6. On the User sign-in page, select Federation with AD FS.


7. Click Next.

8. On the Connect to Azure AD page, enter your global admin Azure AD credentials when prompted.Username: [email protected]: Pass@word1!?Click Next.


9. On the Connect your directories page, select your local active directory and enter AD credentials.Username: LIWARE369\AzureAdminPassword: Pass@word1!?Click Add Directory.

10. Click Next.


11. On the Azure AD sign-in configuration page, leave USER PRINCIPAL NAME as is, i.e. userPrincipalName selected, and click Next.

12. On the Domain and OU filtering page, leave Sync all domains and OUs selected, and click Next.


13. On the Uniquely identifying your users page, leave Users are represented only once across all directories selected, leave SOURCE ANCHOR as is, i.e. objectGUID selected, and click Next.

14. On the Filter users and devices page, leave Synchronize all users and devices selected, and then click Next.


15. On the Optional features page, select any additional features that you need, although it’s okay to leave these unselected, and then click Next.

16. On the AD FS Farm page, leave Configure a new Windows Server 2012 R2 AD FS Farm selected and click Browse to upload the SSL/TLS certificate .pfx file. Select the .pfx file to upload, for example Litware369.pfx in our illustration, and then click Open. A Certificate password dialog pops up.

17. Specify the related password and click OK.


18. Select the subject name to use in SUBJECT NAME.

If you are using a wildcard certificate, you will have to the prefix as follows:


19. Click Next.

20. On the AD FS Servers page, type "ADFS1" for the ADFS1 computer, and then click Add.


21. Type "ADFS2" for the ADFS2 computer, and then click Add.22. Type "adfs2.litware369.com", and then click Add.

23. Click Next.


24. On the Web application proxy servers page, type “WAP1” to add the WAP1 computer. Click Add.

25. Type “WAP2” to add the WAP2 computer, and then click Add.


26. Click Next.

27. On the Domain Administrator credentials page, enter AD credentials:Username: LIWARE369\AzureAdminPassword: ****************Click Next.


28. On the AD FS service account page, leave Create a group Managed Service Account selected. Enter AD credentials:Username: LIWARE369\AzureAdminPassword: ****************And then click Next.

29. On the Azure AD Domain page, select the Azure AD domain, i.e. litware369.com in our configuration that is to be federated.


30. Click Next.

31. On the Ready to configure page, leave checked Start the synchronization process as soon as the configuration completes for starting the synchronization process.

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.

32. Click Install. When installation completes, verify the installation and then exit.


Note Logs regarding the Azure AD Connect installation can be found in the %LocalAppData%\AADCONNECT folder.

33. Click Next.

34. Click Verify.


35. Click Exit.

Configuring additional tasksYou 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:

1. Whilst still being connected on the DC1 computer, launch the wizard again using the Start page or the desktop icon called Azure AD Connect.

2. Click Configure.


3. The Optional features page lists the tasks that are relevant to your configuration. Select the relevant task to your configuration you’d like to conduct, click Next, and follow the instructions.

4. Once completed, click Exit.Let’s see how to verify the synchronization on the Azure AD/Office 365 tenant.

Verifying the synchronization on the Azure AD/Office 365 tenantTo verify the synchronization on the Azure AD tenant, proceed with the following steps:

1. Open a browsing session and navigate to the Azure portal at https://portal.azure.com.

2. Sign in with your administrative credentials to your Azure subscription.3. On the left pane of the Azure management portal, click Azure Active Directory.

A Litware369 blade opens up.

Note If Azure Active Directory is not listed, click More Services, type "Azure", and the select Azure Active Directory.

4. In the Quick tasks tile, click Find a user. A Users and groups – All Users blade opens up.

5. Confirm that both Janet Schorr and Robert Hatley are listed.


https://portal.azure.com/

Verifying the single sign-on with the Azure AD/Office 365 tenantTo verify the single sign-on with the Azure AD/Office 365 tenant (e.g. litware369.onmicrosoft.com), proceed with the following steps:

1. Open a browsing session from your external local computer and navigate to the Office 365 portal at https://portal.office.com.

2. Type [email protected] and press ENTER. This triggers a home realm discovery (HRD) process for federated identities to see if the domain part of the username is federated.

Note If you turn on HTTP tracing on IE or observe the traffic via a tool like the Telerik Fiddler13 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 additional information.

13 Telerik Fiddler: http://www.telerik.com/fiddler


http://www.telerik.com/fiddler

mailto:[email protected]

https://portal.office.com/

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.


Troubleshooting the configurationTroubleshootingDepending upon how Internet Explorer is configured you will either be prompted to provide credentials or be automatically signed-in.Before verifying 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:

1. Open a remote desktop connection on the ADFS1 computer. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINES OF THE TEST LABENVIRONMENT and specify in step 2 "10.0.0.201" for the ADFS1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with “Pass@word1!?” as password.

2. Open a Windows PowerShell or PowerShell Integrated Scripting Environment (ISE) prompt.

3. Start Internet Explorer and select Internet Options on the Tools menu. An Internet Options dialog pops up.

4. Click the Security tab, select the Local intranet zone, and then click Sites. A Local intranet dialog appears.

5. In Add this website to the zone, type "https://adfs.litware369.com", and then

click Add. You should replace litware369.com by your own domain as already mentioned.

6. Click Close, and then click OK.


7. Verify that the security level for the zone is set to the default setting of Medium-

low which enables Windows integrated authentication for Intranet zones.8. Click OK to close the Internet Options dialog.9. Open a browsing session and navigate to the federation service metadata

endpoint, for example, in our configuration: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.

10. You can alternatively navigate to the metadata exchange endpoint, which offers an XML service description:

https://adfs.litware369.com/adfs/services/trust/mex


https://adfs.litware369.com/adfs/services/trust/mex

https://adfs.litware369.com/federationmetadata/2007-06/federationmetadata.xml

11. You can alternatively navigate to the AD FS sign-in page, for example in our configuration:

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.

12. Click Sign in to verify that the user is successfully and seamlessly authenticated thanks to the Windows Integrated Authentication. You shouldn’t see any Windows Security dialog if AD FS has been properly configured.


https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.aspx

13. Repeat steps 1 to 12 on the ADFS2 computer (10.0.0.202). Log on as the LITWARE369 domain administrator account AzureAdmin with “Pass@word1!?” as password.

14. Repeat steps 1 to 11. Log on as the local administrator account AzureAdmin with “Pass@word1!?” as password.

Verifying AD FS farm high availabilityTo verify 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.

TroubleshootingTo verify that you can successfully authenticate against the federation server on the Internet, proceed with the following steps:

1. Open a browsing session on your external local computer and navigate on Internet to https://adfs.litware369.com/adfs/ls/IdpInitiatedSignOn.aspx.

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.

2. Click SignIn to verify that you can successfully be authenticated.


https://adfs.litware369.com/adfs/ls/IdpInitiatedSignOn.aspx

3. Log on as the LIWARE369\JanetS with “Pass@word1!?” as password.

4. Click Sign Out.


Testing WAP farm high availabilityTo 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.You are now in a position to further test the environment.


Monitoring your on-premises deployment (Optional)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 Portal14 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 15.

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 16.

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:

1. Getting started with the Azure AD Connect Health service.2. Configuring Azure AD Connect Health for Sync.3. Configuring Azure AD Connect Health for AD FS.4. Configuring Azure AD Connect Health for AD DS.5. Using the Azure AD Connect Health service.

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.

Getting started with the Azure AD Connect Health serviceTo get started with and use the Azure AD Connect Health service, proceed with the following tasks:

1. Open a browsing session for your external personal computer and navigate to the Azure portal at https://portal.azure.com/.

2. Sign in when prompted with your Azure AD/Office 365 Enterprise global administrator account such as:Username: [email protected]: Pass@word1!?

14 Azure Preview Portal: https://portal.azure.com/15 MONITOR YOUR ON-PREMISES IDENTITY INFRASTRUCTURE AND SYNCHRONIZATION SERVICES IN THE CLOUD: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health16 AZURE ACTIVE DIRECTORY EDITIONS: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-editions



https://docs.microsoft.com/en-us/azure/active-directory/active-directory-editions

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-editions

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health



Click Next.3. Click the Marketplace tile, and then select Security + Identity, or search for it

by typing “Identity”.

4. Under recommended, click Azure AD Connect Health. An introductory blade opens up.

5. Click Create. This will open another blade with your directory information.


6. Click Create.

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? 17. 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 Portal18 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.

Configuring Azure AD Connect Health for SyncThe 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 § . 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:

1. Azure AD Connect Health Sync Insights Service.2. Azure AD Connect Health Sync Monitoring Service.

17 WHAT IS MICROSOFT AZURE ACTIVE DIRECTORY LICENSING?: https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-what-is18 Azure AD Connect Health Portal: https://aka.ms/aadconnecthealth


https://aka.ms/aadconnecthealth

https://portal.office.com/Signup/Signup.aspx?OfferId=01824d11-5ad8-447f-8523-666b0848b381&ali=1#0

https://portal.office.com/Signup/Signup.aspx?OfferId=01824d11-5ad8-447f-8523-666b0848b381&ali=1#0

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-what-is

https://docs.microsoft.com/en-us/azure/active-directory/active-directory-licensing-what-is

Note For more information, see article AZURE AD CONNECT HEALTH AGENT INSTALLATION 19.

Configuring Azure AD Connect Health for AD FSDownloading the health agent for AD FSTo download the latest version of health agent for AD FS, proceed with the following steps:

1. Open a remote desktop connection on the ADFS1 computer that will be also your sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.0.201" for the ADFS1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?" as password.

2. Open a browsing session and navigate to the Azure AD Connect Health portal.3. Click the Quick Start tile. An eponym Quick Start blade opens up.

4. Under Get tools, click Download Azure AD Connect Health for AD FS to download the health agent (AdHealthAdfsAgentSetup.exe).

5. Click Save. 6. Repeat all above steps on the ADFS2, WAP1 and WAP2 computers.

Enabling auditing for AD FSIn 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:


19 AZURE AD CONNECT HEALTH AGENT INSTALLATION: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-agent-install


https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-agent-install

2. Open Server Manager on the Start screen, or Server Manager in the taskbar on the Desktop.

3. In Server Manager, click Tools, and then select Local Security Policy. An eponym window Local Security Policy opens up.

4. Navigate to the Security Settings\Local Policies\User Rights Assignment folder, and then double-click Generate security audits.

5. On the Local Security Setting tab, verify that the AD FS service account NT SERVICE\adfssrv is listed. If it is not present, click Add User or Group and add it to the list, and then click OK.

6. Close Local Security Policy.7. Open a command prompt with elevated privileges and run the following command

to enable auditing:

PS C:\> auditpol.exe /set /subcategory:"Application Generated" /failure:enable /success:enable


8. In Server Manager, click Tools, and then select AD FS Management in order to open the AD FS Management snap-in.

9. In the Actions pane, click Edit Federation Service Properties.10. In the Federation Service Properties dialog box, click the Events tab.11. Select the Success audits and Failure audits check boxes.

Click OK.12. Close the AD FS Management snap-in.13. In Server Manager, click Tools, and then select Event Viewer. An eponym

window Event Viewer opens up.14. Navigate to Windows Logs and select Security.


15. On the right, click Filter Current Log... A Filter Current Log dialog opens up.16. Under Event Source, select AD FS Auditing.

17. Click OK and close the Event Viewer.18. Repeat all above steps on the ADFS2 computer.

You’re ready to install and configure the Azure AD Connect Health agents on the AD FS and WAP farms.

Installing and configuring the health agent for AD FSBefore 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:


2. Double-click the AdHealthAdfsAgentSetup.exe file that you’ve previously downloaded. The Azure Active Directory Connect Health Setup dialog shows up.

3. On the first screen, read the EULA, and then click Install.

4. Once the installation is finished, click Configure Now. A command prompt with elevated privileges opens up.

As stated, an elevated PowerShell command prompt is then launched to execute the following command while the initial command prompt closes:

Register-AzureADConnectHealthADFSAgent


5. A Sign in to your account dialog opens up.

6. Type "[email protected]" for your Azure AD/Office 365 Enterprise global administrator and click Continue.

7. Enter the password of the [email protected] user, e.g. "Pass@word1!?" in our configuration, and then click Sign in. The health agent registration process starts.


Executing Elevated PowerShell Command: Register-AzureADConnectHealthADFSAgent2017-01-05 11:44:19.753 ProductName: Azure AD Connect Health AD FS Agent, FileVersion: 2.6.491.0, Current UTC Time: 2017-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 fileC:\Users\AzureAdmin.LITWARE369\AppData\Local\Temp\2\AdHealthAdfsAgentConfiguration.2017-01-05_11-44-19.log containsmore 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> _

8. Upon successful completion, close the command prompt. 9. To verify the agent has been successfully installed and configured, click Tools in

Server Manager, and then select Services. An eponym window Services opens up.


10. Look for the following services: a. Azure AD Connect Health AD FS Diagnostic Agent.b. Azure AD Connect Health AD FS Insights Service.c. Azure AD Connect Health AD FS Monitoring Service.

These services should be started automatically and the agent will be now monitoring and gathering data.

11. Repeat all above steps on the ADFS2, WAP1 and WAP2 computers.


Configuring Azure AD Connect Health for AD DSDownloading the health agent for AD DSTo download the latest version of health agent for AD DS, proceed with the following steps:

1. Open a remote desktop connection on the DC1 computer that will be also your sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT and specify in step 2 "10.0.0.101" for the DC1 computer. Log on as the LITWARE369 domain administrator account AzureAdmin with "Pass@word1!?" as password.

2. Open a browsing session and navigate to the Azure AD Connect Health portal.3. Click the Quick Start tile. An eponym Quick Start blade opens up. 4. Under Get tools, click Download Azure AD Connect Health for AD DS to

download the health agent (AdHealthAddsAgentSetup.exe)




5. Click Save.6. Repeat above steps on the DC2 computer.

Installing and configuring the health agent for AD DSTo download the latest version of health agent for AD DS, proceed with the following steps:

1. Open a remote desktop connection on the DC1 computer that will be also your sync server. Follow the instructions as per section § ACCESSING THE VARIOUS MACHINESOF THE TEST LAB ENVIRONMENT account AzureAdmin with "Pass@word1!?" as password.

2. Double-click the AdHealthAddsAgentSetup.exe file you’ve downloaded in the previous section. A dialog pops up.

3. The Azure Active Directory Connect Health Setup dialog shows up.

4. On the first screen, read the EULA, and then click Install. The install begins.

5. Once the installation is finished, click Configure Now. A command prompt with elevated privileges opens up.

As stated, an elevated PowerShell command prompt is then launched to execute the following command while the initial command prompt closes:

Register-AzureADConnectHealthADDSAgent


6. A Sign in to your account dialog opens up.

7. Type "[email protected]" for your Azure AD/Office 365 Enterprise global administrator and click Continue.


8. Enter the password of the [email protected] user, e.g. “Pass@word1!?” in our configuration, and then click Sign in. The health agent registration process starts.

Executing Elevated PowerShell Command: Register-AzureADConnectHealthADDSAgent2017-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=DCc-4be2-9b86-5b3513ecb22e, OU=Microsoft ADFS Agent, Issuer=CN=Microsoft PolicyKeyService Certificate Ant=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.logPS C:\Users\AzureAdmin.LITWARE369\Downloads>

9. To verify the agent has been successfully installed and configured, click Tools in Server Manager, and then select Services. An eponym window Services opens up.

10. Look for the following services: a. Azure AD Connect Health AD DS Insights Service.b. Azure AD Connect Health AD DS Monitoring Service.

These services should be started automatically and the agent will be now monitoring and gathering data.

11. Repeat above steps on the DC2 computer.


At this stage, you should now be in position to monitor your on-premises deployment.

Using the Azure AD Connect Health serviceTo now use the Azure AD Connect Health service, proceed with the following tasks:

1. Open a browsing session and navigate to the Azure Preview Portal at https://portal.azure.com/.

2. Sign in when prompted with your Azure AD/Office 365 Enterprise global administrator account such as:Username: [email protected]





Password: Pass@word1!?3. Select Azure AD Connect Health. An introductory blade opens up.

4. Click Active Directory Federation Services. A new blade opens up with information about that services instance.

5. Click adfs.litware369.com. Another blade opens up.


6. You can start investigating the issues you may have if any like illustrated here with a missing QFE.


7. Close these blades to go back to the introductory blade of Azure AD Connect Health.

8. Click Azure Active Directory Connect (Sync). An eponym blade opens up. Synchronization should appear as healthy.

9. Back to introductory blade of Azure AD Connect Health, finally click Active Directory Domain services. A new blade opens up for AD DS as you might expect.

Note For more information on the various health topics (alerts, performance monitoring, usage analytics, properties, etc.), see articles AZURE AD CONNECT HEALTH OPERATIONS 22, USING AZURE AD CONNECT HEALTH FOR SYNC 23, USING AZURE AD CONNECT HEALTH WITH AD FS 24, and USING AZURE AD CONNECT HEALTH WITH AD DS 25.

This concludes the fourth part bis of the whitepaper.

22 AZURE AD CONNECT HEALTH OPERATIONS: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-operations23 USING AZURE AD CONNECT HEALTH FOR SYNC: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-sync24 USING AZURE AD CONNECT HEALTH WITH AD FS: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-adfs25 USING AZURE AD CONNECT HEALTH WITH AD DS: https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-adds


https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-adds

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-adds

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-adfs

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-sync

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-sync

https://docs.microsoft.com/en-us/azure/active-directory/connect-health/active-directory-aadconnect-health-operations


The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.This white paper is for informational purposes only. Microsoft makes no warranties, express or implied, in this document.Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in, or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.© 2017 Microsoft Corporation. All rights reserved.The example companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted herein are fictitious. No association with any real company, organization, product, domain name, e-mail address, logo, person, place, or event is intended or should be inferred. Microsoft, list Microsoft trademarks used in your white paper alphabetically are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

azure ad/office 365 seamless sign-in · web viewazure ad/office 365 seamless sign-in - part 4bis...

Documents