eG Monitoring
 

Measures reported by AzrADUsrAuthTest

One of the main features of an identity platform is to verify, or authenticate, credentials when a user signs in to a device, application, or service. In Azure Active Directory (Azure AD), authentication involves more than just the verification of a username and password. To improve security and reduce the need for help desk assistance, Azure AD authentication includes the following components:

  • Self-service password reset: Self-service password reset gives users the ability to change or reset their password, with no administrator or help desk involvement. This authentication feature works in the following scenarios:

    • Password change - when a user knows their password but wants to change it to something new.

    • Password reset - when a user can't sign in, such as when they forgot password, and want to reset their password.

    • Account unlock - when a user can't sign in because their account is locked out and want to unlock their account.

  • Azure AD Multi-Factor Authentication: Azure AD Multi-Factor Authentication (MFA) adds additional security over only using a password when a user signs in. The user can be prompted for additional forms of authentication, such as the following:

    • OATH tokens: OATH TOTP (Time-based One Time Password) is an open standard that specifies how one-time password (OTP) codes are generated. OATH TOTP can be implemented using either software or hardware to generate the codes.

    • Response to an SMS or phone call: Users can also verify themselves using a mobile phone or office phone as secondary form of authentication used during Azure AD Multi-Factor Authentication or self-service password reset (SSPR).

  • Password protection: By default, Azure AD blocks weak passwords such as Password1. A global banned password list is automatically updated and enforced that includes known weak passwords. If an Azure AD user tries to set their password to one of these weak passwords, they receive a notification to choose a more secure password.

    To increase security, you can define custom password protection policies. These policies can use filters to block any variation of a password containing a name such as Contoso or a location like London, for example.

    For hybrid security, you can integrate Azure AD password protection with an on-premises Active Directory environment. A component installed in the on-prem environment receives the global banned password list and custom password protection policies from Azure AD, and domain controllers use them to process password change events. This hybrid approach makes sure that no matter how or where a user changes their credentials, you enforce the use of strong passwords.

  • Passwordless authentication: When you sign in with a passwordless method, credentials are provided by using methods like biometrics with Windows Hello for Business, or a FIDO2 security key.

Passwords are the basic form of authentication that Azure AD supports. However, a weak password can expose the Azure cloud organization and its resources to malicious attacks/invasions. To assure users of a secure sign-in experience and to protect critical Azure resources, administrators often stack Passwords with additional layers of security using one/more of the above-mentioned authentication methods. If any user login is only configured with Password-based authentication and not any of the more secure authentication methods discussed above (e,g., MFA, SSPR, passwordless authentication, etc.) then impostors may hide behind such logins to gain access to and abuse the critical resources of the Azure organization. This is why, it is important that administrators periodically check whether/not user logins are 'sufficiently authenticated'. This is where the AzrADUsrAuthTest helps!

This test monitors how user accounts managed by Azure AD are authenticated, and reveals which user is configured to use which authentication method. In the process, the test turns the spotlight on those user logins that are authenticated using Passwords alone. These insights into inadequacies in authentication enable administrators to promptly initiate the required changes.

Outputs of the test : One set of results for the Azure Active Directory tenant being monitored

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Total_User Indicates the total number of users registered with Azure AD. Number  
Mfa_Capable Indicates the number of user logins that have been configured with multifactor authentication. Number Use the detailed diagnosis of this measure to know which users have been configured with multifactor authentication.
Mfa_NotCapable Indicates the number of users who have not been configured with multifactor authentication. Number Use the detailed diagnosis of this measure to know which users have not been configured with multifactor authentication.
Passwordless_Capable Indicates the number of users who have been configured with passwordless authentication. Number Use the detailed diagnosis of this measure to know which users have been configured with passwordless authentication.
Passwordless_NotCapable Indicates the number of users who have not been configured with passwordless authentication. Number Use the detailed diagnosis of this measure to know which users have not been configured with passwordless authentication.
Sspr_Capable Indicates the number of users who have been configured with the self-service password reset capability. Number Use the detailed diagnosis of this measure to know which users have been configured with the ability to reset their passwords.
Sspr_NotCapable Indicates the number of users who have not been configured with the self-service password reset capability. Number Use the detailed diagnosis of this measure to know which users have not been configured with the ability to reset their passwords.
Mobile Indicates the number of users who have been configured with a mobile number for authentication purposes. Number For Azure AD Multi-Factor Authentication or SSPR, users can choose to receive a text message with a verification code to enter in the sign-in interface, or receive a phone call.

Use the detailed diagnosis of this measure to know whih users have been configured with a mobile number for the above-mentioned purposes.
Email Indicates the number of users who can use email as an alternative login ID. Number Many organizations want to let users sign in to Azure Active Directory (Azure AD) using the same credentials as their on-premises directory environment. With this approach, known as hybrid authentication, users only need to remember one set of credentials.

Some organizations however, may not want to move to hybrid authentication for the following reasons:

  • By default, the Azure AD User Principal Name (UPN) is set to the same value as the on-premises UPN.

  • Changing the Azure AD UPN creates a mismatch between on-premises and Azure AD environments that could cause problems with certain applications and services.

  • Due to business or compliance reasons, the organization doesn't want to use the on-premises UPN to sign in to Azure AD.



To move toward hybrid authentication, you can configure Azure AD to let users sign in with their email as an alternate login ID. For example, if Contoso rebranded to Fabrikam, rather than continuing to sign in with the legacy ana@contoso.com UPN, email as an alternate login ID can be used. To access an application or service, users would sign in to Azure AD using their non-UPN email, such as ana@fabrikam.com.

Use the detailed diagnosis of this measure to know which users have been configured to use email ID as an alternative login ID.
Software_token Indicates the number of users who are configured to be authenticated by access codes generated using software OATH tokens. Number Software OATH tokens are typically applications such as the Microsoft Authenticator app and other authenticator apps. Azure AD generates the secret key, or seed, that's input into the app and used to generate each OTP.

Use the detailed diagnosis of this measure to know which MFA-enabled user logins are being authenticated by access codes generated using software tokens.
Alternative_mobile Indicaes the number of users who are configured to receive verification calls to an alternative mobile number, if the primary mobile number cannot be reached. Number Use the detailed diagnosis of this measure to know which users are configured with an alternative mobile number.
Office_phone Indicates the number of users who are configured to receive verification calls to their office phone number. Number With phone call verification during SSPR or Azure AD Multi-Factor Authentication, an automated voice call is made to the office phone number registered by the user. To complete the sign-in process, the user is prompted to press # on their keypad.

Use the detailed diagnosis of this measure to know which users have registered their office phone number with Azure AD for the purpose of receiving verification calls.
Password Indicates the number of users who are configured to be authenticated using password. Number Use the detailed diagnosis of this measure to know which users are configured with password-based authentication. A quick look at these details will also point you to those users who have not been configured with authentication methods other thanb password. Such users are a security risk.

To minimize this risk, administrators should rapidly configure such user registrations with with additional layers of security using authentication features such as multi-factor authentication, password protection policies, passwordless authentication etc.
Temp_access_pass Indicates the number of users for whom the Temporary Access Password policy is enabled. Number Users can bootstrap Passwordless methods in one of two ways:

  • Using existing Azure AD Multi-Factor Authentication methods

  • Using a Temporary Access Pass (TAP)



A Temporary Access Pass is a time-limited passcode issued by an admin that satisfies strong authentication requirements and can be used to onboard other authentication methods, including Passwordless ones such as Microsoft Authenticator or even Windows Hello. A Temporary Access Pass also makes recovery easier when a user has lost or forgotten their strong authentication factor like a FIDO2 security key or Microsoft Authenticator app, but needs to sign in to register new strong authentication methods.

Use the detailed diagnosis of this measure to identify the users for whom the temporary access password policy is enabled.
App_notification Indicates the number of users who are configured to be authenticated using Microsoft Authenticator mobile app. Number The Microsoft Authenticator app provides an additional level of security to your Azure AD work or school account or your Microsoft account and is available for Android and iOS. With the Microsoft Authenticator app, users can authenticate in a passwordless way during sign-in, or as an additional verification option during self-service password reset (SSPR) or multifactor authentication events.

Users may receive a notification through the mobile app for them to approve or deny, or use the Authenticator app to generate an OATH verification code that can be entered in a sign-in interface. If you enable both a notification and verification code, users who register the Authenticator app can use either method to verify their identity.

Use the detailed diagnosis of this measure to know which users have been configured to receive notifications or verification codes through the Microsoft Authenticator mobile app.
Hardware_token Indicates the number of users who are configured to be authenticated by access codes generated using hardware OATH tokens. Number Azure AD supports the use of OATH-TOTP SHA-1 hardware tokens that refresh codes every 30 or 60 seconds. Customers can purchase these tokens from the vendor of their choice.

OATH TOTP hardware tokens typically come with a secret key, or seed, pre-programmed in the token. These keys must be input into Azure AD. Programmable OATH TOTP hardware tokens that can be reseeded can also be set up with Azure AD in the software token setup flow.

Use the detailed diagnosis of this measure to know which MFA-enabled user logins are being authenticated by access codes generated using hardware tokens.
Passwordless_app Indicates the number of users who are configured to use the Microsoft Authenticator app to enable passwordless sign-in. Number Microsoft Authenticator can be used to sign in to any Azure AD account without using a password. Microsoft Authenticator uses key-based authentication to enable a user credential that is tied to a device, where the device uses a PIN or biometric.

Use the detailed diagnosis of this measure to know which users have been configured to use the Microsoft Authenticator app to enable passwordless sign-in.
Windows_hello_for_business Indicates the number of users for whom passwordless sign-in is enabled using Windows Hello for Business. Number Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching.
Fido2_security_key Indicates the number of users for whom passwordless sign-in is enabled using FIDO2 security key. Number FIDO2 security keys are an unphishable standards-based passwordless authentication method that can come in any form factor. Fast Identity Online (FIDO) is an open standard for passwordless authentication. FIDO allows users and organizations to leverage the standard to sign in to their resources without a username or password using an external security key or a platform key built into a device. Users can register and then select a FIDO2 security key at the sign-in interface as their main means of authentication.

Using the detailed diagnosis of this measure, you can identify the users whose logins are configured to be authenticated by FIDO2 security keys.
Security_question Indicates the number of users who are configured to use security questions for validating their identity during the SSPR process. Number Security questions aren't used as an authentication method during a sign-in event. Instead, security questions can be used during the self-service password reset (SSPR) process to confirm who you are.

When users register for SSPR, they're prompted to choose the authentication methods to use. If they choose to use security questions, they pick from a set of questions to prompt for and then provide their own answers.Using the detailed diagnosis of this measure to know which users chose 'security questions' as their authentication method.
Total Indicates the total number of users whose logins are authenticated using one/more authentication methods. Number