On premises Active Directory is limited in terms of the built in Authentication Methods. The authentication methods available to on-premises AD are password and smart card authentication. Although, there are 3rd party methods available such as RSA Tokens.
However, Azure Active Directory has many authentication methods available. The default option is password. For most organizations those passwords come from on-premises Active Directory. The user is then authenticated natively in Azure AD or the password is validated by on-premises Active Directory. There are two general trends in terms of security. One trend is Passwordless which is a movement away from passwords for authentication. And the second trend is Multi-Factor Authentication (MFA) where a user is initially authenticated with a password and then need to perform a second authentication with another method.
FIDO2 Security Key
FIDO2 Security Key is the next authentication methods we are going to discuss. In terms of Azure Active Directory, a FIDO2 Security Key can be used for Passwordless authentication. A FIDO2 Security Key uses asymmetric cryptography to authenticate a user to an Identity Provider (IdP). A key pair is generated and the private key is secured on the Security Key and the public key is submitted to the IdP during registrations. The user that has access can prove their identity due to the cryptographic relationship between these two keys. The FIDO Security Key usually requires some sort of authentication before it can be used to authenticate the user. This many time is a biometric such as thumbprint, but can take on other methods such as a PIN. If you feel my description is inadequate the FIDO Alliance has an overview on the topic available here: How FIDO Works – Standard Public Key Cryptography & User Privacy (fidoalliance.org)
Microsoft Authenticator
Microsoft Authenticator is an application that installs on your mobile device. Microsoft Authenticator can be used for MFA, as well as for Passwordless sign-in. By default the user will receive a prompt in Microsoft Authenticator when using Passwordless or MFA to click No, it’s not me or Yes. However, there are a number of features that help increase the security of this process. These three security features are: Require number matching for push notifications, and Show geographic location in push and passwordless notifications. Require number matching for push notifications: A user is prompted with a number in their browser, they will then either need to select that number or key in the number to complete the authentication. Show application name in push: This simply displays the application to which they are authenticating. Show geographic location in push and passwordless notifications: This displays the location from which the authentication originated.
SMS
SMS is another authentication method, and it is currently in preview. This allows the user to receive an SMS message. Then the user can login with the code that is sent to their mobile phone. SMS cannot be used for MFA.
Temporary Access Pass
Temporary Access Pass is a self-descriptive feature. TAP allows the administrator to generate a one time pass code that can be used for authenticating to Azure Active Directory. TAP is ideal if you require MFA for a user enrolling their authentication methods. Since a user does not have authentication methods yet registered, they cannot MFA even if this is required. To get through this limitation a user can be given a TAP and use that as their MFA credential. The downside to this feature is there a lot of administrative overhead since sending a TAP must be completed on a user by user bases.
Certificate Based Authentication (Preview)
Certificate Based Authentication (Preview) allows a user to login with a certificate or Smart Card. There are of course some setup steps like importing your Root CA certificate and configuration of the policy. However, this is a nice addition, especially if you would like to leverage your existing smart card infrastructure. I will post a blog entry on setting this up in the near future.
Authentication Strength (Preview)
Authentication Strength (Preview) assigns an authentication strength to different types of authentication. For example, one authentication strength is named Phishing-resistant. In order for an authentication to be considered Phishing-resistant the authentication method must be Windows Hello for Business (WHfB), FIDO2 Security Key, or Certificate based Authentication. You can then use conditional policy to require a certain authentication strength before a user is given access to an application.
Next time
Next time I will probably divert from this intro series to cover Certificate Based Authentication.
Thank You,
-Christopher
xdot509.blog 