Leverage Multi Factor Authentication Server On Your Premises

Leverage Windows Azure Multi-Factor
Authentication Server for Windows Azure

AD single sign-on with AD FS
Overview Technical Article

Microsoft France
Published: January 2014
Version: 1.0

Author: Philippe Beraud (Microsoft France)
Contributors/Reviewers: Arnaud Jumelet (Microsoft France), Jean-Yves Grasset (Microsoft France), Yann Kristofic
(Microsoft Corporation), Christophe Leroux (Microsoft Corporation), Philippe Maurent (Microsoft Corporation)

For the latest information, please see
www.windowsazure.com/en-us/services/multi-factor-authentication

Copyright 2013 Microsoft Corporation. All rights reserved.

Abstract: With escalating IT security threats and a growing number of users, Software-as-a-Service (SaaS)
applications, and devices, multi-factor authentication is becoming the new standard for securing access
and how businesses ensure trust in a multi-device, mobile, cloud world. Passwords not enough strong can
be easily compromised, and the consumerization of IT along with the Bring-Your-Own-Device (BYOD)
trend have only increased the scope of vulnerability. Regulatory agencies agree and have mandated its use
across a broad range of industries.
Windows Azure Multi-Factor Authentication helps reduce organizational risk and enable regulatory
compliance by providing an extra layer of authentication in addition to a users account credentials. For
that purpose, it leverages for additional authentication a convenient form factor that the users already
have (and care about): their phone. During sign in, users must also authenticate using the mobile app or
by responding to an automated phone call or text message before access is granted. An attacker would
need to know the users password and have in their possession of the users phone to sign in. As a
solution for both cloud-based and on-premises applications, Windows Azure Multi-Factor Authentication
can notably be used as part of the Windows Azure Active Directory authentication.

2 Leverage Windows Azure Multi-Factor Authentication Server for Windows Azure AD single sign-on with AD FS
Table of Contents
INTRODUCTION ................................................................................................................................................. 3
OBJECTIVES OF THIS PAPER ..................................................................................................................................................... 5
NON-OBJECTIVES OF THIS PAPER ........................................................................................................................................... 7
ORGANIZATION OF THIS PAPER .............................................................................................................................................. 7
ABOUT THE AUDIENCE ............................................................................................................................................................. 8
BUILDING A TEST LAB ENVIRONMENT ......................................................................................................... 9
CREATING A TEST WINDOWS AZURE AD TENANT ............................................................................................................... 9
BUILDING THE ON-PREMISES TEST LAB ENVIRONMENT IN WINDOWS AZURE ................................................................ 10
PREPARING THE LOCAL ENVIRONMENT FOR WINDOWS AZURE ....................................................................................... 13
SETTING UP THE WINDOWS SERVER 2012 R2 BASE CONFIGURATION TEST LAB ............................... 19
DEPLOYING THE BASE WORKLOADS IN WINDOWS AZURE ................................................................................................ 21
CONFIGURING THE DOMAIN CONTROLLER ......................................................................................................................... 25
CONFIGURING THE ROOT ENTERPRISE CA .......................................................................................................................... 34
DEPLOYING THE FEDERATION SERVER .................................................................................................................................. 40
PREPARING THE INTERNET-FACING COMPUTER .................................................................................................................. 43
SETTING UP SINGLE SIGN-ON WITH THE WINDOWS AZURE AD TENANT ........................................... 55
INSTALLING THE PREREQUISITE SOFTWARE .......................................................................................................................... 55
CONNECTING WINDOWS POWERSHELL TO WINDOWS AZURE AD ............................................................................... 59
ADDING AND VERIFYING THE DOMAIN NAME IN THE WINDOWS AZURE AD TENANT .................................................. 60
ACTIVATING THE DIRECTORY SYNCHRONIZATION ON THE WINDOWS AZURE AD TENANT ......................................... 66
INSTALLING AND CONFIGURING THE DIRSYNC TOOL ........................................................................................................ 67
VERIFYING THE SYNCHRONIZATION ON THE WINDOWS AZURE AD TENANT ................................................................ 72
VERIFYING THE SINGLE SIGN-ON WITH THE WINDOWS AZURE AD TENANT .................................................................. 73
TESTING AND EVALUATING THE MULTI-FACTOR AUTHENTICATION SERVER .................................... 76
CREATING A MULTI-FACTOR AUTHENTICATION PROVIDER VIA THE WINDOWS AZURE PORTAL ................................ 76
DOWNLOADING THE MULTI-FACTOR AUTHENTICATION SERVER.................................................................................... 78
INSTALLING THE MULTI-FACTOR AUTHENTICATION SERVER ON THE FEDERATION SERVER .......................................... 79
CONFIGURING MULTI-FACTOR AUTHENTICATION ON THE FEDERATION SERVER ............................................................ 81
INSTALLING THE MULTI-FACTOR AUTHENTICATION SDK (OPTIONAL) ........................................................................... 94
DEPLOYING THE MULTI-FACTOR AUTHENTICATION USER PORTAL (OPTIONAL) ............................................................ 99
DEPLOYING THE MULTI-FACTOR AUTHENTICATION SERVER MOBILE APP WEB SERVICE (OPTIONAL)..................... 103

Introduction
Today many organizations use on-premises multi-factor authentication systems to protect mission critical
data in their file servers and their critical Line of Business (LOB) applications. As these workloads (or parts
of them) move to the cloud (at least in a hybrid manner, see whitepaper ENABLING HYBRID CLOUD TODAY WITH
MICROSOFT TECHNOLOGIES
1
), they need an effective and easy-to-use solution in the Cloud for protecting:
That data in the Microsoft services, such Office 365 and Dynamics CRM Online, or other Software-
as-a-Service (SaaS) theyve subscribed to,
The custom cloud-based LOB applications on Windows Azure or in other clouds -,
And the modern business applications
2
theyve created.
Passwords in use that are often not enough strong and the consumerization of IT has only even increased
the scope of vulnerability.
Multi-factor authentication is becoming the new standard for securing access and how businesses ensure
trust in a multi-device, mobile, cloud world.
Note Not only do the above organizations need multi-factor authentication for their employees, but many
of them are also increasingly building cloud-based applications for consumers and citizens that require multi-
factor authentication to ensure a high level of security. These B2C scenarios are growing rapidly and require easy
end-user technology.
Furthermore, multi-factor authentication is no longer optional for many of the above organizations; many
are required by various governing or regulatory agencies to strongly authenticate access to sensitive data
and applications across a broad range of industries.
In such a landscape, phone-based authentication constitutes a very compelling technical approach for
multi-factor authentication as it provides enhanced security for businesses and consumers in a convenient
form factor that the user already has: their phone.
Windows Azure Multi-Factor Authentication
3
addresses user demand for a simple sign-in process while
also helping address the organization's security and compliance standards. The service offers enhanced
protection from malware threats, and real-time alerts notify your IT department of potentially
compromised account credentials.
Windows Azure Multi-Factor Authentication helps to deliver strong security via a range of easy
authentication options. Thus, in addition to entering a username and password during sign in, enabled
users are also required to authenticate with a mobile app on their mobile device or via an automated
phone call or a text message, allowing these users to choose the method that works best for them.
Consequently, in order for an attacker to gain access to a users account, they would need to know the
users login credentials AND be in possession of the users phone. Furthermore, support for the above
multiple methods enables to support more scenarios such as offline (no carrier) scenarios.

1
Enabling Hybrid Cloud today with Microsoft Technologies: http://www.microsoft.com/en-us/download/details.aspx?id=39052
2
Modern business applications: http://www.microsoft.com/en-us/server-cloud/cloud-os/modern-business-apps.aspx
3
Windows Azure Multi-Factor Authentication: http://www.windowsazure.com/en-us/services/multi-factor-authentication/

Whilst Windows Azure Multi-Factor Authentication is powered by a cloud service, it supports on-premises,
cloud, and hybrid scenarios. The following solutions are indeed available for use with Windows Azure
Multi-Factor Authentication:
Adding Multi-Factor Authentication to Windows Azure Active Directory (Windows Azure
AD). Windows Azure Multi-Factor Authentication works with any applications that use the
Windows Azure AD directory tenants. As such, Windows Azure Multi-Factor Authentication can be
rapidly enabled for Windows Azure AD identities to help secure access:
The Windows Azure management portal,
Microsoft Online Services like Office 365 and Dynamics CRM Online, etc.
Any custom LOB, third-party multitenant cloud-based, or modern business applications
that integrate with Windows Azure AD for authentication,
As well as hundreds of cloud SaaS applications like Box, GoToMeeting, Salesforce.com and
others, (and even and more in the coming months,) thanks to the application gallery of
the Application Access Enhancements for Windows Azure AD
4
feature.
Users will be prompted to set up additional verification the next time they sign in.
Note For more information, see the Microsoft TechNet article ADDING MULTI-FACTOR AUTHENTICATION TO
WINDOWS AZURE ACTIVE DIRECTORY
5
.
The white-paper LEVERAGE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE AD
6

describes how to enable, configure, and use Windows Azure Multi-Factor Authentication with such
cloud users in Windows Azure AD for securing resource access in the Cloud.
Enabling Multi-Factor Authentication for on-premises applications and Windows Server. The
Multi-Factor Authentication Server works out-of-the-box with a wide range of on-premises
applications, such as remote access VPNs, web applications, virtual desktops, single sign-on
systems and much more. This includes:
Microsoft products and technologies like Microsoft VPN/RRAS, Remote Desktop Services
and Remote Desktop Gateway, Universal Access Gateway, SharePoint, Outlook Web
Access, etc.
As well as third party VPNs and virtual desktop system.
The Windows Azure Multi-Factor Authentication Server allows the administrator integrate with IIS
authentication to secure Microsoft IIS web applications, RADIUS authentication, LDAP
authentication, and Windows authentication.
The Multi-Factor Authentication Server can be run on-premises on your existing hardware - as a
virtual machine (VM) or not -, or in the cloud for instance as a Windows Azure Virtual Machine.
Multiple, redundant servers can be configured for high availability and fail-over.

4
Application access enhancements for Windows Azure AD: http://technet.microsoft.com/en-us/library/dn308588.aspx
5
ADDING MULTI-FACTOR AUTHENTICATION TO WINDOWS AZURE ACTIVE DIRECTORY: http://technet.microsoft.com/en-
us/library/dn249466.aspx
6
WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE AD: http://www.microsoft.com/en-
us/download/details.aspx?id=36391

Note For more information, see Microsoft TechNet article ENABLING MULTI-FACTOR AUTHENTICATION FOR ON-
PREMISES APPLICATIONS AND WINDOWS SERVER
7
.
Building Multi-Factor Authentication into custom applications. A Software Development Kit
(SDK) is available for use for direct integration with custom cloud-based and on-premises
applications. It enables to build Multi-Factor Authentication phone call and text message
verification into the applications sign-in or transaction processes and leverage the applications
existing user database.
Note For more information, see Microsoft TechNet article BUILDING MULTI-FACTOR AUTHENTICATION INTO
CUSTOM APPS (SDK)
8
.
Objectives of this paper
As an addition to the aforementioned white-paper LEVERAGE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION
WITH WINDOWS AZURE AD, and for an organization that is federated with Windows Azure AD, this paper aims
at describing how to use Windows Azure Multi-Factor Authentication Server and to configure it to secure
cloud resources such as Office 365 so that so that federated users will be prompted to set up additional
verification the next time they sign in on-premises.
Such a scenario complements the directory synchronization with single sign-on (SSO) scenario, which
aims at providing users with the most seamless authentication experience as they access Microsoft cloud
services and/or other cloud-based applications while logged on to the corporate network.
Note For more information, see Microsoft TechNet article DIRECTORY SYNC WITH SINGLE SIGN-ON SCENARIO
9
.
This integration scenario implies to configure the Multi-Factor Authentication Server to work with Active
Directory Federation Services (AD FS) or other supported on-premises third-party security token services
(STS) so that Multi-Factor Authentication is triggered on-premises, or in an Infrastructure-as-a-Service
(IaaS) cloud environment such as Windows Azure as per OFFICE 365 ADAPTER: DEPLOYING OFFICE 365 SINGLE
SIGN-ON USING WINDOWS AZURE
10
whitepaper.

7
ENABLING MULTI-FACTOR AUTHENTICATION FOR ON-PREMISES APPLICATIONS AND WINDOWS SERVER: http://technet.microsoft.com/en-
8
BUILDING MULTI-FACTOR AUTHENTICATION INTO CUSTOM APPS (SDK): http://technet.microsoft.com/en-us/library/dn249464.aspx
9
DIRECTORY SYNC WITH SINGLE SIGN-ON SCENARIO: http://technet.microsoft.com/en-us/library/dn441213.aspx
10
OFFICE 365 ADAPTER: DEPLOYING OFFICE 365 SINGLE SIGN-ON USING WINDOWS AZURE: http://www.microsoft.com/en-

Note Such an integration is natively supported by AD FS but differs in terms of integration path
depending on the version of AD FS. More specifically, for more information on using the Multi-Factor
Authentication Server with AD FS 2.x, see Microsoft TechNet article USING MULTI-FACTOR AUTHENTICATION WITH ACTIVE
DIRECTORY FEDERATION SERVICES
11
. For information on using Windows Azure Multi-Factor Authentication Server with
AD FS in Windows Server 2012 R2, see Microsoft TechNet article WALKTHROUGH GUIDE: MANAGE RISK WITH ADDITIONAL
MULTI-FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS
12
.
For the other supported on-premises third-party security token services (STS), the aforementioned SDK is
available for use with custom applications and directories.
Beyond this integration, this scenario additionally implies directory synchronization between the on-
premises identity infrastructure (based on Windows Server Active Directory (AD) or on other (LDAP-based)
directories) and the Multi-Factor Authentication Server to streamline user management and automated
provisioning.
This also supposes to deploy:
The on-premises Multi-Factor Authentication Users portal, which allows users to enroll in Multi-
Factor Authentication and maintain their accounts.
And optionally the Multi-Factor Authentication Server mobile app web service, which is used in
the Multi-Factor Authentication mobile app activation process. The Multi-Factor Authentication
App offers an additional out-of-band authentication option.
With all of the above, the enrolled federated users can use their on-premises corporate credentials
(user name and password) and their existing phone for additional authentication to access
Windows Azure AD and any cloud-based application that is integrated into Windows Azure AD as
well as their existing on-premises resources.
Important note With the Multi-Factor Authentication Server, only browser-based applications can be
secured. Rich clients wont work with the Multi-Factor Authentication Server. The App Password feature that is
devoted to rich client is indeed currently only provided through the Windows Azure Multi-Factor Authentication
service and is not available for federated users. For more information on the App Password feature, see the
aforementioned whitepaper LEVERAGE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE AD
13
.
Built on existing Microsoft documentation and knowledge base articles, this document provides a
complete walkthrough to build a suitable test lab environment in Windows Azure, test, and evaluate the
above scenario. It provides additional guidance if any.

11
USING MULTI-FACTOR AUTHENTICATION WITH ACTIVE DIRECTORY FEDERATION SERVICES http://technet.microsoft.com/en-
12
WALKTHROUGH GUIDE: MANAGE RISK WITH ADDITIONAL MULTI-FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS:
http://technet.microsoft.com/en-us/library/dn280946.aspx
13
WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE AD: http://www.microsoft.com/en-

Note For more information, see Microsoft TechNet article USING MULTI-FACTOR AUTHENTICATION WITH
WINDOWS AZURE AD
14
.
Non-objectives of this paper
This document doesnt introduce Windows Azure Multi-Factor Authentication. Such a presentation is
provided in the aforementioned whitepaper LEVERAGE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH
WINDOWS AZURE AD
15
.
This document doesnt discuss either how to configure Windows Azure Multi-Factor Authentication for
cloud identities in Windows Azure AD to secure cloud-based resources. This scenario is also covered in
detail in the above whitepaper. This document doesnt describe either how to configure the advanced
settings and reports of the service. All of these are also covered in the above whitepaper. For more
information, please refer to it.
As already mentioned, the Multi-Factor Authentication Server also works out-of-the-box with a wide range
of on-premises applications, such as remote access VPNs, web applications, virtual desktops, single sign-
on systems and much more. Those scenarios are not discussed in this document.
Note For more information, see Microsoft TechNet article ENABLING MULTI-FACTOR AUTHENTICATION FOR ON-
PREMISES APPLICATIONS AND WINDOWS SERVER
16
.
Organization of this paper
To cover the aforementioned objectives, this document is organized in the following four sections:
BUILDING A TEST LAB ENVIRONMENT.
SETTING UP THE WINDOWS SERVER 2012 R2 BASE CONFIGURATION TEST LAB.
SETTING UP SINGLE SIGN-ON WITH THE WINDOWS AZURE AD TENANT.
TESTING AND EVALUATING THE MULTI-FACTOR AUTHENTICATION SERVER.
These sections provide the information details necessary to (hopefully) successfully build a working
environment for the Windows Azure Multi-Factor Authentication Server. They must be followed in order.

14
USING MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE AD: http://technet.microsoft.com/en-us/library/jj713614.aspx
15
USE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION SERVER FOR WINDOWS AZURE AD SINGLE SIGN-ON WITH AD FS:
http://www.microsoft.com/en-us/download/details.aspx?id=36391
16
ENABLING MULTI-FACTOR AUTHENTICATION FOR ON-PREMISES APPLICATIONS AND WINDOWS SERVER: http://technet.microsoft.com/en-

About the audience
This document is intended for system architects and IT professionals who are interested in understanding
how to enable and configure the Windows Azure Multi-Factor Authentication Server for Windows Azure
AD federated users to help secure access to cloud resources such as Office 365.

Building a test lab environment
As its title suggests, this section guides you through a set of instructions required to build a representative
test lab environment. Considering the involved services, products, and technologies that encompass such
a cross-premises environment with:
In the on-premises, Windows Server Active Directory, Active Directory Certificate Services (AD CS),
Active Directory Federation Services (AD FS), and Internet Information Services (IIS), to name a few
- and the related required configuration;
In the cloud, a Windows Azure AD tenant, and cloud-based applications that leverage Windows
Azure AD for identity management and access control.
The following diagram provides an overview of the overall test lab environment with the software and
service components that need to be deployed / configured.

We have tried to streamline and to ease as much as possible the way to build a suitable test lab
environment, to consequently reduce the number of instructions that tell you what servers to create, how
to configure the operating systems and core platform services, and how to install and configure the
required core services, products and technologies, and, at the end, to reduce the overall effort that is
needed for such an environment.
We hope that the provided experience will enable you to see all of the components and the configuration
steps both on-premises and in the cloud that go into such a multi-products and services solution.
Creating a test Windows Azure AD tenant
The easiest way to provision both a Windows Azure AD tenant and application workloads for the purpose
of the test lab certainly consists in signing up to a Microsoft Office 365 Enterprise
17
tenant. Windows Azure
AD is indeed the directory used to store user identities and other tenant properties by Office 365 (and
other Microsoft services such as Dynamics CRM Online, and Windows Intune).
To sign up to a free 30-day Microsoft Office 365 Enterprise E3 trial, follow the instructions at
http://office.microsoft.com/en-us/business/redir/XT104175934.aspx.

17
Office 365 Enterprise: http://office.microsoft.com/en-us/business/office-365-enterprise-e3-business-software-FX103030346.aspx
DC1
EDGE1
ADFS1
Active Directory Domain Services (AD DS)
Domain Name Services (DNS)
Active Directory Certificates Services (AD CS)
Active Directory Federation Services (AD FS)
Windows Azure AD Directory Synchronization Tool (DirSync)
Multi-Factor Authentication Server
Multi-Factor Authentication SDK
Web Application Proxy
Multi-Factor Authentication Users portal
Multi-Factor Authentication Server mobile app web service
Internal Virtual Network Switch
Corpnet
External Virtual Network Switch
Internet

Note For more information, see the article SIGN IN TO OFFICE 365
18
.
For the course of this walkthrough, weve provisioned an Office 365 Enterprise (E3) tenant:
litware369.onmicrosoft.com. You will have to choose in lieu of a tenant domain name of your
choice whose name is currently not in used. Whenever a reference to litware369.onmicrosoft.com is
made in a procedure, it has been replaced by the tenant domain name of your choice to reflect
accordingly the change in naming.
Building the on-premises test lab environment in Windows
Azure
A challenge in creating a useful on-premises test lab environment is to enable their reusability and
extensibility. Because creating a test lab can represent a significant investment of time and resources, your
ability to reuse and extend the work required to create the test lab is important. An ideal test lab
environment would enable you to create a basic lab configuration, save that configuration, and then build
out multiple test lab scenarios in the future by starting with the base configuration.
Moreover, another challenge people is usually facing with relates to the hardware configuration needed to
run such a base configuration that involves several (virtual) machines.
For these reasons and considering the above objectives, this guide will leverage Windows Azure
environment along with the Windows Azure PowerShell cmdlets to build the on-premises test lab
environment to test and evaluate the Multi-Factor Authentication Server.
Introducing Windows Azure Infrastructure as a Services (IaaS)
capabilities
Windows Azure Virtual Machines
19
provides support for virtual machines (VMs). At a glance, a VM consists
of a piece of infrastructure to deploy an application. Specifically, this includes a persistent operating
system (OS) disk, possibly some persistent data disks, and internal/external networking glue/connectivity
to hold it all together. With these infrastructure ingredients, it enables to create a platform where you can
take advantage of the reduced cost and ease of deployment offered in Windows Azure.
To mimic an on-premises deployment with a multi-VM workload as needed here, virtual networks are also
required. This is where Windows Azure Virtual Networks comes into play. Windows Azure Virtual Network
20

will let you provision and manage virtual networks (VNET) in Windows Azure. A VNET is the ability to
create a logical boundary and place into it VMs. VNET also provides the capability of connecting Windows
Azure Cloud Services
21
(VMs, web roles, and worker roles) that are in the same affinity group directly with
them.

18
SIGN IN TO OFFICE 365: http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff637600.aspx
19
Windows Azure Virtual Machines: https://www.windowsazure.com/en-us/services/virtual-machines/
20
Windows Azure Virtual Networks: https://www.windowsazure.com/en-us/services/virtual-network/
21
Windows Azure Cloud Services: https://www.windowsazure.com/en-us/services/cloud-services/

Note An affinity group is a container where you choose the location (Windows Azure region) and where
you placed your Windows Azure resources. An affinity group represents also a convenient way to designate a
Windows Azure data center region with the name of your choice. (As of this writing, Windows Azure Cloud
Services can be added to an affinity group only at the time of creation of the service.).
Windows Azure Virtual Network provides control over network topology, including configuration of IP
addresses, routing tables and security policies. A VNET has its own private address space. The address
space is initially IPv4 only (but could be extended to IPv6 in a future release).
Note Windows Azure Virtual Network also allows to securely extend on-premises networks into the cloud.
With the ability to assign a private address range for its VNET, you can indeed treat it as an extension of your own
corporate private network address space by establishing appropriate gates (VPN gateway) between their on-
premises corporate private network and their virtual network(s) in Windows Azure. For that purpose, Windows
Azure Virtual Network enables to set up secure site-to-site connectivity between the organizations corporate
VPN gateway and Windows Azure, and then to connect the organizations on-premises corporate network to the
organizations Windows Azure tenant by using a VPN gateway along with the industry-standard IPSEC protocol.
With such a capability, IT administrators can easily create a logically isolated private environment in Windows
Azure, and connect it to the organizations on-premises IT infrastructure by using a secure VPN tunnel. Once set
up, the isolated Windows Azure environment can be viewed as a natural extension of the on-premises corporate
network.
To synthetize, Windows Azure Virtual Network allows you to create private network(s) of VMs in your
Windows Azure tenant environment that you can assign IP addresses to (and then optionally connect to
your data center through a VPN gateway. Using this method, you can seamlessly connect on-premises
(virtual) machines to VMs running in your Windows Azure tenant.
The fundamental requirements for deploying Windows Server AD on VM(s) in Windows Azure differ very
little from deploying it in VMs (and, to some extent, physical machines) on-premises. For example, if the
domain controller that you deploy on VMs are replicas in an existing on-premises corporate
domain/forest, then the Windows Azure deployment can largely be treated in the same way as you might
treat any other additional Windows Server AD site. That is, subnets must be defined in Windows Server
AD, a site created, the subnets linked to that site, and connected to other sites using appropriate site-links.
There are, however, a number of differences that are common to all Windows Azure deployments and
some that vary according to the specific deployment scenario.

Note For more information, see the Microsoft TechNet articles INSTALL A NEW ACTIVE DIRECTORY FOREST IN
WINDOWS AZURE
22
and GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL
MACHINES
23
that cover the fundamental differences and explain in great detail how successfully deploy and operate
AD in Windows Azure. The former deals with a standalone configuration in the cloud as we will deploy later in this
document whereas the latter highlights the requirements for deploying AD in a hybrid scenario in which Windows
Server AD is partly deployed on-premises and partly deployed on VMs in Windows Azure.
Adding a Windows Azure trial to the Office 365 account
Once you have signed up
24
and established your organization with an account in Office 365 Enterprise E3,
you can then add a Windows Azure trial subscription to your Office 365 account. This can be achieved by
accessing the Windows Azure Sign Up page at https://account.windowsazure.com/SignUp with your Office
365 global administrator account. You need to select Sign in with your organizational account for that
purpose.
Note You can log into the Office 365 administrator portal and go to the Windows Azure Signup page or
go directly to the signup page, select sign in with an organizational account and log in with your Office 365 global
administrator credentials. Once you have completed your trial tenant signup you will be redirected to the
Windows Azure account portal
25

and can proceed to the Windows Azure management portal by clicking Portal at
the top right corner of your screen.

Note This enables you to empower
26
your Office 365 subscription with the access management and
security features that Windows Azure AD is offering. While there are and will be ongoing investments in the Office
365 management portal
27
, rich identity and access management capabilities are and will be exposed through the
Active Directory section in the Windows Azure management portal
28
first. For example, the Application Access
Enhancements for Windows Azure AD
29
, which provides an streamlined access to hundreds
30
of cloud SaaS pre-
integrated applications like Box, GoToMeeting, Salesforce.com and others, (and even and more in the coming
months,) can be only managed today by accessing the directory through the Windows Azure management portal.
At this stage, you should have an Office 365 Enterprise E3 trial subscription with a Windows Azure
trial subscription.

22
INSTALL A NEW ACTIVE DIRECTORY FOREST IN WINDOWS AZURE: http://www.windowsazure.com/en-us/manage/services/networking/active-
directory-forest/
23
GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES: http://msdn.microsoft.com/en-
us/library/windowsazure/jj156090
24
Office 365 Enterprise E3 Trial: http://office.microsoft.com/en-us/business/redir/XT104175934.aspx
25
Windows Azure account portal: https://account.windowsazure.com/Subscriptions
26
USING YOUR OFFICE 365 AZURE AD TENANT WITH APPLICATION ACCESS ENHANCEMENTS FOR WINDOWS AZURE AD:
http://blogs.technet.com/b/ad/archive/2013/09/10/empower-your-office-365-subscription-identity-management-with-application-
access-enhancements-for-windows-azure-ad.aspx
27
Office 365 management portal: https://portal.microsoftonline.com
28
Windows Azure management portal: https://manage.windowsazure.com
29
APPLICATION ACCESS ENHANCEMENTS FOR WINDOWS AZURE AD: http://technet.microsoft.com/en-us/library/dn308588.aspx
30
WINDOWS AZURE ACTIVE DIRECTORY APPLICATIONS: http://www.windowsazure.com/en-us/gallery/active-directory

Preparing the local environment for Windows Azure
Windows Azure PowerShell is the module for Windows PowerShell that you can use to control and
automate the deployment and management of the workloads in Windows Azure.
Installing and configuring Windows Azure PowerShell
The configuration of Windows Azure PowerShell on a local computer consists in:
Installing Windows Azure PowerShell,
Verifying that Windows Azure PowerShell can run scripts, and, in the negative, enabling scripts to
run in Windows PowerShell,
Verifying that WinRM allows Windows PowerShell to connect, and, in the negative, configuring
WinRM to support basic authentication.
This local computer MUST have Internet connectivity.
Installing Windows Azure PowerShell
To install the Windows Azure PowerShell module, proceed with the following steps:
1. Open a browsing session and navigate to the Windows Azure Downloads
31
page.
2. Scroll down to Command line tools.

3. Under Windows downloads, click Windows Azure PowerShell.

4. When prompted to run or save the .exe installation file (WindowsAzurePowerShell.3f.3.3fnew.exe),
choose the Run button.
5. A User Account Control dialog brings up. Click Yes. This launches the Web Installer Platform 4.6.

31
Windows Azure Downloads: http://go.microsoft.com/fwlink/?LinkID=294711


6. Click Install and follow the online instructions to complete the installation.

7. Click I Accept. The package is downloaded and installed.

8. Click Finish.
9. Click Exit.
You can run then the cmdlets from the Windows Azure PowerShell console.
To connect to your Windows Azure subscription with the Windows Azure PowerShell console, proceed
with the following steps:
1. Open a Windows Azure PowerShell command prompt.

2. Run the following command.

PS C:\> Add-AzureAccount

3. A Sign in to Windows Azure dialog brings up.

4. Type the email address and password associated with your account.
5. Windows Azure authenticates you and saves the credential information, and then closes the
dialog.

6. Once connected to your default subscription, you can use the built-in Help system to list and get
help about the cmdlets in the Windows Azure PowerShell module. To list the available cmdlets,
run the following command:

PS C:\> help azure

You can then display help about a specific cmdlet by typing help followed by the name of the
cmdlet, for example help New-AzureVM.

Note For instructions, see the articles HOW TO INSTALL AND CONFIGURE WINDOWS AZURE POWERSHELL
32
and GET
STARTED WITH WINDOWS AZURE CMDLETS
33
.

Note For more information about the cmdlets in the Windows Azure PowerShell module, see the
Microsoft MSDN article WINDOWS AZURE MANAGEMENT CMDLETS
34
.
Enabling Windows PowerShell scripts
To verify that Windows Azure PowerShell can run scripts, proceed with the following steps;
1. Open an elevated Windows Azure PowerShell command prompt, and run the following command:

PS C:\> Get-ExecutionPolicy

2. If the value returned is anything other than RemoteSigned, you need to change the value to
RemoteSigned.
Note A digital signature is required from a trusted publisher on scripts and configuration files that are
downloaded from the Internet (including e-mail and instant messaging programs) so that they can run. However,
a digital signature isnt required on scripts that you have written on the local computer (not downloaded from
the Internet). Finally, you can run scripts that are downloaded from the Internet and not signed, if the scripts are
unblocked, such as by using the Unblock-File cmdlet. For more information, see the Microsoft TechNet article
ABOUT_EXECUTION_POLICIES.
35
.
Run the following command if needed:

PS C:\> Set-ExecutionPolicy RemoteSigned

When invited, press Y to confirm the operation.
Enabling WinRM for remote PowerShell shell
To verify that WinRM allows Windows PowerShell to connect, proceeds as follows:
1. In the above elevated Windows Azure PowerShell session, run the following command to check
the status of the WinRM service:

PS C:\> sc query winrm

32
HOW TO INSTALL AND CONFIGURE WINDOWS AZURE POWERSHELL: http://www.windowsazure.com/en-us/manage/install-and-configure-
windows-powershell/
33
GET STARTED WITH WINDOWS AZURE CMDLETS: http://msdn.microsoft.com/en-us/library/windowsazure/jj554332.aspx
34
WINDOWS AZURE MANAGEMENT CMDLETS: http://msdn.microsoft.com/en-us/library/jj152841.aspx
35
ABOUT_EXECUTION_POLICIES: http://technet.microsoft.com/library/hh847748.aspx

2. If the WinRM service isnt running, start it with the following command:

PS C:\> net start winrm

3. Run the following command:

PS C:\> winrm get winrm/config/client/auth

4. In the results, look for the value Basic =. If the value is Basic = false, you must change the
value to Basic = true.
If the value has to be changed, run the following command:

PS C:\> winrm set winrm/config/client/auth @{Basic="true"}

The value between the braces { } is case-sensitive. In the command output, verify the value Basic
= true.
5. If you started the WinRM service in step 2, run the following command to stop it:

PS C:\> net stop winrm

You are now ready to setup the Windows Server 2012 R2 Base Configuration needed for the test
lab.
This is the purpose of the next section.

Setting up the Windows Server 2012 R2 Base
Configuration test lab
By following the instructions outlined hereafter, you should be able to successfully prepare your on-
premises test lab environment based on virtual machines (VMs) running in Windows Azure to later deploy
and configure the Multi-Factor Authentication Server environment, install and configure it with Active
Directory Federation Services (AD FS) in Windows Server 2012 R2, etc. and start evaluating/using it.
Important note Individual virtual machines (VMs) are needed to separate the services provided on the
network and to clearly show the desired functionality. This being said, the suggested configuration to later
evaluate the Multi-Factor Authentication Server is neither designed to reflect best practices nor does it reflect a
desired or recommended configuration for a production network. The configuration, including IP addresses and
all other configuration parameters, is designed only to work on a separate test lab networking environment.
Any modifications that you make to the configuration details provided in the rest of this document may affect or
limit your chances of successfully setting up the on-premises collaboration environment that will serve as the
basis for the integration with the Windows Azure Multi-Factor Authentication service in the Cloud.
Microsoft has successfully built the suggested environment with Windows Azure IaaS, and Windows Server 2012
R2 virtual machines.
In order to complete the documents walkthrough, you need an environment that consists of the following
components for on-premises test lab infrastructure:
One computer running Windows Server 2012 R2 (named DC1 by default) that is configured as a
domain controller with a test user and group accounts, and Domain Name System (DNS) server.
One intranet member server running Windows Server 2012 R2 (named ADFS1 by default) that is
configured as an enterprise root certification authority (PKI server), and an AD FS federation
server.
One Internet-facing member server running Windows Server 2012 R2 (named EDGE1 by default)
that is configured as a Web server.
Note Windows Server 2012 R2 offers businesses and hosting providers a scalable, dynamic, and
multitenant-aware infrastructure that is optimized for the cloud. For more information, see the Microsoft
TechNet Windows Server 2012 R2 homepage
36
.
The above VMs expose one public endpoint for remote desktop (RDP) and another one for remote
Windows PowerShell (WinRMHTTPS) as illustrated hereafter.

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

The EDGE1 VM exposes in addition a public endpoint for HTTPS (HttpsIn).

These VMs will enable you to create snapshots so that you can easily return to a desired configuration for
further learning and experimentation.
The integrated test lab consists of:
A first subnet (10.0.1.0/24) that will expose the test lab resources that require Internet
connectivity/endpoint(s). It is separated from a second subnet that hosts the corporate intranet
resources. The computer on this subnet is EDGE1.
A second subnet (10.0.2.0/24) that simulates a private intranet. Computers on the Subnet2 subnet
are DC1 and ADFS1.

Important Note Windows Azure assigns IP addresses dynamically, which may seem weird especially when
you have the habit to set static IP addresses, especially for domain controllers. More specifically, static IP
addresses are NOT supported. For more information, see section IP Addressing and DNS
37
of the MSDN article
GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES.
Within a subnet, the first 3 addresses are reserved and, in the case of Subnet2 above, the first address that is
assigned by the Windows Azure DHCP will be 10.0.2.4. However, it is guaranteed that the first address will remain
constant, which is not the case for the addresses that belong to the rest of the range. Such a behavior must be
taken into account if you want that a specific VM will have the same IP address allocated over the time, which will
be the case of our domain controller DC1 that will also host the DNS server for the test lab environment.
In order to later define a federated domain in the Windows Azure AD tenant (e.g.
litware369.onmicrosoft.com), weve opted to configure the domain litware369.com (LITWARE369).
You will have to choose in lieu of a domain name of your choice whose DNS domain name is
currently not in used on the Internet. For checking purpose, you can for instance use the domain search
capability provided by several popular domain name registrars.

37
GUIDELINES FOR DEPLOYING WINDOWS SERVER ACTIVE DIRECTORY ON WINDOWS AZURE VIRTUAL MACHINES:
http://msdn.microsoft.com/en-us/library/windowsazure/jj156090.aspx

Whenever a reference to litware369.com is made in a procedure, it has been 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.
Furthermore, for the sake of simplicity, the same password pass@word1 is used throughout the
procedures of the above TLGs as well as the ones 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 LITWARE369 domain Administrator account
AzureAdmin for each Windows Server 2012 R2 VM, unless instructed otherwise.
The following five steps must be followed in order to set up the on-premises core infrastructure of our test
lab:
1. Deploying the base workloads in Windows Azure.
2. Configuring the domain controller.
3. Configuring the root Enterprise CA.
4. Deploying the federation server.
5. Preparing the Internet-facing computer.
Deploying the base workloads in Windows Azure
To deploy the base workloads in your Windows Azure subscription, proceed with the following steps:
1. Download the script New-TestLabEnvironment.ps1
38
and unblock it so that it can comply with the
above execution policy and be executed in your environment.
Note The script New-TestLabEnvironment.ps1 is largely inspired by the sample script DEPLOY A DOMAIN
CONTROLLER AND MEMBER USING WINDOWS AZURE VIRTUAL MACHINES
39
available on the Microsoft TechNet Script
Center
40
.

Note The script Remove-TestLabEnvironment.ps1
41
enables you to later seamlessly remove the test lab
environment from your Windows Azure subscription. Its usage is not covered in this paper since its arguments
are unsurprisingly almost the same as the ones used by the above script.
2. Open a Windows Azure PowerShell command prompt and navigate to the folder where the above
script is located, for example C:\Scripts in our illustration.
3. Run the following command to connect to your subscription:

PS C:\Scripts> Add-AzureAccount

38
New-TestLabEnvironment.ps1: http://www.microsoft.com/en-us/download/details.aspx?id=36391
39
DEPLOY A DOMAIN CONTROLLER AND MEMBER USING WINDOWS AZURE VIRTUAL MACHINES:
http://gallery.technet.microsoft.com/scriptcenter/Deploy-a-domain-controller-2ab7d658
40
Script resources for IT professionals: http://gallery.technet.microsoft.com/scriptcenter
41
Remove-TestLabEnvironment.ps1: http://www.microsoft.com/en-us/download/details.aspx?id=36391


A Sign in to Windows Azure dialog brings up.

4. Enter the credentials for your Windows Azure (trial) subscription.

You are now connected to your default subscription.
5. Run the following command to deploy the base workloads in your subscription:

PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfalab" -Location "North Europe"

6. The script New-TestLabEnvironment.ps1 proceeds with the setup and will prompt you to gather
the administrator credentials to use when provisioning the aforementioned VMs. A Windows
PowerShell credential required dialog brings up.

7. Provide the administrator credentials you want to use. We will use throughout this walkthrough
AzureAdmin for the username and pass@word1 for the password.
The script New-TestLabEnvironment.ps1 continues with the setup. It executes the following tasks for you:

Create an affinity group to associate all the workloads to be deployed with.
The name of the affinity group is based on the provided service name in the command line, for
example mfalab in our configuration, with the added suffix "aff, resulting for example in
mfalabaff in our configuration.
Create a cloud service for these workloads.
Similarly to the affinity group name, the name of the cloud service is based on the provided
service name in the command line with the added suffix "svc, for example mfalabsvc in our
configuration.
Create an account storage to store the VHDs of the workloads as blobs.
The name of the account storage is based on the provided service name in the command line with
the added suffix "stor, for example mfalabstor in our configuration.
Create a VNET for the workloads.
The name of the VNET is based on the provided service name in the command line with the added
suffix "vnet, for example mfalabvnet in our configuration. The address space is 10.0.0.0/8.
DC1
IP: 10.0.2.4
EDGE1
IP: 10.0.1.4
ADFS1
IP: 10.0.2.5
Active Directory Domain Services (AD DS)
Domain Name Services (DNS)
Internet Information Services (IIS)
Active Directory Certficates Services (AD CS)
Internet Information Services (IIS)
Subnet1 (10.0.1.0/24): mfalabvnet-subnet1
VNET: mfalabvnet
Cloud Service: mfalabsvc
Subnet2 (10.0.2.0/24): mfalabvnet-subnet2
HttpsIn

By default, the name of the above Subnet1 is -subnet1 prefixed by the name of the VNET, for
example mfalabvnet-subnet1 in our configuration. The address space is 10.0.1.0/24 by default.
Likewise, the name of the above Subnet2 is -subnet2 prefixed by the name of the VNET, for
example mfalabvnet-subnet2 in our configuration. The address space is 10.0.2.0/24 by default.
Create a DC1 virtual machine of small size based on the latest available Windows Server 2012 R2
image, add a second disk for the AD DS role service, install the AD DS role service, and finally
install Active Directory Domain Services (AD DS) to make the DC1 computer a domain controller in
Windows Server 2012 R2. This action upgrades the AD DS schema as part of the domain controller
creation.
Create a domain-joined ADFS1 virtual machine of small size based on the latest available Windows
Server 2012 R2 image, and install the Active Directory Certificates Services (AD CS) role service
and install an Enterprise CA (PKI) along with Internet Information Services (IIS). The Active
Directory Federation Services (AD FS) role service will be installed later on this machine and
referred as to adfs.litware369.com.
Create an Internet-facing domain-joined EDGE1 virtual machine of small size based on the latest
available Windows Server 2012 R2 image, and install Internet Information Services (IIS). The
default web site on this machine will be later referred as to www.litware369.com. As already
mentioned, a public endpoint for HTTPS (HttpsIn) is defined for that purpose as part of the script
configuration.
The script leverages the remote Windows PowerShell capabilities along with the Windows Server
automation with Windows PowerShell to setup the above virtual machines.
Note To learn about the Windows PowerShell command line and scripting environment, see the TechNet
Script Center
42
.

Note For information about installing, learning, using, and customizing Windows PowerShell, see the
Microsoft TechNet article Scripting with Windows PowerShell
43
.

Note For information about what scripts are and how to run them in Windows PowerShell, see the
Microsoft TechNet article RUNNING SCRIPTS
44
. This article includes basic information about creating scripts and
configuring your computer to run scripts.

Note For information on Windows Server Automation with Windows PowerShell, see the eponym
Microsoft TechNet article
45
. This article provides references to install and configure the various role services.
If needed to accommodate your own configuration, the script New-TestLabEnvironment.ps1 enables you to
customize the VNET and VM details:

PS C:\Scripts> .\New-TestLabEnvironment.ps1 -ServiceName "mfatest" -Location "North Europe" `
-DomainControllerName "dc1" -DCVMSize "Small" -FQDNDomainName "litware369.com" -NetBIOSDomainName "LITWARE369" `

42
TechNet Script Center: http://go.microsoft.com/fwlink/p/?linkid=320211&clcid=0x409
43
SCRIPTING WITH WINDOWS POWERSHELL: http://go.microsoft.com/fwlink/p/?linkid=320210&clcid=0x409
44
RUNNING SCRIPTS: http://go.microsoft.com/fwlink/p/?linkid=320627&clcid=0x409
45
WINDOWS AND WINDOWS SERVER AUTOMATION WITH WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/dn249523.aspx

-MemberServerName "adfs1" -MemberVMSize "Small" -StandaloneServerName "edge1" StandaloneVMSize "ExtraSmall" `
-VNetAddressPrefix "10.0.0.0/8" -Subnet1AddressPrefix "10.0.1.0/24" -Subnet2AddressPrefix "10.0.2.0/24"

At the end of the script, you should have an up and running base configuration that we will
leverage in the next steps. The next sections imply that you have in place such an environment.
Furthermore, to externally resolve the adfs.litware369.com and www.litware369.com FQDN names and
point to the above cloud service in Windows Azure, you will need to create the following CNAME records
in your DNS zone (e.g. litware369.com in our configuration) of your domain registrar. The exact method
depends on the chosen domain registrar.
You will need to externally resolve these FQDN names for the Web Application Proxy (WAP)
respectively the optional Multi-Factor Authentication Server Mobile App Web service.
Name Type Value TTL
adfs CNAME mfalabsvc.cloudapp.net 3 hours
www CNAME mfalabsvc.cloudapp.net 3 hours

Configuring the domain controller
To configure the domain controller, proceed with the following steps:
1. Opening a remote desktop connection on the domain controller.
2. Configuring public DNS forwarders.
3. Creating DNS records.
4. Creating a group Managed Service Account (gSMA).
5. Creating test accounts.
6. Allowing test accounts to log on locally.
The following subsections describe in the context of our test lab environment each of these steps.
Opening a remote desktop connection on the domain controller
To open a remote desktop connection on the DC1 computer, proceed with the following steps:
1. Open a browsing session and navigate to the Windows Azure management portal at
https://manage.windowsazure.com.
2. Sign in with your administrative credentials to your Windows Azure subscription.
3. On the left pane of the Windows Azure management portal, click VIRTUAL MACHINES.


4. On the virtual machine page, at the top, ensure VIRTUAL MACHINE INSTANCES is selected.
5. Select the dc1 machine and click CONNECT at the tray of the bottom.

6. Click Open. A Remote Desktop Connection dialog brings up.

7. Check Dont ask me again for connections to this computer and click Connect.
8. A Windows Security dialog brings up.
9. Log on as LITWARE369\AzureAdmin with pass@word1 as password.

10. Another Remote Desktop Connection dialog brings up.

11. Check Dont ask me again for connections to this computer and click Yes.
The connection is then established to the remote desktop.

Configuring public DNS forwarders
The Windows PowerShell script used to setup our test lab environment configures the DNS server on the
DC1 computer for name resolution instead of the Windows Azure-provided name resolution.
We must ensure that our DNS server is configured to use the root hints if no forwarders are available so
that we can correctly resolve name over the Internet in our test lab environment.
Note For more information on the root hints, see the eponym page ROOT SERVERS
46
.
To configure the DNS server to use the root hints, proceed with the following steps:
1. Open a Windows PowerShell command prompt, and run the following command to start the DNS
Manager console:

PS C:\Users\AzureAdmin> dnsmgmt.msc
PS C:\Users\AzureAdmin>

The DNS Manager console brings up.

2. In the console tree, select DC1.
3. On the Action menu, click Properties. The DC1 Properties dialog brings up.
4. Select the Forwarders tab.

46
ROOT SERVERS: http://www.iana.org/domains/root/servers


5. Ensure that Use rot hints if no forwarders are available is checked.
6. Click OK and close the DNS Manager console.
7. From the above Windows PowerShell command prompt, type the following command to validate
the resolution with the root hints:

PS C:\Users\AzureAdmin> dnscmd /ipvalidate /roothints 192.5.5.241

. completed successfully.
Raw Flags ResultCode NoTcp RTT IP Address
---------------------------------------------------------------------------
00001000 0 Success 0 10 192.5.5.241
Command completed successfully.


You should see Success as the result code.

Creating DNS records
To create a DNS record for adfs and www, proceed with the following steps:
1. Open a remote desktop session as per previous section.
2. Open an elevated Windows PowerShell command prompt and run the following command to add
a A record for adfs:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -ZoneName "litware369.com" -A -Name "adfs" -IPv4Address "10.0.2.5"

PS C:\users\AzureAdmin>

Important note If the DNS resolution of the AD FS service endpoint is performed through CNAME record
lookup instead of through an A record lookup, you will be repeatedly prompted for credentials later in this lab
during sing-in to Office 365. For more information, see the Microsoft TechNet article 2461628
47
A FEDERATED USER IS
REPEATEDLY PROMPTED FOR CREDENTIALS DURING SIGN-IN TO OFFICE 365, WINDOWS AZURE, OR WINDOWS INTUNE.

Note For more information on the DNS cmdlets, see the Microsoft TechNet article DOMAIN NAME SYSTEM
(DNS) SERVER CMDLETS IN WINDOWS POWERSHELL
48
.
3. Run the following command to add a CNAME record for www:

PS C:\users\AzureAdmin> Add-DnsServerResourceRecord -CName -Name "www" -HostNameAlias "edge1.litware369.com" -ZoneName
"litware369.com"

Creating a group Managed Service Account (gSMA)
A group Managed Service Account (gMSA) account will be required during the AD FS installation and
configuration. The benefit of using a gMSA is its auto-negotiated password update feature.
Note For more information, see the blog post NEW FEATURES IN ACTIVE DIRECTORY DOMAIN SERVICES IN WINDOWS
SERVER 2012, PART 8: GROUP MSAS (GMSAS)
49
.
To create the gMSA account, proceed with the following steps:
1. From the above elevated Windows PowerShell command prompt, run the following command to
verify whether the KDS Root Key has been created in your domain to enable gMSA in your
domain:

PS C:\users\AzureAdmin> Get-KdsRootKey

2. If it has not been created (the output displays no information), run the following command to
create the key:

PS C:\users\AzureAdmin> Add-KdsRootKey EffectiveTime (Get-Date).AddHours(-10)

Guid
----
7d5decb2-6c35-2b0c-6286-8055e413f2a5


47
2461628 A FEDERATED USER IS REPEATEDLY PROMPTED FOR CREDENTIALS DURING SIGN-IN TO OFFICE 365, WINDOWS AZURE, OR WINDOWS INTUNE:
http://support.microsoft.com/kb/2461628
48
DOMAIN NAME SYSTEM (DNS) SERVER CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/jj649850.aspx
49
NEW FEATURES IN ACTIVE DIRECTORY DOMAIN SERVICES IN WINDOWS SERVER 2012, PART 8: GROUP MSAS (GMSAS):
http://blogs.dirteam.com/blogs/sanderberkouwer/archive/2012/09/04/new-features-in-active-directory-domain-services-in-
windows-server-2012-part-8-group-msas-gmsas.aspx


Note For more information, see the Microsoft TechNet article KEY DISTRIBUTION SERVICE (KDS) IN WINDOWS
POWERSHELL
50
.

PS C:\users\AzureAdmin> New-ADServiceAccount FsGmsa -DNSHostName adfs.litware369.com -ServicePrincipalNames
http/adfs.litware369.com

Creating test accounts
We will now create a test group and test user accounts in our domain litware369.com and add one of the
user account to the group account. These accounts are used to complete the walkthroughs later in this
document.
To create the test user accounts proceed with the following steps:
1. Open an elevated Windows PowerShell command prompt, and run the following command to
create the user Robert Hatley with the following credentials: User name: RobertH and password:
pass@word1:

PS C:\users\AzureAdmin> Import-Module -Name ActiveDirectory
PS C:\users\AzureAdmin> New-ADUser Name "Robert Hatley" -SamAccountName "roberth" -DisplayName "Robert Hatley" -
AccountPassword (ConvertTo-SecureString pass@word1 -AsPlainText Force) -ChangePasswordAtLogon $false -
PasswordNeverExpires $true -Enabled $true -UserPrincipalName roberth@litware369.com" -GivenName "Hatley" -Surname
"Robert"

2. Run the following command to create the user Janet Schorr with the following credentials: User
name: User name: JanetS and password: pass@word1:

PS C:\users\AzureAdmin> New-ADUser Name "Janet Schorr" -SamAccountName "janets" -DisplayName "Janet Schorr" -
AccountPassword (ConvertTo-SecureString pass@word1 -AsPlainText Force) -ChangePasswordAtLogon $false -
PasswordNeverExpires $true -Enabled $true -UserPrincipalName janets@litware369.com" -GivenName "Schorr" -Surname "Janet"

50
KEY DISTRIBUTION SERVICE (KDS) IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/jj852115.aspx

3. Run the following command to create the group Finance:

PS C:\users\AzureAdmin> New-ADGroup -Name "Finance" -SamAccountName Finance -GroupCategory Security -GroupScope Global -
DisplayName "Finance" -Description "Members of this group belong to the Litware369 Finance Division"

4. Run the following command to add the Robert Hatley account to the Finance group:

PS C:\users\AzureAdmin> Add-ADGroupMember -Identity "Finance" -Members roberth"

5. Run the following command to retrieve the security identifier (SID) of the Finance group. This
value will be needed later at the end of the document when configuring AD FS for multi-factor
authentication.

PS C:\users\AzureAdmin> Get-ADGroup -Identity "Finance"

DistinguishedName : CN=Finance,CN=Users,DC=litware369,DC=com
GroupCategory : Security
GroupScope : Global
Name : Finance
ObjectClass : group
ObjectGUID : 0582050c-ddc4-4a58-9aa7-4486b94f4b39
SamAccountName : Finance
SID : S-1-5-21-2309203066-2729394637-456832893-3109


Allowing test accounts to log on locally
By default a domain user is not allowed to log on locally on a member server like the EDGE1 computer. A
configuration of group policy can be modified so that a domain user account can log on locally on a
member sever. Though this is NOT at all recommended in production environment but for testing purpose
or in lab setup like this one this configuration can be quite handy. This configuration indeed helps where
there are only few computers.
To modify group policy settings to allow a domain user to log on locally a member server, proceed with
following steps:
1. Open an elevated command prompt if none, and run the following command:

PS C:\users\AzureAdmin> gpmc.msc

A Group Policy Management windows brings up.


2. Double-click the name of the forest, double-click Domains, and double-click the name of the
domain.

3. Right-click Default Domain Policy, and then click Edit. A Group Policy Management Editor
window brings up.


4. In the console tree, expand Computer Configuration, Policies, Windows Settings, Security
Settings, and Local Policies, and then click User Rights Assignment.
5. In the details pane, double-click Allow Logon Locally.

6. Check Define these policy settings, and then click Add User or Group. An Add User or Group
dialog brings up.

7. Click Browse to locate the account with the Select Users, Computers, or Groups dialog.


8. Under Enter the object names to select, type janets; roberth; administrators, click Check
Names, and then click OK.
9. Click OK in the Add User or Group dialog, and then click OK in the Allow log on locally
Properties dialog box.
10. Close the Group Policy Management Editor window.
11. Close the Group Policy Management window.
Configuring the root Enterprise CA
To configure the root Enterprise CA, proceed with the following steps:
1. Opening a remote desktop connection on the target computer.
2. Configuring an appropriate certificate template for SSL certificate (optional).

Opening a remote desktop connection on the target computer
To open a remote desktop connection on the ADFS1 computer, proceed as illustrated before with the DC1
computer but with the ADFS1 computer instead. As previously illustrated, log on as
LITWARE369\AzureAdmin with pass@word1 as password since ADFS1 is a domain-joined computer.

Configuring an appropriate certificate template for SSL certificate
(optional)
Services on both the ADFS1 and EDGE1 computers will require secure sockets layer (SSL) / transport layer
security (TLS).
The Web Server certificate template is the one conventionally used to request such a SSL certificate for a
domain-joined computer. Its settings are perfectly appropriated when the certificate must be installed on
the server that requests it. However, for a test lab environment, it could convenient to be able to export
both the certificate and private key. In such situation, these default settings are not suitable because they
do not allow to export the private key.
Consequently, we will configure a new certificate template that will inherit from this template, and thus
presenting the same characteristics as the original template but with the possibility to export the private
key.
To configure a certificate template for SSL certificate, proceed with the following steps:
2. From the Server Manager, click Tools and then Certification Authority. The Certification
Authority console brings up.


3. Expand the certification authority litware369-ADFS1-CA so that you can see Certificate
Templates. The name of the certification authority may differ if you have chosen another NetBIOS
domain name and another name for the ADFS1 computer.
4. Right-click Certificate Templates and then click Manage. The Certificate Templates Console
brings up.

5. In the details pane of the Certificate Templates console, right-click the Web Server template and
then click Duplicate Template. A Properties of New Template dialog brings up.


6. Select the Request Handling tab.

7. Check Allow private key to be exported.
8. Select the Security tab.


9. We must ensure the domain computer accounts will have the ability to enroll for the template. To
do so, click Add. A Select Users, Computers, Services Accounts, or Groups dialog brings up.

a. In Select Users, Computers, Service Accounts, or Groups, type Domain computers.
Click Check Names, and then click OK.
b. Ensure that the group is selected and then select the Allow checkbox that corresponds to
the Enroll permission.
10. Select the General tab.


11. Under Template display name, type a name that you want to use for the template, for example,
SSL Certificates in our configuration.
12. Click OK.
13. Close the Certificate Templates console and return to the Certificate Authority console.
14. In the console tree of the Certification Authority console, right-click Certificate Templates, click
New, and then click Certificate Template to Issue. An Enable Certificate Templates dialog
brings up.

15. In the Enable Certificate Templates dialog, select the new certificate template that you just
configured and then click OK.

Deploying the federation server
This section walks you through the deployment of the federation server on the ADFS1 computer with the
following steps:
1. Issuing a SSL/TLS certificate.
2. Installing and configuring the AD FS role service.
Note For more information, see the Microsoft TechNet article PLAN FOR AND DEPLOY AD FS FOR USE WITH SINGLE
SIGN-ON
51
.

Important note You must have domain administrator permissions to deploy the AD FS role.
Issuing a SSL/TLS certificate
The AD FS role service will require a server Secure Socket Layer (SSL) certificate. The certificate MUST have
the following attributes:
Subject Name (CN): adfs.litware369.com
Subject Alternative Name (DNS): adfs.litware369.com
Note For more information about setting up SSL certificates, see the Microsoft TechNet Wiki article
CONFIGURE SSL/TLS ON A WEB SITE IN THE DOMAIN WITH AN ENTERPRISE CA
52
.
To issue the SSL certificate, proceed with the following steps:
1. Open a remote desktop session if needed as LITWARE369\AzureAdmin.
2. Open an elevated Windows PowerShell command prompt, and run the following command:

PS C:\users\AzureAdmin.LITWARE369> Get-Certificate -Template SSLCertificates -SubjectName CN=adfs.litware369.com DnsName
adfs.litware369.com -CertStoreLocation cert:\LocalMachine\My

Status Certificate Request
------ ----------- -------
Issued [Subject]

PS C:\users\AzureAdmin.LITWARE369>

51
PLAN FOR AND DEPLOY AD FS FOR USE WITH SINGLE SIGN-ON: http://technet.microsoft.com/en-us/library/jj151794.aspx
52
CONFIGURE SSL/TLS ON A WEB SITE IN THE DOMAIN WITH AN ENTERPRISE CA:
http://social.technet.microsoft.com/wiki/contents/articles/12485.configure-ssltls-on-a-web-site-in-the-domain-with-an-enterprise-
ca.aspx


Note If you have not configured a new certificate template (e.g. the SSLCertificates in our configuration),
you can use the WebServer certificate template in lieu of in the above command.

Note For more information, see the Microsoft TechNet article AD CS ADMINISTRATION CMDLETS IN WINDOWS
POWERSHELL
53
.
3. The SSL certificate should now be imported into the Local Computer\My Store on the ADFS1
computer. Verify whether the SSL certificate has been imported by running the following
command:

PS C:\users\AzureAdmin.LITWARE369> dir Cert:\LocalMachine\My

Thumbprint Subject
---------- -------
F1DF749C3D84DFF8BE9DED211145C53F2F06D83D CN=mfalabsvc.cloudapp.net
DD6F97EAF0CE4FDB039036199136752F62C8E027 CN=litware369-ADFS1-CA, DC=litware369, DC=com
59D4CFDD539CB616B5608A555E115824BAF14E77 CN=WMSvc-ADFS1

044F380EE49583536012D77D940ACEBBCAC05B86 CN=adfs.litware369.com


The certificates are listed by their thumbprint in the Local Computer\My Store. We will be later
interested in the thumbprint of the newly issued certificate, i.e. the one whose CN equals
adfs.litware369.com, for example in our configuration:
044F380EE49583536012D77D940ACEBBCAC05B86.

53
AD CS ADMINISTRATION CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/hh848365.aspx

Installing and configuring the AD FS role service
To install and configure the AD FS role service, proceed with the following steps:
1. Open an elevated Windows PowerShell command prompt if none, and run the following
command:

PS C:\users\AzureAdmin.litware369> Install-windowsfeature adfs-federation IncludeManagementTools

Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {Active Directory Federation Services}
WARNING: To finish configuring this server for the federation server role using Windows PowerShell, see
http://go.microsoft.com/fwlink/?LinkId=224868.

PS C:\Users\AzureAdmin.LITWARE369>

2. Run the following commands to create a Windows Internal Database (WID) along with the
required gMSA account:

PS C:\users\AzureAdmin.litware369> Import-Module ADFS
PS C:\users\AzureAdmin.litware369> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" |
Select-Object -First 1).Thumbprint
PS C:\users\AzureAdmin.litware369> Install-AdfsFarm CertificateThumbprint $certificateThumbprint -
FederationServiceDisplayName "Litware369" -FederationServiceName "adfs.litware369.com" GroupServiceAccountIdentifier
"LITWARE369\FsGmsa$"

Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success


Important note The $ at the end of the gMSA account is required.


Note If this is NOT the first time you run this command, add OverwriteConfiguration.
Preparing the Internet-facing computer
To prepare the Internet facing computer, proceed with the following steps in order:
1. Opening a remote desktop connection on the target computer.
2. Allowing the domain users to open a remote session.
3. Testing the federation server configuration.
4. Issuing a SSL/TLS certificate.
5. Configuring HTTPS on the default web site.
6. Deploying the Web Application Proxy (WAP).
The following subsections describe each of these steps in the context of our test lab environment.
Opening a remote desktop connection on the target computer
To open a remote desktop connection on the EDGE1 computer, proceed as illustrated before with the DC1
computer but with the EDGE1 computer instead. As previously illustrated, log on as
LITWARE369\AzureAdmin with pass@word1 as password since EDGE1 is a domain-joined computer.

Allowing the domain users to open a remote session
We have previously modify group policy settings so that our test user accounts can log on locally on
member servers. We now need to apply the modified group policies.
To update the group policies, proceed with the following steps:
2. Open an elevated Windows PowerShell command prompt.

PS C:\users\AzureAdmin.LITWARE369> gpupdate /force
Updating policy...

Computer Policy update has completed successfully.
User Policy update has completed successfully.


In addition, we need to add our test user accounts to the local group Remote Desktop Users so that they
can open a remote desktop session on the virtual machine in Windows Azure.
To add the test user accounts to the local group Remote Desktop Users, proceed with the following
steps:
1. Open an elevated Windows PowerShell command prompt, and run the following command to add
Janet Schorr to the local group:

PS C:\users\AzureAdmin.LITWARE369> net localgroup "Remote Desktop Users" /add "LITWARE369\janets"
The command completed successfully.


2. Run the following command to add Robert Hatley to the local group:

PS C:\users\AzureAdmin.LITWARE369> net localgroup "Remote Desktop Users" /add "LITWARE369\Roberth"
The command completed successfully.


Testing the federation server configuration
Before testing the configuration, you need to configure your browser settings to trust the federation server
role by adding your federation service name (for example in our configuration,
https://adfs.liteware369.com) to the browsers local intranet zone.
To configure the browser settings accordingly on the EDGE1 computer, proceed with the following steps:
1. Close the current remote desktop connection and open a new one on the EDGE1 computer as
LITWARE369\JanetS with pass@word1 as password.
2. Start Internet Explorer and select Internet Options on the Tools menu. An Internet Options
dialog pops up.

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

4. Click Advanced. A Trusted sites 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.
To verify that a federation server on ADFS1 is operational, proceed with the following steps:
1. Open a browsing session on ADFS1 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 SSL errors or
warnings, your federation server is operational.

2. You can alternatively navigate to the metadata exchange endpoint, which offers an XML service
description:
https://adfs.litware369.com/adfs/services/trust/mex

3. You can alternatively navigate to the AD FS sign-in page, for example in our configuration:
https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.htm
This displays the AD FS sign-in page where you can sign in with the domain credentials.

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

Issuing a SSL/TLS certificate
The default web site will require a server Secure Socket Layer (SSL) 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): www.litware369.com
If you want to optionally deploy and test the Multi-Factor Authentication Server App Mobile Web
service along with the Multi-Factor App as illustrated at the end of this document, a SSL certificate
issued from a public certification authority is required. The exact method depends on the chosen
public certification authority. Please refer to their instructions.
If you do not want to use the Mobile App, you can instead issue such a SSL certificate with the test lab
certification authority litware369-ADFS1-CA as illustrated hereafter. With the exception of the SSL
certificate import into the Local Computer\My Store on the EDGE1 computer, the rest of the suggested
configuration doesnt differ from the one illustrated in this document.
To issue the SSL certificate with the test lab certification authority, proceed with the following steps:
1. Close the current remote desktop connection and open a new one on the EDGE1 computer as
LITWARE369\AzureAdmin with pass@word1 as password.
2. Open an elevated Windows PowerShell command prompt, and run the following command:

PS C:\users\AzureAdmin.LITWARE369> Get-Certificate -Template SSLCertificates -SubjectName CN=www.litware369.com DnsName
adfs.litware369.com, www.litware369.com -CertStoreLocation cert:\LocalMachine\My

Status Certificate Request
------ ----------- -------
Issued [Subject]


Note If you havent 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.
Configuring HTTPS on the default web site
To configure HTTPS on the default web site, proceed with the following steps:
command to add a SSL binding to the default web Site:

PS C:\users\AzureAdmin.LITWARE369> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

2. Run the following commands to associate the imported SSL certificate to the newly created SSL
binding:

PS C:\users\AzureAdmin.LITWARE369> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match
"CN\=www.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443

PS C:\Users\AzureAdmin.LITWARE369> New-Item IIS:SslBindings\0.0.0.0!443 -value $cert

IP Address Port Host Name Store Sites
---------- ---- --------- ----- -----
0.0.0.0 443 MY Default Web Site


3. Open a browsing session and navigate to the default web site at https://www.litware369.com:

Deploying the Web Application Proxy (WAP)
The Web Application Proxy (WAP) is the new proxy for AD FS in Windows Server 2012 R2.
Note For more information, see the Microsoft TechNet article WEB APPLICATION PROXY OVERVIEW
54
.
To install and configure the Web Application Proxy role service, proceed with the following steps:
command:

PS C:\Users\AzureAdmin.LITWARE369> Install-WindowsFeature Web-Application-Proxy IncludeManagementTools

Success Restart Needed Exit Code Feature Result
------- -------------- --------- --------------
True No Success {RAS Connection Manager Administration Kit...
WARNING: To finish configuring this server for the Web Application Proxy role service using Windows PowerShell, see
http://go.microsoft.com/fwlink/?LinkId=294322.


2. Run the following command to collect the credential of the LITWARE369\AzureAdmin user:

PS C:\Users\AzureAdmin.LITWARE369> $credentials = Get-Credential

cmdlet Get-Credential at command pipeline position 1
Supply values for the following parameters:
Credential

54
WEB APPLICATION PROXY OVERVIEW: http://technet.microsoft.com/en-us/library/dn280944.aspx

When prompted, enter the following credential in the dialog below and click OK:
Username: LITWARE369\AzureAdmin
Password: pass@word1

3. Run the following commands to install and configure the Web Application Proxy (WAP):

PS C:\users\AzureAdmin.litware369> $certificateThumbprint = (Get-ChildItem cert:\LocalMachine\MY -DnsName "*adfs*" |
Select-Object -First 1).Thumbprint
PS C:\users\AzureAdmin.litware369> Install-WebApplicationProxy -FederationServiceTrustCredential $credential -
CertificateThumbprint $certificateThumbprint -FederationServiceName "adfs.litware369.com"

Message Context Status
------- ------- ------
The configuration completed successf... DeploymentSucceeded Success


Note For more information, see the Microsoft TechNet article WEB APPLICATION PROXY CMDLETS IN WINDOWS
POWERSHELL
55
.
To 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 local computer and navigate to the AD FS sign-in page, for
example in our configuration:
https://adfs.litware369.com/adfs/ls/idpinitiatedsignon.htm
Note If the SSL 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-ADFS1-CA root certificate in the trusted root
certification authorities of your local machine.
As before, this displays the AD FS sign-in page where you can sign in with the domain credentials.

55
WEB APPLICATION PROXY CMDLETS IN WINDOWS POWERSHELL: http://technet.microsoft.com/en-us/library/dn283404.aspx


2. Click Sign in to verify that you can successfully be authenticated.

3. Enter the following credential and the click Sign in:
Username: LITWARE369\JanetS

The base configuration is now complete.
To avoid spending your credit when you dont work on the test lab, you can shut down the 3 VMs
(DC1, ADFS1, and EDGE1) when you dont work on the test lab.
To shut down the VMs of the test lab environment, proceed with the following steps:
1. From within the Windows Azure management portal, select VIRTUAL MACHINES on the left
pane.
2. Under VIRTUAL MACHINE INSTANCES, select edge1 and then click SHUTDOWN at the tray of
the bottom.
3. Repeat step 2 with adfs1, and then dc1.
4. Once all the allocated resources will be deallocated, the status of the VMs will then change to
Stopped (Deallocated).

To resume working on the test lab, you will then need to start in order the DC1 computer, then the ADFS1
one, and finally EDGE1.
To start the VMs of the test lab environment, proceed with the following steps:
1. From within the Windows Azure management portal, select VIRTUAL MACHINES on the left
pane.
2. Under VIRTUAL MACHINE INSTANCES, select dc1 and then click START at the tray of the
bottom.
3. Click dc1, and then select DASHBOARD.

4. Verify under quick glance that the INTERNAL IP ADDRESS is set to 10.0.2.4 in our configuration.
5. Select adfs1 on the left and then click START at the tray of the bottom.
6. Repeat step 5 with edge1.

Setting up single sign-on with the Windows
Azure AD tenant
This section provides a walkthrough on how to setup single sign-on between the on-premises Active
Directory (e.g. litware369.com) and the Windows Azure AD 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 .
Note For more information, see the Microsoft TechNet article and CONFIGURE SINGLE SIGN-ON
56
.
For the sake of simplicity, and to set up the directory synchronization and the federation between the on-
premises infrastructure of our test lab and the litware369.onmicrosoft.com tenant in the cloud, we will
leverage as much as possible the available Windows PowerShell cmdlets to manage Windows Azure AD
(see later in this document).
Note For information on how to manage Windows Azure AD using Windows PowerShell, see the
Microsoft TechNet article MANAGE WINDOWS AZURE AD USING WINDOWS POWERSHELL
57
.
Consequently, the following seven main steps must be followed in order:
1. Installing the prerequisite software.
2. Connecting Windows PowerShell to Windows Azure AD.
3. Adding and verifying the domain name in the Windows Azure AD tenant.
4. Activating the directory synchronization on the Windows Azure AD tenant.
5. Installing and configuring the DirSync tool.
6. Verifying the synchronization on the Windows Azure AD tenant.
7. Verifying the single sign-on with the Windows Azure AD tenant.
Unless noticed otherwise, all the instructions should be done on the ADFS1 computer.
Installing the prerequisite software
Disabling the IE Enhanced Security Configuration (ESC)
The installation of the prerequisite software implies to download files from the Internet and should
consequently be authorized.

56
CONFIGURE SINGLE SIGN-ON: http://technet.microsoft.com/en-us/library/hh967628.aspx
57
MANAGE WINDOWS AZURE AD USING WINDOWS POWERSHELL: http://aka.ms/aadposh

Since the ADFS1 computer is intended to run on a test lab environment, the IE Enhanced Security
Configuration could be disabled for the course of the installation operations.
To disable the IE Enhanced Security Configuration (ESC), proceed with the following steps:
1. Open a remote desktop session to the ADFS1 computer.
2. On ADFS1, log on as the domain administrator LITWARE369\AzureAdmin.
commands:

PS C:\Users\AzureAdmin.LITWARE369> $adminKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A7-37EF-
4b3f-8CFC-4F3A74704073}"
PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path $adminKey -Name "IsInstalled" -Value 0
PS C:\Users\AzureAdmin.LITWARE369> $userKey = "HKLM:\SOFTWARE\Microsoft\Active Setup\Installed Components\{A509B1A8-37EF-
4b3f-8CFC-4F3A74704073}"
PS C:\Users\AzureAdmin.LITWARE369> Set-ItemProperty -Path $userKey -Name "IsInstalled" -Value 0
PS C:\Users\AzureAdmin.LITWARE369> Stop-Process -Name Explorer

Installing the Microsoft Online Sign-In Assistant (SIA)
The Windows PowerShell script of the quick start guide doesnt point to the latest version of the Microsoft
Online Services Sign-In Assistant (SIA) 7.0, which is 7.250.4551.0 as of this writing. So we will install it
manually.
Note The Microsoft Online Services Sign-In Assistant (SIA) 7.0 provides end user sign-in capabilities to
Microsoft services such Office 365. In the context of this paper, the MOS SIA is used to authenticate users to
these services through a set of dynamic link library files (DLLs) and a Windows service as described in the
community article DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA)
58
.

58
DESCRIPTION OF MICROSOFT ONLINE SERVICES SIGN-IN ASSISTANT (MOS SIA): http://community.office365.com/en-us/w/office/534.aspx

To install the Microsoft Online Sign-In Assistant (MOS SIA) 7.0, proceed with the following steps:
1. Still from the domain administrator LITWARE369\AzureAdmin session, open a browsing session
and navigate to the following link: Microsoft Online Services Sign-In Assistant for IT Professionals
59

and click Download.
2. In the Choose the download you want page, check msoidcli_64bit.msi and click Next.

The Microsoft Online Services Sign-in Assistant Setup wizard opens.

3. On the license terms page, select I accept the terms in the License Agreement and Privacy
Statement and click Install.

4. On the completion page, click Finish.
Installing Windows Azure Active Directory Module for Windows
PowerShell
The Windows Azure Active Directory Module for Windows PowerShell is a download for managing your
organizations data in Windows Azure AD.

59
Microsoft Online Services Sign-In Assistant for IT Professionals BETA: http://go.microsoft.com/fwlink/?LinkId=286152

Note A Windows PowerShell "module" is a package that contains Windows PowerShell commands,
cmdlets, providers, functions, variables, and aliases. The Windows Azure Active Directory Module for Windows
PowerShell installs a set of cmdlets specifically designed for Windows Azure AD tenant-based administration. For
more information, see the article MANAGE WINDOWS AZURE AD BY USING WINDOWS POWERSHELL
60
.
Administrative privileges are needed on the local computer in order to install the Windows Azure Active
Directory Module.
To install the module, proceed with the following steps:
1. Whilst still being remotely logged as LITWARE369\AzureAdmin on the ADFS1 computer, use the
following link download the module: Windows Azure Active Directory Module for Windows
PowerShell (64-bit version)
61
.
2. Click Run to execute it (AdministrationConfig-EN.msi). The wizard Windows Azure Active
Directory Module for Windows PowerShell Setup pops up.

3. On the Welcome page, select the Next option.

4. On the License Terms page, select I accept the terms in the License Terms and click Next.

60
MANAGE WINDOWS AZURE AD BY USING WINDOWS POWERSHELL: http://aka.ms/aadposh
61
Windows Azure Active Directory Module for Windows PowerShell (64-bit version):
http://go.microsoft.com/fwlink/p/?linkid=236297


5. On the Install Location page, select the defaults for the installation location and click Next.

6. On the Ready to Install page, click Install.

7. On the completion page, click Finish option.
Connecting Windows PowerShell to Windows Azure AD
The next step consists in opening the Windows PowerShell from Windows Azure Active Directory for
Windows PowerShell and connect the Windows PowerShell to the online domain using the administrator
account credentials of your subscription.

To connect Windows PowerShell to Windows Azure AD, proceed as follows:
1. Open a remote desktop session to the ADFS1 computer if needed and log on as the domain
administrator LITWARE369\AzureAdmin.
2. Double click the shortcut Windows Azure Directory Module for Windows PowerShell on the
desktop. A Windows PowerShell command prompt brings up.
3. From the Windows PowerShell command prompt, run the following command;

PS C:\Users\AzureAdmin.LITWARE369\Desktop> Connect-MsolService

You will be then prompted for your administrator account credentials.

4. In the Windows PowerShell Credential Request window that opens up, provide the credentials
for the Office 365 Enterprise global administrator account such as:
Username: admin@litware369.onmicrosoft.com
Password: ****************
5. If you were not on the AD FS federation server, you would normally need to execute the command
Set-MsolADFSContext to set an AD FS context server. This command prompts for the host name
of an AD FS server.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> Set-MsolADFSContext

cmdlet Set-MsolADFSContext at command pipeline position 1
Supply values for the following parameters:
Computer: adfs1
PS C:\Users\AzureAdmin.LITWARE369\Desktop>

You do NOT need to execute this cmdlet when you are on the ADFS1 computer.
Adding and verifying the domain name in the Windows Azure
AD tenant
This section walks you through the process of adding a federated domain (e.g. litware369.com) in a
Windows Azure AD tenant (e.g. litware369.onmicrosoft.com). The process consists in the following four
steps:
1. Adding the local UPN suffix as domain in the Windows Azure AD tenant.
2. Adding the domain verification record to the external DNS.
3. Verifying the domain name in the Windows Azure AD tenant.

4. Verifying the domain status in the Windows Azure management portal.
Note For more information, see the Microsoft TechNet article SET UP A TRUST BETWEEN AD FS AND WINDOWS
AZURE AD
62
.
Adding the local UPN suffix as domain in the Windows Azure AD
tenant
To add the local UPN suffix (e.g. litware369.com) as domain in the Windows Azure AD tenant, proceed with
1. Connect Windows PowerShell to Windows Azure AD as per above eponym section.
2. From the Windows PowerShell command prompt, run the following command. This New-
MsolFederatedDomain cmdlet adds a new top-level domain, as illustrated here with
litware369.com, (or subdomain) that will be configured for single sign-on, a.k.a. federated
authentication.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> New-MsolFederatedDomain DomainName litware369.com
WARNING: Verify litware369.com domain ownership by adding a DNS TXT record with
a text value of MS=ms58060785 or a DNS MX record targeting
ms58060785.msv1.invalid with a priority of 32767 at your domain registrar. For
more information, see "Create a DNS record at your domain name registrar"
located here http://g.microsoftonline.com/0BL10EN/118

The results of the cmdlet provides the verification information that should be created in your
domain registrar to prove the ownership of the DNS domain. The information to add consists in a
TXT record, for example in our configuration:
Alias or host: litware369.com
Value: MS=ms58060785
TTL: 1 hour

62
SET UP A TRUST BETWEEN AD FS AND WINDOWS AZURE AD: http://technet.microsoft.com/en-us/library/jj205461.aspx

Adding the domain verification record to the external DNS
For the added UPN suffix domain, add a text record for the domain that matches the verification
information to external, public DNS.
Note For more information on this process, including detailed steps for several popular domain name
registrars, see the Microsoft TechNet article VERIFY A DOMAIN
63
.
For illustration purposes, we use the Go Daddy registrar in our test lab environment.
Note For more information on verifying a domain Go Daddy, see the eponym Microsoft TechNet article
VERIFY A DOMAIN AT GO DADDY
64
.
To add the TXT record, proceed with the following steps:
1. Open a browsing session with the browser of your choice and navigate to
http://www.godaddy.com/ and click Log In. in the upper right corner. A Log in dialog appears.

2. Enter your credentials.
3. On the right end side of the green header bar, click on your Account Name and select Visit My
Account. The My Account page opens.

63
VERIFY A DOMAIN: http://technet.microsoft.com/en-us/library/jj151788.aspx
64
VERIFY A DOMAIN AT GO DADDY: http://technet.microsoft.com/en-us/library/jj151773.aspx


4. On the Products tab, at the end of the DOMAINS row, click Launch.
5. On the Domains page, find the domain name that youre verifying, in our case litware369.com.
6. Click the domain name, in our case LITWARE369.COM. The Domain Details page opens in a new
tab in your browser.

7. Click DNS in the toolbar, and then DNS Manager. A DNS Manager opens in a new tab in your
browser.
8. Select your domain and Edit Zone. The Zone File Editor page opens.
9. Click the Add Record option, which is under your domain name in the upper left.

10. When you click Add Record, the Add DNS Record dialog appears.
11. Click the down arrow for the Record type: box and choose TXT (Text).

a. For TXT Name:, type @.
b. For TXT Value:, type MS= followed by the verification value provided by the script:
MS=ms58060785 in our case.
c. For TTL:, leave the value set to 1 Hour.
12. Click OK to close the dialog.
13. Click Save Zone File to save your new TXT record. A Confirm dialog appears and click OK.
14. Click OK.
To check the above DNS record for TXT entries for our unverified domain, open a Windows PowerShell
command prompt and run the following command:

PS C:\Users\AzureAdmin.LITWARE369> nslookup -type=TXT litware369.com 209.244.0.3
Server: resolver1.level3.net
Address: 209.244.0.3

Non-authoritative answer:
litware369.com text =

"MS=ms58060785"

If you see the TXT entry, you can continue with the next section.
Note You can specify one of the name server of your DNS zone instead of the external DNS server used
above (209.244.0.3). In our illustration with GoDaddy.com, see the article FINDING YOUR HOSTING ACCOUNT'S NAME
SERVERS
65
to determine the name servers. For our litware369.com zone, the name servers are
ns09.domaincontrol.com (216.69.185.5) and ns10.domaincontrol.com (208.109.255.5).

65
FINDING YOUR HOSTING ACCOUNT'S NAME SERVERS: http://support.godaddy.com/help/article/6795

Verifying the domain name in the Windows Azure AD tenant
To verify the domain name in the Windows Azure AD tenant (e.g. litware369.onmicrosoft.com), proceed
1. Connect Windows PowerShell to Windows Azure AD as per above eponym section if needed.
2. From the Windows PowerShell command prompt, rerun the cmdlet New-MsolFederatedDomain
a second time, specifying the same domain name to finalize the process, for example
litware369.com in our test lab environment.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> New-MsolFederatedDomain DomainName litware369.com
Successfully added litware369.com domain.

Note The domain could also have been added from the Windows Azure management portal (or from the
Microsoft Office 365 portal) as well. The steps would have be identical and the domain would still have to be
verified in the same way.
Verifying the domain status in the Windows Azure management
portal
After the above steps are completed, you can verify that the domain was added correctly and is set for
single sign-on via the Windows Azure management portal.
To verify the domain status in the Windows Azure management portal, proceed with the following steps:
3. On the left pane of the Windows Azure management portal, click ACTIVE DIRECTORY.

4. Click the domain that you just added, for example Litware369 in our configuration, and then select
DOMAINS.


5. Confirm that the STATUS of the domain is marked as Verified, and the SINGLE SIGN-ON as
Configured.
When the domain is configured for single sign-on (federated), you will no longer have the option to add
the domain suffix litware369.com to the Windows Azure AD/Office 365 user accounts. The users will need
to be created on-premises in order for them to have the federated domain name available to them. You
can still create accounts directly in the cloud, for example in litware369.onmicrosoft.com, but they cannot
have the federated domain name litware369.com assigned to them unless they are created on-premises.
Activating the directory synchronization on the Windows
Azure AD tenant
To activate the directory synchronization on your Windows Azure AD tenant, proceed with the following
steps:
1. Connect Windows PowerShell to Windows Azure AD as per above eponym section if needed.
2. From the Windows PowerShell command prompt, run the following command and type Y when
prompted:

PS C:\Users\AzureAdmin.LITWARE369\Desktop> Set-MsolDirSyncEnabled EnableDirSync $true

Confirm
Continue with this operation?
[Y] Yes [N] No [S] Suspend [?] Help (default is "Y"): Y

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

Note For more information, see the Microsoft TechNet article ACTIVATE DIRECTORY SYNCHRONIZATION
66
.
Installing and configuring the DirSync tool
This final configuration step enables to configure and activate the Directory Synchronization (DirSync) tool.
The DirSync tool is a custom, specialized implementation of Microsoft Forefront Identity Manager (FIM)
2010 that is configured to synchronize accounts between your on-premises domain (e.g. litware369.com)
and a corresponding Windows Azure AD domain.
Note For more information, see the Microsoft TechNet article SET UP YOUR DIRECTORY SYNC COMPUTER
67
.
To download, install, and configure the DirSync tool, proceed with the following steps:
1. Connect Windows PowerShell to Windows Azure AD as per above eponym section.
2. Run the following command to create a DirSyncAgent@litware369.onmicrosoft.com account with
administrative privileges:
Important note This account will be used as the ongoing synchronization account and must not be
configured in the synchronized litware369.com domain our default domain litware369.onmicrosoft.com for the
Windows Azure AD tenant represents a good choice -, and must be set to not have its password expire.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> $user = New-MsolUser DisplayName DirSync Agent UserPrincipalName
DirSyncAgent@litware369.onmicrosoft.com FirstName DirSync LastName Agent AlternateEmailAddresses
admin@litware369.onmicrosoft.com Password pass@word1 PasswordNeverExpires $true ForceChangePassword $false
PS C:\Users\AzureAdmin\Desktop>Add-MsolRoleMember RoleName Company Administrator RoleMemberObjectId $user.ObjectId

3. Close the Windows PowerShell command prompt.
4. Open a browsing session and use the following link to download and install the DirSync tool:
Windows Azure Active Directory Sync tool 64 bit
68
.

5. Click Run to download the DirSync tool (dirsync.exe). The Windows Azure Active Directory Sync
Setup wizard brings up.

66
ACTIVATE DIRECTORY SYNCHRONIZATION: http://technet.microsoft.com/en-us/library/dn144766.aspx
67
SET UP YOUR DIRECTORY SYNC COMPUTER: http://technet.microsoft.com/en-us/library/dn144767.aspx
68
Windows Azure Active Directory Sync tool 64 bit: http://go.microsoft.com/fwlink/?LinkID=278924


6. Click Next. Follow the instructions in the Setup wizard.

7. On the Microsoft Software License Terms page, select I accept and click Next.

8. On the Select Installation folder page, click Next. The installation starts. When installing
components, the wizard will install a local SQL Server Express instance to support the
synchronization. The installation for the most part will be invisible as it runs.


9. When the installation completes, click Next.

10. On the Finished page, ensure Start Configuration Wizard now is selected, and then click Finish.
The Windows Azure Active Directory Sync tool Configuration Wizard dialog brings up.

11. Click Next.


12. In the Windows Azure Active Directory Credentials page, provide the
DirSyncAgent@litware369.onmicrosoft.com credentials as prompted, and click Next.

13. In the Active Directory Credentials page, provide the LITWARE369\AzureAdmin credentials as
prompted, and click Next.

14. In the Hybrid Deployment page, leave Enable Hybrid Deployment unselected and click Next.


15. In the Password Synchronization page, leave Enable Password Sync unselected and click Next.
The configuration of the DirSync tool starts.

16. Click Next.

17. In the Finished page, ensure Synchronize your directories now is selected and click Finish to
start synchronization. A dialog brings up.


18. Click OK.
19. Log off and log on again as the domain administrator LITWARE369\AzureAdmin.
Verifying the synchronization on the Windows Azure AD
tenant
To verify the synchronization on the Windows Azure AD tenant, proceed with the following steps:

4. Click the domain that you just added, for example Litware369 in our configuration, and then select
USERS.

20. Confirm that both Janet Schorr and Robert Hatley are listed under DISPLAY NAME and that
their SOURCE FROM is marked as Local Active Directory.

Note If you need to troubleshoot the installation of the DirSync tool, see the Microsoft TechNet article
2684395
69
HOW TO TROUBLESHOOT WINDOWS AZURE ACTIVE DIRECTORY SYNC TOOL INSTALLATION AND CONFIGURATION WIZARD
ERROR MESSAGES for more information.
You can use the Directory Synchronization Windows PowerShell cmdlet to force synchronization. The
cmdlet is installed when you install the DirSync tool. To force the directory synchronization, proceed with
1. On the ADFS1 computer, navigate to the directory synchronization installation folder located here:
%ProgramFiles%\Windows Azure Active Directory Sync.
2. Double-click DirSyncConfigShell.psc1 to open a Windows PowerShell window with the cmdlets
loaded.
3. In the Windows PowerShell command prompt, run the following command:

PS C:\Program Files\Windows Azure Active Directory Sync> Start-OnlineCoexistenceSync

Verifying the single sign-on with the Windows Azure AD
tenant
To verify the single sign-on with the Windows Azure AD tenant (e.g. litware369.onmicrosoft.com), proceed
1. Close the current remote desktop connection if any on the EDGE1 computer and open a new one
as LITWARE369\JanetS with pass@word1 as password.
2. Open a browsing session and navigate to the Microsoft Online Portal at
https://portal.microsoftonline.com.

69
2684395 HOW TO TROUBLESHOOT WINDOWS AZURE ACTIVE DIRECTORY SYNC TOOL INSTALLATION AND CONFIGURATION WIZARD ERROR MESSAGES:
http://support.microsoft.com/kb/2684395


3. Log on with the Janet Schorr test account credentials:
Username: janets@litware369.com
4. Click inside Password. 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 Fiddler2
70
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 there results show the AD FS endpoint information.
If single sign-on is correctly set up, you should be automatically redirected to the ADFS1
computer, and then redirected back to the portal after a successful seamless authentication
with your local user credentials thanks to the Windows Integrated Authentication. At the end of
the process, you should have a seamless access to the signed in user settings in Office 365.

70
Fiddler2: http://www.fiddler.com


This is expected for the test user as in fact you have not assigned a license to the test user.
You are now in a position to install and configure the Multi-Factor Authentication Server
environment on your on-premises test lab environment.

Testing and evaluating the Multi-Factor
Authentication Server
This walkthrough provides instructions for configuring multi-factor authentication in AD FS in Windows
Server 2012 R2. It is based on the on-premises test lab environment deployed in Windows Azure as per
previous sections.
Note For the purpose of this document, it leverages the existing walkthrough WALKTHROUGH GUIDE: MANAGE
RISK WITH ADDITIONAL MULTI-FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS
71
, adapt it to the Office 365 context in
lieu of the sample application ClaimApp, and extend it to illustrate the deployment of additional Windows Azure
Multi-Factor Authentication components, namely the Users portal, the SDK, and the Mobile Application web
service. For more information, see the Microsoft TechNet article OVERVIEW: MANAGE RISK WITH ADDITIONAL MULTI-
FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS
72
.
It consists in the following seven steps that must be followed in order:
1. Creating a Multi-Factor Authentication Provider via the Windows Azure Portal.
2. Downloading the Multi-Factor Authentication Server.
3. Installing the Multi-Factor Authentication Server on the federation server.
4. Configuring multi-factor authentication on the federation server.
5. Installing the Multi-Factor Authentication SDK (optional).
6. Deploying the Multi-Factor Authentication User portal (optional).
7. Deploying the Multi-Factor Authentication Server Mobile App Web service (optional).
Creating a Multi-Factor Authentication Provider via the
Windows Azure Portal
To create a Multi-Factor Authentication Provider via the Windows Azure Portal, proceed with the following
steps:
1. Open a browsing session from your local machine and navigate to the Windows Azure
management portal at https://manage.windowsazure.com.
2. Sign in with your administrative credentials.

71
WALKTHROUGH GUIDE: MANAGE RISK WITH ADDITIONAL MULTI-FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS:
http://technet.microsoft.com/en-us/library/dn280946.aspx
72
OVERVIEW: MANAGE RISK WITH ADDITIONAL MULTI-FACTOR AUTHENTICATION FOR SENSITIVE APPLICATIONS: http://technet.microsoft.com/en-

4. On the active directory page, at the top, click MULTI-FACTOR AUTH PROVIDERS.

4. Click CREATE A NEW MULTI-FACTOR AUTHENTICATION PROVIDER or click NEW in the tray at
the bottom, and then select APP SERVICES, ACTIVE DIRECTORY, MULTI-FACTOR AUTH
PROVIDER, and then QUICK CREATE.

5. Fill in the following fields and click CREATE.
a. Name. The name of the Multi-Factor Auth Provider, for example Litware369 Auth.
b. Usage Model. The usage model of the Multi-Factor Authentication Provider.
Per Authentication. This purchasing model charges per authentication, and is
typically used for scenarios that use Windows Azure Multi-Factor Authentication
in a consumer-facing application.
Per Enabled User. This purchasing model charges per enabled user, and is
typically used for employee-facing scenarios.
Note For more information on usage model, see MULTI-FACTOR AUTHENTICATION PRICING DETAILS
73
.
c. Directory. The Windows Azure AD tenant that the Multi-Factor Authentication Provider is
associated with. This is optional as the provider does not have to be linked to Windows

73
MULTI-FACTOR AUTHENTICATION PRICING DETAILS: http://www.windowsazure.com/en-us/pricing/details/multi-factor-authentication/

Azure AD when securing on-premises resources. Ensure Do not link a directory is
selected.
6. Once you click CREATE, the Multi-Factor Authentication Provider will be created and you should
see a message stating: Successfully created Multi-Factor Authentication Provider. Click OK.
Note For more information, see Microsoft TechNet article ADMINISTERING WINDOWS AZURE MULTI-FACTOR
AUTHENTICATION PROVIDERS
74
.
Next, you must download the Windows Azure Multi-Factor Authentication Server. You can do this by
launching the Windows Azure Multi-Factor Authentication Portal through the Windows Azure
management portal.
Downloading the Multi-Factor Authentication Server
All the instructions below should be done on the ADFS1 computer.
To download the Windows Azure Multi-Factor Authentication Server, proceed with the following steps:
1. Open a remote desktop connection as LITWARE369\AzureAdmin on the ADFS1 computer.
3. Sign in with your administrative credentials.
5. On the active directory page, at the top, click MULTI-FACTOR AUTH PROVIDERS.
6. Click on the Multi-Factor Authentication Provider youve just created in the section above. Then
click MANAGE at the tray of the bottom.
This launches the Windows Azure Multi-Factor Authentication portal.

74
ADMINISTERING WINDOWS AZURE MULTI-FACTOR AUTHENTICATION PROVIDERS: http://technet.microsoft.com/en-us/library/dn376346.aspx

7. Click DOWNLOADS. You navigate to a Downloads Server page.

8. Click Download to download the setup file (MultiFactorAuthenticationServerSetup.exe) for
Windows Azure Multi-Factor Authentication Server.

9. Click Save to save the setup file.
Note For more information, see Microsoft TechNet article NEW INSTALLATION OF WINDOWS AZURE MULTI-FACTOR
AUTHENTICATION SERVER
75
.
You are now ready to install on the ADFS1 computer the above setup file for the Windows Azure Multi-
Factor Authentication Server.
Installing the Multi-Factor Authentication Server on the
federation server
All the instructions below should be done on the ADFS1 computer.
To install the Windows Azure Multi-Factor Authentication Server on the ADFS1 computer, which is the
federation server in our test lab, proceed with the following steps:
1. Whilst still being remotely logged on the ADFS1 computer as LITWARE369\AzureAdmin, double-
click the downloaded setup file (MultiFactorAuthenticationServerSetup.exe) to begin the
installation. A Multi-factor Authentication Server setup wizard brings up.

75
NEW INSTALLATION OF WINDOWS AZURE MULTI-FACTOR AUTHENTICATION SERVER: http://technet.microsoft.com/en-


2. Ensure that the destination folder is correct and click Next.

3. Once the installation complete, click Finish. As indicated, this launches the Multi-Factor
Authentication Server Authentication Configuration wizard to configure it.

This is the topic of the next section.
Note For more information, see Microsoft TechNet article NEW INSTALLATION OF WINDOWS AZURE MULTI-FACTOR
AUTHENTICATION SERVER
76
.
You are now ready to configure the Multi-Factor Authentication Server Agent as an additional
authentication method in AD FS in Windows Server 2012 R2 for the course of this walkthrough.

76
NEW INSTALLATION OF WINDOWS AZURE MULTI-FACTOR AUTHENTICATION SERVER: http://technet.microsoft.com/en-

Configuring multi-factor authentication on the federation
server
The configuration of multi-factor authentication in AD FS in Windows Server 2012 R2 consists in two parts
as follows:
1. Configuring Windows Azure Multi-Factor Authentication as an additional authentication method.
2. Setting up the multi-factor authentication policy.
Unless noticed otherwise, all the instructions below should be done on the ADFS1 computer.
Configuring Windows Azure Multi-Factor Authentication as an
additional authentication method
To configure Windows Azure Multi-Factor Authentication as an additional authentication method on the
ADFS1 computer, proceed with the following steps:
1. The completion of the installation of the Multi-Factor Authentication Server launches the Multi-
Factor Authentication Server Authentication Configuration wizard.

2. On the Welcome page, check Skip using the Authentication Configuration Wizard, and click
Next. This closes the wizard as expected and the Multi-Factor Authentication Server user
interface (MultiFactorAuthUI) brings up.


3. To activate the Multi-Factor Authentication Server, go back to the Downloads Server page in the
Multi-Factor Authentication management portal where youve downloaded the setup file for the
Multi-Factor Authentication Server and click Generate Activation Credentials. Credentials valid
for 10 minutes are then displayed underneath.

4. Back in the Multi-Factor Authentication Server user interface, enter the credentials that were
generated and click Activate. A Join Group dialog appears.

5. Click OK. Next, the Multi-Factor Authentication Server user interface prompts you to run the
Multi-Server Configuration Wizard.

6. Select No.

Important note You can skip completing the Multi-Server Configuration Wizard given the lab
environment with only one federation server (e.g. adfs1.litware369.com) that is used to complete this
walkthrough. However, if your environment contains (a farm of) several federation servers, you must install the
Multi-Factor Authentication Server and complete the Multi-Server Configuration Wizard on each federation
server in order to enable replication between the Multi-Factor Authentication servers running on your federation
servers.

7. In the Multi-Factor Authentication Server user interface, select the Users icon.

8. Click Import from Active Directory. An Import from Active Directory window brings up.

9. Expand litware369.com, and then select Users underneath.
10. Select the Robert Hatley test account to provision it in Windows Azure Multi-Factor
Authentication, and then click Import. An Import from Active Directory dialog brings up.

11. Click OK, and then click Close.
12. Back in the Users list, select the Robert Hatley test account, and click Edit. An Edit User window
brings up.


13. Select the appropriate country code in Country Code and provide a cell phone number of this
account in Phone, make sure Enabled is checked, click Apply, and then Close.
14. Back in the Users list, select the Robert Hatley test account, and click Test. A Test User dialog
brings up.

15. Provide the credentials (e.g. pass@word1) for the Robert Hatley test account and click Test.
When the cell phone rings, press # to complete the account verification. An information dialog
confirms the successful authentication.

16. Click OK and click Close.
17. Back in the Multi-Factor Authentication Server user interface, select the AD FS icon.


18. Make sure that Allow user enrollment, Allow users to select method (including Phone call,
Text message, and Mobile app), Use security questions for fallback and Enable logging are
checked, click Install AD FS Adapter. An Install ADFS Adapter installation wizard brings up.

19. In the Active Directory page, click Next.

20. In the Launch installer page, click Next. A Multi-Factor Authentication ADFS Adapter
installation wizard brings up.

21. Click Next.

22. In the Installation Complete, click Close.

Note The Multi-Factor Authentication AD FS Adapter installation wizard creates a security group called
PhoneFactor Admins in litware369.com AD and then adds the AD FS service account of your federation service
to this group.
It is recommended that you verify on your domain controller that the PhoneFactor Admins group is indeed
created and that the AD FS service account is a member of this group. If necessary, add the AD FS service
account to the PhoneFactor Admins group on your domain controller manually. For additional details on
installing the AD FS Adapter, click the Help link in the top right corner of the Multi-Factor Authentication Server.

23. To register the adapter in the federation service on the ADFS1 computer, open a Windows
PowerShell command prompt, and run the following commands:

PS C:\Users\AzureAdmin.LITWARE369> cd C:\Program Files\Multi-Factor Authentication Server"
PS C:\Program Files\Multi-Factor Authentication Server> .\Register-MultiFactorAuthenticationAdfsAdapter.ps1
WARNING: PS0114: The authentication provider was successfully registered with the policy store. To enable this
provider, you must restart the AD FS Windows Service on each server in the farm.
PS C:\Program Files\Multi-Factor Authentication Server>

The adapter is now registered as WindowsAzureMultiFactorAuthentication (see below). As
indicated, you must restart the Active Directory Federation Services service (adfssrv) for the
registration to take effect.
24. Run the following command to restart the:

PS C:\Program Files\Multi-Factor Authentication Server> Restart-Service adfssrv
WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to stop...

WARNING: Waiting for service 'Active Directory Federation Services (adfssrv)' to start...
PS C:\Program Files\Multi-Factor Authentication Server>

25. Close the Windows PowerShell command prompt and launch the AD FS Management console
from the Tools menu of the Server Manager to finally configure Windows Azure Multi-Factor
Authentication as the additional authentication method.

26. Navigate to the Authentication Policies node, scroll down in the middle pane to the Multi-
factor Authentication section.

27. Click Edit next to the Global Settings sub-section. An Edit Global Authentication Policy window
brings up.


28. Select WindowsAzureMultiFactorAuthentication as an additional authentication method, and
then click OK.
Note You can customize the name and description of the Windows Azure Multi-Factor Authentication
method, as well as any configured third-party authentication method, as it appears in your AD FS UI, by running
the Set-AdfsAuthenticationProviderWebContent cmdlet. For more information, see the Microsoft TechNet
article SET-ADFSAUTHENTICATIONPROVIDERWEBCONTENT
77
.
Setting up the multi-factor authentication policy
To set up the multi-factor authentication policy, proceed with the following steps:
1. Open an elevated Windows PowerShell command prompt and run the following command to
retrieve the Office 365 relying party:

PS C:\Users\AzureAdmin.LITWARE369> $rp = Get-AdfsRelyingPartyTrust Name "Microsoft Office 365 Identity Platform"

2. Run the following command to specify the claim rule:

PS C:\Users\AzureAdmin.LITWARE369> $groupMfaClaimTriggerRule = 'c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Value =~ "^(?i) S-1-5-21-2309203066-2729394637-
456832893-3109$"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value =
"http://schemas.microsoft.com/claims/multipleauthn");'

77
SET-ADFSAUTHENTICATIONPROVIDERWEBCONTENT: http://technet.microsoft.com/en-us/library/dn479401.aspx

3. Run the following command to set the claim rule on the Office 365 relying party:

PS C:\Users\AzureAdmin.LITWARE369> Set-AdfsRelyingPartyTrust TargetRelyingParty $rp AdditionalAuthenticationRules
$groupMfaClaimTriggerRule

Note Make sure to replace S-1-5-21-2309203066-2729394637-456832893-3109 with the value of the SID
of your AD group Finance.
Verifying the multi-factor authentication mechanism
To verify the multi-factor authentication policy, proceed with the following steps:
1. Close the current remote desktop connection if any on the Internet-facing EDGE1 computer and
open a new one as LITWARE369\RobertH with pass@word1 as password.
2. Open a browsing session and add https://adfs.litware369.com to the Local Intranet zone as
previously done with Janet Schorr when testing the single sign-on with Office 365.
3. Navigate to the Microsoft Online Portal at https://portal.microsoftonline.com.

4. Log on with the Robert Hatley test account credentials:

Username: roberth@litware369.com
You should be automatically redirected to the ADFS1 computer. At this point, after a successful
seamless authentication with your local user credentials (thanks to the Windows Integrated
Authentication), you are prompted to undergo additional authentication because of the previously
configured multi-factor authentication policy.

The default message text is For security reasons, we require additional information to verify
your account. However, this text is fully customizable.
Note For more information about how to customize the sign-in experience, see the Microsoft TechNet
article CUSTOMIZING THE AD FS SIGN-IN PAGES
78
.

Note The text also states that A call will be placed to your phone to complete your authentication.
For more information about signing in with Windows Azure Multi-Factor Authentication and using various
options for the preferred method of verification, see Windows Azure Multi-Factor Authentication Overview
79
.
5. Click Continue. When the cell phone rings, press # to complete the account verification.
6. Since weve previously set Use security questions for fallback when installing the AD FS adapter
and because this is the first time you log on after we set the multi-factor authentication policy,
youre now invited to set four questions and provide an answer for each of them.

78
CUSTOMIZING THE AD FS SIGN-IN PAGES: http://technet.microsoft.com/en-us/library/dn280950.aspx
79
WINDOWS AZURE MULTI-FACTOR AUTHENTICATION OVERVIEW: http://technet.microsoft.com/en-us/library/dn249479.aspx


7. Set your questions, type an answer, and then click Continue when ready.
8. You are then redirected back to the portal after a successful authentication with both your local
user credentials (thanks to the Windows Integrated Authentication) and the multi-factor
authentication. At the end of the process, you should have a seamless access to the signed in user
settings in Office 365.

This is expected for the test user as in fact you have not assigned a license to the test user.
At this stage, you have successfully deployed the Windows Azure Multi-Factor Authentication
Server in your environment.

You can optionally deployed the Multi-Factor Authentication User portal and the Multi-Factor
Authentication Server Mobile App Web service.
The Multi-Factor Authentication User portal is an Internet Information Services (IIS) web site which allows
on-premises users to enroll in Windows Azure Multi-Factor Authentication and maintain their on-premises
accounts. A user may change their phone number, change their PIN, or bypass Windows Azure Multi-
Factor Authentication during their next sign on.
Users will log in to the Multi-Factor Authentication User portal using their normal on-premises username
and password and will either complete a Windows Azure Multi-Factor Authentication call or answer
security questions to complete the authentication. If user enrollment is allowed, a user will configure their
phone number and PIN the first time they log in to the Multi-Factor Authentication User portal.
The corporate administrators may be set up and granted permission to add new users and update existing
users.
The Multi-Factor Authentication Server Mobile App Web service enable the users to install the Multi-
Factor Authentication Server Mobile App on their smartphone from the Multi-Factor Authentication User
portal.
In our configuration, this supposes to first install the Multi-Factor Authentication SDK.
Installing the Multi-Factor Authentication SDK (optional)
All the instructions should be done on the ADFS1 computer.
To install the Multi-Factor Authentication SDK, proceed with the following steps:
1. Open a remote desktop connection on ADFS1 if needed and log on as LITWARE369\AzureAdmin.
2. Open the Windows Azure Multi-Factor Authentication Server.
3. Click the Web Service SDK icon.


4. Click Install Web Service SDK. An Install Web Service SDK installation wizard brings up. Follow
the instructions presented.
Note Instead of step 2 to 4, you can navigate to the folder where the Windows Azure Multi-Factor
Authentication Server is installed (e.g. C:\Program Files\Windows Azure Multi-Factor Authentication) and double-
click the MultiFactorAuthenticationWebServiceSdkSetup64.msi installation file (64-bit version).

5. Click Next.


6. ASP.NET 3.5 is already installer on the ADFS1 computer. Click Next.

7. Click Next. If the prerequisites are satisfied, the Select Installation Address page is displayed.

8. Click Next.


9. Click Close.
The Web Service SDK (PfWsSdk) is configured to be secured with an SSL certificate. We thus need to
configure HTTPS on the default web site. We already issued a adfs.litware369.com SSL certificate for the
AD FS configuration.
Configuring HTTPS on the default web site
To configure HTTPS on the default web site on the ADFS1 computer, proceed with the following steps:
command to add a SSL binding to the default web Site:

PS C:\users\AzureAdmin.LITWARE369> New-WebBinding -Name "Default Web Site" -IP "*" -Port 443 -Protocol https

2. Run the following commands to associate the already issued adfs.litware369.com SSL certificate
to the newly created SSL binding:

PS C:\users\AzureAdmin.LITWARE369> Get-ChildItem cert:\LocalMachine\MY | where { $_.Subject -match
"CN\=adfs.litware369.com" } | select -First 1 | New-Item IIS:\SslBindings\0.0.0.0!443

PS C:\Users\AzureAdmin.LITWARE369> New-Item IIS:SslBindings\0.0.0.0!443 -value $cert

IP Address Port Host Name Store Sites
---------- ---- --------- ----- -----
0.0.0.0 443 MY Default Web Site


3. Open a browsing session and navigate to the Web Service SDK (PfWsSdk) at
https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx. A Windows Security
brings up.

4. Provide the credentials for the LITWARE369\AzureAdmin administrator account such as:
Username: AzureAdmin
5. Click OK. The collection of operations supported by the Web Service SDK (PfWsSdk) should now
be listed in the .asmx page.


Deploying the Multi-Factor Authentication User portal
(optional)
Unless noticed otherwise, all the instructions should be done on the Internet-facing EDGE1 computer.
To install and configure the Multi-Factor Authentication User portal, proceed with the following steps:
2. Open a remote desktop connection on EDGE1 if needed and log on as LITWARE369\AzureAdmin.
3. Open Windows Explorer on the ADFS1 computer and navigate to the folder where Multi-Factor
Authentication Server is installed (e.g. C:\Program Files\Windows Azure Multi-Factor
Authentication). Choose the MultiFactorAuthenticationUserPortalSetup64.msi installation file as
appropriate (64-bit version) for the EDGE1 computer that the Multi-Factor Authentication Users
portal will be installed on. Copy the installation file to the EDGE1 computer.

4. On the EDGE1 computer, the setup file must be run with administrator rights. Open an elevated
command prompt as an administrator and navigate to the location where the installation file was
copied, for example the Desktop in our illustration.

PS C:\Users\AzureAdmin.LITWARE369> cd .\Desktop

5. Run the MultiFactorAuthenticationUserPortalSetup64.msi installation file.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> .\MultiFactorAuthenticationUserPortalSetup64.msi

A Multi-Factor Authentication User Portal installation wizard brings up.

6. Click Next.

7. Click Close.

8. After finishing the install of the MultiFactorAuthenticationUserPortalSetup64.msi file, browse to
C:\inetpub\wwwroot\MultiFactorAuth (or appropriate directory based on the virtual directory
name) and edit the web.config file.
9. Locate the appSettings section in the web.config file.
<?xml version="1.0"?>
<configuration>
<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="pfup.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
</configSections>
<appSettings>

<add key="USE_WEB_SERVICE_SDK" value="false"/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PATH" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PASSWORD" value=""/>
<add key="OVERRIDE_PHONE_APP_WEB_SERVICE_URL" value=""/>

</appSettings>

</configuration>

10. Set the value of the following keys as follows:
a. USE_WEB_SERVICE_SDK: true
b. WEB_SERVICE_SDK_AUTHENTICATION_USERNAME: LITWARE369\AzureAdmin
c. WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD: pass@word1
d. OVERRIDE_PHONE_APP_WEB_SERVICE_URL: https://www.litware369.com/PA (see later
in this document)
Note The username must be a member of the PhoneFactor Admins security group. Be sure to enter the
Username and Password in between the quotation marks at the end of the line, (value=""/>). It is recommended
to use a qualified username (e.g. domain\username).
11. Locate the pfup_pfwssdk_PfWsSdk setting.
<configuration>

<applicationSettings>
<pfup.Properties.Settings>

<setting name="pfup_pfwssdk_PfWsSdk" serializeAs="String">
<value>http://localhost:4898/PfWsSdk.asmx</value>

</setting>
</pfup.Properties.Settings>
</applicationSettings>
</configuration>

Change the value from http://localhost:4898/PfWsSdk.asmx to the URL of the Web Service SDK
that is running on ADFS1, e.g.
https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx in our configuration.

Note Since SSL is used for this connection, you must reference the Web Service SDK by server name and
not IP address since the SSL certificate will have been issued for the server name and the URL used must match
the name on the certificate. In our configuration, the adfs.litware369.com server name does resolve to an IP
address from the Internet-facing server EDGE1. You should otherwise add an entry to the hosts file on that server
to map the name of the Windows Azure Multi-Factor Authentication Server server to its IP address.

Note The root certification authority litware369-ADFS1-CA certificate is imported into the Trusted Root
Certification Authorities store of the EDGE1 computer that will be our Mobile App Web Service web server. Thus,
it will trust the adfs.litware369.com certificate when initiating the SSL connection.
12. Save the web.config file after changes have been made.
Important note It is helpful to open a browsing session on EDGE1 and navigate to the URL of the Web
Service SDK that was entered into the web.config file, e.g.
https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx in our configuration. If the browser
can get to the web service successfully, it should prompt you for credentials as previously illustrated. Enter the
username and password that were entered into the web.config file exactly as it appears in the file. Ensure that no
certificate warnings or errors are displayed.
To test the User portal, proceed with the following steps:
1. Open a browser session and navigate to http://www.litware369.com/MultiFactorAuth.

2. Provide the credentials (e.g. roberth and pass@word1) for the Robert Hatley test account and
click Log In. When the cell phone rings, press # to complete the account verification. After a
successful authentication, you can now manage the account settings.


Note For more information, see the Microsoft TechNet articles INSTALLING THE WINDOWS AZURE MULTI-FACTOR
AUTHENTICATION USERS PORTAL
80
and USER ENROLLMENT AND SELF-MANAGEMENT
81
.
Deploying the Multi-Factor Authentication Server Mobile App
Web service (optional)
Installing the Mobile App Web Service
To deploy the Windows Azure Multi-Factor Authentication Mobile App Web Service on the Internet-facing
EDGE1 computer, proceed with the following steps:
2. Open a remote desktop connection on EDGE1 if needed and log on as LITWARE369\AzureAdmin.
3. Open Windows Explorer on the ADFS1 computer and navigate to the folder where the Windows
Azure Multi-Factor Authentication Server is installed (e.g. C:\Program Files\Windows Azure Multi-
Factor Authentication). Choose the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi
installation file as appropriate (64-bit version) for the EDGE1 computer that Mobile App Web
Service will be installed on. Copy the installation file to the EDGE1 computer.

80
INSTALLING THE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION USERS PORTAL: http://technet.microsoft.com/en-
81
USER ENROLLMENT AND SELF-MANAGEMENT: http://technet.microsoft.com/en-us/library/dn394292.aspx

4. On EDGE1, the above installation file must be run with administrator rights. The easiest way to do
this is to open a command prompt as an administrator and navigate to the location where the
installation file was copied, for example the Desktop in our illustration.

PS C:\Users\AzureAdmin.LITWARE369> cd .\Desktop

5. Run the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi installation file.

PS C:\Users\AzureAdmin.LITWARE369\Desktop> .\MultiFactorAuthenticationMobileAppWebServiceSetup64.msi

A Multi-Factor Authentication User Portal installation wizard brings up.

6. Change the Site if desired and change the Virtual directory to a short name such as PA. A short
virtual directory name is recommended since users must enter the Mobile App Web Service URL
into the mobile device during activation. Click Next.

7. Click Close.
8. After finishing the installation of the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi
file, browse to C:\inetpub\wwwroot\PA (or appropriate directory based on the virtual directory
name) and edit the web.config file.
9. Locate the appSettings section in the web.config file.
<configuration>

<configSections>
<sectionGroup name="applicationSettings" type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089">
<section name="pfup.Properties.Settings" type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false"/>
</sectionGroup>
</configSections>
<appSettings>

<add key="WEB_SERVICE_SDK_AUTHENTICATION_USERNAME" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PATH" value=""/>
<add key="WEB_SERVICE_SDK_AUTHENTICATION_CLIENT_CERTIFICATE_FILE_PASSWORD" value=""/>

</appSettings>

</configuration>

10. Set the value of the following keys as follows:
a. WEB_SERVICE_SDK_AUTHENTICATION_USERNAME: LITWARE369\AzureAdmin
b. WEB_SERVICE_SDK_AUTHENTICATION_PASSWORD: pass@word1
Note The username must a member of the PhoneFactor Admins security group. Be sure to enter the
Username and Password in between the quotation marks at the end of the line, (value=""/>). It is recommended
to use a qualified username (e.g. domain\username).
11. Locate the pfpaws_pfwssdk_PfWsSdk setting.
<configuration>

<applicationSettings>
<pfpaws.Properties.Settings>

<setting name="pfpaws_pfwssdk_PfWsSdk" serializeAs="String">
<value>http://localhost:4898/PfWsSdk.asmx</value>

</setting>
</pfpaws.Properties.Settings>
</applicationSettings>
</configuration>

Change the value from http://localhost:4898/PfWsSdk.asmx to the URL of the Web Service SDK
that is running on ADFS1, e.g.
https://adfs.litware369.com/MultiFactorAuthWebServiceSdk/PfWsSdk.asmx in our configuration.
12. Save the web.config file after changes have been made.
Note Since the Windows Azure Multi-Factor Authentication User Portal is already installed on the EDGE1
computer, the username, password and URL to the Web Service SDK can be copied from the User Portals
web.config file.
13. Open a browsing session and navigate to the URL where Mobile App Web Service was installed
(e.g. https://www.litware369.com/PA). Ensure that no certificate warnings or errors are displayed as
illustrated hereafter.


Configuring the Mobile App Settings in the Windows Azure Multi-
Factor Authentication Server
All the instructions should be done on the ADFS1 computer.
To configure the Mobile App Settings in the Windows Azure Multi-Factor Authentication Server, proceed
2. Launch the Windows Azure Multi-Factor Authentication Server.
3. Click on the User Portal icon.


1. On the Settings tab, type the Multi-Factor Authentication User portal URL, for example
https://www.litware369.com/MultiFactorAuth in our configuration.
2. Check Allow user enrollment.
3. Check Allow users to select method. Under Allow users to select method, check Mobile app.
Without this feature enabled, end users will be required to contact the Help Desk to complete
activation for the Mobile App. Also check Phone call and Text message.
4. Check Allow users to activate mobile app.
5. Click on the Mobile App icon.


6. In Mobile App Web Service URL, type the URL being used with the virtual directory which was
created when installing the MultiFactorAuthenticationMobileAppWebServiceSetup64.msi file, for
example https://www.litware369.com/PA in our configuration.
7. In Account name, an account name may be entered in the space provided. This company name
will display in the mobile application. If left blank, the name of your Multi-Factor Auth Provider
created in the Windows Azure management portal will be displayed, for example Litware369
Auth in our configuration. Type Litware369 Inc. for example.
Activating the Windows Azure Multi-Factor Authentication App for
End Users
To activate the Mobile App, proceed with the following steps:
1. Download the Multi-Factor Authentication application from your app store. This application is
available for Windows Phone
82
, iOS
83
, and Android
84
. Once the Multi-Factor Authentication app has
been downloaded and is installed, you can activate it for multiple accounts.
2. Open a browsing session from any computer connected to the Internet and navigate to the Multi-
Factor Authentication Users Portal at https://www.litware369.com/MultiFactorAuth.

82
Multi-Factor Authentication app on Windows Phone Store: http://www.windowsphone.com/en-
us/store/app/phonefactor/0a9691de-c0a1-44ee-ab96-6807f8322bd1
83
Multi-Factor Authentication app on iTunes: https://itunes.apple.com/us/app/phonefactor/id475844606?mt=8
84
Multi-Factor Authentication app on Google Play: https://play.google.com/store/apps/details?id=com.phonefactor.phonefactor

3. Provide the credentials (e.g. roberth and pass@word1) for the Robert Hatley test account and
click Log In. When the cell phone rings, press # to complete the account verification.

4. Under My Account on the left, click Activate Mobile App.

5. Click Generate Activation Code. (You can instead contact an administrator who will generate an
activation code for them.)


6. Switch to your mobile device
7. Open the Multi-Factor Authentication application.
8. In the mobile app, click New (+).
Note The interface will differ slightly between mobile OS apps.
9. Activate the Windows Azure Multi-Factor Authentication App by entering the above activation
code and URL or by scanning the barcode picture.
10. Switch the authentication method to Mobile App or contact an administrator who will change it
for them
Note For more information, see Microsoft TechNet article DEPLOYING THE WINDOWS AZURE MULTI-FACTOR
AUTHENTICATION SERVER MOBILE APP WEB SERVICE
85
.
This concludes the guided tour of Windows Azure Multi-Factor Authentication Server in the context of
Windows Azure AD federated users as well as this paper.
For the configuration of the advanced settings and reports of the service, please refer to the
aforementioned whitepaper LEVERAGE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION WITH WINDOWS AZURE
AD
86
.

85
DEPLOYING THE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION SERVER MOBILE APP WEB SERVICE: http://technet.microsoft.com/en-
86
USE WINDOWS AZURE MULTI-FACTOR AUTHENTICATION SERVER FOR WINDOWS AZURE AD SINGLE SIGN-ON WITH AD FS:
http://www.microsoft.com/en-us/download/details.aspx?id=36391


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

Leverage Multi Factor Authentication Server On Your Premises

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Leverage Multi Factor Authentication Server On Your Premises

Încărcat de

Drepturi de autor:

Formate disponibile

Leverage Windows Azure Multi-Factor

Authentication Server for Windows Azure

S-ar putea să vă placă și