Users Authentication Methods Test

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 Users Authentication Methods test 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.

Target of the Test: A Microsoft Azure Active Directory

Agent deploying the test: A remote agent

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

Configurable parameters for the test
Parameters	Description
Test Period	How often should the test be executed.
Host	The host for which the test is to be configured.
Tenant ID	Specify the Directory ID of the Azure AD tenant to which the target subscription belongs. To know how to determine the Directory ID, refer to Configuring the eG Agent to Monitor Microsoft Azure Active Directory Using Microsoft Graph API
Client ID, Client Password, and Confirm Password	To connect to Azure AD, the eG agent requires an Access token in the form of an Application ID and the client secret value. If a Microsoft Azure Subscription component is already monitored in your environment, then you would have already created an Application for monitoring purposes. You can provide the Application ID and Client Secret value of that application here. However, if no such application pre-exists, you will have to create one for monitoring Azure AD. To know how to create such an application and determine its Application ID and Client Secret, refer to Configuring the eG Agent to Monitor Microsoft Azure Active Directory Using Microsoft Graph API. Specify the Application ID of the Application in the Client ID text box and the client secret value in the Client Password text box. Confirm the Client Password by retyping it in the Confirm Password text box.
Proxy Host and Proxy Port	In some environments, all communication with the Azure cloud be routed through a proxy server. In such environments, you should make sure that the eG agent connects to the cloud via the proxy server and collects metrics. To enable metrics collection via a proxy, specify the IP address of the proxy server and the port at which the server listens against the Proxy Host and Proxy Port parameters. By default, these parameters are set to none, indicating that the eG agent is not configured to communicate via a proxy, by default.
Proxy Username, Proxy Password and Confirm Password	If the proxy server requires authentication, then, specify a valid proxy user name and password in the Proxy Username and Proxy Password parameters, respectively. Then, confirm the password by retyping it in the Confirm Password text box.
Detailed Diagnosis	To make diagnosis more efficient and accurate, the eG Enterprise embeds an optional detailed diagnostic capability. With this capability, the eG agents can be configured to run detailed, more elaborate tests as and when specific problems are detected. To enable the detailed diagnosis capability of this test for a particular server, choose the On option. To disable the capability, click on the Off option. The option to selectively enable/disable the detailed diagnosis capability will be available only if the following conditions are fulfilled: The eG manager license should allow the detailed diagnosis capability Both the normal and abnormal frequencies configured for the detailed diagnosis measures should not be 0.

Measures made by the test:
Measurement	Description	Measurement Unit	Interpretation
Total user count	Indicates the total number of users registered with Azure AD.	Number
Users capable of multifactor authentication	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.
Users not capable of multifactor authentication	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.
Users capable of passwordless authentication	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.
Users not capable of passwordless authentication	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.
Users capable of self-service password reset	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.
Users not capable of self-service password reset	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.
Temporary access password	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