Welcome to another installment of our May series of articles – “20 Key Scenarios with Windows Azure Infrastructure Services”.
Today I’m going to describe a scenario, a problem, and then propose a solution.
The Scenario: Single Sign-On support using Active Directory, Windows Azure Active Directory, ADFS (Active Directory Federation Services), and Office 365 and/or Windows InTune.
For those of you who may not be familiar with it, you have the ability to set up a federated identity relationship between your local Active Directory and your Office 365 authentication. In this way, your people, simply logging in with their local domain accounts, are able to be automatically authenticated against Office 365, because Office 365’s use of Windows Azure Active Directory, and you have the ability to set up an ADFS relationship between the authentication in Office 365 and your company’s Active Directory domain. So, you manage one set of user accounts locally, just like you always have, and Office 365 can grant access based on the “claim” that the user account is known and valid. Your client (laptop, tablet, or other mobile device) gets the claim from your Active Directory (preferably by accessing an ADFS Proxy in your company’s perimeter network), and then passes that acquired claim up to Office 365.
In short – Your users are either already authenticated, or just have to set up the authentication parameters one time for their use of the cloud-based services such as Office 365, Windows InTune, or other such services.
For details on setting up Single Sign-On for Office 365, see “Plan for and deploy AD FS for use with single sign-on”
So this is great. No matter where I am, or where my people are in the world, they can use their domain account and local profile and just open up Outlook or access the cloud-based SharePoint or their SkyDrive Pro storage, and they’re authenticated. And even if they’re using a non-domain machine or a mobile device, they’ll use the same company credentials they’re already familiar with to connect to their company e-mail or other resources.
The Problem: I’m outside the office, and the connection to my ADFS Proxy is unavailable. 
What happens then?
“Yeah.. what happens then?!”
I’ll tell you what happens then. It’s a problem, because, your device needs to get to the ADFS (STS) proxy to verify that you are who you say you are, and to give you the claim token that is passed up to Office 365. If it is unavailable, then your users can’t be trusted by their cloud-based resources. Outlook won’t be able to connect to the Office 365 Exchange server. Yeah.. a big problem. That’s why so much documentation (and even the promise of Microsoft support) is devoted to the configuration of a load-balanced farm of servers to keep that proxy service high-performing and highly available.
Granted, it’s an even bigger problem for the people who are sitting in that office. Presumably they can’t access the Internet at all. So assuming that your company, like most others, is becoming more and more dependent upon that Internet connection being live in order to get their work done, you’ve probably already addressed alternatives. And many people nowadays have multiple personal paths to the Internet that would restore some amount of personal access. But that doesn’t fix their problem of not being able to get Outlook to connect.
The Solution: Put a copy of your domain in “the cloud”!
Think about it: If I have a replicated copy of my domain up on a virtual machine running in Windows Azure, then that domain controller can also serve as the trusted location where Office 365 and the ADFS trust can be connected!
“Sounds like an interesting idea. But what if I don’t want a copy of my domain up in the cloud?”
Then another option would be to Windows Azure virtual machines as your ADFS Proxies. Basically think of Windows Azure as an alternative to (or an extension of) your Perimeter network (DMZ). Of course in this case if the availability of your home datacenter goes down, you’re still going to have authentication issues.
Here’s a thought: Do both! Have an AD site up in Windows Azure, with a secured/authenticated/encrypted connection back to the corporate network. And then build an externally available, load-balanced set of machines in a separate “perimeter” network in Windows Azure as well. In this way, even if your connection back to your main office and the local AD DCs goes down, you still have AD authentication available “locally” within your Windows Azure subscription.
---
What do you think? Do you have any other ideas or suggestions? Any concerns? I’d love to hear about them in the comments. Let’s discuss!
And if you’ve missed any of our ““20 Key Scenarios with Windows Azure Infrastructure Services” series, please click on this link to find all of the other great articles.