Quantcast
Channel: Microsoft Office 365
Viewing all articles
Browse latest Browse all 17713

ADFS 2.0 and the dos and don’ts of single sign-on for Office 365

$
0
0

This is the 216th article in the Spotlight on IT series. If you'd be interested in writing an article on the subject of backup, security, storage, virtualization, mobile, networking, wireless, cloud and SaaS, or MSPs for the series PM Eric to get started.

Sometimes it seems Microsoft loves complicated things — this should come as no surprise to anyone who’s been in IT for more than a minute. Office 365 and Active Directory Federation Services are no exception to this.

Going through a recent Office 365 migration, the question was posed, “Do we want to allow single sign-on (SSO) for all domain users?” Of course, everyone said, “Yes! It makes absolute sense! The same password to log in is the same password for your email and other services!” Here’s where reality hits you in the face…

1. ADFS is pretty complicated

It requires a good bit of pre-work and resources to get this setup properly. Can you run it all on one server? Sure. Do you want to run it all on one server? Absolutely not! Reason is, Microsoft in their recommendations says you should use five (count ‘em) servers for a proper ADFS 2.0 setup. And all of these need to talk to each other in specific ways. So prepare yourself for a treat — it isn’t fun!

What MS calls for is:

  • Two ADFS internal servers with wwo NICs and NLB
  • Two ADFS external proxy servers with two NICs and NLB
  • External and internal DNS records pointing to your NLB fed farm (fs.whatever.com)
  • One directory sync server
  • An SSL cert registered to fs.whatever.com
  • HTTPS traffic allowed from external proxies to internal NLB cluster

2. Yes, get an SSL Cert

One thing that kind of bothers me is people get really antsy when buying SSL certificates. The idea of spending $250 for a GoDaddy simple SSL cert for five years pains people, yet the five servers’ worth of resources in either physical or VMs seems like nothing. The cert should be the LEAST of your problems, and people want to always go the self-signed route. Take it from me, buy the cert! You’ll want your traffic for login information properly secured.

3. Sign-in requests and uptime are now YOUR responsibility

A thing to remember is that Office 365 was meant to take the hassle away from managing Exchange, SharePoint and Lync. With ADFS now at your site, you are in charge of making sure it stays up. If your proxies go down, ALL Outlook clients cease to connect. So the ability for IT to effectively manage ADFS is crucial to uptime. Yeah, MS will have your email in the cloud and mail will still flow to it, but nobody will be able to touch it if those are down.

4. VMware does not play nice with NLB/unicast

One of the gotchas we found is that VMware hates unicast mode in the MS recommended NLB setup over different hosts. Hyper-V doesn’t share this issue, but if you have your VMs on different hosts within a VMware environment, unicast gets spotty. They also recommend in VMware, and I’d recommend in ANY virtualized setup, that you have two NICs per federation server.

The benefits of it do outweigh the hardships and risks, given that as far as your users are concerned, it’s transparent. And it transfers into other services, such as InTune, which you should definitely check out if you want to effectively manage outside machines. The good news is once ADFS is set up, you typically don’t have to mess with it. It works until you mess with something or a password expires. After setting it up, you’ll eventually know the ins and outs of it. Just gather your resources — and beer — it’s going to be a long weekend!

On the side note, since I’ve gone through the ringer with setting these up, I have a how-to on setting this up. I plan on posting it soon in the How-To’s, so keep a look out.


Viewing all articles
Browse latest Browse all 17713

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>