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.
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.
- 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.
- 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:
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-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:
In the next part of the series, we will deploy the virtual Machines with the proper configuration using Azure PowerShell.
Until next time!
Pingback: Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure – Part 2 | Tailspintoys – 365lab.net
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?
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.
Pingback: Office 365: Deploying your SSO Identity Infrastructure in Microsoft Azure (Using Azure AD Connect) – Part 3 | Tailspintoys – 365lab.net
Pingback: Real world example on Network Security Groups in Azure | Tailspintoys – 365lab.net
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?
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.
Are you planning to publish the steps for Option 2:
Some Office 365 SSO integration components deployed in Azure for disaster recovery.
I’m looking at it , but not have had the time just yet.