Host Active Directory Federation Services in Azure

Objective

Learn how to migrate a customer's existing AD FS infrastructure to Azure Infrastructure-as-a-Service (IaaS).

Scenario

Contoso Pharmaceuticals, being a forward-thinking company, has moved their office productivity configuration to the hosted Office 365 environment. As part of the initial configuration, they created a simple AD FS configuration on-site. However, they did not do so in a highly-available configuration, and as such, they have had occasional downtime with user authentication, such as during on-premises server scheduled maintenance. Their CTO, Corey Carter, has asked why, if they are hosting their mail "in the cloud," do they need a server in the Contoso on-premises datacenter to be working to access their mail. After discussion with a Microsoft specialist, they have decided to host their AD FS environment in Azure Infrastructure-as-a-Service virtual machines, improving their high availability stance and removing a direct on-premises dependency for Office 365 access.

Virtual Machines

Client
ADFS
RRAS
DC1
WAP

Exercise 1 : Redeem Your Azure Promo Code

In this exercise you will:

Set up your Azure Account
Scenario: To perform this lab, you must have an Azure account set up that you can modify. To set up up this account, use the promotional code visible in the Content tab of the lab interface. This exercise will walk you through the steps for redeeming the code.

Open Site (Azure Pass)

Open the Edge or IE browser, and navigate to http://microsoftazurepass.com. Use the Azure Promo Code provided in the top right hand corner of the Lab UI under the content pane and follow the steps on screen to complete the Azure Trial account creation. Once your account is created please proceed to the next excercise.

Exercise 2 : Creating an Azure Network and Gateway

In this task, you will create an Azure virtual network that will be where you connect the Azure-hosted virtual machines to each other and to the on-premises network. The Azure network will have a unique private address space, independent of the on-premises address space, to ensure simplified routing. It is a requirement for Azure-to-on-premises site-to-site VPN configurations that there not be an overlap between the two address spaces.

Connect to the Azure portal

On the Client virtual machine, signed in as tedhynes@contoso.com, launch Internet Explorer, and navigate to https://portal.azure.com.
Sign in using your Azure account

When prompted, enter your Azure credentials to sign in to the portal. If you are prompted to save your credentials, click No, not for this site. If you are prompted about using local storage, click Yes.
Begin creation of a new resource

In the upper-left of the Azure Portal, click the + New button.
Search for "virtual network"

In the Search the marketplace text box of the New blade (a blade is one of the vertical sections of the Azure Portal interface), type virtual network, and press Enter.
Select "Virtual network"

In the Everything blade that opens, click Virtual network.
Select the deployment model

At the bottom of the Virtual network blade, confirm that Select a deployment model has Resource Manager selected, and click Create.

The Azure Resource Manager (ARM, "v2") Portal allows you to create certain resources in the Classic deployment model. The Classic (ASM, "v1") portal, however, is often a better choice for such operations.
Configure the new virtual network

The Create virtual network blade will open. Enter the following values for the network configuration, then click Create.

Name Contoso-Azure-Network

Address space 172.16.0.0/16

Subnet name GatewaySubnet

Subnet address range 172.16.0.0/29

Resource group Create new

New resource group name ADFSLab

Location North Central US

Make sure you name the initial subnet with the exact name given.

Connecting to an ARM virtual network with a site-to-site VPN requires a virtual network gateway. That gateway (a fault-tolerant RRAS implementation) requires a small subnet with the special name GatewaySubnet as part of the overhead of running the gateway. You're setting that as the first subnet in the virtual network so as to ensure we it is taken care of, in this case at the low end of the network.

You are also creating a resource group; details of resource group management are outside of the scope of this lab. The lab uses a single one to make it easier to remove all the resources later.
Wait for the network to be deployed

After you click Create, a quick validation check will be done. Assuming your values are accurate, you will receive a quick set of messages indicating your deployment has begun. Soon after, the deployment should succeed. You will see an indication on the upper right of the portal that shows a new notification is available (the icon is a bell); when you click the icon, you should see a notice reading Deployments succeeded.
Navigate to your resource group list

Continue by looking to the upper-left of the portal, and clicking Resource groups.

You are going to find the network to modify through the parent resource group. Later in the lab, you will find resources through other paths in the portal.
Select the ADFSLab resource group

In the list of resource groups, click the ADFSLab resource group.
Select the virtual network

In the list of resources in the resource group, click Contoso-Azure-Network.
Open the subnet list

In the Settings blade, under General, click Subnets.
Start adding a subnet

At the top of the Subnets blade, click the + Subnet button
Configure the DMZ subnet

On the Add subnet blade, enter the following values, then click OK.

Name DMZ

Address range 172.16.1.0/24 (should be the default)

Network security group None (should be the default)

Route table None (should be the default)
Start adding another subnet

At the top of the Subnets blade, again click the + Subnet button.
Configure the Internal subnet

On the Add subnet blade, enter the following values, then click OK. Begin the next task while the addition completes.

Name Internal

Address range 172.16.2.0/24 (should be the default)

Network security group None (should be the default)

Route table None (should be the default)
Start adding a virtual network gateway

In the upper-left of the portal, click the + New button again.
Search for "virtual network gateway"

On the New blade, In the Search the marketplace textbox, type virtual network gateway, and press Enter.
A site-to-site connection in ARM consists of the following components:
1. A virtual network gateway, which is the Azure end of the VPN.
2. A local network gateway, which is the Azure representation of the on-premises network, and includes the public IP address of the on-premises VPN endpoint as well as the list of IPv4 networks that are in Azure.
3. A connection, which is the IPsec tunnel definition (including the user-defined shared key) for the VPN between the two gateways.
Select "Virtual network gateway"

On the Everything blade, click the first match, Virtual network gateway.
Choose to create the gateway

At the bottom of the Virtual network gateway blade, click Create.

Configure the gateway

On the Create virtual network gateway blade, enter or select the following values (as appropriate), then click Create. After you click Create, a brief validation will occur, and you will receive a quick set of messages indicating your deployment has begun. Do not wait for the gateway to be completely deployed before continuing.

Name	Contoso-Azure-Gateway
Virtual network	Click Choose a virtual network, Contoso-Azure-Network
Public IP address	Click Choose a public IP address, + Create new. Enter the name Contoso-Azure-Gateway (may be the default) and click OK
Gateway type	VPN
VPN type	Route-based (should be the default)
Subscription	(leave the default)
Resource group	ADFSLab (should be fixed)
Location	North Central US (should be the default)

Exercise 3 : Creating the Virtual Machines

In this exercise, you will create the virtual machines that will be used as domain controllers, AD FS servers, and Web Application Proxy (WAP) servers.

IMPORTANT: Note that in order to be more like a real production environment, you will be creating a redundant pair of VMs for each role. If you would like to save some time, at the cost of not replicating a production-ready scenario, you can skip creating the second virtual machine from each pair. If you do, be sure to remember when in later steps (such as when you create the load balancer back-end pools) that you only created one of the machines.

Begin creating a storage account

Again, in the upper-left of the Azure portal, click + New.
Search for "storage account"

On the New blade, In the Search the marketplace textbox, type storage account, and press Enter.
Select "Storage account"

On the Everything blade, select the Storage account entry from the Web + Mobile category.
Choose to create the storage account

On the Storage account blade, click Create.

Configure the storage account

On the Create storage account blade, enter the following values, and then click Create. Wait for the indication that the deployment has succeeded before continuing.

Name	Enter a name in the form adfslabyyyymmddhhmm, where yyyy is the year, mm is the month number, dd is the date, hh is the current hour, and mm is the current minute. If the name is in use, try a slightly different name.
Deployment model	Resource manager (should be the default)
Account kind	General purpose (should be the default)
Performance	Standard (should be the default)
Replication	Locally-redundant storage (LRS)
Subscription	(leave the default)
Resource group	Use existing, ADFSLab (select from the dropdown)
Location	North Central US (should be the default)

Make sure you follow the instructions to make a unique storage account name, and not one with the yyyy, etc. placeholders!

Storage accounts require globally uniqe names across all of Azure, relative to the offiering, Enterprise or Government. (The namespaces for Azure Enterprise and Azure Government are differnt.) You are using what is hopefully a unique name.

Begin creating the AzureADFS1 VM

Again, in the upper-left of the portal, click + New.
Search for the AzureADFS1 OS

On the New blade, In the Search the marketplace textbox, type 2012 r2, and press Enter.
Choose the AzureADFS1 source image

On the Everything blade, click on Windows Server 2012 R2 Datacenter.

Azure pre-defined images only offer Windows Server 2012 and 2012 R2 in the Datacenter edition. A customer is welcome to upload their own image for Standard edition, if they'd like to "bring your own license" for virtual machines and their license agreement permits such use.
Confirm the AzureADFS1 deployment model

On the Windows Server 2012 R2 Datacenter blade, ensure Select a deployment model reads Resource Manager, and click Create.
Configure the basics for AzureADFS1

In the Basics blade, enter the following information, and click OK:

Name AzureADFS1

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US

Please note you will need to select the HDD option from the hard drive selection drop down menu.

You may ask, "What happens if I forget the password I use here, or I enter it wrong?" There is an Azure VM extension that allows resetting the local administrator password, assuming the VM Agent has been installed in the VM.
Choose the AzureADFS1 VM size

On the Choose a size blade, if A2 Standard is listed, click it. Otherwise, click View all, then scroll down to A2 Standard and click it.

In either case, click Select after clicking the size.

While retail customers and trial customers see their local pricing estimates on each size, Enterprise Agreement customers typically will not, and instead will need to refer to their agreement. However, the relative costs of, for example, D3 versus D4 are generally consistent between retail pricing and Enterprise Agreement pricing.

An important difference between Basic VMs and Standard VMs is the ability to scale and load balancer Standard size VMs. You will be load-balancing the AD FS and WAP machines, so they will be Standard sizes. The domain controllers will be Standard for consistency sake, although they are legitimate choices for Basic sizes in some lower-performance-requirement scenarios.

Configure the remaining AzureADFS1 settings

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click Internal
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then + Create new, and for Name, enter ADFS, then click OK

Be careful with the virtual machine settings. Some settings, such as the availability set membership, cannot be easily changed later.

The reasoning behind some of these choices is as follows:

Disk type: Changing to SSD storage would automatically change the VM size to one that supports SSDs, but is significantly more expensive. It's not justifiable in this case.
Public IP address: ARM virtual machines do not require public IP addresses. For machines here exposed to the outside, they will be behind an external load balancer, which has a public IP.
Network security group: You will revist this later.
Monitoring: Monitoring by default includes boot monitoring, which logs the boot porcess and captures console screenshots.
Availability: A detailed explanation of availability sets is beyond the scope of this lab. Load balanced virtual machines must be in the same availability set (virtual machines not in an availability set cannot be load balanced with an Azure load balancer.)

Confirm the AzureADFS1 configuration

A brief validation will occur on the Summary blade. When the configuration is validated, review it to be sure the values look correct, then click OK. Move on to the next task immediately; do not wait for this to complete.

Create the AzureADFS2 VM

Repeat all of the steps used to create the AzureADFS1 VM, except with the following values. (Note that when you click + New, you can find the Windows Server 2012 R2 Datacenter entry under Recent.) Move on to the next task immediately; do not wait for this to complete.

On the Basics blade, enter the following information, and click OK:

Name AzureADFS2

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US
Again choose size A2 Standard when prompted.

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click Internal
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then click ADFS

Create the AzureDC1 VM

On the Basics blade, enter the following information, and click OK:

Name AzureDC1

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US
This time, choose size A1 Standard when prompted.

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click Internal
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then + Create new, and for Name, enter DCs, then click OK

Note the size change - the remaining VMs are A1 Standard.

Create the AzureDC2 VM

On the Basics blade, enter the following information, and click OK:

Name AzureDC2

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US
Again, choose size A1 Standard when prompted.

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click Internal
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then click DCs

Create the AzureWAP1 VM

On the Basics blade, enter the following information, and click OK:

Name AzureWAP1

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US
This time, choose size A1 Standard when prompted.

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click DMZ
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then + Create new, and for Name, enter WAPs then click OK

Make sure you place this VM into the correct subnet - it is in the DMZ subnet.

Create the AzureWAP2 VM

On the Basics blade, enter the following information, and click OK:

Name AzureWAP2

User name localadmin

Password ADFS4Contoso!

Subscription (leave the default)

Resource group Use existing, ADFSLab (select from the dropdown)

Location North Central US
Again, choose size A1 Standard when prompted.

On the Settings blade, enter the following information, and then click OK:

Disk type	Standard (should be the default)
Storage account	Click, and then click your created storage account (should be the default)
Virtual network	Click, and then click Contoso-Azure-Network (should be the default)
Subnet	Click, and then click DMZ
Public IP address	Click, and then click None
Network security group	Click, and then click None
Diagnostics	Enabled (should be the default)
Diagnostics storage account	Click, and then click your created storage account (should be the default)
Availability set	Click, and then click WAPs

Exercise 4 : Creating the Site-to-Site VPN Connection

In this exercise, you will complete the Site-to-Site VPN configuration between your Azure virtual network and the Contoso on-premises network.

Request the Contoso on-premises public IP

On the RRAS VM, signed in as tedhynes@contoso.com, ADFS4Contoso!, on the desktop, double-click Get Public IP.
Read the public IP

After a short time, a dialog box will appear with the Contoso on-premises public IP address. Make a note of this IP address for future reference.
Begin creating the local network gateway

Begin on the Client VM, signed in as tedhynes@contoso.com, ADFS4Contoso!, with the Azure Portal active.
In the upper left of the Azure portal, click + New.
Search for "local network gateway"

In the search textbox, type local network gateway and press Enter.
Select "local network gateway"

On the Everything blade, click on Local network gateway.
Request creation of the local network gateway

On the Local network gateway blade, click Create.

Configure the local network gateway

On the Create local network gateway blade, enter the following values for your local network gateway, and click Create:

Name	ContosoCleveland
IP Address	The on-premises public IP as determined earlier (change to the RRAS VM temporarily if necessary)
Address space	192.168.1.0/24, press Tab twice, then 192.168.2.0/24
Subscription	(leave the default)
Resource Group	Use existing, ADFSLab (select from the dropdown)
Location	North Central US (should be the default)

Wait for the local network gateway to deploy

Wait for the deployment to complete. It should happen relatively quickly.
Begin creating the VPN connection

In the upper-left of the Azure portal, click + New.
Search for "connection"

In the search textbox, type connection, and press Enter.
Select "Connection"

On the Everything blade, click Connection.
Request creation of the connection

On the Connection blade, click Create.
Configuire the connection

In the Basics tab, select the following values, and click OK:

Connection type Site-to-site (IPsec)

Subscription (leave the default)

Resource Group Use existing, ADFSLab (select from the dropdown)

Location North Central US (should be the default)

Configure the rest of the connection

On the Settings blade, select the following settings, and click OK.

Virtual network gateway	Click Choose a virtual network gateway, and then click Contoso-Azure-Gateway
Local network gateway	Click Choose a local network gateway, and then click ContosoCleveland
Connection Name	Contoso-Azure-Gateway-ContosoCleveland (should be the default)
Shared key (PSK)	contosopsk (this is case sensitive)

Confirm the connection configuration

On the Summary blade, review the information to ensure it is correct, and then click OK.
View the full list of resources

In the Azure portal, in the quick launch area on the left, click All resources.
Search for the gateway

In the textbox on the All resources blade, type gateway, and press Enter.
Select your virtual network gateway

In the list, click Contoso-Azure-Gateway of type Virtual network gateway.
Find the public IP of the gateway

On the Contoso-Azure-Gateway blade, in the Essentials section, locate the Public IP address. You will use this shortly.
Launch the RRAS console on RRAS

If the RRAS VM is not your active VM, change to it. If not signed in, sign in to the VM using the tedcarter@contoso.com account. If Server Manager is not running, launch it. On the Tools menu, click Routing and Remote Access.

The exact details of configuring the on-premises side of the VPN are specific to the customer's device and other configuration factors. Here, you're using an RRAS on-premises configuration that's been created for your use.
Locate the Network Interfaces node

In the Routing and Remote Access tree, click RRAS, Network Interfaces.
Open the Contoso Azure interface properties

Double-click the Contoso Azure interface.
Set the Azure public IP

On the General tab of the Contoso Azure Properties dialog, enter the public IP address of your Azure gateway, and click OK.
Enable the Azure connection

Right-click on the Contoso-Azure interface, and click Enable. (Depending on your VM configuration, this step may not be required.)
Complete the VPN connection

Right-click the interface again, and click Connect. The Connection State should change to Connected relatively quickly.

Exercise 5 : Promoting the domain controllers

In this exercise, you will configure the on-premises Active Directory installation to be ready for the promotion of the Azure domain controllers, reconfigure the Azure network to use on-premises DNS, and promote the Azure domain controllers.

Launch Active Directory Sites and Services on DC1

Change to the DC1 VM, and sign in to it if it is not signed in. If Server Manager is not launched, launch it. Next, on the Tools menu, click Active Directory Sites and Services.
Open Sites

In Active Directory Sites and Services, double-click Sites.
Begin creating a new site

Right-click Sites, and click New Site....
Name the site and select the site link

In the New Object - Site dialog, enter the name Azure, select the DEFAULTIPSITELINK, and click OK.
Acknowledge the next steps dialog

In the Active Directory Domain Services dialog, click OK.
Open Subnets

In the tree view, double-click Subnets.
Begin creating a new subnet

Right-click Subnets, and click New Subnet….
Define the subnet

Enter 172.16.0.0/16 for the Prefix, select the Azure site, and click OK.
Navigate to the resource group list

Change to the Client VM, and unlock it if it is locked. On the left of the Azure portal, click Resource groups.
Select the ADFSLab resource group

In the resource group list, click ADFSLab.
Close Settings

Close the Settings blade when it automatically opens.
Open Contoso-Azure-Network

Locate Contoso-Azure-Network in the list, and click it.

Make sure you do not click Contoso-Azure-Gateway.
Open the DNS server list

On the Settings blade, under General, click DNS servers.
Configure the primary DNS server

In the DNS servers blade, click Custom DNS, enter 192.168.1.100 for the Primary DNS server, click on the Secondary DNS server textbox, and click Save.

You are setting the primary DNS server to allow the new domain controllers to locate the on-premises domain controllers.

You are clicking on the Secondary DNS server textbox to get the Azure interface to enable the Save button.
Wait for the virtual network to save

Wait for the virtual network to save.
Navigate to the virtual machine list

On the left of the portal, click Virtual Machines.
Open the AzureDC1 VM settings

Locate the AzureDC1 VM, and click it.
Open the network interface list

In the Settings blade (which should automatically open), under General, click Network Interfaces.
Locate the private IP address

Locate the PRIVATE IP ADDRESS for the VM (it is very likely 172.16.2.6).

If you created all VMs, in the order they were listed, then they should have all the listed IP addresses. If not, make sure you make note of the differences.
Start Remote Desktop Connection

On the Client1 taskbar, click the pinned shortcut for the Remote Desktop Connection client.
Connect to AzureDC1

For Computer, enter the IP address of AzureDC1.

You are using the IP address here because the new servers are not listed in DNS yet.

We are signing in to do a restart instead of using the Azure portal because this allows validating that the VM deployed correctly through a basic RDP connection.
Sign in as the local administrator account

When prompted, click Use another account. For User name, enter localadmin; for Password, enter ADFS4Contoso!. Then, click OK.
Trust the automatic certificate

When prompted about trusting the certificate, click Don't ask me again for connections to this computer, and then click Yes.
Trust the local network

In the Remote Desktop Connection window, when prompted about trusting the network, click Yes. (If you miss this prompt, don't worry about it.)
Start PowerShell as Administrator

In the remote desktop session, right-click PowerShell on the taskbar, right-click Windows PowerShell, and click Run as administrator.

Be sure you're working in the remote desktop session here, and not on the Client1 VM.
Restart the computer

Type Restart-Computer, and press Enter.

We are restarting the computer as it is the fastest way for the VM to register the DNS change. There are other ways to register the change, but Azure virtual machines restart fast enough that it's reasonable to do that here.
Go back to the virtual machine list

Using the scrollbar at the bottom of Internet Explorer, scroll to the left, until the Virtual Machines list is again in view.
Restart AzureDC2

Following the same process as you did for AzureDC1, restart AzureDC2.
Reconnect to AzureDC1

As you did before, use Remote Desktop Connection to connect to AzureDC1, and launch PowerShell as an Administrator.
Add necessary roles to AzureDC1

In PowerShell, type Install-WindowsFeature -Name AD-Domain-Services,DNS, and press Enter.

There are several steps in PowerShell through this exercise. The lab environment offers the Action function (indicated by the lightning bolt to the right of the task text), which will type the PowerShell into the virtual machine for you.

There are several steps in PowerShell through this exercise. The lab envcironment offers the Action function (indicated by the lightning bolt to the right of the task text), which will type the PowerShell into the virtual machine for you.
```
Install-WindowsFeature -Name AD-Domain-Services,DNS
```
Minimize the AzureDC1 connection

While the installation proceeds, click the Minimize button on the Remote Desktop Connection Bar at the top of the connection.
Reconnect to AzureDC2

As you did before, use Remote Desktop Connection to connect to AzureDC2, and launch PowerShell as an Administrator.
Add necessary roles to AzureDC2

In PowerShell, type Install-WindowsFeature -Name AD-Domain-Services,DNS, and press Enter.
```
Install-WindowsFeature -Name AD-Domain-Services,DNS
```
Change back to AzureDC1

Minimize the AzureDC2 Remote Desktop Connection, and change to the AzureDC1 Remote Desktop Connection. The installation should be finished on it. If not, wait for the installation to complete before continuing.
Create a credential request

In PowerShell, type $cred=Get-Credential, and press Enter.
```
$cred=Get-Credential
```
Enter your promotion credentials

When prompted, enter User name: tedhynes@contoso.com and Password: ADFS4Contoso!, and click OK.

This dialog does not attempt to confirm the credentials. Be sure to enter them carefully, or use the Paste option on the Commands menu in the lab environment. If you make a mistake in credentials, the promotion will fail with an error indicating invalid credentials, in which case you'll need to go back to the previous step to request new credentials.

These credentials will be used to access the on-premises domain controller for promotion.
Start the promotion in PowerShell

In PowerShell, type Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'contoso.com' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Azure' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$false -Force:$true -Credential $cred, and press Enter.

In the case of very large domains or very high performance requirements, you may wish to add data disks and install the database and log files on the data disks instead of on the operating system drive.

You are using PowerShell here to avoid stepping through many wizard screens.
```
Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'contoso.com' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Azure' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$false -Force:$true -Credential $cred
```
Enter the safe mode administrator password

When prompted for the SafeModeAdministratorPassword, type P@ssw0rd!, and press Enter. When prompted to confirm the SafeModeAdministratorPassword, type P@ssw0rd!, and press Enter.
```
P@ssw0rd!
```
Minmize AzureDC1 and change to AzureDC2

While the promotion runs, minimize the AzureDC1 connection, and change to to the AzureDC2 connection.
Enter your promotion credentials

In PowerShell, type $cred=Get-Credential, and press Enter. When prompted, enter User name: tedhynes@contoso.com and Password: ADFS4Contoso!, and click OK.
```
$cred=Get-Credential
```
Start the promotion on AzureDC2

In PowerShell, type Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'contoso.com' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Azure' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$false -Force:$true -Credential $cred, and press Enter.
```
Install-ADDSDomainController -CreateDnsDelegation:$false -DatabasePath 'C:\Windows\NTDS' -DomainName 'contoso.com' -InstallDns:$true -LogPath 'C:\Windows\NTDS' -NoGlobalCatalog:$false -SiteName 'Azure' -SysvolPath 'C:\Windows\SYSVOL' -NoRebootOnCompletion:$false -Force:$true -Credential $cred
```
Enter the safe mode administrator password

When prompted for the SafeModeAdministratorPassword, type P@ssw0rd!, and press Enter. When prompted to confirm the SafeModeAdministratorPassword, type P@ssw0rd!, and press Enter.
```
P@ssw0rd
```
Wait for the promotions to finish

Wait for both domain controllers to reboot after promotion (your Remote Desktop Connection sessions will close) before continuing.

Exercise 6 : Joining the AD FS machines to the domain

In this exercise, you will join the AD FS servers to the domain, after configuring the Azure virtual network to use the new domain controllers as their DNS servers.

Return to editing the DNS servers

In the Azure portal, navigate back to the DNS servers settings for the virtual network. One way to do that is to go to the upper line of the portal, to the right of "Microsoft Azure", and click the downward arrow. Next, click the line representing the DNS settings.
Change the DNS to use the new DCs

Change the Primary DNS server to the AzureDC1 address (probably 172.16.2.6), the Secondary DNS server to the AzureDC2 address (probably 172.16.2.7), and click Save.
Wait for the change to save

Wait for the network change to save.
Find the private IP address for AzureADFS1

On the left of the portal view, click Virtual Machines. Locate AzureADFS1 in the list, and click it. In the Settings blade, click Network interfaces, and locate the PRIVATE IP ADDRESS for AzureADFS1 (probably 172.16.2.4).
Find the private IP address for AzureADFS2

On the left of the portal view, click Virtual Machines. Locate AzureADFS2 in the list, and click it. In the Settings blade, click Network interfaces, and locate the PRIVATE IP ADDRESS for AzureADFS2 (probably 172.16.2.4).
Restart the AzureADFS1 and AzureADFS2 VMs

Using Remote Desktop Connection, connect to AzureADFS1 and AzureADFS2, and restart them, as you did for AzureDC1 and AzureDC2 earlier. Remember to use the IP addresses you just found for the VMs, as they are not in DNS yet; the user name will be localadmin and the password will be ADFS4Contoso!.
Connect again to AzureADFS1

Start Remote Desktop Connection, and connect again to AzureADFS1.
Begin configuring the local server

When Server Manager launches, click Configure this local server.
Click WORKGROUP

Click WORKGROUP.
Click Change...

Click Change....
Enter the domain name

Under Member of, click the radio button for Domain:, enter contoso.com, and click OK.
Enter domain join credentials

When prompted for credentials, enter User name tedhynes@contoso.com and Password ADFS4Contoso!, and then click OK.
Accept the join dialogs and restart

Click OK in the Computer Name/Domain Changes welcome dialog. Click OK in the Computer Name/Domain Changes restart dialog. Click Close in the System Properties dialog. Finally, click Restart Now in the Microsoft Windows dialog.
Join AzureADFS2 to the domain

Following the same steps you used to join AzureADFS1 to the contoso.com domain, join AzureADFS2 to the contoso.com domain.

Exercise 7 : Configuring AD FS on the AD FS Servers

In this exercise, you will join the new, Azure-hosted AD FS servers to the existing on-premises AD FS farm.

Launch the AD FS Management tool

Change to the ADFS lab virtual machine. If not signed in, sign in as tedhynes@contoso.com, ADFS4Contoso!. If Server Manager is not running, start Server Manager. On the Tools menu, click AD FS Management.
Navigate to the Certificates view

In the AD FS Management console, double-click Service, and then double-click Certificates.
Open the Service communications certificate

Under Certificates, double-click the Service communications certificate.

In the lab environment, the on-premises certificate is from a local certificate authority. In real life, this certificate would be from a public certificate authority to avoid trust issues. When you export the certificate, you'll export the entire hierarchy, so the new AD FS servers will trust the issued certificate.
Begin exporting the certificate

In the Certificate dialog, click the Details tab, then click the Copy to File… button.
Skip the export welcome screen

On the Certificate Export Wizard welcome page, click Next.
Export the private key

On the Export Private Key page, click Yes, export the private key, and then click Next.
Export as a PFX file

On the Export File Format page, click Next.
Set the export password

On the Security page, check the Password: checkbox, enter Password: password, and Confirm password: password, and click Next.

Here, you are using a very simple password for the purposes of a lab environment. You're also not going to bother cleaning up the copies of the exported certificate from the various servers. In production, you would want to take more care around managing the certificate, as you would any SSL certificate.
Save the certificate as cert.pfx

On the File to Export page, for the File name:, enter C:\cert.pfx, and click Next.
Complete the export wizard

On the Completing the Certificate Export Wizard page, click Finish.
Accept the confirmation dialog

In the Certificate Export Wizard success dialog, click OK. Then, close the Certificate dialog.
Copy the PFX file to the clipboard

Still on the ADFS virtual machine, start File Explorer. Double-click Local Disk (C:). Left-click the cert file, and then right-click it, and click Copy.
Open the Client C drive in File Explorer

In the Address Bar, type \\client\c$ and press Enter.
Paste the PFX file

Right-click in the open area, and click Paste.
Open File Explorer on the Client VM

Change to VM Client1, and start File Explorer and double-click Local Disk (C:).
Copy the PFX file to the clipboard

Right-click on the cert file, and click Copy.
Connect to AzureADFS1 as tedhynes

Using Remote Desktop Connection, connect to AzureADFS1; however, in this case, sign in as tedhynes@contoso.com, ADFS4Contoso!.
Navigate to the Desktop in File Explorer

On AzureADFS1, start File Explorer, and click the Desktop shortcut under Favorites.
Paste the PFX file

Right-click the open space on the right of File Explorer, and click Paste.
Start an Administrator PowerS

Still on AzureADFS1, start an Administrator PowerShell.
Install AD FS

Type Install-WindowsFeature ADFS-Federation, and press Enter.
```
Install-WindowsFeature ADFS-Federation
```
Refresh Server Manager

Wait for the feature to finish installing. Then, change to Server Manager, and click Refresh.

While waiting for the feature to finish installing, you may sign in to AzureADFS2 through Remote Desktop as tedhynes@contoso.com; this will save you a little time in a later step.
Open the configuration notification

When the refresh finishes, click the Notifications icon, then click Configure the federation service on this server..
Choose to join an existing farm

When the Welcome wizard finishes loading, click Add a federation server to a federation server farm and click Next.
Point to the existing primary server

On the Connect to Active Directory Domain Services page, click Next. Then, on the Specify Farm page, enter adfs.contoso.com as the Primary Federation Server:, and click Next.
Choose to import the SSL certificate

On the Specify SSL Certificate page, click Import….
Choose the cert file

In the Open dialog, double-click the cert file.
Enter the certificate password

In the Enter certificate password dialog, type password and click OK, and then click Next.
Select a service account

On the Specify Service Account page, click Select….
Locate the service account

In the Select User or Service Account dialog, under Enter the object name to select (examples):, type svc, and click OK.
Enter the service account password

For Account Password:, enter ADFS4Contoso!, and click Next.
Review the options

On the Review Options page, click Next.
Wait for pre-requisites

On the Pre-requisite Checks page, wait for the checks to finish, then click Configure.
Wait for AD FS to finish configuration

Wait for the configuration to complete, then click Close.
Make the new machine the primary AD FS server

Change to the running PowerShell instance. Type Set-AdfsSyncProperties -Role PrimaryComputer, and press Enter.

In the lab environment, the on-premises server was configured to use Windows Internal Database for configuration storage, rather than a separate SQL database instance. This is the easier configuration to set up, however two AD FS features (SAML artifact resolution and token replay detection) require use of an external SQL database instance. In the Windows Internal Database environment, one server acts as the writable configuration copy (the primary server), and the other servers (secondary servers) automatically pull configuration updates from the primary. You are moving the primary role to an Azure-hosted VM as part of removing on-premises production dependencies.
```
Set-AdfsSyncProperties -Role PrimaryComputer
```
Configure the original AD FS server

Close the Remote Desktop Connection session. Change to the ADFS Lab VM. Launch an Administrator PowerShell. Type Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName AzureADFS1.contoso.com, and press Enter.
```
Set-AdfsSyncProperties -Role SecondaryComputer -PrimaryComputerName AzureADFS1.contoso.com
```
Again copy the PFX file to your clipboard

Change to VM Client. If File Explorer is not still open, open it. Next, double-click Local Disk (C:). Right-click on the cert file, and click Copy.
Paste the PFX file into AzureADFS2

Using Remote Desktop Connection, connect to AzureADFS2 as as tedhynes@contoso.com, ADFS4Contoso!. On AzureADFS2, start File Explorer, and click the Desktop shortcut under Favorites. Right-click the open space, and click Paste.
Install AD FS on AzureADFS2

On AzureADFS2, start an Administrator PowerShell. Type Install-WindowsFeature ADFS-Federation and press Enter. Wait for the feature to finish installing.
```
Install-WindowsFeature ADFS-Federation
```
Begin configuring AD FS

Change to Server Manager, and click Refresh. When the refresh finishes, click the Notifications icon, and then click Configure the federation service on this server..
Choose the first configuration options

When the Welcome wizard finishes loading, click Add a federation server to a federation server farm and click Next. On the Connect to Active Directory Domain Services page, click Next. On the Specify Farm page, enter AzureADFS1.contoso.com as the Primary Federation Server:, and click Next.

Notice that you are using a different primary federation server, now that you have changed the server that holds that role.
Import the SSL certificate

On the Specify SSL Certificate page, click Import…. In the Open dialog, double-click the cert file. On the Enter certificate password dialog, type password and click OK, then click Next.
Specify the service account

On the Specify Service Account page, click Select…. In the Select User or Service Account dialog, under Enter the object name to select (examples):, type svc, and click OK. For Account Password:, enter ADFS4Contoso!, and click Next.
Complete the AD FS configuration on AzureADFS2

On the Review Options page, click Next. On the Pre-requisite Checks page, wait for the checks to finish, and then click Configure. Wait for the configuration to complete, then click Close. Close the Remote Desktop Connection session.

Exercise 8 : Creating the Azure Load Balancers

In this exercise, you will create two load balancers in Azure, one for the Web Application Proxy servers (which you have not yet configured) and one for the AD FS servers. You are doing this now so that you are able to use the AD FS load balancer later, when configuring the Web Application Proxy servers.

Search for the load balancer resource provider

On the Client1 VM, change back to Internet Explorer. In the upper-left of the portal, click + New. In the search textbox, type load balancer and press Enter.
A standard Azure Load Balancer is a simple round-robin load balancer built from the following components:
- A backend pool, which represents the VMs being balanced, all of which must be in the same availability set
- An optional probe, which allow application-level monitoring of the load-balanced application through very simple health checks of either a TCP port responding to a connection request, or an HTTP request receiving a success response code (e. g. 200)... if you don't configure a probe, the basic VM health status as provided by the Azure VM Agent is used
- One or more load balancing rules, indicating the ports to be balanced against the backend pool members
- Optional direct NAT mappings from a port on the load balancer to a specific port on a specific load-balanced backend pool member (e. g. 53389 on the load balaner of 3389 on the first host in a pool)
In the ARM model, there are two forms of load balancer available:
1. External load balancers, which have a public IP address
2. Internal load balancers, which have an IP address on a virtual network
It is also possible to select from many load balancing virtual appliances in the Azure Marketplace (e. g. Kemp load balancers), or to use the Azure Traffic Manager or Azure Application Gateway offerings for load balancing in more sophisticated scenarios. Simple AD FS environments do not need the extra complexity offered by these other offerings, but larger environments and more complex web applications will find them useful.
Click Load Balancer, and begin creating it

Click Load Balancer in the selection list. Next, on the Load Balancer blade, click Create.

Configure the load balancer

On the Create load balancer blade, enter the following values, and then click Create:

Name	ADFS-LB
Scheme	Internal
Virtual network	Click Choose a virtual network, and then click Contoso-Azure-Network
Subnet	Click Choose a subnet, and then click Internal
IP address assignment	Dynamic
Subscription	(leave the default)
Resource group	Click Use existing, and then select ADFSLab from the dropdown list
Location	North Central US (should be the default)

Wait for the deployment to succeed

After a brief validation, your load balancer will begin to be created. Wait to be notified that it has been created (the deployment was successful); it should not take long.
Request the deployment log

Click on the notification message to bring up the deployment log messages.
Click to go to the properties of ADFS-LB

On the Deployments succeeded blade, click on the ADFS-LB (load-balancer) link.
Open the backend pool list

On the Settings blade, click Backend pools.
Add a backend pool

On the Backend address pools blade, click + Add.
Name the pool, then start adding VMs

For Name, enter ADFS. Next, click + Add a virtual machine.
Choose the ADFS availability set

On the Choose virtual machines blade, click Choose an availability set, and then on the Choose an availability set blade, click ADFS.
Choose the VMs

Click Choose the virtual machines, AzureADFS1, and then click the checkmark to the left of AzureADFS2 (it will be under the checkmark for AzureADFS1). Finally, click Select.
Complete VM selection

Click OK on the Choose virtual machines blade.
Finish adding the backend pool

On the Add backend pool blade, click OK.
Change to the Probes settings

Close the Backend address pools blade. Next, on the Settings blade, click Probes.

You are explcitly closing one blade from Settings before opening another, although that's not strictly necessary. The intent is clearer this way, however.
Begin adding a probe

On the Probes blade, click + Add.

Configure the probe

On the Add probe blade, enter the following values, and click OK:

Name	ADFS
Protocol	HTTP (should be the default)
Port	80 (should be the default)
Path	/adfs/probe
Interval	5 seconds (should be the default)
Unhealthy threshold	2 consecutive failures (should be the default)

Change to the load balancing rules settings

Close the Probes blade. On the Settings blade, click Load balancing rules.
Begin adding a load balancing rule

On the Load balancing rules blade, click + Add.

Configure the load balancing rule

On the Add load balancing rule blade, enter the following values, and click OK:

Name	ADFS
Protocol	TCP
Port	443
Backend port	443
Backend pool	ADFS (2 virtual machines) (should be the default)
Probe	ADFS (HTTP:80/adfs/probe) (should be the default)
Session persistence	None (should be the default)
Idle timeout (minutes)	4 (should be the default)
Floating IP	Disabled (should be the default)

As explained in the help in the Azure Portal, there is only one time you normally uise the Floating IP option, namely when configuring a SQL AlwaysOn Availability Group.

Begin adding another load balancer

On the Client1 VM, change back to Internet Explorer. In the upper-left of the portal, click + New. Under Recent, click Load Balancer.

Configure the load balancer

On the Create load balancer blade, enter the following values, and then click Create:

Name	WAP-LB
Scheme	Public
Public IP address	Click Choose a Public IP address, click + Create new, type WAP for the name, and then click OK.
Subscription	(leave the default)
Resource group	Click Use existing, and then select ADFSLab from the dropdown list
Location	North Central US (should be the default)

Wait for the deployment to succeed

After a brief validation, your load balancer will begin to be created. Wait to be notified that it has been created (the deployment was successful); it should not take long.
Request the deployment log

Click on the notification message to bring up the deployment log messages.
Click to go to the properties of WAP-LB

On the Deployments succeeded blade, click on the WAP-LB (load-balancer) link.
Open the backend pool list

On the Settings blade, click Backend pools.
Add a backend pool

On the Backend address pools blade, click + Add.
Name the pool, then start adding VMs

For Name, enter WAP. Next, click + Add a virtual machine.
Choose the WAPs availability set

On the Choose virtual machines blade, click Choose an availability set, and then on the Choose an availability set blade, click WAPs.
Choose the VMs

Click Choose the virtual machines, AzureWAP1, and then click the checkmark to the left of AzureWAP2 (it will be under the checkmark for AzureWAP1). Finally, click Select.
Complete VM selection

Click OK on the Choose virtual machines blade.
Finish adding the backend pool

On the Add backend pool blade, click OK.
Change to the Probes settings

Close the Backend address pools blade. Next, on the Settings blade, click Probes.
Begin adding a probe

On the Probes blade, click + Add.

Configure the probe

On the Add probe blade, enter the following values, and click OK:

Name	WAP
Protocol	HTTP (should be the default)
Port	80 (should be the default)
Path	/adfs/probe
Interval	5 seconds (should be the default)
Unhealthy threshold	2 consecutive failures (should be the default)

Change to the load balancing rules settings

Close the Probes blade. On the Settings blade, click Load balancing rules.
Begin adding a load balancing rule

On the Load balancing rules blade, click + Add.

Configure the load balancing rule

On the Add load balancing rule blade, enter the following values, and click OK:

Name	WAP
Protocol	TCP
Port	443
Backend port	443
Backend pool	WAP (2 virtual machines) (should be the default)
Probe	WAP (HTTP:80/adfs/probe) (should be the default)
Session persistence	None (should be the default)
Idle timeout (minutes)	4 (should be the default)
Floating IP	Disabled (should be the default)

Exercise 9 : Configuring WAP on the WAP Servers

In this exercise, you will configure the Web Application Proxy servers in Azure IaaS to act as AD FS front end servers, directly available to external users from the Internet.

Determine the AzureWAP1 private IP address

Locate the private IP address of the AzureWAP1 VM (using the same process used for AzureADFS1, etc.). (It is likely 172.16.1.4.)
Copy the cert file to the clipboard

Copy the cert file from the Client1 machine into the clipboard, as you did before.
Paste the PFX onto AzureWAP1

Connect to AzureWAP1 with Remote Desktop Connection as localadmin, ADFS4Contoso!, and paste the cert file onto the Desktop, as you did before.
Begin importing to the Local Machine store

Double-click the cert file to launch the Certificate Import Wizard. For Store Location, click Local Machine, and click Next.

Unlike the AD FS Configuration Wizard, the WAP Configuration Wizard does not allow you to import a certificate in the wizard. Thus, you are going to import the certificate outside of the wizard.
Accept the cert file

On the File to Import page, click Next.
Enter the certificate file password

On the Private key protection page, for Password:, enter password, and click Next.
Automatically select the store

On the Certificate Store page, click Next.
Finish the Certificate Import Wizard

On the Completing the Certificate Import Wizard page, click Finish.
Accept the import completion

In the Certificate Import Wizard dialog, click OK.
Begin editing the local HOSTS file

Start an Administrator PowerShell. At the prompt, type notepad C:\windows\system32\drivers\etc\hosts, and press Enter.
```
notepad C:\windows\system32\drivers\etc\hosts
```
Add a HOSTS entry

Once Notepad opens, go to the bottom of the file, and add a line for the AzureADFS1 IP address (likely 172.16.2.4) and the AD FS service name (fs.contoso.com), and then save and close the file.
Begin installing the WAP feature

Type Install-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess, and press Enter.
```
Install-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess
```
Begin configuring the WAP feature

When the feature has finished installing, switch to Server Manager and click Refresh. Click the Notifications icon, and click Open the Web Application Proxy Wizard.
Acknoweldge the WAP welcome

On the Welcome page of the Web Application Proxy Configuration Wizard, click Next.
Enter the initial WAP configuration values

On the Federation Server page, enter the following values, and then click Next:

Federation service name: fs.contoso.com

User name: tedhynes@contoso.com

Password: ADFS4Contoso!
Select the WAP certificate

On the AD FS Proxy Certificate page, under Select a certificate to be used by the AD FS proxy:, choose the *.contoso.com certificate you imported earlier, and click Next.
Accept the confirmation page

On the Confirmation page, click Configure.

Note that the generated PowerShell in the wizard has an error due to a bug in the wizard; instead of inserting a valid credential object, it shows the type name of the credential class. You would need to modify the PowerShell should you wish you use it to take this into account.
Review the WAP status page

Wait for the configuration to complete. It shouldn't take long. Then, click Close. The Remote Access Management Console will launch automatically. Notice that the Cluster Servers list shows both your new WAP installation and the on-premises WAP installation. Close the Remote Access Management Console after reviewing the configuration.
Create firewall rule

In the open PowerShell session, type New-NetFirewallRule -DisplayName "HTTP In" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow and press Enter. This adds a rule to allow the WAP load balancer probe in on port 80.
```
New-NetFirewallRule -DisplayName "HTTP In" -Direction Inbound -LocalPort 80 -Protocol TCP -Action Allow
```
Minimize AzureWAP1

Minimize the Remote Desktop Connection window (you will need the connection later).
Begin searching for the internal load balancer

At the top of the Portal, click the magnifying glass.
Select ADFS-LB

In the dropdown of recent resources, click ADFS-LB.
Locate the ADFS-LB IP

In the Essentials area, locate the Private IP address, and make a note of it for later (it is likely 172.16.2.8).
Change back to AzureADFS1

Change back to the (currently minimized) AzureADFS1 RDP session.
Change the HOSTS file

As you did before, edit the HOSTS file on AzureWAP1, except this time, change the fs.contoso.com entry to point at the internal load balancer IP address, rather than the AzureADFS1 address.

You initially used the primary server address rather than the load balancer address to ensure you were attempting to make changes against the writable copy of the AD FS configuration. If you didn't do that, the configuration might fail in a non-obvious way.
Determine the AzureWAP2 private IP address

Locate the private IP address of the AzureWAP2 VM (using the same process used for AzureADFS1, etc.). (It is likely 172.16.1.5.)
Copy the cert file to AzureWAP2

Copy the cert file from the Client1 machine into the clipboard, as you did before. Connect to AzureWAP2 with Remote Desktop Connection as localadmin, ADFS4Contoso!. Paste the cert file onto the Desktop, as you did before.
Import the cert file on AzureWAP2

Double-click the cert file to launch the Certificate Import Wizard. For Store Location, click Local Machine, and click Next. On the File to Import page, click Next. On the Private key protection page, for Password:, enter password, and click Next. On the Certificate Store page, click Next. On the Completing the Certificate Import Wizard page, click Finish. In the Certificate Import Wizard dialog, click OK.
Add the HOSTS file entry on AzureWAP2

Start an Administrator PowerShell. At the prompt, type notepad C:\windows\system32\drivers\etc\hosts, and press Enter. Once Notepad opens, go to the bottom of the file, and add a line for the AzureADFS1 IP address (likely 172.16.2.4) and the AD FS service name (fs.contoso.com), and then save and close the file.
Install the WAP feature on AzureWAP2

Type Install-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess, and press Enter. When the feature has finished installing, switch to Server Manager and click Refresh. Click the Notifications icon, and click Open the Web Application Proxy Wizard.
```
Install-WindowsFeature Web-Application-Proxy,RSAT-RemoteAccess
```
Configure the WAP role on AzureWAP2

On the Welcome page of the Web Application Proxy Configuration Wizard, click Next. On the Federation Server page, enter the values in the following table, and click Next. On the AD FS Proxy Certificate page, under Select a certificate to be used by the AD FS proxy:, choose the *.contoso.com certificate you imported earlier, and click Next. On the Confirmation page, click Configure.

Federation service name: fs.contoso.com

User name: tedhynes@contoso.com

Password: ADFS4Contoso!
Review the installation results on AzureWAP2

Wait for the configuration to complete. It shouldn't take long. Next, click Close. The Remote Access Management Console will launch automatically. Notice that the Cluster Servers list shows three servers now. Close the Remote Access Management Console after reviewing the configuration. Minimize the Remote Desktop Connection window (you will need the connection later).
Change the HOSTS file

As you did on AzureADFS1, now that you have configured the WAP on AzureADFS2, configure the HOSTS file on AzureADFS2 to point at the internal load balancer IP rather than the AzureADFS1 IP address.

Exercise 10 : Configuring the Network Security Group

In this exercise, you will add a security layer to your solution to contorl the traffic flow in your Azure virtual network. In Azure, a Network Security Group (NSG) is a mesh-level port filtering firewall that controls what traffic is allowed incoming or outgoing relative to a subnet, a network interface card, or both. (In Azure Classic, an NSG applies to a subnet and/or a virtual machine.) For the purposes of simplicity here, we are going to restrict traffic at the subnet level, although in a more secure environment, stronger restrictions may be desired, such as per-network-card and per-IP address for the rules. This very much depends on the uses of the different subnets, as well as how the responsible security personnel think about security in their environment. It's important to remember that Azure routes between subnets by default; we're using the NSG to restrict what is allowed through that routing. You can also use a third-party firewall device from the Azure Marketplace and User-Defined Routing to send all traffic from a subnet to that firewall, but that is beyond the scope of this lab.

Locate the AzureWAP1 NIC

In the Azure Portal, along the top bar, click the magnifying glass icon, click the textbox, type azurewap1, then locate and click the NETWORK INTERFACE entry.
Open the DNS servers list for the NIC

In the Settings blade for the network interface card, under General, click DNS servers.
Set the DNS server to the Azure DNS server

Click Custom DNS, and for Primary DNS server, type 168.63.129.16, then press Tab. Once the address is validated, click Save.

Due to an issue in the Azure Portal, the DNS servers entry will read Azure DNS, even though the virtual network has custom DNS servers configured. You are explicitly overriding the virtual network values with the standard Azure DNS server. The IP address you are using is a special IP address that Azure guarantees will always be available for DNS and KMS use, and will be the DHCP server address for all DHCP assignments in Azure.
```
168.63.129.16
```
Locate the AzureWAP2 NIC

While the change to AzureWAP1 saves, locate the network interface for AzureWAP2 using the top bar search function, as you did for AzureWAP1.
Set the DNS server to the Azure DNS server

As you did for AzureWAP1, set the DNS server for AzureWAP2 to 168.63.129.16.
```
168.63.129.16
```
Wait for the WAP servers to reboot

When the network interface change has been completed, Azure may automatically reboot the associated VM. If not, manually restart each VM. Wait for AzureWAP1 and AzureWAP2 to reboot (your RDP sessions will be dropped) before continuing.
Begin creating a Network Security Group

In the upper-left of the Azure Portal, again click + New, search for network security group, and press Enter.

In Azure, a Network Security Group (NSG) is a mesh-level port filtering firewall that controls what traffic is allowed incoming or outgoing relative to a subnet, a network interface card, or both. (In Azure Classic, an NSG applies to a subnet and/or a virtual machine.) For the purposes of simplicity here, you are going to restrict traffic at the subnet level, although in a more secure environment, stronger restrictions may be desired, such as per-network-card and per-IP address for the rules. This very much depends on the uses of the different subnets, as well as how the responsible security personnel think about security in their environment. It's important to remember that Azure routes between subnets by default; we're using the NSG to restrict what is allowed through that routing. You can also use a third-party firewall device from the Azure Marketplace and User-Defined Routing to send all traffic from a subnet to that firewall, but that is beyond the scope of this lab.
Select Network security group

In the result list on the Everything blade, click Network Security Group. Next, on the Network security group blade, click Create.
Configure basic Network Security Group settings

Enter the following values on the Create network security group blade, and click Create:

Name DMZ-Restriction

Subscription (leave the default)

Resource group Use existing, ADFSLab

Location North Central US (should be the default)
Locate the created NSG

Wait for the creation to complete; it will not take long. On the Notifications view, click the Deployments succeeded notification.

Yes, this is yet another path for locating a resource in the Portal.
Select the NSG link

In the Deployments succeeded blade, click the DMZ-Restriction (network security group) link.
Select the Outbound security rules list

On the Settings blade, under General, click Outbound security rules.

Create the first outgoing rule

First, you will add a rule to allow the DMZ to access the AD FS farm. On the Outbound security rules blade, click + Add. On the Add outbound security rule blade, enter the following values, and then click OK:

Name	Allow-DMZ-ADFS
Priority	100 (should be the default)
Destination	CIDR block
Destination IP address range	(your internal load balancer IP address, likely 172.16.2.8)
Destination port range	443
Source	CIDR block
Source IP address range	172.16.1.0/24
Protocol	TCP
Source port range	*
Action	Allow

Create the second outgoing rule

Next, you will add a rule to allow the DMZ to have Internet access, to facilitate Windows Update. In the Outbound security rules blade, again click + Add. On the Add outbound security rule blade, enter the following values, then click OK:

Name	Allow-DMZ-Internet-HTTPS
Priority	110 (may be the default, depending on timing)
Destination	Tag
Destination tag	Internet (should be the default)
Destination port range	443
Source	CIDR block
Source IP address range	172.16.1.0/24
Protocol	TCP
Source port range	*
Action	Allow

Create the final outgoing rule

Finally, add a rule to block all other outgoing traffic. Again, on the Outbound security rules blade, click + Add.
On the Add outbound security rule blade, enter the following values, and then click OK:

Name Block-DMZ

Priority 4096

Destination Any

Destination port range *

Source CIDR block

Source IP address range 172.16.1.0/24

Protocol Any

Source port range *

Action Deny

This rule, with the highest allowed user priority number, overrides the lower priority (higher numbered) rules that are there by default to prevent the normal Azure routing between subnets. You can see the default rules by clicking the Default rules button at the top of the Outbound security rules blade. Because rules are applied in order, with the first matching rule stopping the rest of the evaluation, the rules you created to allow specific traffic will not be stopped by this rule.
Confirm the outbound rule list

Wait for the rules to finish being added; when done, confirm you have three rules in the Outbound security rules blade, and then close the blade.
Change to the Inbound security rules list

You now need one incoming rule, to allow SSL connections to the WAP servers. On the Settings blade, under General, begin by clicking Inbound security rules.

Create the SSL incoming rule for the WAPs

On the Inbound security rules blade, click + Add. In the Add inbound security rule blade, enter the following values, and then click OK.

Name	Allow-SSL
Priority	100 (should be the default)
Source	Any (should be the default)
Protocol	TCP
Source port range	* (should be the default)
Destination	CIDR block
Destination IP address range	172.16.1.0/24
Destination port range	443
Action	Allow

Confirm the inbound rule list

Wait for the rule to finish being added; when done, confirm you have one rule in the Inbound security rules blade, then close the blade.
Apply the NSG to the DMZ subnet

On the Settings blade, under General, click Subnets. At the top of the Subnet associations blade, click + Associate. On the Associate subnet blade, for Virtual network, select the Contoso-Azure-Network network, and for Subnet, select the DMZ subnet, and then click OK.
Wait for the subnet association to complete

Wait for a notification indicating your association is complete before continuing.

Exercise 11 : Testing your solution

In this exercise, you will test your completed solution, step by step, ensuring everything is working.

Determine all necessary IP addresses

Determine the IP address for each of the following resources, if you do not remember them:

Resource	Sample Location in Azure Portal
AzureADFS1 IP	Virtual Machines, AzureADFS1, Settings, Network Interfaces, PRIVATE IP ADDRESS (likely 172.16.2.4)
AzureADFS2 IP	Virtual Machines, AzureADFS2, Settings, Network Interfaces, PRIVATE IP ADDRESS (likely 172.16.2.5)
AzureWAP1 IP	Virtual Machines, AzureWAP1, Settings, Network Interfaces, PRIVATE IP ADDRESS (likely 172.16.1.4)
AzureWAP2 IP	Virtual Machines, AzureWAP2, Settings, Network Interfaces, PRIVATE IP ADDRESS (likely 172.16.1.5)
ADFS-LB	Browse (bottom of the left side list), Load balancers, ADFS-LB, Essentials: Private IP address (likely 172.16.2.8)
WAP-LB	Browse (bottom of the left side list), Load balancers, WAP-LB, Essentials: Public IP address: WAP, Essentials: IP address)

Open the HOSTS file on Client1

On the Client1 VM, close all open windows. On the VM desktop, double-click the Edit HOSTS (Admin) shortcut, which will launch an Administrator Notepad editing the local HOSTS file on the client. When prompted by UAC, click Yes to continue.
Add an entry pointing the AD FS name at AzureADFS1

At the end of the HOSTS file, add a line for name fs.contoso.com using the AzureADFS1 VM IP address, and then save the file and close Notepad.
Open Internet Explorer

Open Internet Explorer. The default home page has been set to the standard AD FS test page on the AD FS installation, in this case https://fs.contoso.com/adfs/ls/idpinitiatedsignon.aspx.
Verify sign in

Ensure the Contoso Pharmaceuticals sign-in page appears, and click Sign in.
Sign out from AD FS

Confirm you sign in automatically (using Windows Integrated Authentication), and then click Sign Out.
Close Internet Explorer

Close Internet Explorer.

It is important that you close the browser, not just minimize it, because Internet Explorer does internal DNS caching that may prevent HOSTS changes from being immediately seen in the browser.
Test AzureADFS2

Edit HOSTS again, this time changing the IP address to the AzureADFS2 address. Test again using Internet Explorer. Sign out again, then close the browser..

When this succeeds, you will have validated each AD FS server individually.
Test ADFS-LB

Edit HOSTS again, this time changing the IP address to the ADFS-LB address. Test again using Internet Explorer. Sign out again, then close the browser..

When this succeeds, you will have validated the internal load balancer, which is the address that would be used for fs.contoso.com internally.
Test AzureWAP1

Edit HOSTS again, this time changing the IP address to the AzureWAP1 address. Test again using Internet Explorer. Notice that this time, because you are going through a WAP server, you are testing as if you were an extranet user, so you will be prompted for forms-based authentication; use tedhynes@contoso.com and ADFS4Contoso! to sign in. (If prompted to store your password, click Not for this site.) Again sign out, and close the browser.
Test AzureWAP2

Edit HOSTS again, this time changing the IP address to the AzureWAP2 address. Test again using Internet Explorer, tedhynes@contoso.com and ADFS4Contoso!. Again sign out, and close the browser.
Test WAP-LB

Edit HOSTS again, this time changing the IP address to the WAP-LB address. Test again using Internet Explorer, tedhynes@contoso.com and ADFS4Contoso!. Again sign out, and close the browser.

When this succeeds, you will have validated the external load balancer, which is the address that would be used for fs.contoso.com externally.

For the purposes of this lab, you're done. If you'd like to clean up your Azure environment, navigate to the ADFSLab resource group, and delete the resource group.

In production, you would likely next remove the on-premises AD FS and WAP servers from the environment cleanly, although you may decide to keep them as backup copies of the roles for emergency or testing purposes. Some customers choose to use on-premises AD FS for internal access and Azure WAP servers for external access, which is also a possible scenario. Ultimately, it depends on what's best for the particular environment.

WN

Tuesday, March 21, 2017