Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure – Part 1

This is part 1 of 3 in a series where we go through how to create a highly available SSO infrastructure for Office 365 in Microsoft Azure.
Part 2 of the series can be found here.
Part 3 of the series can be found here.

Implementing SSO infrastructure with ADFS is something many customers want in order to reduce the amount of logins for their end users. Soon we will even get single sign on in the Outlook client! (YAY 🙂 ) The biggest challenge implementing the infrastructure is that you get dependent on your local server infrastructure and internet connection.
When it’s not possible to make the solution redundant with you own infrastructure, but still need single signon, my recommendation is to deploy the SSO infrastructure in Microsoft Azure.

THE OPTIONS
Microsoft has provided a white paper on the topic that gives you an idea on what options you have and important things to consider. The White paper describes two deployment options implementing the infrastructure in Azure.

  1. All Office 365 SSO integration components deployed in Azure. This is cloud-only approach; you deploy directory synchronization and AD FS in Azure. This eliminates the need to deploy on-premises servers.
  2. Some Office 365 SSO integration components deployed in Azure for disaster recovery. This is the mix of on-premises and cloud-deployed components; you deploy directory synchronization and AD FS, primarily on-premises and add redundant components in Azure for disaster recovery.

Option 1 to put the entire Identity Infrastructure in the cloud has been the choice for most of the implementations I’ve been involved in. This gives you a very flexible solution that will provide you a highly available SSO infrastructure, yet putting the infrastructure near the services you are providing.

SETTING IT UP – NETWORK AND STORAGE
In order to set it up in a highly available SSO infrastructure in Azure, the following components/servers must be deployed in Azure. Recommendations on the high-level architecture is also described on http://technet.microsoft.com/en-us/library/dn509538.aspx.

First of all, if you’re setting up your Azure Infrastructure from scratch, you need a virtual network and a storage account in the region that is closest/best for you (in my case, North Europe). See the following tutorials on how to create a virtual network, a storage account and an affinity group.

In my example – the virtual network in Azure is configured as follows:

2014-11-22 13-42-09

The network 10.255.255.0/24 is divided into two subnets except for the gateway subnet. One “Internal” subnet and one “Perimeter” subnet in order to filter traffic based on the source/destination IP, that is now possible through Network Security Groups (NSG’s) in Azure. A local network has also been added for on-premises connectivity.

SETTING IT UP – VIRTUAL MACHINES
In my example, I will deploy six(6) virtual Machines with the following roles:

Name Role IP Size Cloud Service Availability Set
AZURE-DC1 Domain Controller 10.255.255.4 Small 365lab-azr01
AZURE-AADSYNC1 DirSync/AADSync 10.255.255.5 Medium 365lab-azr01
AZURE-ADFS01 ADFS Server 10.255.255.6 Small 365lab-sts sts-365lab
AZURE-ADFS02 ADFS Server 10.255.255.7 Small 365lab-sts sts-365lab
AZURE-WAP01 Web Application Proxy 10.255.255.132 Small 365lab-wap wap-365lab
AZURE-WAP02 Web Application Proxy 10.255.255.133 Small 365lab-wap wap-365lab

In this case, I’m choosing to deploy only one domain controller in Azure, and configure that one as the primary dns for the virtual network, and the local network domain controllers as secondary dns servers. Note that the ADFS and WAP servers are placed in separate cloud services/availability sets in order to make them highly available.
You will find a reference regarding machine sizing here. Estimated costs per month for the above setup will with list pricing be around $500 including network traffic and storage. The exact pricing will of course be depend on your Azure agreement and network traffic.

 

The overall high level design of the setup will be as in the following sketch:
Azure-Reference-Test

In the next part of the series, we will deploy the virtual Machines with the proper configuration using Azure PowerShell.

Until next time!

/Johan

Advertisements

9 thoughts on “Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure – Part 1

  1. Pingback: Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure – Part 2 | Tailspintoys – 365lab.net

  2. Anders Bäck

    Hi Johan. Great series of articles !
    A question though, whats the reason for using a separate server for DirSync, instead of installing it on the DC (AZURE-DC1) ? As I guess you are using the “light” version of FIM 2010 R2 that comes with O365, which now support installation on domain controllers, I’m curious to know if there are any special reasons for the separate server?

    Reply
    1. Johan Dahlbom Post author

      Hi Anders,
      Thanks for reading! The reason in this case to put DirSync/AADSync on a separate server is just to keep the environment as clean as possible. If you were to deploy the same solution in the cloud and would like to save compute costs, you could definately co-locate the DirSync/AADSync Service on another server as long as you choose a proper instance-size. For management and security purposes, my preference in that case though, would be to co-locate it on one of the ADFS servers than rather than a Domain Controller.

      /Johan

      Reply
  3. Pingback: Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure (Using Azure AD Connect) – Part 3 | Tailspintoys – 365lab.net

  4. Pingback: Real world example on Network Security Groups in Azure | Tailspintoys – 365lab.net

  5. Baatch

    Hi Johan,

    What is your take on using seperate Virtual Networks for Azure-Internal and Azure-Perimeter network VS having it all in 1 Virtual Network and use NSG?

    Which is best/safest/easiest to administer and what to do recommend your customers to use?

    Reply
    1. Johan Dahlbom Post author

      Hi,

      Of course it depends on what you want to acheive. But in most cases the separate subnet is the way to go, since customers don’t want multiple gateways for internal connectivity. Of course the NSG management part can be a bit tricky, hopefully MS will make that a bit easier when they release the new portal in full.

      /Johan

      Reply
  6. Ryan

    Hi

    Are you planning to publish the steps for Option 2:

    Some Office 365 SSO integration components deployed in Azure for disaster recovery.

    Thanks

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s