Why Windows Hello for Business, Microsoft Authenticator, and FIDO2 are not a suggestion, but a requirement for your Azure AD powered enterprise – PART 2

If your environment is a Microsoft Active Directory-based environment and leverages Microsoft Azure Active Directory (Azure AD or AAD for short) to extend your deployment as your primary cloud-based identity provider (IdP), then you must plan to deploy the 3 modern password-less access management solutions that work with Azure AD in order to take full advantage of the identity platform. In yesterday’s Part 1 of this article series, I covered the theory and history around the path to password-less authentication and today in Part 2 I will cover these 3 solutions in more technical depth as well as share some of my real-world experiences with them.

Deploying these solutions is not a suggestion anymore, it’s a requirement for you to run your business successfully at a time when user credentials are attacked and stolen leading to massive security breaches at an unprecedented level year after year causing enterprises millions of dollars. Not even the stolen intellectual property, damage to systems, or bad press….just the amount of IT overhead involved is significant managing this day-to-day, much less post-security incident. I’m not going to cover those numbers and attempt to fear-based sell you to take action within your organization. You should only take action if you want to genuinely progress the security of your environment and offer a faster end-user authentication experience compared to using passwords. Your attempts to modernize your organization should be based on positive outcomes for your end-users, not a negative driver.

Just entering a user ID, then password + MFA is not good enough anymore. I repeat, enabling MFA is not good enough anymore. You need to deploy fully passwordless solutions that use localized biometrics and trust solutions to ensure very strong multi-factor authentication that are unphishable to prove the identity of your users while also maintaining a stellar user experience for them that they will embrace. This is not smoke and mirrors talking about an ideal years from now. These solutions are here and now ready for you to deploy and will work with your physical desktops/laptops, virtual desktops, and SaaS apps from any device, anywhere. I’ve helped organizations deploy these solutions enough times now and use them daily myself, I can’t imagine going back to passwords in an enterprise setting.

If your organization is still forcing user password expiration every 90 days, you are far behind the curve and doing this against recommended practices from the National Institute of Standards and Technology (NIST) and Microsoft. You need to completely re-think your identity and access management strategy and start deploying passwordless authentication as soon as possible. There are 3 fundamental password-less access management solutions from Microsoft and the potential authentication use cases they may solve in your organization that I will cover today. It’s not a massive undertaking to deploy these solutions so there is no reason to wait on these deployments in your organization. Get CISO (chief information security officer) level buy-in and start now if you haven’t already. Don’t be afraid to talk to your CISO. I can almost guarantee he/she already has user credential theft mitigation as a top of mind item and is just waiting for someone in the organization to help prioritize and drive it.

Be that person. Be the spark to get others around you talking and genuinely excited about going passwordless.

Microsoft’s modern password-less access management solutions in detail

Windows Hello for Business

Use cases and important items to note include:

• For domain-joined physical Windows desktops and laptops
• Uses biometrics (fingerprint, facial recognition) or PIN. Don’t worry, neither is sent over the network as part of the authentication flow and is localized. Try and use biometrics with your users for better security and user experience, PIN should be a fallback for them. PINs are something that can be stolen simply by observing a user and isn’t a true proof of identity (it’s something you know vs something you are). You can set longer PIN requirements but that just causes unnecessary user friction in the real world. Instead, use the Multifactor Unlock capability of Windows Hello for Business to have a higher assurance the PIN is really being entered by the user and not someone that simply managed to figure out another user’s PIN. Also note, you cannot disable PIN as it is a fallback mechanism for biometrics. Users will almost always naturally gravitate to the easier thing to use so biometrics should have high adoption with minimal user training and encouragement needed in my experience.
• Requires the laptop or desktop to have Windows Hello for Business compatible hardware. So newer devices in your organization will work but older devices may not.
• Is considered a client device with a platform authenticator in most cases, meaning the device you are logging into also contains the authenticator mechanism internally (fingerprint sensor, IR camera). In this case, the secure Trusted Platform Module (TPM) chip is recommended for all Windows Hello for Business compatible devices for best security posture, but is not a requirement. The Trusted Computing Group (TCG) helped bring the TPM specifications to a standard. Initially, there were TPM 1.2 chips and now newer TPM 2.0 chips on devices from 2016 onward. An admin doesn’t have to do anything with the TPM, Windows 10 will automatically initiate and control it. Do not confuse TEE (Trusted Execution Environment) with TPM. A TPM chip is an additional physical chip on the mainboard while a TEE is just a secure portion of the board and not physically isolated from the mainboard. Another thing to note is that Secure Enclave (used by Apple devices) has many of the same capabilities a TPM chip enables for processing biometrics securely like Face ID, Touch ID, etc. that is isolated from the main processor of the phone, but in the form of Apple A-series chips on phones or T1 or the newer Apple T2 chips on laptops. These do not apply to Windows Hello for Business at all.
• A private key is stored on the TPM chip of the Windows 10 device. This is the something you have and the biometric or PIN that unlocks it is the something you are or something you know respectively.
• Has been around longer than Microsoft Authenticator password-less phone sign-in and FIDO2 so is very mature at this point and deployed widely.
• Up to 10 users on a device can register in Windows Hello for Business on the machine. If you have a shift-worker based environment where multiple people may use a single device on a manufacturing floor for example, then consider deploying FIDO2 keys to them if you need to go over this limit. I suspect this is more of an artificial limit due to TPM chip constraints.
• Windows Hello comes in 2 flavors: Windows Hello and Windows Hello for Business. Windows Hello is designed for consumer devices and will allow a user to login with a biometric or PIN. Windows Hello for Business is designed for enterprises and offers more configuration options that IT can push and requires back-end infrastructure to support it which ultimately makes it stronger than regular consumer Windows Hello. In many enterprise organizations Windows Hello for Business is referred to as the shortened “Windows Hello”. Just keep in mind in enterprise IT if you have conversations around Windows Hello, usually, the person you are talking to is actually talking about Windows Hello for Business.

The key requirements to deploy Windows Hello for Business:

• Windows 10 Enterprise laptops or desktops only
• TPM chip-enabled device is strongly preferred
• Fingerprint reader or IR enabled camera (not a regular camera) on the device must meet very stringent hardware requirements for Windows Hello for Business use for fingerprint and facial recognition. If the device does not have them built-in, then you can purchase a USB fingerprint reader or USB IR Camera. Note, not all are created equally and some are hit or miss in my experience vs. built-in.
• The laptop or desktop MUST be Hybrid Azure AD Joined (Windows 10 1703 or later) or Azure AD Joined (Windows 10 1511 or later). Yeah, from way back in April 2017 and November 2015 onward respectively so hopefully you are on a newer OS build than this by now.
• You must choose if you want to deploy a key-trust (preferred) or certificate-trust model (which requires more back-end infrastructure). It is far more common to deploy certificate-trust in large enterprises but that will change in time.
• Your Active Directory needs to be on Windows Server 2016 Schema
• Your Active Directory domain functional level needs to be on Server 2008 R2 or later
• Your Domain Controllers need to be on Server 2012 OS or later or certificate-trust or Server 2016 or later for key-trust. This is really the big requirements difference between the 2 strategies.
• Your Certificate Authorities need to be on Server 2012 OS or later
• Azure MFA enabled. If you federate with AD FS, then make sure you have configured it for Azure MFA.
• An Azure AD tenant with Azure AD Connect syncing users. Enabling PHS and Seamless SSO is not a requirement for this to work but I would highly suggest both are enabled.

And there is a table of requirements covering every scenario your environment has in detail that is published by Microsoft. Again, Windows Hello for Business is very mature and has a few more moving parts/dependencies than the other 2 passwordless solutions I will cover. For this reason, there is quite a bit of deep technical documentation. Always look at this page for the latest requirements: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification

Microsoft Authenticator password-less phone sign-in

Use cases and important items to note include:

• Can protect access to SaaS apps like Microsoft Office 365, SalesForce, ServiceNow, or whatever websites you are protecting with Azure AD (aka have set Azure AD as your identity provider for these web apps). Any website that supports OpenID Connect (OIDC) or SAML is a good candidate to protect with Azure AD.
• Works when accessing resources from non-Windows devices (Mac, Linux, thin clients, Android, iOS, any modern web browser, etc)
• Works when accessing resources from non-managed devices (non-domain joined Windows devices, aka BYO devices)
• Works when accessing Microsoft Windows Virtual Desktop (WVD), Citrix Virtual Apps and Desktops (CVAD), VMware Horizon, and other solutions that “webify” Windows 10 as if it were a SaaS app and deliver it over a remoting protocol. And with Microsoft AD FS, Citrix FAS, or VMware True SSO (soon), with their respective remoting solutions previously mentioned, you can get full SSO into the Windows 10 OS after the remoting session has launched.
• With Windows 10 1903 from May 2019, Microsoft has pushed a new credential provider with this build so that you can actually use Microsoft Authenticator on your physical Windows device logon screen. It pops up up a web view with the number match screen. I have not tested this functionality just yet. The use case appears to be more for first-time setup of the device for things like Microsoft Windows Autopilot and not the day-to-day passwordless login method for users from what I have seen vs. using Windows Hello.

The key requirements to deploy Microsoft Authenticator password-less phone sign-in:

• An iOS or Android smartphone.
• Uses the built-in biometric platform authenticators on the phone (Face ID, Touch ID) or PIN code. So in the case of Apple, it takes advantage of the Secure Enclave I mentioned earlier.
• About 1 hour of your time. No seriously, it’s that simple to turn on run through PoC to a full deployment quickly. The technical side of this solution is a cakewalk. End-user and IT Service Desk communication and training are going to be the things that will take up your time but even that is so simple.
• I’ve written about it in detail here: https://www.jasonsamuel.com/2019/03/04/how-to-setup-password-less-phone-sign-in-authentication-with-microsoft-authenticator-azure-ad-and-citrix-workspace/

FIDO2 hardware security keys

Use cases and important items to note include:

• People that don’t have managed Windows desktops or laptops
• People that don’t have iOS or Android smartphones or make a personal choice not to put anything company-related on their personal devices
• Users that are bound by specific governance policy that mandates the use of a roaming authenticator (where the authentication device is separated from the computing device)
• Users that may have poor network connectivity. There are developing countries where many companies operate that don’t have the most reliable connectivity. There are parts of the United States where critical infrastructure passes through essentially no man’s land, where there are no cell towers and no Internet infrastructure in place, yet companies have to have personnel in those areas to help inspect and maintain the critical infrastructure.
• Physical hardware is required for contextual “step-up” authentication to a sensitive or classified system
• Can be used in shared computing or kiosk environments, think a hospital clinical scenario and the typical tap and go with a nurse/doctor’s proximity badge use case that companies like Imprivata and Caradigm have traditionally been able to provide
• Can be used with multiple AAD tenants with ease and with an excellent user experience choosing the identity at time of authentication. So all your test/dev AAD tenants or even 3rd party vendor AAD tenants can all be protected with a single key for the user. After all, a persona can change at any time but the user’s identity never changes. I can be an end-user or an admin of a system (persona) but I am Jason Samuel (identity) and that’s what you need to key in on, pun intended.
• Can be used for user’s personal services like Gmail, Facebook, Twitter, etc. to improve security hygiene on these services that can be used for targetted attacks against high-value end-users within your company. A single key can work for identity assurance for both enterprise and personal and if the user leaves the organization, don’t worry there is nothing proprietary on the key. You just disable their AD/AAD account as you have always done and they can’t use the key for your enterprise services but all their personal services continue to work as they own those accounts. The FIDO2 key is just a way to prove identity with high assurance and has nothing proprietary to your company. Issuing a key or letting a user bring their own key means that a single key can help users authenticate securely in personal and corporate lives.
• FIDO2 is not only password-less, but can be considered user ID-less to a degree too. The FIDO2 key stores the user ID (UPN, which is usually email address) and when used with Azure AD, after unlocking the FIDO2 key you are presented with all the identities labeled by UPN (email address) and you just click on the one you want to complete your authentication. It’s a very nice user experience not having to type in a user ID or password at all.

The key requirements to deploy FIDO2 hardware security keys in your environment are:

• A FIDO2 compatible hardware security key:
  • Step 1 – FIDO2 keys come in all sorts of shapes and sizes and support both physical and contactless authentication. Choose a key that supports the computing devices you like to use:
    • Physical ports
      • USB-A
      • USB-C
      • Lightning port
    • Contactless
      • NFC (Near-Field Communication) – for authenticating up to around 1.5 inches (4 centimeters) between the key and the device you are trying to log into. This works great with mobile devices like iPhone where iOS 13.3 and newer now supports FIDO2 over NFC and works quite well in my testing (note: support for Azure AD on iOS Safari is not available at the time of writing this article but will be available soon).
      • BLE (Bluetooth Low Energy) – for authenticating up to 330 ft (100 meters) theoretically between the key and the device you are trying to log into (I have personally tested to around 30 ft). These are great for use cases where a small form factor PC may be in a cabinet, on a cart, or mounted behind a monitor on a conference room wall while the keyboard and mouse are wireless and sitting elsewhere like on a table a great distance away. I have personally solved this exact use case using a BLE supported FIDO2 key. It feels akin to using Microsoft Authenticator in this regard but without the smartphone requirement.
    • Windows 10 itself
      • Windows 10 build 1903 and newer – starting with this build, Windows Hello has become a certified FIDO2 authenticator. Though not a hardware security key, you can use the Windows OS itself to manage your hardware security keys above including enrolling biometrics, PIN, etc on the key without having to use any 3rd party helper software from the hardware key vendors. You just go to the Windows Start menu and type “Sign-in options” and use the Security Key option to manage the fingerprints and PIN for your keys. It is the best enrollment experience in my opinion currently so I list it here as part of your requirements. This makes FIDO2 key adoption easy for your environment because you don’t have to deploy any 3rd party software to your Windows systems.
        
        
  • Step 2 – Now decide on the user experience when using the key:
    • PIN code
    • Biometric (fingerprint) – note, fingerprints are only used locally and never transmitted over the network or stored anywhere but locally, just like Touch ID on an iPhone.
    • Biometric (fingerprint) as primary + PIN code as secondary – this is a combo of the two above and is what I have been using on all my biometric keys as you are guided down this path when you do fingerprint enrollment with Windows.
  • Step 3 – And finally, purchase a key from a vendor. Many keys can do multiple forms of authentication and also support other less modern protocols that may be in use in your company. Multi-protocol FIDO2 keys give you extra flexibility if you need it in your environment (like using PIV and FIDO2 on a single key for legacy and modern access scenarios). I won’t recommend any specific key for you to use since your needs may vary from mine. My collection of FIDO2 keys has been growing quite a bit and here are some models I have tested successfully with Azure AD to date:
    • Yubico YubiKey 5 NFC – https://www.yubico.com/product/yubikey-5-nfc
    • Yubico YubiKey 5Ci – https://www.yubico.com/product/yubikey-5ci
    • Feitian BioPass K27 – https://shop.ftsafe.us/collections/fido2-usb-a-biometrics-1/products/k27
    • Feitian BioPass K26 – https://shop.ftsafe.us/collections/fido2-usb-a-biometrics/products/k26
    • Feitian All-In-Pass K33 – https://shop.ftsafe.us/collections/fido2-usb-nfc-ble/products/k33
    • Ensurity ThinC-AUTH – https://www.ensurity.com/Products/ThinC_AUTH
    • eWBM Goldengate G310 – https://www.ewbm.com/security-keys/goldengate-g310
    • HID Global Crescendo Key – https://www.hidglobal.com/products/cards-and-credentials/crescendo/crescendo-key
    • And I expect to test out keys from other vendors in the near future. The point is, there are many manufacturers of FIDO2 keys out there and every one I’ve tried thus far works really well with Azure AD.
• You guessed it, about 1 hour of your time. It’s mostly the same steps as Microsoft Authenticator passwordless phone sign-in at this point to enable. Since FIDO2 is still so new ensuring your users are using the right Windows OS build level or browsers will be your biggest challenge if any. Then, of course, communication and training.
• And I’ve written a detailed guide here covering the setup and testing of FIDO2 keys with Azure Active Directory step-by-step: https://www.jasonsamuel.com/2019/09/18/how-to-enable-fido2-password-less-authentication-with-microsoft-azure-ad-for-use-with-windows-10-and-saas-web-apps/

Thinking beyond passwordless authentication to decentralized identity

Once you have the 3 fundamental passwordless access management mechanisms in place, you should then keep an eye on where Microsoft and the identity industry as a whole are going with decentralized identity. The concept that the user owns and manages their own identity themselves which can be used for work services and their personal services. The user controls all aspects of their identity (in a secure and private method using a decentralized public distributed ledger that doesn’t require them to be an identity and access management expert!). The user proves this identity to your IT systems where you only have to manage what that identity can do within the services you provide to the end-user.

This universally accepted user-owned identity (derived from your identity-based private key stored in a user-friendly digital wallet) is called a DID (Decentralized Identifier). It is something still under development at various working groups like DIF (Decentralized Identity Foundation), but will at some point in the future hopefully become a standard. What the FIDO Alliance has done for more universal and open standards-based passwordless authentication, DIF is doing for identity. So my take away for you is to plan for what you need to do now which is to eliminate password usage by your end-users. Then plan for what you need to do in the future by having convos with your security teams and socializing that someday, Azure Active Directory or whatever identity provider you are using may work very differently when you don’t need to maintain ownership of the user’s identity. Identity will at some point be owned by your users as it rightfully should be. You will be responsible for making sure your IT systems will work with these solutions to ensure your business stays relevant as modern computing continues to evolve at an ever-accelerating rate.

Final Thoughts

I hope this 2 part article series has given you a good primer on understanding passwordless authentication and helps you plan to deploy these solutions in your environment a little easier. It all seems very simple when broken down like this, and it really is. There is nothing scary about this change. Once you begin this journey you will see very quickly how simple it is to deploy these very secure passwordless solutions for your user base and how fast they will embrace them. If you have any questions or comments please leave them below.