Lately, the method of declaring your identity with more or less random, and static characters has come under fire in the public discussion. Here I am of course referring to the infamous Password, which is the subject in my blog.
Evolutionary history of the Password has been one of increasing complexity and length of the strain, not much of focus has gone into getting rid of the Password altogether. As this seems easier said than done, it is probably safe to say that PASSWORD remains undisrupted in the age of DISRUPTION.
Password, a vessel of mayhem
Today, the sheer amount of secrets and power held behind the Password is enough to cause chronical anxiety and sleepless nights. The mayhem one can cause with a VPN-client and Username/Password combo is nothing short of Apocalyptic in magnitude. Maybe in some distant (or not so distant) future, a small group of survivors will tell cautionary tales to their progeny about the infamous Password, and the maladies it brought upon the unsuspecting mankind.
The jury might be still out about the future of Password. Nonetheless... I’ve devised a short plan to address parts of the dilemma - if you feel it’s time for the passwords to do die? Let’s call it the “Passwordless Authentication” for the time being, which is already known concept.
The concept is based on the following two tenets:
- Modern application user-interface should do without passwords
- We almost always have a mobile phone on us
If you want to embark a journey on something that Google calls BeyondCorp, or what Microsoft calls their Enterprise Mobility vision, then this is one of the most tempting ways to start the journey. In short summary, both models place the focus on identity and devices, instead of using the model of trusted & untrusted networks.
The solution itself is very simple, we just remove the Username/Password factor from the typical Multifactor Authentication sequence. Nuts? Arguments can be of course made to retain the Username/Password factor. Yet I am making an argument here, which assumes that throwing passwords at your keyboard/web forms, actually weakens the total security of the user?
- You’re less likely to throw passwords at your keyboard, since the option is missing from the login screen
- Joining of device to Azure AD is automated
- Users with Hybrid Azure AD joined devices have seamless SSO experience inside and outside corporate network, with just initial login to Windows
- Conditional Access or AD FS Access Policies can enforce multiple factors if the single factor isn't enough.
How it plays out in action?
User experience – Non-joined Device
“Non-joined Device” is any other device than the Hybrid Azure AD joined device
- User has only one authentication method available (Azure MFA OTP)
- In this example user Roy.Batty@tannhausergate.io attempts to access corporate resource
User experience – Hybrid Device
- “Hybrid Device” is Windows device that is joined to both Azure AD and Local AD, and is recognized by both.
- With Hybrid Device, user has satisfied authentication requirement after Windows login is performed successfully, and can access properly configured resources with seamless SSO from there.
What’s behind the seamless login experience (shortly)?
Finer details of this solution have been covered in many blogs before. Thus I am saving LinkedIn from PowerShell transcripts, and from most of the technical details.
Following technical data can be inspected from Active Directory and desktops when seamless login is configured and working as expected.
(To avoid confusion there is also Seamless SSO, which is another Azure AD feature, this is somewhat parallel scenario, with AD FS and Hybrid Device Join)
- Device holds unique token, that is used to validate Devices Azure AD join relationship with Azure AD Device Registration Service.
- Device is written back to on-premises AD from Azure AD and can be identified in two different AD containers.
- Some lifting with claim rules is in order, before OTP works as single factor (Non-Azure AD joined devices).
A lot of good can come of out the Passwordless deployment already today, but it would be unfair to leave the following facts out, as there are still some roadblocks to take out.
- Some legacy clients don’t support Passwordless/Multifactor-authentication.
- Seamless authentication might be too bit seamless for the concerned sort. Basically meaning, that no visible authentication factors are performed once users logged into Windows with device PIN or Fingerprint.
- Applications that don’t support Windows Authentication, or don’t support any federation protocol as means of authenticating will require some work before you can even think of bringing them into the scope of seamless login, or MFA as primary authentication.