Login prompts to websites are a pain. Enterprise employees these days expect to have a single sign-on experience (meaning the same username/password everywhere) and a minimal amount of logging in to systems each day.

It’s a very different from years ago where every system had it’s own unique login, and users got into the habit of synchronizing password changes when the regular password expiries hit (and I’m sure some companies still run this way), but it’s a problem IT as a whole has worked on for many years.

Microsoft has had a big focus in identity management for many years, with products such as FIM/MIM and ADFS along with the old faithful Active Directory, controlling and giving framework for authentication. The on-premises approach didn’t work for cloud based technologies though. Going to a site such as Office365.com will show an area to sign in:

Going back to the requirements of getting logged out of sites, or needing to log into each different Microsoft service is a pain and time sink for users. The original answer to this problem was ADFS. This works well, but requires the ADFS infrastructure to be set up, and needs to be highly available. If ADFS goes down, your users can no longer authenticate to Azure AD, which is what powers the identity management and authentication orchestration for Microsoft enterprise users (this includes Office 365).

More recently, another native solution was released – Pass Through Authentication for Azure AD Connect (Azure AD Connect being the service that syncs your on premises AD to Azure AD). This removes the requirement for entering a password to these Microsoft services which is great for users, but still requires the entry of the username (which in Azure AD, is the User Principal Name, and looks the same as an email address to confuse things more for users). It’s a good start, but still not the seamless authentication many users expect.

There is another way of providing zero-touch logins to Microsoft services without ADFS, which is Azure AD Domain Join. Windows 10 is a requirement here, but beyond that, the setup is quite easy if you’re already configured for Azure AD. Maurice Daly has written a great guide on this, which outlines all the requirements and steps to follow to be up and running. (Thanks Maurice for your help on this!)

Gotcha for myself: I found that I had an old version of the Microsoft Azure Active Directory Module for Windows PowerShell which didn’t have the get-msoldevice cmdlet at all, and had to download an updated version. I also updated the AzureRM module for good measure since it was also out of date, but shouldn’t have been a requirement.

This is a rather complex topic, so I’ve tried to give a fly-over view of the native options available. There’s also Smart Links which can speed up and improve the user experience.

If you’re on Azure AD and Windows 10, give Azure AD Domain Join a try. It may save you the hassle of building and maintaining an ADFS server, and give your users a better experience overall.