Welcome, fellow Azure Security Practitioner! I’m willing to bet my next paycheck that you’ve stumbled across this particular post as you’ve recently been tasked by Management with helping your organization make the transition to passwordless authentication. Being that you’re already operating within the Azure ecosystem, you figured this post was a practical place to begin. Wise decision! Did you know that compromised passwords played a key role in 80+% of cybersecurity breaches last year? You do now. It’s not just about being safe, it’s also about being practical and operationally efficient. For the cost conscious and frugal amongst us, you should also be aware that there’s tremendous ROI associated with going passwordless, and you’ll even save a few bucks on your cyber insurance rates. All good stuff!
In the following guide, we aim to provide insight on how you can go passwordless in Azure AD. We intend to cover everything from all the “gotchas,” to links, to step-by-step tutorials for each process, to the pointers that’ll ensure you’re up-to-date with Azure Identity Security Best Practices.
On the path to passwordless authentication, selecting which method(s) of authentication you’re going to use is considered to be the proverbial “square one” of the entire operation. Here’s our take on your choices, their pros and cons, and which scenarios in which they work best.
If there’s an “old man River” of passwordless authentication, it’s “cert”ainly CBA, or certificate based authentication. Smartcard (PIV) authentication uses x.509 certificates in a smartcard (or hardware tokens). This is the only authentication method that is supported by all on-premises and Azure-cloud authentication libraries, making it the most versatile authentication method.
FIDO2 has gained popularity in the passwordless community due to its reputation of being easier to implement and more convenient to authenticate with (which it is). Some of the most prominent examples of hardware security keys are the YubiKey, and Google’s Titan Security Key. Unfortunately, as with any new technology, there are some problems authenticating with legacy systems such as on-premises, and there is still no full FIDO2 support in iOS or Azure PowerShell. Did we mention we’re proud, card-carrying members of the FIDO Alliance? …because we are.
While not the most secure method, phone authentication has quickly become the authentication method-de-jour in the IAM community. Why? Easy: pretty much everyone carries their phone with them at all times. For that simple reason, it’s the most widely employed method today. Phone authentication is not considered to be unphishable as users are prone to MFA fatigue.
One of the most common misconceptions about going passwordless is that EVERYONE in the organization requires the same level of protection. It’s simply not true. For example, your sales team may use their phones and authenticate via an app, and your Executives (with more valuable data) can be protected using hardware security keys that employ FIDO2+CBA. At the end of the day, passwordless solutions are truly agile in nature. So, when it comes down to it, it’s a delicate balancing act between usability, cost, and risk tolerance. Here’s some specific use cases for your consideration:
If you are on a budget, using the most popular passwordless authentication method, Microsoft Passwordless Authenticator is a great option.
Why?
1) It is $Free.99 (that is to say, it’s free).
2) Users are accustomed to using their phones. Employing it as an authentication method is very natural.
Note: phones aren’t fully unphishable and MFA fatigue plays a major role in phishing.
We’ve written extensively this year about On-Prem passwordless deployments, and in every post, we’ve gone out of our way to make it clear that Smartcard PIV Authentication is the way to go in this scenario. A couple of really great things here…
1) Smartcards are significantly less expensive when compared to the cost of Hardware Keys like YubiKeys.
2) Smartcards can be used for more than just authentication! For example, you can leverage them as employee IDs and use them for Building/Room access.
If there’s one “con” in this scenario, it would be that you’re going to need additional hardware (card readers, smartcard printers, etc.) to really make this a feasible option. While you can acquire reasonably priced hardware these days, it’s important to do a full cost/benefit analysis prior to making any knee jerk reactions. That said, you should probably use smartcards in an On-Prem deployment. More on acquiring hardware later on in the post…
The natural inclination for most Azure AD Practitioners is to gravitate towards FIDO2 in a cloud-only deployment. While very well intentioned, a single authentication method isn’t sufficient in this use case, mainly because FIDO2 isn’t compatible with all Microsoft services. For example, tools using MSAL, like Azure PowerShell, do not support FIDO2 authentication.
To work around this headache, we use FIDO2 + Azure CBA certificate authentication. Basically, how we accomplished this was by adding a smartcard certificate into our FIDO2 Credential (YubiKeys, in our case!) Our tool, EZCMS, is the only solution available that can add a Smartcard certificate and FIDO2 credential to a YubiKey in the same onboarding process! The best part? All of your authentication needs are solved with no confusion for the end user. More often than not, they’re not even aware as to which method was employed to authenticate!
Making the decision to go passwordless is a courageous one, and we certainly do admire your ambition! That said, we’ve still got PLENTY of more research and testing ahead in order to make this transition as smooth as possible. Here’s a quick glimpse into some of the FAQs and next-steps associated with going fully-passwordless in Azure.
While Microsoft has been talking a whole lotta smack about being “fully-passwordless” for quite some time now, they STILL don’t have the option of creating users without a password. In this case, we create users with very long passwords (that are not stored anywhere) and have conditional access policies that require a passwordless authentication method. We have a great guide on how to create users with random passwords that will provide you with the PowerShell code to create the users.
If you are reading the Microsoft documentation, they will recommend using a TAP, but if you really break it down, a TAP is just a one-time password vulnerable to the attacks we mentioned before. Need more info? We have a full article on how to onboard users without TAP.
TL:DR: You must have a self-service onboarding option such as EZCMS’ government ID validation.
For both large and small businesses, one of the hardest parts of going passwordless with hardware tokens is the distribution; from dealing with customs, to having a dedicated team to manage and ship the keys, it can become exceptionally complex. Luckily, we have learned from distributing tens of thousands of keys around the world and happily offer managed smartcard and YubiKey logistics services where we leverage our partners around the world to distribute keys to your users. At Keytos, no matter your size, we can help you with everything related to hardware logistics.
The best way to authenticate into your VPN and WIFI is using X.509 Certificates managed through Intune SCEP. You can setup your ADCS CA and SCEP server and manually maintain those servers; however, there are third-party Intune PKI services such as EZCA that make the whole process VERY easy. Have your HSM backed CA and passwordless WIFI profile set up in minutes.
Once you have rolled out passwordless authentication to your organization, it is time to enforce that only those methods are used for authentication. Thankfully, Microsoft makes it easy with conditional access (as long as you have an Azure Premium P1 or higher license, but it is definitely worth it). To set this up you can go to the Azure portal as a global administrator, click on Azure AD then on Security -> Conditional Access Policies -> New Policy. Name your policy, set a handful of test users to test the policy (you don’t want to lock out your users), Select the applications you want to enforce this policy on. Set your conditions (in here you can exclude device platforms that do not support your selected authentication method; however, we recommend enforcing it everywhere. Remember, hackers only have to find one weak spot). Set the “Require Authentication Strength” to Passwordless MFA in the Grant section of the access controls. We also recommend setting device requirements; you can watch our webinar on device security, but this blog is already too long to go in depth on device security as well.
While the first step to passwordless authentication is getting your corporate account secured, many organizations end there and forget about one of the biggest portions of their critical infrastructure: Linux. By default, Linux is designed to have local accounts that are not connected to Active Directory. This used to be acceptable, but in today’s world, the overhead of credential lifecycle and user management does not scale to cloud requirements. To solve this, many try to AD join their Linux machines. While it “works,” it’s not as secure and prone to DNS-related outages. Industry leaders like Google, Facebook, Uber, and Netflix have instead turned to SSH certificates for secure Linux authentication. So, what are SSH Certificates? More on that over on the blog.
As you can plainly see, going fully passwordless in Azure may have a lot of moving parts, but it is 100% attainable. If you are ready to take the next step on your passwordless journey, book a call with one of our engineers with over decades of experience moving some of the largest companies (including Microsoft) to a fully passwordless environment. We are happy to review your plan and ensure that you have crossed all your t’s and dotted all your i’s!
