Deploying Highly Available AD FS 3.0 Solution in Windows Azure For Single Sign-On With Office365

Using Exchange Deployment Assistant to
Help Plan a Migration to Office 365

I am a planner, I really dont like to walk into situations not prepared.
When I am doing an assessment for a company, I will always get the client to set goals; Current
State and Future State. When you have clear goals from the client, there is less likely to be a
surprise along the way. Take your time and plan the migration well. You and your client cannot
afford downtime during the migration
Lets walk through a typical migration to Office 365.
Current State:
1500 Users Accounts that are mail enabled
15 Windows Server 2003 SP2 Servers (2 DCs, 3 File/Print Cluster, 3 Exchange Cluster,
1 FW, 1 SharePoint, etc)
4 Exchange Server 2003 SP2 (2 WFE and 2 BE Clustered)
Windows XP SP3 w/ Office 2000
15 Physical Servers
Future State:
1500 User Accounts in Office 365 on Enterprise Plan E3
SharePoint Online
Lync Online
Exchange Online
File and Print to remain on premise
Replace 15 physical servers with 3 new physical servers
3 new physical servers running Windows Server 2008 R2 Enterprise (Enterprise is key,
because it gives you the licenses to run 4 virtual servers)
10 new virtual servers
I will then Visio the solution. (Note: this one only shows the ADFS and DirSync setup)
One of the tools in my belt is the Exchange Server Deployment Assistant. This is an online
tool from Microsoft that allows you to enter information about your current Exchange
environment, your future Exchange environment and then it will spit out a beautiful plan for you
to follow.
Exchange Server Deployment Assistant
The Exchange Server Deployment Assistant is a web-based tool that asks you a few
questions about your current environment and then generates a custom step-by-step
checklist that will help you deploy different versions of Exchange Server for different types
of scenario
http://technet.microsoft.com/en-us/exdeploy2010/default.aspx#Index
Select the End Goal for Exchange, for us this is Hybrid. The reason that we choose this and not
Cloud only is because we want that Hybrid server for Migration purposes. We are not going to
move 1500 accounts overnight. When the migration is complete, the Exchange 2010 Hybrid
server will be removed.
What is your current on-premises mail system? Exchange Server 2003

The next four questions are customizable depending on your goals
Do you want all users to use their on-premises credentials when they log on to their
Exchange Online mailbox?
Do you want to route inbound mail for both your on-premises and Exchange Online
mailboxes through your on-premises organization?
Do you want mail sent between Exchange Online and your on-premises organizations to go
through an Edge Transport server in your perimeter network?
Do you already use Forefront Online Protection for Exchange to protect your on-premises
mailboxes?
Once you click next it will compile a custom plan for you, to move to Office 365. This online
checklist will remember your choices as you check them off. You can also download a PDF of
the plan.
INSERT PLAN HERE
What I love about this is that includes detailed actions that you can share with the client and
some nice pics that can be used to show the client the setup and mail flow during the migration.
Happy Migrating
Thanks for visiting and reading my posts. I am always looking for more ideas. Please comment
or email me with what you would like to see.
Setting up the Primary AD FS 3.0 Server in Windows Azure for Office365 Single SignOn
This BLOG post covers setting up the primary AD FS 3.0 server on a Windows Server 2012 R2
virtual machine in Windows Azure.
Assumptions:
Azure account is setup
Directory Sync is activated, setup and running
Valid SSL certificate is available (with private key)
VPN connection setup from Azure to your on-premise network
Create a New Cloud Service

Because we are going to load balance one or more virtual machines, we need to create a Cloud
Service to put them in. Think of it as a bucket to hold your virtual machines. You will require one
for the AD FS Servers and one for the Web Application Proxies (AD FS Proxy Servers)
Click New
Select Compute -> Cloud Service -> Custom Create
Enter a URL or Name for the Cloud Service. This name must be unique across the .cloudapp.net
name space.
Select your Region or Affinity Group
Click OK
Create the Virtual Machine in Windows Azure

Click New
Select Compute -> Virtual Machine -> From Gallery
Choose Windows Server 2012 R2 Datacenter

Click Next
Enter Virtual Machine Name

Select Server Tier
Select Server Size
Click Next
Selcect the AD FS Cloud Service that was created earlier. This is very important.
Verify Subnet
Drop down to Create an availability set
Enter name for the availability set
***Note*** This does not load balance the servers, it will just place the VM accordingly so that
if a rack of servers goes down, all the members of the set will be placed in different fault
domains. This ensures that an outage isnt extened to all the servers in the set.
Click Next
Click Next
Once the VM is provisioned go to the next step
Add the Server to the Domain

Since the AD FS server needs to authenticate against Active Directory, they need to be added to
the local domain. Add the server to the local domain
Install the Windows Azure Active Directory Module for

Windows PowerShell
Use this BLOG post to install the Windows Azure Active Directory Module for PowerShell and
the required Microsoft Online Services Sign-In Assistant 7.0
Connecting to Office365 with PowerShell
Install the AD FS Role

Open Server Manager
Click Add roles and features
Click Next
Select Role-based or feature-based installation

Click Next
Make sure that the AD FS Server is listed as the server to install to

Click Next
Select Active Directory Federation Services

Click Next
Leave defaults
Click Next
Click Next
Click Install
Wait for the install to complete
Import the SSL Certificate

AD FS uses certificate to secure the connection from AD FS to Office365. For this reason, we
need a valid SSL certificate. I choose to use GoDaddy, as I find they are a one stop shop for all
my domain needs. Its a personal choice, so use whoever you feel comfortable with. For the
purposes of this BLOG post, I will use a multi-name certificate; I DONT recommend this for a
production environment. A couple reasons are that I like to keep things simple and if we have
multiple names on the certificate, it starts to get complicated (not technically, but management of
the certificate). Secondly, I dont like to share certificates across services. This cuts down on the
cross contamination from the support teams at larger companies. If you lump the AD FS services
with the Exchange certificate, AD FS usually gets left in the dust and forgot about when it comes
time to renew.
Open the Start Screen
Type MMC
Click the MMC app
MMC opens
Click File
Click Add/Remove Snap-in
Select Certificates
Click Add>
Select Computer Account

Click Next
Select Local Computer

Click Finish
Click OK
Expand Certificates
Expand Personal
Right Click Certificates
Select Import
Select Local Machine

Click Next
Browse to the Exported Certificate

Click Next
Enter Password
Mark the key as exportable
Click Next
Place in the Personal certificate store

Click Next
Click Finish
Successful
Setup and Configure AD FS 3.0

Open Server Manger
Select AD FS
Click More
where it says Configuration required for Active Directory Federation Servers at
Click
Configure the federation service action on the Post-Deployment Configuration
Select Create the first federation server in a federation server farm

Click Next
Enter credentials for a user that has domain administrator permissions. This is used to complete
the install, its not used as the AD FS service account
Click Next
Select the SSL certificate that you imported

Select the Federation Service Name
Enter the Federation Service Display Name
*** Note *** Since I am using a multi-name certificate these three values dont match for me. In
production I always recommend that you use a single name certificate to keep things simple. If
thats the case then the three values below should all match e.g. sts.domain.com
Click Next
Enter the AD FS Service Account Name and Password

***Note*** This can be a managed service account or a domain user account designated for AD
FS. If you use a domain user account, it does not need any special permissions. The install will
give it the permissions required.
Click Next
Select Windows Internal Database or the location of a SQL Server Database. The choice is yours,
but for most companies the Windows Internal Database works just fine
Click Next
Click Next
Wait for the Pre-requisite checks to be completed

Click Configure
Successful
Federate with Office365

Open the Desktop on the AD FS server
Find Windows Azure Active Directory Module for Windows PowerShell
Right Click and Run As Administrator

Set the credential variable
$cred=Get-Credential
Enter a Global Administrator account from Office 365.
Connect to Microsoft Online Services with the credential variable set previously
Connect-MsolService Credential $cred
Set the MSOL ADFS Context server, to the ADFS server (optional if you are on the AD
FS server)
Set-MsolADFSContext Computer
adfs_servername.domain_name.com
Convert the domain to a federated domain
Convert-MsolDomainToFederated DomainName
domain_name.com
Successful Federation
Successfully updated domain_name.com domain
Verify federation
Get-MsolFederationProperty DomainName domain_name.com
This concludes the setup of the first AD FS server and federation with Office365. Please
continue through the rest of the series to complete the setup for the rest of the servers.
My BLOG Series
Deploying a Highly Available AD FS 3.0 Solution in Windows Azure for Single Sign-on with
Office365
1. Setting up the Primary AD FS 3.0 Server in Windows Azure for Office365
Single Sign-On
2. Setting up the Secondary AD FS 3.0 Server in Windows Azure for Office365
Single Sign-On
3. Load Balance the AD FS Servers in Windows Azure for Office365 Single SignOn
1. Configure the AD FS Servers in an Internal Load-Balanced Set in
Windows Azure for Office365 Single Sign-On
2. Configure the AD FS Servers with Azure Load Balanced Set in Windows
Azure for Office365 Single Sign-On
4. Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP
Communications
5. Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows
6. Setting up the Second Web Application Proxy Server (AD FS Proxy) in
7. Configure Endpoints and Test the Web Application Proxy Servers (LoadBalanced Set in Windows Azure) for Office365 Single Sign-On
Kelsey Epps Office365 MVP
Technical Consultant
Setting up the Secondary AD FS 3.0 Server in Windows Azure for Office365 Single
Sign-On
Now that we have the first AD FS server setup and are federate with Office365, we can add more
servers into the AD FS farm. This process can be repeated on one or many more servers
depending on the number of servers you need in the AD FS farm to support the load from your
user base.
Assumptions:
Valid SSL certificate is available (with private key)
Primary AD FS server is setup (see previous post in this series)
Setting up the Virtual Machine in Windows Azure

Click New -> Compute -> Virtual Machine -> From Gallery
Select Windows Server 2012 R2 Datacenter

Click Next
Enter the Virtual Machine Name

Select the Tier
Select the Size
Click Next
Choose the Cloud Service that the first AD FS Server is installed in (setup earlier in the BLOG
series)
Verify Subnet
Choose the Availability Set that was created when we provisioned the first AD FS server
Click Next
Click Next
Wait for the Virtual Machine to be provisioned and then continue
Connect to the Virtual Machine over RDP

Add the Virtual Machine to the Domain
Installing the AD FS 3.0 Role on the Virtual Machine and Importing the
SSL Certificate
Please reference this BLOG post on how to install the AD FS 3.0 Role on the virtual machine
and then import the SSL certificate
Setting up the Primary AD FS 3.0 Server in Windows Azure for Office365 Single Sign-On
Adding the Secondary AD FS 3.0 Server to the AD FS Farm

Open Server Manger
Select AD FS
Click More
where it says Configuration required for Active Directory Federation Servers at
Click
Configure the federation service action on the Post-Deployment Configuration
Select Add a federation server to a federation server farm

Click Next
Enter credentials for a user that has domain administrator permissions. This is used to complete
the install, its not used as the AD FS service account
Click Next
Specify the Primary Federation Server

Click Next
Select the SSL certificate that was imported earlier (the same certificate that was installed on the
primary AD FS server)
*** Note *** Since I am using a multi-name certificate the name of the certificate does not
match my AD FS farm name. In production I always recommend that you use a single name
certificate to keep things simple. If thats the case then the certificate name should match the AD
FS farm name e.g. sts.domain.com
Click Next
Select the AD FS service account (the same account that was used in the setup of the primary AD
FS server in the farm)
Enter the password
Click Next
Click Next
When the pre-requisites are completed

Click Configure
Success
We now have a two node AD FS server farm setup in Windows Azure. Keep in mind that you
have to continue to the next post to setup load balancing for the servers.
My BLOG Series
Office365
Single Sign-On
Single Sign-On
Communications
Load Balance the AD FS Servers in Windows Azure for Office365 Single Sign-On
1 Reply
Azure has two methods of load balancing services out of the box. Depending on your needs and
the security requirements of your company will help decide the method that you will use. I have
detailed both methods in two blog posts below. Be sure to reference the Microsoft link for the
details on both and decide what method is best for your company.
Method 1 Azure Internal Load Balancing (ILB)
Azure Internal Load Balancing (ILB) provides load balancing between virtual machines that
reside inside of a cloud service or a virtual network with a regional scope
Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for Office365
Single Sign-On
With this method you have one network with different address spaces for the internal (10.0.0.0)
and DMZ (172.16.0.0) networks. This method works, because Azure allows routing between the
different address spaces on the same network.
Method 2 Azure Load Balanced Set
Azure load balanced set is layer 4 load balancing across the virtual machines of a cloud service
Configure the AD FS Servers with Azure Load Balanced Set in Windows Azure for Office365
Single Sign-On
With this method, you have two physical networks in Azure. With this method, we rely on end
points and hosts files for routing between the networks. This is the more secure way of
implementing the solution since we will control access with ACLs between the networks.
My BLOG Series
Office365
Single Sign-On
Single Sign-On
Communications
Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for

Office365 Single Sign-On
9 Replies
Assumptions:
Primary and Secondary AD FS servers are setup (see previous posts in this
series)
WAP servers are deployed on the same network, different subnet as the ADFS
Servers. If you are unsure, see this BLOG post.
Reference this TechNet Article http://msdn.microsoft.com/en-us/library/azure/dn690125.aspx
Connect to Windows Azure with PowerShell

If you are unsure how to or have never connected to Windows Azure with PowerShell, please
reference the article below. This will guide you to install the tools and connect with PowerShell
http://azure.microsoft.com/en-us/documentation/articles/install-configure-powershell/#Install

Right Click Windows Azure PowerShell and Run as administrator
Click Yes to the UAC
Type Add-AzureAccount
Press Enter
Enter email address used login to your Azure account

Click Continue
Enter email address and password used login to your Azure account
Click Continue
Azure authenticates your account and then takes you back to the PowerShell window.
Create the Internal Load-Balanced Set Instance

Before we can continue, we need to gather some information. This information is used to set
variables in the PowerShell command that will be used to create the ILB instance
Cloud Service Name This was created prior to creating the first AD FS 3.0 Virtual Machine
and can be found in the Azure Management Portal under Cloud Services
Internal Load-Balanced Instance Name This is a name that is used to reference the ILB Set
Subnet Name This was created when Azure Networking was created and can be found in the
Azure Management Portal under Networking
IP Address for the Internal Load-Balanced Instance This can be set or automatically generated
Set the variables in PowerShell

$svc=ConceppsADFS
$ilb=ConceppsADFS-ILB
$subnet=Subnet-1
$IP=10.0.0.8
Execute the command in PowerShell

Add-AzureInternalLoadBalancer -ServiceName $svc -InternalLoadBalancerName $ilb
SubnetName $subnet StaticVNetIPAddress $IP
Add End Points to the Internal Load-Balanced Set

Below is a script that will set the variables, create the end points and update the Virtual Machines
with the configuration.
$svc=ConceppsADFS
$ilb=ConceppsADFS-ILB
$prot=tcp
$locport=443
$pubport=443
$epname=ADFS01
$vmname=ConceppsADFS01
Get-AzureVM ServiceName $svc Name $vmname | Add-AzureEndpoint -Name $epname

LBSetName ADFS-SSL -Protocol $prot -LocalPort $locport -PublicPort $pubport
DefaultProbe -InternalLoadBalancerName $ilb | Update-AzureVM
$epname=ADFS02
$vmname=ConceppsADFS02
Get-AzureVM ServiceName $svc Name $vmname | Add-AzureEndpoint -Name $epname

LBSetName ADFS-SSL -Protocol $prot -LocalPort $locport -PublicPort $pubport
DefaultProbe -InternalLoadBalancerName $ilb | Update-AzureVM
Add DNS Record

Now that we have our farm configured and the servers are load balanced, we need to ensure that
the clients can get to them using the virtual IP of the Internal Load-Balanced Set.
In the steps above we created an Internal Load-Balanced set with the IP of 10.0.0.8. We now
need to create an A record in the internal DNS, with a name of STS that points to the VIP. In my
case sts.office365supportlab.com points at 10.0.0.8
Testing AD FS Sign-On
Open IE
Browse to the URL https://sts.domain.com/adfs/ls/IdpInitiatedSignon.aspx
Click Sign in
Testing Server High Availability

Shutdown the AD FS Servers one at a time and check that you can still access AD FS with each
server offline. This will test the failure of losing one of the servers in the ILB set.
We are now setup with a highly available AD FS solution for all internal users. Continue on with
the series to setup the Web Application Proxies (AD FS Proxy) so that the external users have
access.
My BLOG Series
Office365
Single Sign-On
Single Sign-On
Communications
Configure the AD FS Servers with Azure Load Balanced Set in Windows Azure for
Office365 Single Sign-On
Leave a reply
Assumptions:
series)
WAP servers are deployed on a differnet network than the ADFS Servers. If
you are unsure, see this BLOG post.
Reference this TechNet Article http://msdn.microsoft.com/en-us/library/azure/dn655055.aspx
Creating the Load Balanced Set on the Primary ADFS Server
Open Azure Management Portal

Click Virtual Machines
Click the Primary AD FS Server
Click Endpoints Tab
Click Add (+)

Select Add a Stand-alone Endpoint
Click Next
Configure as follows:
Name HTTPS
Protocol TCP
Public Port 443
Private Port 443
Select Create a Load-Balanced Set

Click Next
Configure as follows:
Load-Balanced Set Name ADFS_SSL
Probe Protocol TCP
Probe Port 443
Probe Internal 15
Number of Probes 2
Click the complete check mark
The load balanced set is created
Adding the Second ADFS Server to the Load Balanced Set

Click the Primary AD FS Server
Click Endpoints Tab
Click Add (+)

Select Add an Endpoint to an Existing Load Balanced Set
Select ADFS_SSL or whatever you called it
Click Next
Enter Name ADFS_SSL

Click the complete checkmark
The end point will be re-configured to load balance across the two ADFS servers.
At this point ADFS have now been load balanced. If you have more than two ADFS servers,
keep adding them to the load balanced endpoint.
My BLOG Series
Office365
Single Sign-On
Single Sign-On

Communications
Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP
Communications
3 Replies
If you read the earlier posts in the series, you would have noted that there is two methods to
deploy the AD FS server load balancing. Because I am in an all Azure environment, I choose to
deploy with method 2, using Azure load balancing on port 443 for AD FS. The following post
details how to setup Azure ACLs to allow communication from the DMZ network to the
production network and then deny all others.
This post needs the cloud service for the WAP servers created along with at least one WAP server
deployed to the cloud service so that we can get the Public Virtual IP. This need to be completed
before we can add the WAP servers as proxies for the AD FS servers. There is no real clean way
to blog this so you will have to jump back and forth between this post and Setting up the First
Web Application Proxy Servers (AD FS Proxy) in Windows Azure for Office365 Single Sign-On
to complete the task.
Assumptions:
series)
The cloud service for the WAP servers is created.
The first thing that you need to do is gather the Public Virtual IP for the WAP cloud service.
Change ACLs to allow WAP access

Navigate to the Primary AD FS Server
Select Endpoints
Select HTTPS (or whatever you called the endpoint for AD FS)
Click Manage ACL
You will notice that the ACL list is not populated, which means that its wide open to the
internet. We need to secure the AD FS load balanced set, while still giving the WAP servers
access. This will allow the WAP servers to talk to the AD FS servers. We are going to create two
rules; one permit and one deny.
The first rule will grant access from the WAP servers to the AD FS servers
Enter a description of the rule
Select Permit
Enter the IP address of the WAP cloud service in CIDR format. You will notice the /32 at the
end, which will limit the rule to that one IP address.
Now that we have granted access on port 443 to the WAP servers, we need to deny all others.
Keep in mind that this is for external traffic only. Internal users will still be able to access the AD
FS servers on the domain network. This is just for the NAT address from external client access in
Azure.
Enter a description of the rule
Select Deny
Enter the 0.0.0.0/0
This will deny all traffic

Azure will update the rule. There is no need to complete this on the other servers as the rule will
apply to the load balanced endpoint.
My BLOG Series
Office365
Single Sign-On
Single Sign-On

Communications
Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows Azure
for Office365 Single Sign-On
4 Replies
The Web Application Proxy servers are the new way to publish AD FS to the internet. They
replace the old AD FS proxy servers and are new to Windows Server 2012 R2. These servers
should be deployed in a DMZ network and are non-domain joined.
Create a New Cloud Service

Because we are going to load balance one or more virtual machines, we need to create a Cloud
Service to put them in. Think of it as a bucket to hold your virtual machines and to apply ACLs
to secure the virtual machines. You will require one for the AD FS Servers and one for the Web
Application Proxies (AD FS Proxy Servers)
Click New
Select Compute -> Cloud Service -> Custom Create
Enter a URL or Name for the Cloud Service. This name must be unique across the .cloudapp.net
name space.
Select your Region or Affinity Group
Click OK
Create the Virtual Machine

Click New
Select Windows Server 2012 R2

Click Next arrow
Enter a virtual machine name, tier, size, username and password

Click Next arrow
Select the cloud service you created above

Verify Virtual Network
Create an Availability Set
Click Next arrow
Let the process configure the virtual machine. Once completed, log into the server and continue
with the next steps.
Configure the Primary DNS Suffix

Open Server Manager
Click the Computer Name
Click Change
Click More
Enter your public domain as the Primary DNS suffix of this computer
Click OK
Click OK
Reboot
Install Web Application Proxy Role

Open Server Manager
Click Manage
Click Add Roles and Features
Click Next
Click Next
Click Next
Select Remote Access

Click Next
Click Next
Click Next
Select Web Application Proxy

Click Next
Click Add Features
Click Next
Click Install
Installing
Click Close

time to renew.
Type MMC
Click the MMC app
MMC opens
Click File
Select Certificates
Click Add>

Click Next

Click Finish
Click OK
Expand Certificates
Expand Personal
Select Import

Click Next

Click Next
Enter Password
Click Next

Click Next
Click Finish
Successful
Edit HOSTS File

Because we need to make contact back to the AD FS servers, we need to tell the WAP servers
how to get to them. The simplest way of doing this (and not opening more FW ports) is to edit
the local HOSTS file on the WAP server. Keep in mind that we dont have connectivity or the
ability to route to the internal IP address, so we need to route to the external IP of the Cloud
Service that holds the AD FS servers.
Complete in Azure
Click Cloud Services

Click the Cloud Service for your AD FS Servers
Make note of the Public Virtual IP (VIP) Address
Complete on WAP Server
Right Click Notepad and Run as Administrator

Navigate to c:\windows\system32\drivers\etc
Switch view to All Files
Open HOSTS
Edit HOSTS file with the AD FS Farm Name and the external IP Address of the AD FS Cloud
Service
Click File -> Save
Close Notepad
Setup Azure ACLs to Allow the WAP Servers to Communicate with the
AD FS Servers
Since we are on separate networks (from the Internal Network) we also need to make sure that
we have configured Azure ACLs to allow the WAP servers to communicate to the AD FS serves
on the internal network. Please review this BLOG post to complete that task.
Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP Communications
Configure the Web Application Proxy Role

Open Server Manager
Click More Configuration required for Web Application Proxy
Click Open the Web Application Proxy under the Action column
Click Next
Enter the Federation Service Name

Enter Credentials for a local administrator on the AD FS servers
Click Next
Select the SSL certificate that you imported earlier

Click Next
Click Configure
Setting up the WAP server
Success
Click Close
At this point the WAP server is functioning. To test the WAP server, you can edit your local
workstation hosts file to point at the external IP of the WAP cloud service. This will allow you to
test the configuration without editing global DNS.
Continue on to the rest of the series where we will add a second WAP server and then load
balance the two.
My BLOG Series
Office365

Single Sign-On
Single Sign-On
Communications
Setting up the Second Web Application Proxy Servers (AD FS Proxy) in Windows
4 Replies
In the previous post, we created the first of two WAP servers. This is the continuation of the
series.
Create the Virtual Machine

Click New
Select Windows Server 2012 R2

Click Next arrow
Enter a virtual machine name, tier, size, username and password

Click Next arrow
Select the cloud service you created when creating the first WAP server
Verify Virtual Network
Select an Availability Set that you created when creating the first WAP server
Click Next arrow
Let the process configure the virtual machine. Once completed, log into the server and continue
with the next steps.
Configure the Primary DNS Suffix

Open Server Manager
Click the Computer Name
Click Change
Click More
Enter your public domain as the Primary DNS suffix of this computer
Click OK
Click OK
Reboot
Install the Web Application Proxy Role

Open Server Manager
Click Manage
Click Add Roles and Features
Click Next
Click Next
Click Next
Select Remote Access

Click Next
Click Next
Click Next
Select Web Application Proxy

Click Next
Click Add Features
Click Next
Click Install
Installing
Click Close

time to renew.
Type MMC
Click the MMC app
MMC opens
Click File
Select Certificates
Click Add>

Click Next

Click Finish
Click OK
Expand Certificates
Expand Personal
Select Import

Click Next

Click Next
Enter Password
Click Next

Click Next
Click Finish
Successful
Edit HOSTS File

Because we need to make contact back to the AD FS servers, we need to tell the WAP servers
how to get to them. The simplest way of doing this (and not opening more FW ports) is to edit
the local HOSTS file on the WAP server. Keep in mind that we dont have connectivity or the
ability to route to the internal IP address, so we need to route to the external IP of the Cloud
Service that holds the AD FS servers.
Complete in Azure
Click Cloud Services
Click the Cloud Service for your AD FS Servers
Make note of the Public Virtual IP (VIP) Address
Complete on WAP Server

Right Click Notepad and Run as Administrator
Navigate to c:\windows\system32\drivers\etc
Switch view to All Files
Open HOSTS
Edit HOSTS file with the AD FS Farm Name and the external IP Address of the AD FS Cloud
Service
Click File -> Save
Close Notepad
Setup Azure ACLs to Allow the WAP Servers to Communicate with the
AD FS Servers
Since we are on separate networks (from the Internal Network) we also need to make sure that
we have configured Azure ACLs to allow the WAP servers to communicate to the AD FS serves
on the internal network. Please review this BLOG post to complete that task.
Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP Communications
Configure the Web Application Proxy Role

Open Server Manager
Click More Configuration required for Web Application Proxy
Click Open the Web Application Proxy under the Action column
Click Next
Enter the Federation Service Name

Enter Credentials for a local administrator on the AD FS servers
Click Next
Select the SSL certificate that you imported earlier

Click Next
Click Configure
Success
Click Close
At this point the WAP server is functioning. Now all that remains is that we need to do is that we
need to add an end point for port 443 and load balance the two servers.
Continue onto the next post in the series to finish the configuration.
My BLOG Series
Office365

Single Sign-On
Single Sign-On
Communications
Configure Endpoints and Test the Web Application Proxy Servers (Load-Balanced Set
in Windows Azure) for Office365 Single Sign-On
2 Replies
In the previous post we setup two WAP servers that will act as the AD FS proxy role for our
internal AD FS servers. Now that the servers are setup, we need to add an end point so that the
servers are accessible from the internet and we also need to load balance the end point across the
two WAP servers.
Configure a Load Balanced End Point on the first Web Application Proxy
Server
Open the Azure Management Portal
Select the first WAP Server
Select Endpoints
Click + Add
Select Add a Stand-Alone Endpoint

Click Next Arrow
Select HTTPS
Verify TCP
Verify Public Port 443
Verify Private Port 443
Select Create a Load-balanced set
Click Next Arrow
Name the load-balanced Set

Verify Protocol TCP
Verify Probe Port 443
Verify Probe Interval 15
Verify Number of Probes 2
Click the complete check mark
Load balanced endpoint is added
Add the Second Web Application Proxy Server to the WAP Load
Balanced Set
Now that we have the load balanced endpoint setup on the first server, we now need to add the
second server to this set.
Select the second WAP server

Click Endpoints
Click + Add
Select Add an endpoint to an existing load-balanced set

Select the load-balanced set you created in the step above
Click Next Arrow
Name the endpoint for this server

Verify the protocol TCP
At this point the servers are both added to the load balanced end point and are live on the
internet.
Collect the External IP Address of the WAP Cloud Service

Now that the WAP servers are load balanced, we will need to update our public DNS so that the
Public Virtual IP (VIP) Address for the WAP cloud service is resolving to the AD FS farm name
(in my case its sts.office365supportlab.com)
Click on the WAP Cloud Service On the main page the Public Virtual IP (VIP) Address will be
displayed
Update Public DNS

Before you complete this step, please note that this could have an impact if you are already in
production. Dont update this record if you dont know what you are doing.
Since we all use different DNS hosts, Ill leave this one up to you. Here is a screen shot of my
GoDaddy DNS zone for reference.
Testing AD FS from External
Browse to the URL https://sts.domain.com/adfs/ls/IdpInitiatedSignon.aspx

Make sure to modify the hostname and domain for your own domain.
Enter credentials
Click Sign in
Testing Access from Office365

Navigate to https://portal.office.com
Enter your UserID

Hit Tab
Redirecting to the WAP servers
The user name should be populated with the value entered on Office365 sign-in page
Enter Password
Click Sign-in
Credentials are verified and you are re-directed to Office365
This completes the series for Deploying a Highly Available AD FS 3.0 Solution in Windows Azure for
Single Sign-on with Office365.
My BLOG Series
Office365
Single Sign-On
Single Sign-On
Communications

Deploying Highly Available AD FS 3.0 Solution in Windows Azure For Single Sign-On With Office365

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Deploying Highly Available AD FS 3.0 Solution in Windows Azure For Single Sign-On With Office365

Enviado por

Direitos autorais:

Formatos disponíveis

Using Exchange Deployment Assistant to

Help Plan a Migration to Office 365

1500 Users Accounts that are mail enabled

4 Exchange Server 2003 SP2 (2 WFE and 2 BE Clustered)

Windows XP SP3 w/ Office 2000

1500 User Accounts in Office 365 on Enterprise Plan E3

File and Print to remain on premise

Replace 15 physical servers with 3 new physical servers

10 new virtual servers

What is your current on-premises mail system? Exchange Server 2003

Azure account is setup

Directory Sync is activated, setup and running

Valid SSL certificate is available (with private key)

VPN connection setup from Azure to your on-premise network

Create a New Cloud Service

Create the Virtual Machine in Windows Azure

Choose Windows Server 2012 R2 Datacenter

Enter Virtual Machine Name

Add the Server to the Domain

Install the Windows Azure Active Directory Module for

Install the AD FS Role

Click Add roles and features

Select Role-based or feature-based installation

Make sure that the AD FS Server is listed as the server to install to

Select Active Directory Federation Services

Wait for the install to complete

Import the SSL Certificate

Open the Start Screen

Select Computer Account

Select Local Computer

Select Local Machine

Browse to the Exported Certificate

Place in the Personal certificate store

Setup and Configure AD FS 3.0

Select Create the first federation server in a federation server farm

Select the SSL certificate that you imported

Enter the AD FS Service Account Name and Password

Wait for the Pre-requisite checks to be completed

Federate with Office365

Right Click and Run As Administrator

Connect-MsolService Credential $cred

Convert the domain to a federated domain

Successfully updated domain_name.com domain

Get-MsolFederationProperty DomainName domain_name.com

Azure account is setup

Directory Sync is activated, setup and running

Valid SSL certificate is available (with private key)

VPN connection setup from Azure to your on-premise network

Primary AD FS server is setup (see previous post in this series)

Setting up the Virtual Machine in Windows Azure

Select Windows Server 2012 R2 Datacenter

Enter the Virtual Machine Name

Connect to the Virtual Machine over RDP

Adding the Secondary AD FS 3.0 Server to the AD FS Farm

Select Add a federation server to a federation server farm

Specify the Primary Federation Server

When the pre-requisites are completed

Method 1 Azure Internal Load Balancing (ILB)

Method 2 Azure Load Balanced Set

Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for

Azure account is setup

Directory Sync is activated, setup and running

VPN connection setup from Azure to your on-premise network