다음을 통해 공유

Quick Start Guide for Integrating a Single Forest On-Premises Active Directory with Azure AD

  • 아티클

Update 8/5/2014 - Microsoft has just released the Microsoft Azure Active Directory Connect (Preview) which will help you configure DirSync and/or Federation in a wizard format.

This will be the official, engineering supported mechanism to do configurations moving forward. http://blogs.technet.com/b/ad/archive/2014/08/04/connecting-ad-and-azure-ad-only-4-clicks-with-azure-ad-connect.aspx

 

↑ Back to top

Short URL

Bookmark this page as:  http://aka.ms/AD2AAD.

 

↑ Back to top

Download

The script is available at: http://aka.ms/AD2AAD-PS

 

↑ Back to top

Overview

You can continue to read the article and Wiki if you'd like to understand the technical steps which need to go on in a Windows Server 2012 (not R2) environment to accomplish an end-to-end DirSync + ADFS federation to your on-premises AD.

Azure Active Directory (Azure AD) is the fundamental authentication service for Microsoft Online Services such as Office 365 and Windows Intune. It supports both cloud authentication and single sign-on with on-premises Active Directory through Active Directory Federation Services (AD FS). Single sign-on requires some additional hardware configuration but leads to substantial end-user satisfaction by removing another username and password for the user to remember and maintain.

The purpose of this quick start guide is to provide a general overview and additional requirements and configuration changes necessary to enable an on-premise environment to connect to Windows Azure-based applications and services. More complicated scenarios are covered in detail in widely available documentation. Rather, this guide, it is hoped, will provide enough support and guidance so that you can configure a simple environment to meet the basic requirements for enabling connectivity to Windows Azure applications and exploring their capabilities and advantages in greater detail.

This document supports a preliminary release of a software product that may be changed substantially prior to final commercial release. This document is provided for informational purposes only and Microsoft makes no warranties, either express or implied, in this document. Information in this document, including URL and other Internet Web site references, is subject to change without notice. The entire risk of the use or the results from the use of this document remains with the user. Unless otherwise noted, the companies, organizations, products, domain names, e-mail addresses, logos, people, places, and events depicted in examples 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. 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.

 

↑ Back to top

Introduction

Objectives

After completing this Quick Start Guide, you will have federated your on-premises Active Directory environment with Windows Azure Active Directory (Windows Azure AD) in a pre-production configuration. This will provide single sign-on capabilities to users of Windows Azure AD clients such as Office 365 and Windows Intune. The guidance will walk you through using the accompanying script to perform the various tasks to do the necessary work.

If you are starting with an existing cloud service that uses Windows Azure AD such as an Office 365 account, you can later use the same account to add Windows Intune access, or vice-versa. It is strongly recommended that all of your Windows Azure AD services share the same sign-in configuration by starting with one service, and then adding the other services to the same administrative account. This will substantially improve the end-user and administrative experience.

Audience

The audience for this document is an IT professional, tester, or presenter who has experience administering Windows Server 2008 R2 and Windows 7 client systems, as well as familiarity with Windows Server 2012 and Windows 8. This document assumes some familiarity with Active Directory, Hyper-V, Domain Name Services (DNS), Public Key Infrastructure (PKI), and TCP/IP networking. Specific knowledge of Active Directory Federation Services (AD FS) is not required.

You should know, in particular, how to:

  • Configure Active Directory User Principal Names (UPNs)
  • Configure DNS zones and DNS records
  • Configure firewall and network address translation (NAT) rules
  • Configure external DNS records
  • Initially create a cloud service (like Office 365 or Windows Intune) that utilizes Windows Azure AD

Prerequisites

The following is a list of mandatory prerequisites for completion of the tasks in this guide. If you cannot meet these requirements, you will not be able to use this guide to synchronize the on-premise environment with Windows Azure AD.

  • Internet access. You need both inbound and outbound Internet access to and from the internal corporate network. This includes DNS queries from internal servers against external DNS servers. You will also need Internet access to download software installers.

  • Active Directory. You need a working on-premises Active Directory environment. This document assumes that you will be starting with an on-premises Active Directory environment of a single-tree domain in a single forest (i.e. joined namespace of corp.contoso.com and contoso.com). Multiple-tree domain forest (i.e. disjointed namespace of contoso.com and fabrikam.com) and multiple forest environments are out of scope.

    WARNING
    Some portions of the script assume only a single domain in use; in particular generation of the self-signed certificate assumes only a single UPN in use.

     

  • Administrative access. You must have full administrative access including Enterprise Administrator to the domain and forest.

  • Three servers and one client. There are a total of four machines needed for building the environment. These machines can be physical or virtual.

  • A domain controller for the source domain running Windows Server 2008 or later. IE Enhanced Security Configuration should be disabled for users and administrators to prevent download failures when the script tries to download support and integration tools.

  • A domain-joined member server for the source domain running Windows Server 2012. After completing the steps in this guide, this server will run the AD FS role and DirSync. IE Enhanced Security Configuration should be disabled for users and administrators on this server as well, for the same reason.

  • A server running Windows Server 2012 in a workgroup. After completing the steps in this guide, this server will run the AD FS Proxy role. IE Enhanced Security Configuration should be disabled for users and administrators. This machine will be published to the Internet; thus, if a DMZ is in use, this machine should be in the DMZ. It should not be a domain member.

  • A client machine running Windows 7 or later (either x86 or x64) that has access inside the domain and outside the domain. The client is used to test that the configuration is working.

  • Microsoft cloud service tenant. A tenant on a Microsoft cloud service that uses your Windows Azure AD tenant, such as an Office 365 E plan or Windows Intune. Both trial and production subscriptions are acceptable. An administrator account will be necessary to sign in to the environment and will be used as part of the configuration steps. Your tenant should be created (i.e. sign up for a trial and sign in) before starting, but no other tenant configuration is required.

  • Internal DNS configuration for the desired UPN domain. The internal DNS configuration must include the UPN domain name as an internal zone. This zone must support dynamic updates; it is acceptable to only allow secure dynamic updates.

  • Public DNS configuration access for the desired UPN domain. The UPN to be used must be a public domain name with a user-configurable public-facing DNS zone where you have the ability to add TXT records.

     

    Note

Although Windows Azure AD supports MX records for the verification process, that is typically more complicated and error prone and can negatively impact production e-mail flow if done incorrectly. Therefore, this guide and the supplied script do not support that scenario.

  • External firewall publishing access to the AD FS proxy server. You will need to be able to publish port 443 to the AD FS proxy server so external clients can authenticate.

What This Guide Does Not Provide

There are specific scenarios and limitations you should be aware of before you begin. This guide does not provide guidance for the following:

  • Setting up an Exchange hybrid deployment (Office 365 only). An Exchange hybrid deployment implementation is outside of the scope of this document. If you are looking at an Office 365 deployment and have Exchange 2010 SP1 or later on-premises, please review the details of a hybrid environment at http://technet.microsoft.com/en-us/library/hh852414.aspx before continuing.
  • Synchronizing domains with more than 50,000 users. This document primarily covers source Active Directory domains of under 50,000 users. For environments above 50,000 users, there are special procedures that must be followed. For more information on this, please refer to How to request a Directory Service quota increase in Office 365 at http://support.microsoft.com/kb/2459803 and Computer Requirements at http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652544.aspx.
  • Configuring high availability. There is no redundancy in the Active Directory Federation Services (AD FS) environment created using this guide; therefore, there are single points of failure around that service. A large-scale production implementation should include appropriate high availability around all components as is documented elsewhere (i.e. http://technet.microsoft.com/en-us/library/jj151794.aspx). After you have configured your environment using this guide, it is possible to extend the environment to be highly available.
  • Purchasing your own SSL certificate. This document is designed to be a rapid implementation guide, so it does not require purchase of an external SSL certificate for AD FS access. A production environment would use a purchased certificate from a trusted public certificate authority (CA). This guide allows you to perform basic validation of a production certificate for AD FS configuration, but does not provide guidance on how to obtain the appropriate certificate. If you don’t want to use a production certificate, a self-signed certificate is automatically created and used. The self-signed certificate is not an appropriate production configuration but is sufficient for validation of the service and functionality.
  • Configuration of multiple top-level UPNs. This guide will support a single UPN domain suffix that matches the desired sign-in address for Windows Azure AD applications. Sub-domains with a joint-namespace under a top-level domain are supported in this guide (i.e. corp.contoso.com and contoso.com) assuming you use this guide to configure federation of the top-level domain. Furthermore, clients who have manually assigned UPNs that are not a part of a forest are not in scope for this guide.

 

It is possible to use an environment with multiple, top-level UPN suffixes to complete all steps, but it is outside of the scope of this guide. For more information on multiple domain suffixes to federate, please see: http://community.office365.com/en-us/wikis/sso/support-for-multiple-top-level-domains.aspx.

Machine Configuration

The script package consists of a single Windows PowerShell script (Menu.ps1) found at: http://aka.ms/AD2AAD-PS. Create a folder on the soon-to-be AD FS server and place the file into that folder. You will later copy the contents of this folder to the AD FS proxy server, but other files will need to be placed in there by the AD FS server process first.

 

Note

All testing was done on servers running the United States English locale/language.

 

Note

Each section of each process indicates the target machine and credentials for the section. You must follow the given direction or steps will fail.

 

 

↑ Back to top

Step 1: Initial Software Installation

In this section, you will install basic pre-requisite software on the AD FS server.

Perform all steps in this section on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Install the Microsoft Online Services Sign-In Assistant

  1. Run the Menu.ps1 Windows PowerShell script as an administrator.
  2. When prompted, select choice 1 to Install Microsoft Online Services Sign-In Assistant.
  3. The installation should download and complete quickly. Review the output from Windows PowerShell to ensure it shows a successful completion.

Install the Microsoft Online Services Module for Windows PowerShell

  1.  Select menu choice 2 from the Menu.ps1 script to Install Microsoft Online Services Module for Windows PowerShell.
  2. The installation should download and install. Review the output from Windows PowerShell to ensure it shows a successful completion.

 

Note

You can ignore a warning about automatic updating if you receive one.

 

Validate Readiness

If you are configuring Windows Azure Active Directory for Office 365 use, then you should validate your environment before using DirSync. Users of other services (for example, Windows Intune) may also use the tool, but it may report issues that do not matter for your implementation.

  1. Select choice 3 from the Menu.ps1 script to Download and run the Office 365 Deployment Readiness tool.
  2. Wait for the tool to finish; it will take a few minutes. You can watch the progress in Internet Explorer.
  3. Once the tool finishes, you will get a report. Review the report and ensure that you understand any warnings or errors. Some may be safely ignored, while others may require action. It is outside the scope of this document to describe every possible error or warning, but the tool gives guidance on how to resolve any issues found.

 

Note

Remember that if you are not using Office 365, some of the reported issues will not apply.

 

↑ Back to top

Step 2: Add and Verify the Domain Name in Windows Azure AD

In this section, you will add your domain name to Windows Azure AD.

Perform all steps in this section on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Add the Local Domain to Windows Azure AD

  1. Select menu choice 4 from the Menu.ps1 script to Add local UPN suffix as domain in Windows Azure Active Directory.

  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example, admin@domain.onmicrosoft.com) and password.

     

    Note

You can ignore a warning about automatic updating if you receive one.

 

  1. Select the UPN suffix you would like to add. Note that the tool only lists domains which have not yet been added to Windows Azure AD. If only one UPN suffix is active in the on-premises domain, the script will assume that is the one you wish to add.

    Note

If you have a multiple domain forest with a single tree, you would want to first add the top-level domain (for example, contoso.com) and then add the child domain names (for example, corp.contoso.com).

  1. The script will add the domain to Windows Azure AD. Once it is done, it will display the domain verification information for the domain. Record this as you will use it in the next step.

Add the Domain Verification Record to External DNS

  1. If you did not record the verification information for any new domains:
    1. a. Select menu choice 5 from the Menu.ps1 script to Retrieve verification information for domains in Windows Azure Active Directory.
    2. b. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example, admin@domain.onmicrosoft.com) and password.
  2. For the added UPN suffix domain, add a text record for the domain that matches the verification information to external, public DNS. For more information on this process, including detailed steps for several popular domain name registrars, please refer to http://technet.microsoft.com/en-us/library/jj151788.aspx.

 

↑ Back to top

Step 3: Enable Directory Synchronization (DirSync)

In this section, you will enable directory synchronization (DirSync) support in Windows Azure AD. This process can take up to 24 hours, although it rarely takes longer than an hour. You will enable the setting here, but not use it until later; this will give Windows Azure AD time to complete processing the request while you continue with further steps.

 

Perform all steps in this section on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Enable Directory Synchronization (DirSync) Support

  1. Select choice 6 from the Menu.ps1 script to Enable directory synchronization (DirSync) support on the tenant.
  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example, admin@domain.onmicrosoft.com) and password.
  3. Confirm when prompted.
  4. NOTE: The current cmdlets do not offer a way to avoid this confirmation prompt.
  5. Once the request has been made, continue with the configuration process. Although enabling DirSync can take up to 24 hours, there are other process that can be done while waiting, so it makes sense to work on the next processes. You will verify that synchronization is working later when it's necessary.

 

 

WARNING
If you previously had DirSync enabled and disabled it, this process might not work due to an apparent bug in the Windows PowerShell provider. If you see this behavior, use the administration portal for your service to enable DirSync. Details of that process are outside the scope of this document.

 

↑ Back to top

Step 4: Configure an On-Premises AD FS Server

In this section you will create a basic on-premises Active Directory Federation Services (AD FS) server configuration. AD FS is used to support single-sign-on (SSO) with Windows Azure AD clients. Although a detailed explanation of this process is outside of the scope of this document, the important thing to know as an IT professional is that at no point in the process are user credentials for the on-premises environment accessible to the Windows Azure AD client. Instead, authentication tokens with a limited lifetime are used to represent the authenticated user. This is done using industry-standard processes and protocols and ensures the integrity of on-premises credentials while still supporting single-sign-on.

More detail on the SSO process can be found at http://community.office365.com/en-us/wikis/sso/727.aspx, How Single Sign-On Works in Office 365. Although this is an entry in the Office 365 wiki, the details of the process are not specific to Office 365 and apply to all Windows Azure AD clients.

Perform all steps in this section on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Enable the AD FS Role

  1. Select choice 7 from the Menu.ps1 script to Add the ADFS role on the server.
  2. Wait for the role installation to complete.

 

Note

You can ignore any warnings about automatic updating and about finishing configuration of the server.

 

Create an AD FS Service Account in a Domain

The AD FS installation process will create a simple AD FS farm. AD FS farms require the use of a service account.

  1. Select choice 8 from the Menu.ps1 script to Create a service account in the local domain for ADFS use.
  2. You will be prompted for the domain name (FQDN or NetBIOS will work), SAM account name, and password (with confirmation) for the new on-premises service account. The new account will be created with the Password never expires flag set.

 

Note

If you type the wrong domain name, then make sure to go back and input a new account, choosing [N]o to overwrite the existing credentials.

You can move the account from the default container in Active Directory later, if desired, with no ill effects.

 

Create the AD FS DNS Alias

 

Note

you only need to do this if the member server's name is not already adfs.domain.

 

  1. Select choice 9 from the Menu.ps1 script to Create an internal DNS entry for ADFS.
  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example, admin@domain.onmicrosoft.com) and password.
  3. NOTE: You can ignore a warning about automatic updating if you receive one.
  4. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. For instance, if you would like to use user@contoso.com for your Windows Azure AD logins, then select contoso.com from the list. You will not be prompted if only one custom domain exists in Windows Azure AD.

Create or Validate the AD FS Server Certificate

The script does have limited support for using your own certificate. If you would like to do so, install it on the AD FS server in the Local Computer\Personal\Certificates store, and make sure it meets the following requirements:

  • The friendly name of the certificate must be AD to AAD QuickStart ADFS Certificate, as that name is hard-coded into the script.
  • The certificate’s private key must be marked exportable so the same certificate can be used on the AD FS server and the AD FS proxy server.
  • The certificate’s subject must be “CN=adfs.domain”.

The script will validate the certificate if it exists.

  1. Select choice 10 from the Menu.ps1 script to create a new, self-signed SSL certificate or validate your own certificate.

  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.

  3. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.

  4.  

    Note

You are using a self-signed certificate here for demonstration purposes. However, in a production environment, you would generally use a certificate issued by a public certificate authority (CA) such as VeriSign, although if only internal domain-joined clients will be used to access services, then a private Enterprise CA would be acceptable. In either case, you need to make sure the common name (subject) of the certificate matches the AD FS alias and external name (those will be the same), and the certificate must be exportable to support multiple machines using the same certificate.

 

> [!NOTE]

You will be configuring the AD FS proxy server and a test client to trust this certificate later in the document.

 

  1. If you have already created a certificate, or imported one, you will be prompted to validate the certificate. Choose to validate the certificate.

  2. If a certificate is not found on the local machine, you will be prompted to create one. If you have not created one yet, choose to create one. If you expected the script to find one, check the friendly name on the certificate to make sure it matches AD to AAD QuickStart ADFS Certificate.

Export the Certificate for Future Use

The self-signed certificate must be available for multiple uses on other machines, so in this step you will create an export of the new certificate.

  1. Select choice 11 from the Menu.ps1 script to export the certificate. The certificate will be exported to two files in the same folder as the script: a PFX file with the private key, and a CER file without the private key. The certificate private key password on the PFX file will be secret.

Configure AD FS to Use the Service Account and Certificate

  1. Select choice 12 from the Menu.ps1 script to Configure ADFS with basic configuration.

  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.

  3. You will be prompted for service account credentials. If you have entered them in the same script session, you will be asked if you’d like to use the already-entered credentials instead of having to re-enter them. AD FS will then be configured.

  4.  

    WARNING
    This will remove any existing AD FS configuration on the system.

     

  5. Wait for the process to complete. It will take some time; the steps will be reported as they occur. When done, you will have a complete local single-server AD FS farm installation.

 

Note

For ease of configuration and implementation the AD FS server is left with its default of Windows Integrated Authentication, but has NTLM prioritized over Negotiate in the provider list. This is not a default configuration but avoids potential Kerberos issues. In production, you would likely leave the default to keep the enhanced security offered by Kerberos.

 

Confirm/Configure Windows Firewall

  1. Select choice 13 from the Menu.ps1 script to Confirm/configure Windows Firewall for port 443.

 

Add the AD FS Server to the Local Intranet Zone

 

Note

You will want to do this on any machine that will be using the federated service internally. You can also do these steps through Group Policy if desired; more information can be found at http://technet.microsoft.com/en-us/library/jj203438.aspx.

 

  1. Start Internet Explorer.
  2. On the Tools menu, select Internet Options.
  3. Click the Security tab.
  4. Select the Local intranet zone, and then click Sites.
  5. If using Internet Explorer 9 or 10, click the Advanced button.
  6. In Add this website to the zone, type the URL for your AD FS server, https://adfs.domain.
  7. Click Add, click Close, and then click OK.
  8. Verify that the security level for the zone is set to the default setting of Medium-low which enables integrated Windows authentication for Intranet zones. Click OK to close the Internet Options dialog box.

Confirm AD FS is Working Correctly

  1. Select choice 14 from the Menu.ps1 script to Launch test web pages.
  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.
  3. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.
  4. Three Internet Explorer windows/tabs will launch:
  5. a. https://adfs.domain/adfs/services/trust/mex, which will show an XML service description.
  6. b. https://adfs.domain/FederationMetadata/2007-06/FederationMetadata.xml, which will show a text service description (this is not expected to be human-readable text).
  7. c. https://adfs.domain/adfs/ls/IdpInitiatedSignon.aspx, which will show a sign-in page. You should be able to sign in without being asked for credentials.

 

↑ Back to top

Step 5: Configure the AD FS Proxy

Perform all of the steps in this section except firewall, external DNS changes, and client testing on the AD FS proxy server logged in as a local administrator.

Import and Trust the AD FS Certificate

  1. Copy the entire folder with the Menu.ps1 script (including the exported certificate files) to the AD FS proxy server.
  2. Select choice 15 from the Menu.ps1 script to Import certificates for ADFS proxy.

Install the AD FS Proxy Role

1. Select choice 16 from the Menu.ps1 script to Add the ADFS Proxy role to this server.

 

Note

You can ignore any warnings about automatic updating and about finishing configuration of the server.

 

Configure IIS to Use the Appropriate Certificate and Authentication

1. Select choice 17 from the Menu.ps1 script to Configure IIS SSL and authentication using the certificate you imported.

 

Note

Towards the end of the process, you may receive one or two error messages about a configuration value missing from the server. The output will indicate when this is an acceptable condition.

 

Add the Local HOSTS File Entry

You will be updating the local HOSTS file to direct the proxy server to the internal AD FS server. This allows multiple DNS configurations to work as well as helps with supporting a workgroup member proxy server.

  1. Select choice 18 from the Menu.ps1 script to Add a HOSTS file entry for ADFS access from the proxy.

  2.  

    Note

You can ignore any warnings about automatic updating.

 

  1. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.

  2. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant; you can go back to menu choice 3 on the AD FS Server if you forgot what UPN suffix you are using. You will not be prompted if only one custom domain exists in Windows Azure AD.

  3. When prompted, type the IP address of the AD FS server as accessed by the AD FS proxy server.

 

Note

If there is NAT between the AD FS proxy server and the AD FS server, make sure you enter the IP address that would be used by the AD FS proxy, not the actual IP address of the AD FS server.

 

 

Note

You can go through choice 19 again if you need to change this IP address.

 

Note

You must be able to access port 443 on the AD FS server from the AD FS proxy server. This is the only port used for direct communication between the servers.

 

Note

The current HOSTS file will be saved as HOSTS.backup.

Configure the AD FS Proxy Role

  1. Select choice 19 from the Menu.ps1 script to configure the AD FS Proxy service.
  2. You will be prompted for service account credentials. If for some reason you already have entered those credentials in the same script session, you can re-use them.
  3. If you are prompted for credentials to connect to the Windows Azure AD tenant, enter your administrator username (for example, admin@domain.onmicrosoft.com) and password.
  4. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.

Confirm/Configure Windows Firewall

  1. Select choice 20 from the Menu.ps1 script to Confirm/configure Windows Firewall for port 443.

Confirm the AD FS Proxy is Working Correctly

  1. Select choice 21 from the Menu.ps1 script to Launch test web pages.
  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.
  3. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.
  4. Three Internet Explorer windows will launch:
  5. a. https://adfs.domain/adfs/services/trust/mex, which will show an XML service description.
  6. b. https://adfs.domain/FederationMetadata/2007-06/FederationMetadata.xml, which will show a text service description (this is not expected to be human-readable text).
  7. c. https://adfs.domain/adfs/ls/IdpInitiatedSignon.aspx, which will show a sign-in page. You should be able to sign in at this time to the server directly from the server. Make sure you include the domain name in the user name when prompted.

Configure External Connectivity to the AD FS Proxy

On the external (edge) firewall, publish SSL port 443 on the AD FS proxy server on an external interface.

 

Note

These steps must be done manually. There are too many variations possible in external access and DNS configuration to support automating these steps.

If you are using Microsoft Internet Security and Acceleration (ISA) Server 2004 or 2006 or Microsoft Threat Management Gateway (TMG) 2010 as your edge firewall, you can find information on publishing the AD FS Proxy at http://blog.c7solutions.com/2011/06/publishing-adfs-through-isa-or-tmg.html.

 

External DNS Configuration

On the external DNS provider, add the AD FS published address to the outside. Use the hostname adfs in the UPN suffix domain.

 

Note

These steps must be done manually. There are too many variations possible in external access and DNS configuration to support automating these steps.

 

Help pages for common DNS providers for adding an A record (DNS address) include:

 

Note

You may need to wait for the DNS record you add to propagate. Be sure that you can resolve adfs.domain externally before continuing.

 

External Basic AD FS Testing

Perform these steps on a client connected to an external network.

  1. Browse to https://adfs.domain/FederationMetadata/2007-06/FederationMetadata.xml. You will receive certificate warnings because a self-signed certificate is being used.
  2. Confirm you receive results similar to when you connected to this site internally.
  3. Browse to https://adfs.domain/adfs/ls/IdpInitiatedSignon.aspx.
  4. When the page appears, choose Continue to Sign In.
  5. Sign in with valid network credentials.
  6. NOTE: You will need to enter credentials on a sign-in form. This is the default and recommended configuration for an AD FS Proxy. This is different from the internal AD FS server, which is configured to support Integrated Windows Authentication by default.
  7. Confirm that the sign in worked.

 

↑ Back to top

Step 6: Configure Windows Azure AD Federation Support

You will next change the Windows Azure AD domain to use federation for SSO support. By default, Windows Azure AD manages accounts and sign ins independent from on-premises accounts. To use SSO, you need to configure the use of federation on the domain, and then configure Directory Synchronization (DirSync). You are starting with federation, and then finalizing DirSync, as that is the recommended order. Remember that earlier in the process, you started with requesting DirSync to be enabled on the Windows Azure AD side.

Perform all of these steps in this section except client testing on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Configure Windows Azure AD Connection to AD FS

  1. Wait for the DNS verification record you added previously to propagate. In most cases, this will be a short time (a few minutes), but this depends on the DNS server configuration for your local DNS server among other variables. Use this time to review the next steps in the document.
  2. If the AD FS server is able to look up DNS records on an external DNS host (not just on an internal server):
  3. a. Select menu choice 22 from the Menu.ps1 script to Check DNS records for TXT entries for unverified domains.
  4. b. When prompted, press ENTER to use the default external DNS server of 209.244.0.3, or type a different external DNS server’s IP address.
  5. c. If you are prompted for credentials to connect to the Microsoft Online Services tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.
  6. d. Confirm you receive two Success messages – one for locating a single record and one for matching the expected record. If you do not, use the reported errors as a guide to correct the issue.
  7. Select choice 23 from the Menu.ps1 script to Configure Windows Azure AD connection to ADFS.
  8. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.
  9. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.

Create an AD FS/SSO Test User

  1. Select choice 24 from the Menu.ps1 script to Create a single sign-on test user.

  2. Type the new user's credentials and other details when prompted.

     

    Note

You are not prompted for the domain for the account; the account will be in the current logged-in domain.

 

  1. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.

  2. If prompted, select the domain name to use for AD FS externally. This should match the UPN suffix active in the tenant. You will not be prompted if only one custom domain exists in Windows Azure AD.

  3. Wait for the user to be created locally and in Microsoft Online.

 

Note

If you choose to replicate these steps manually, it’s important to know that you cannot simply create a pair of accounts (one on-premises and one in Windows Azure AD). There are rules around matching accounts when AD FS is used that require a specific configuration, namely that the ObjectGUID for the on-premises account must match the ImmutableId (as a Base64 string) for the Windows Azure AD account. The script does this automatically for the new user. New-MsolUser allows you to supply the ImmutableId on account creation, while Set-MsolUserPrincipalName allows you to change it after creation time.

 

Confirm the Test User Can Sign In Through AD FS

Perform these steps on a client connected to an external network.

  1. On an external machine, browse to the appropriate portal for your service (for example https://portal.microsoftonline.com/ for Office 365). You may receive a certificate error as the machine does not trust the self-signed certificate offered by the AD FS server; this is expected.
  2. If you are presented with a different user pre-populated, choose Sign in with a different user:
  3. For User ID, type the UPN of the test user.
  4. Select Password. The screen should indicate that you are now required to sign in at the on-premises site.
  5. Choose the link to Sign in at domain:
  6. The default configuration for an AD FS Proxy is to use Forms-Based Authentication. Thus you should get a simple form:
  7. Type the test user name in the form of a UPN or DOMAIN\USERNAME. Either should work.
  8. Type the test user’s password.
  9. Choose Sign In. You should be authenticated to the service successfully. You may receive an error screen indicating you do not have a license assigned (for example, Office 365 will show such a page). This is expected for the test user as in fact you have not assigned a license to the test user.

 

↑ Back to top

Step 7: Install and Configure DirSync

Next, you will configure and activate Directory Synchronization (DirSync). DirSync is a custom, specialized implementation of Microsoft Forefront Identity Manager that is configured to synchronize accounts between your on-premises domain and a corresponding Windows Azure AD domain.

 

Perform all steps in this section on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

Download and Install DirSync

  1. Select choice 25 from the Menu.ps1 script to Download and install the DirSync tool. This will take some time; the download is approximately 100 MB, and when installing, it will install a local SQL Server 2008 Express instance to support the synchronization. The installation for the most part will be invisible as it runs.
  2. When it is complete, the script will prompt you to exit. Press ENTER.
  3. Sign out of Windows. You must do this to get your updated group membership to apply.
  4. Sign in again as the same user.

 

Configure DirSync

 

Note

If you are in an environment running Exchange 2010 SP1 or later, and would like to configure a hybrid Office 365 deployment, you will need to configure DirSync manually, Run the wizard manually from the desktop to do so.

 

  1. Select choice 26 from the Menu.ps1 script to Configure the DirSync tool.

  2. If you are prompted for credentials to connect to the Windows Azure AD tenant, type your administrator username (for example admin@domain.onmicrosoft.com) and password.

  3. When prompted, type your permanent Windows Azure AD synchronization credentials.

  4.  

    Note

This account will be used as the ongoing synchronization account, so if you don't want to use the Online Services administrator account you've been using, this is a good time to go to your portal (for example https://portal.microsoftonline.com/) to create a user specifically for this purpose. Make sure the user is not configured in the synchronized domain (the domain.onmicrosoft.com domain is a good choice), and make sure it is set to not have its password expire.

 

  1. When prompted, type your local Active Directory administration credentials.

  2. NOTE: This account will not be used long-term; the wizard will create its own service account for ongoing use.

  3. The configuration will complete. The script will then request an immediate synchronization.

Wait for Completion by Watching the Event Log

  1. Select choice 27 from the Menu.ps1 script to Get the latest Directory Synchronization events (event in the past thirty minutes). You should see the following events in order, typically at the bottom of the list:

InstanceID

Text

0

Starting synchronization now.

1

 Confirming Import has started.

20

Running Full Import

2

 Confirming Import has completed.

3

 Export has started.

5

The cumulative number of objects…

4

 Export has completed.

 

Verify and Activate Newly Synchronized Users

  1. Sign in to the appropriate portal (for example https://portal.microsoftonline.com/).
  2. In the left-side navigation area, under Management, click Users or Users and Groups.
  3. In the View drop-down, select the option that represents currently inactive users (for example Unlicensed users for Office 365 or Not Windows Intune users for Windows Intune).
  4. Confirm the User name shows the appropriate single-sign on UPN for each user. If not, refer to the appendix on correcting a user's UPN; it is strongly recommended that you do this before activating the user.
  5. Select all users that you would like to activate.
  6. Click the Activate synced users link.
  7. Complete the activation wizard as appropriate for the service you are using. Generally, this will include selecting one or more license check boxes and the choosing the users’ location.
  8. Wait for a few minutes     before continuing to test to ensure the users are properly provisioned.

 

↑ Back to top

Step 8: Test on a Client

Perform all steps in this section on the client machine.

Basic Test

  1. Browse to the appropriate portal (for example https://portal.microsoftonline.com/). You will receive a certificate error because the self-signed AD FS certificate is not yet trusted by the client.
  2. Attempt to sign in as one of the synchronized users that you activated previously.
  3. Confirm a synchronized user is able to sign in. You should see the same process as when using the test user, including a prompt to use AD FS, an AD FS sign-in form, and then a redirect back to the portal as a signed-in user.

Optional: Install Self-Signed Certificate Issuer as Trusted

 

Note

This is optional. If you are going to use a "real" certificate from a public certificate authority, or you are going to use an Enterprise Certificate Authority and a domain-joined machine, then you will not need to do this step.

These steps are for a Windows 8 client. They will be different for other operating system, but the concepts will be the same.

 

  1. Using a convenient transfer method (file share, USB flash key), copy the ADFSSelfSigned.cer file from the AD FS server to the client.

     

    Note

Be sure to copy the .CER file and not the .PFX file. In Windows 7 and later it will be called a Security Certificate file and will look like this:

 

<table data-cellspacing="0" data-cellpadding="0" style="width:100%;border-collapse:collapse;">
<tbody>
<tr class="header">
<th style="text-align: left; padding-top: 5px; padding-bottom: 5px; padding-left: 5px; background-color: darkgray;"><img src="resources/5811.Caution.gif" /> <strong>WARNING</strong></th>
</tr>
&#10;<tr class="odd">
<td style="text-align: left; padding-left: 5px; background-color: whitesmoke;">Depending on operating system and UAC configuration, installing directly from a file share may be problematic. A local copy of the file is strongly recommended. This copy may be removed after the import is complete.</td>
</tr>
</tbody>
</table>

 

  1. Double-click the file to run it.

  2. In the Certificate properties window, click Install Certificate to begin the Certificate Import Wizard.

  3. Click Local Machine, and then click Next.

  4. If prompted by UAC, type local machine administrative credentials.

  5. Select Place all certificates in the following store, click Browse, and then click Enterprise Trust. Click OK, and then click Next.

  6. Click Finish to close the wizard.

  7. Click OK when a The import was successful message is displayed.

  8. Install the certificate again, this time into the Local Machine, Trusted Root Certification Authorities store.

     

    Note

The reason we are installing the root twice is to avoid a security feature of the Windows operating system. Recent versions of Windows automatically remove unknown third-party certificate authority entries from the Trusted Root Certification Authorities store as a housekeeping task. Indicating the issuer is a local corporate issuer (by installing in the Enterprise Trust store)

 

  1. indicates to Windows that it should not remove the third-party Trusted Root Certification Authorities store certificate.

  2. Click OK to close the Certificate properties dialog, and then launch the certificate again. This time, you should not see any warnings about an untrusted root.

  3. Navigate to the portal again in a clean browser session; you should not receive a certificate error.

 

 

↑ Back to top

Appendix 1: Force an Immediate Synchronization

In this appendix, you will see how to immediately synchronize your on-premise AD to Windows Azure AD. You will do this using a Windows PowerShell cmdlet to synchronize the change to the Windows Azure AD environment.

Perform these steps on the AD FS server logged in as a Domain Administrator in the on-premises domain and an Enterprise Administrator in the on-premises forest.

  1. Start an elevated (Admin) Command Prompt.
  2. Type cd /d %ProgramFiles%\Microsoft Online Directory Sync.
  3. Type .\DirSyncConfigShell.psc1.
  4. Wait for the Windows PowerShell session to launch. This should not take long.
  5. Type Start-OnlineCoexistenceSync.
  6. Using the Application event log, watch for the synchronization to complete. In most cases this won’t take more than a minute or two. Refer back to Wait for Completion by Watching the Event Log to see an idea of what events to expect from the Directory Synchronization source (or use the choice in Menu.ps1 to review the log entries).
  7. Once complete, launch your administration portal and confirm that the UPN shows as the new value under Management, Users.

 

↑ Back to top

Appendix 2: Glossary of Terms

Active Directory Federation Services (AD FS): A standards-based service that supports application authentication and authorization against a corporate Active Directory implementation while not exposing credentials to the requesting application.

Single Sign-On (SSO): A single username and password that administrators need to manage in a single location (for example, On-premise AD). End users are able to use this single username and password for authentication with on-premise and cloud applications such as Office 365. Depending on the client configuration, they may need to type in those same credentials again to authenticate.

DirSync: A customized, limited version of Microsoft Forefront Identity Manager that supports copying selected account information (not including password information) from a corporate Active Directory environment to Windows Azure AD.

User principal name (UPN): A way of expressing the username/domain name combination first introduced in Windows 2000 Active Directory. It is formatted similar to an e-mail address for a user.

Windows Azure Active Directory (Windows Azure AD): A Microsoft-hosted directory service that supports authorization and optionally, authentication for Microsoft Online Services offerings such as Office 365 and Windows Intune.

 

↑ Back to top