Share via

Put your ADFS in the Cloud - 20 Key Scenarios with Windows Azure Infrastructure Services

  • Article

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.

Relying party trust with Windows Azure AD

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.   Sad smile  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.

Here’s a document that describes the process in great detail: 

Office 365 Adapter: Deploying Office 365 Single Sign-On using Windows Azure

---

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.

Comments

  • Anonymous
    May 16, 2013
    Personally, I don't see the point of putting just the ADFS servers on Azure VMs and keeping the DCs on-premise and that's also what Microsoft recommends in www.microsoft.com/.../details.aspx where they say: "Although it’s possible to deploy AD FS on Virtual Machines in Windows Azure and leave the domain controllers on-premises, we strongly discourage it. Separating your domain controllers from your AD FS may introduce latency into the authentication chain. This creates a real-time dependency on the network connectivity for these two services." Comments?

  • Anonymous
    May 16, 2013
    Excellent point, Jones.  (and thanks for the link) This is another good argument for putting a domain controller in the cloud alongside of the ADFS, as I mentioned in my last option.

  • Anonymous
    May 17, 2013
    Something like this is what I have done for my home/family network. I created a VPN between Azure and my home router. At home I am running two virtual servers: One domain controller and one memberserver with Office 365 DirSync. In Azure I created a domain controller and installed AD FS on it. Whenever my internet connection is down, DirSync does not work (who cares, I don't create new users every day) but AD FS keeps working. Also because I am only running a very small network, I did not create AD FS proxies, but just a standalone AD FS server. I have tested a disaster recovery scenario, and it takes only about 30 to 60 minutes to recreate a domain controller with AD FS in Azure, including replication from the on premises DC to Azure. Microsoft's recommendations are for large enterprises. I don't see the point of having a redundant AD FS for small businesses or home users.

  • Anonymous
    May 17, 2013
    Thanks for sharing the details of your setup, Stefan.  And I in general would agree that if you're just using this for home users, a redundant ADFS isn't really that necessary.  But really, that determination for small business or even home use would be based on how absolutely critical the up-time for single sign-on should be.  Even the smallest business may have need of a consistent, highly available service.  It all depends on what they're doing or what they're using it for.  

  • Anonymous
    June 12, 2013
    Thanks for the article.  I have two questions,

  1. What's the best way to make the VPN between the Azure DC/ADFS and the local DC persistent?  What VPN connection should be used?
  2. Is there any firewalls in place for a Windows Azure VM, besides the built in windows firewall?  When it's on a local network, it's behind a firewall.  I'm hesitant to put a DC out in the public with only the Windows firewall to fend off predators.  What are your thoughts?
  • Anonymous
    June 12, 2013
    Great questions, Caleb.
  1. You can make a consistent tie between gateways for virtual networking between your datacenter and the network you create in Windows Azure.  Check out Keith's step-by-step blog post here for a good description and example of the process to create that connection: blogs.technet.com/.../step-by-step-extend-your-private-cloud-with-windows-azure-virtual-networks.aspx
  2. Every Azure VM also has "endpoints" that can be configured.  Unless specifically defined endpoints are created, there is no access to the machine.  By default, for example, and endpoint is created to map some external non-standard port # to the machine's port 3389 for the Remote Desktop Protocol (RDP) connection.  You can create other endpoints, and then map them from some non-standard port to a different port on the VM itself, or just use standard ports for both.  (Example: a web server would want external port 80 coming in on the VMs external IP address to map to port 80 on the internal IP address. I hope that helps! Kevin

  • Anonymous
    August 02, 2013
    Also if you want a quick way to configure AD to Windows Azure AD federation and proxies using powershell, check out this quickstart guide: http://aka.ms/ad2aad

  • Anonymous
    August 02, 2013
    Thanks for sharing that, David!  I definitely think people should check that out.

  • Anonymous
    October 19, 2015
    The recent announcement of Azure AD Domain Services (domain controller as a service) put a new twist on this concept, making it even more workable in many cases.