Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for Office365 Single Sign-On

 

Assumptions:

  • Azure account is setup
  • Directory Sync is activated, setup and running
  • VPN connection setup from Azure to your on-premise network
  • 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

 

Open the Start Screen

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

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
    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
  3. Securing the AD FS 3.0 servers and Configuring Azure ACLs for WAP Communications
  4. Setting up the First Web Application Proxy Servers (AD FS Proxy) in Windows Azure for Office365 Single Sign-On
  5. Setting up the Second Web Application Proxy Server (AD FS Proxy) in Windows Azure for Office365 Single Sign-On
  6. Configure Endpoints and Test the Web Application Proxy Servers (Load-Balanced Set in Windows Azure) for Office365 Single Sign-On

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.

Kelsey Epps Office365 MVP

Technical Consultant

Concepps Group

Email Me Follow me on Twitter Connect with me on LinkedIN

9 thoughts on “Configure the AD FS Servers in an Internal Load-Balanced Set in Windows Azure for Office365 Single Sign-On

  1. Steve Rackham

    Hi there, if you already have ADFS on premise and wish to migrate ADFS to the Azure Cloud, what is the best way? I have read someone suggesting that simply adding an Azure based VM wtih ADFS installed to the existing farm on premise and then make the azure based VM the primary. Does this actually work?
    What is the best method? And once I make this server the primary would I then create the secondary as suggested within this blog series?
    Thanks for your help. All servers are 2012R2…

    Reply
    1. Kelsey EppsKelsey Epps Post author

      Extend your existing farm out to Azure and transfer the primary server role to the Azure server. Add the WAP servers that point at the Azure ADFS and then test using a hosts file. Keep the DNS pointing at the on-prem until all testing is completed. Once you are happy, then switch internal and external DNS to the Azure servers and decommission the on-prem servers. Keep in mind that your VPN link to Azure will be your single point of failure for the solution. I’d recommend leaving one ADFS server on-prem and also deploying a full DC to Azure. This ensures that if the VPN tunnel goes down, no impact on the client.

      Reply
  2. Steve Rackham

    Hi Kelsey,
    Thanks for that. Yeah, I have concerns about the VPN link. DCs are in the cloud. A good idea to keep one on-premise.
    Is the internal load balancing method still the same as described in your blog series with this method?
    Thanks so much for help and input, finding concise information has been most difficult.

    Steve.

    Reply
  3. Steve Rackham

    Hi Kelsey
    All deployed and working externally, yet when I try testing through Office 365 portal I get the following error:
    Please try again in a few minutes. If this doesn’t work, you might want to contact your admin and report the following error: 80041317.

    Do I need to refresh the federated domain on the Office 365 side of things? I seem to remember something about this last time but it was a few years ago…

    At this stage I am still testing with host records only and the on-premise servers are still live.

    Thanks again for your help, it is truly appreciated.
    S.

    Reply
  4. Steve Rackham

    Hi Kelsey,
    Looking back through my notes I saw I had forgotten to update the federation configuration to reflect the change of primary computer…

    Update-MSOLFederatedDomain –DomainName:

    and all go.
    Thanks again :-)

    Reply
  5. Thomas

    Hello,

    We also have 2 adfs Servers behind an internal azure load balancer. Wirre You able to join the WAP Servers to the Farm without any problems? We had to retry the join a few times before it finally succeeded.

    Thanks, thomas

    Reply
    1. Kelsey EppsKelsey Epps Post author

      It happens sometimes, try the re-join with PowerShell.

      https://technet.microsoft.com/en-ca/library/dn383662.aspx

      The following Windows PowerShell cmdlet or cmdlets perform the same function as the preceding procedure. Enter each cmdlet on a single line, even though they may appear word-wrapped across several lines here because of formatting constraints.

      The following command will prompt you to enter credentials of a local administrator account on the AD FS servers.

      Install-WebApplicationProxy –CertificateThumbprint ‘1a2b3c4d5e6f1a2b3c4d5e6f1a2b3c4d5e6f1a2b’ -FederationServiceName fs.contoso.com

      Reply
  6. Peter Park

    Is it possible to have both azure load balancing and internal load balancing on two ADFS server? I am planning to use only two ADFS server without proxy and wonder if we can get them load balanced both for internal and external side.

    Reply
    1. Kelsey EppsKelsey Epps Post author

      Yes, but there are some custom powershell commands to get that public IP to the internal load balanced set. Why no proxies? I would not recommend that from a security perspective.

      Reply

Leave a Reply