Azure Interactive Sign-ins Test

How often should the test be executed.

The host for which the test is to be configured.

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

The eG agent communicates with the target Microsoft Azure Subscription using Java API calls. To collect the required metrics, the eG agent requires an Access token in the form of an Application ID and the client secret value. To know how to determine the Application ID and the key, refer to Configuring the eG Agent to Monitor Microsoft Azure Active Directory. Specify the Application ID of the created 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.

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.

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.

Typically, Interactive Sign-in logs are sent to a Log Analytics Workspace. By default, the Log Analytics Workspace Name parameter is set to All. This indicates that the test reads sign-in data from all Log Analytics Workspaces configured for the target tenant, by default. However, if you want the test to monitor only specific Log Analytics Workspaces, then provide the names of these workspaces here as a comma-separated list. To determine the names of such workspaces, do the following:

1. Login to the Microsoft Azure Portal and select the Sign-in Logs option (see Figure 1).

   

   Figure 1 : Selecting the Sign-in Logs option

2. Figure 2 will then appear listing the log entries. Next, click on the Export Data Settings button indicated by Figure 2.

   

   Figure 2 : Clicking on the Export Data Settings button

3. The diagnostic settings that pre-exist for the sign-in logs will then appear. If any of the existing diagnostic settings have already been configured with Log Analytics Workspaces, then the Log Analytics workspace column highlighted in Figure 3 will display these workspace names. You can configure the LOG ANALYTICS WORKSPACE NAME parameter of this test with any of these workspace names. If required, you can even configure this parameter with two/more workspaces listed in Figure 3, as a comma-separated list.

   

   Figure 3 : List of Log analytics workspaces

However, If the Log Analytics workspace column in Figure 3 is blank for all the existing diagnostic settings, it is a clear indication that the sign-in logs are not yet configured to be sent to any Log Analytics Workspace. In this case therefore, you should create a new diagnostic setting, where a Log Analytics Workspace is configured as the destination for the Sign-in logs. To achieve this, follow the procedure detailed in Configuring the Sign-in Logs to be Sent to a Log Analytics Workspace.

By default, this flag is set to No. This means that, by default, this test will not report detailed diagnostics for the 'Success' metrics (eg., Successful sign-ins, Success IP addresses etc.). This is because, in a typical Azure cloud organization, there may be numerous successful sign-in attempts. A well-tuned, well-sized eG database is required for storing these detailed metrics. Without it,over a period of time, the detailed statistics of 'Successful' sign-in attempts may end up choking the eG database. To avoid it, this parameter is set to No by default. Set this flag to Yes only if your eG database has sufficient space to store detailed diagnostics for the 'Success' metrics.

By default, this flag is set to 5. This means that, by default, the test will count a sign-in attempt from a specific user / IP address / location / protocol or for a specific application / service principal / resource as a success/failure, only if 5 or more consecutive sign-in attempts from/for that entity succeed/fail (as the case may be). For instance, if 5 or more sign-in attempts from a specific IP address fail, then the test will count that as one failure - i.e., the Failure IP addresses measure will report the value 1. Similarly, if 5 or more sign-in attempts from a specific IP address succeed, then the test will count that as a single sign-in success - i.e., the Success IP addresses measure will report the value 1. Needless to say, by default, the values of these measures will also be incremented only with every 5 or more consecutive sign-in successes/failures. This is done so that administrators are alerted only to those sign-in attempts that are 'suspect' - for example, repeated sign-in failures from the same IP address. You can change the value of this measure based on what is normal sign-in activity and what is not in your environment.

This parameter applies to the following measures reported by the test:

• Successful IP addresses
• Successful locations
• Successful applications
• Successful service principals
• Success resources
• Successful users
• Successful authentication protocols
• Failure IP addresses
• Failure locations
• Failure applications
• Failure service principals
• Failure resources
• Failure users
• Failure authentication protocols

Use the detailed diagnosis of this measure to know which sign-in attempts succeeded.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Ideally, the value of this measure should be 0.

Use the detailed diagnosis of this measure to know which sign-in attempts failed.

In Azure AD Identity Protection, risk detections include any identified suspicious actions related to user accounts in Azure AD.

Ideally, the value of this measure should be 0. If a non-zero value is reported, then use the detailed diagnosis of this measure to know the risky sign-in attempts.

Use the detailed diagnosis of this measure to know from which IP addresses successful sign-in attempts were made.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know from which locations successful sign-in attempts were made.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know which applications signed into Azure successfully.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know which service principals signed into Azure successfully.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know which services were used in successful sign-ins.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know which users' sign-in attempts succeeded.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Use the detailed diagnosis of this measure to know which protocols were used in successful sign-ins.

Note that this measure will report detailed diagnostics only if the Successful Signin DD parameter of this test is set to Yes.

Ideally, the value of this measure should be low.

Use the detailed diagnosis of this measure to know which sign-in attempts failed.

Use the detailed diagnosis of this measure to know from which IP addresses the maximum number of failed sign-in attempts were made. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know from which locations the maximum number of failed sign-in attempts were made. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know which applications failed to sign into Azure the maximum number of times. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know which service principals failed to sign into Azure the maximum number of times. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know which services were used in the maximum number of failed sign-ins. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know which users experienced the maximum number of failed sign-ins. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to know which were used in the maximum number of failed sign-ins. You may want to investigate these attempts to figure out if they were geniuine attempts or malicious attacks.

Use the detailed diagnosis of this measure to view the sign-ins made using single-factor authentication.

Use the detailed diagnosis of this measure to view the sign-ins made using multi-factor authentication.

Modern authentication is a method of identity management that offers more secure user authentication and authorization. Modern authentication is an umbrella term for a combination of authentication and authorization methods between a client (for example, your laptop or your phone) and a server, as well as some security measures that rely on access policies that you may already be familiar with.

Use the detailed diagnosis of this measure to view the sign-ins made using modern client authentication.

Legacy authentication refers to basic authentication, which was once a widely used industry-standard method for passing user name and password information through a client to an identity provider.

Use the detailed diagnosis of this measure to view the sign-ins made using legacy client authentication.

Conditional Access policies at their simplest are if-then statements, if a user wants to access a resource, then they must complete an action. Example: A payroll manager wants to access the payroll application and is required to do multi-factor authentication to access it.