This post is the next in our series evaluating multi-device management and mobility with the Microsoft solution stack—specifically Microsoft Enterprise Mobility Suite (EMS). Security is a centerpiece of this discussion.
Enterprises (organizations with 5,000 or more employees) amass a large collection of tools, apps, and solutions that require secure user access. It can cost a small fortune to ensure continued access as the help desk resets passwords. Lost productivity costs can also spiral as employees try to remember multiple passwords.
Because of these costs, business leaders are highly motivated to make it fast and easy for users to access resources. But mobile devices and the bring-your-own-device (BYOD) trend can make easy, secure access a challenge.
Single Sign-On: Dream vs. Reality
IT departments are forced into a tightrope walk. They must give users easy productivity with the highest levels of security possible. If security requirements are restrictive, people will simply work around IT using consumer solutions that are a threat to security. But if you don’t implement some kind of security, you leave an attack surface that spans the entire footprint of enterprise IT.
Single sign-on (SSO) has long been marketed as an attractive security convenience. It promises to enforce access controls, but to do so in a simple way: users enter their credentials one time and then access all the resources they need.
But, as with most other things related to IT, reality is not quite so simple. SSO can be complicated and has lots of intimidating components like certificate management. In this article we take a deeper look at SSO; and we think you might find that you can deploy it faster than you thought and maintain it sustainably.
Your Microsoft Infrastructure Could Simplify SSO
Is an SSO solution enabled by Microsoft software right for your business? See Figure 1.
As you can see, your decision could depend on your current or future use of Microsoft cloud services. For example, if your business is transitioning to Microsoft Office 365, the timing is great to implement SSO because SSO might be a simple four steps away. These steps deliver an SSO-like solution that can support any resources based in the Microsoft cloud:
- Register with Microsoft Azure Active Directory
- Synchronize on-premises Active Directory Domain Services (AD DS)
and Azure Active Directory
- Configure federation
- Enable trust
To take full advantage of this timing, we recommend registering your domain with Azure Active Directory. Doing so will allow users to log on to their Office 365 accounts using the domain they’re accustomed to rather than a Microsoft.com domain.
Following Azure Active Directory registration, install the directory synchronization tool, which you can download here. This tool can help you securely synchronize your on-premises AD DS with the Azure Active Directory service. The installation and operation are straightforward, but watch for the option that allows on-premises passwords to synchronize with the Azure Active Directory users.
Next, install Active Directory Federation Services (AD FS), which will allow SSO with the Office 365 and Windows Intune web portal services. You can install AD FS 2.0 through Roles and Features on a Windows Server 2012 or Windows Server 2012 R2 server and as a downloadable package for Windows Server 2008 or Windows Server 2008 R2. The process looks a lot like this:
It is always a best practice to install an AD FS Proxy service, especially if outside resources will use internal solutions. The proxy server sits in the DMZ to separate traffic flow from the outside world and the internal AD FS server.
Use the following command shell command to establish the trust relationship for the on-premises AD FS and Azure Active Directory:
Set-MsolAdfscontext -Computer (http://msdn.microsoft.com/en-us/library/azure/jj205461.aspx)
We recommend that you do not use self-signed certificates for communication in an AD FS environment. The public DNS should point to the proxy server and internal DNS should point to the AD FS server. Both should use a central DNS name, for example sts.contoso.com. This central DNS name should be the name used for the public certificate request. You should then use this certificate on all AD FS servers involved in the setup.
To make your setup more resilient, we also recommend that you use more than one AD FS server and AD FS Proxy server to handle requests and failures. You can also set up AD FS to take advantage of database clustering capabilities to make your SSO even more robust.