Brian Jackson - Fotolia


Office 365 single sign-on augurs complexity, setup hitches

Office 365 SSO allows end users to log into the enterprise network with existing credentials from any device, but admins should consider security requirements before implementing SSO.

Single sign-on is one of those security technologies that, due to implementation challenges and network architecture complexities, among other things, never really took off on a large scale. However, a cloud service such as Office 365 is the perfect scenario for SSO.

Whether you deploy SSO on premises or in Azure, the key benefit of Office 365 single sign-on is that end users log in with their existing enterprise network user credentials.

Other positive aspects of Office 365 SSO include not having to store passwords in the cloud, support for multifactor authentication and someone else being responsible for system resiliency.

What more could an already overwhelmed Microsoft Exchange admin ask for? Well, experienced IT pros know things don't always work the same in the real world as they do in sales and marketing brochures.

By jumping on the Office 365 SSO bandwagon, there are plenty of considerations and complexities that can make your job as an Exchange administrator more difficult. Users can access Office 365 via any device. Therefore, controlling and auditing specific device usage (e.g., which user logged in from which device) can be problematic. Office 365 single sign-on complicates mobile device management (MDM) and BYOD policies and procedures. You can, however, limit user and device authentication to Office 365 by requiring the devices first be connected to the enterprise network. You have to ask: What are you trying to accomplish? Will you be able to meet specific security requirements by using SSO for Office 365? How will things interact with any existing MDM deployment?

Complexity is the enemy of security. Single sign-on aims to simplify network and application access; however, getting your enterprise ready for seamless connectivity to Office 365 can end up complicating things more than before. For example, the mobile scenario above opens up questions of remote connectivity and network access control. What happens when you introduce Active Directory Federation Services, synchronization and federation into your environment? The high-level instructions for configuring Office 365 SSO can be distilled down into a seemingly manageable scenario. That said, your situation is unique. Will you be solving one set of problems (i.e., systems to manage, things that can break) while creating another?

If you're partially or fully dependent on Microsoft Azure for authentication services, you need to have a backup plan for when Office 365 goes offline. How will users authenticate? What failover environment might the enterprise require if cloud-based services remain unavailable for an extended period? What service-level agreement requirements must you and your business meet? Are you willing to stand behind such a configuration knowing the risks?

Will your existing network infrastructure, Internet bandwidth and related technical underpinnings be able to support and maintain a rollout of single sign-on for Office 365?

I love what SSO stands for and I'm a huge advocate of taking advantage of the cloud -- but only when it makes sense. With email being such a critical business application, you have to step back and think about the potential consequences of your choices. Do it well and you score a big win. Do it poorly and you've got a whole new set of challenges, causing the messaging environment to become kludgy at best and at worst opening holes in the enterprise security defenses.

Next Steps

Troubleshoot the banes of Office 365 admins' existence

Make the Office 365 migration an easy one

How many tenants should you use in Office 365?

Dig Deeper on Office 365 and Microsoft SaaS setup and management