Determining a rollout strategy for Azure MFA

You need to think strategically about the rollout of Azure MFA within an organization. Striking a right balance between deployment velocity and its scope is the key to a successful rollout. Following are key points to keep in mind:

• Plan the deployment in small iterations by starting with a small subset of users who are receptive to change and whose daily tasks are least impacted by the rollout.

• Provide users with clear guidance regarding the registration process along with the MFA methods available to them for authentication.

• Continuously monitor for any issues reported by users, including steep learning curves, lack of preferred authentication methods, and technical challenges that may hamper the adoption.

• Ensure that support staff are trained well in advance before the rollout.

• Anticipate some resistance from a subset of users due to the change in their daily routine.

Licensing requirements for Azure MFA

Azure MFA licensing can be configured in a variety of ways. Understanding how licensing affects the availability of various MFA features to end users is an important part of planning. Table 2-1 provides a high-level breakdown of various Azure MFA features along with Azure AD and Microsoft 365 license requirements.

Table 2-2 lists the commonly used Azure AD MFA and access management features, as well as the Azure AD licenses that support them.

Register an authentication method for self-service password reset

Follow the steps below to sign in as a user and register a phone number that will be used during SSPR.

1. Sign in as a user to the My Sign-Ins portal at: https://mysignins.microsoft.com.

2. On the Keep your account secure page, enter the phone number and click Next, as shown in Figure 2-3. A text code will be sent to the phone number provided.

   

3. Enter the text code received on the phone number and click Next. Figure 2-4 shows a sample text code sent to the phone number registered in the previous step.

   

4. You should see SMS verified. Your phone was registered successfully message, as shown in Figure 2-5. Click Next.

   

5. Click Done to complete the phone number registration process for SSPR, as shown in Figure 2-6.

   

6. You can close the browser. You don’t need to finish the sign-in process at this time.

Reset password using Self Service Password Reset

Follow the steps below to reset the user’s password using Self Service Password Reset:

1. Navigate to the URL https://passwordreset.microsoftonline.com/ using an InPrivate or Incognito browser session.

2. Enter the user’s Email or Username and complete the CAPTCHA check, as shown in Figure 2-7, and then click Next.

   

3. Enter the phone number associated with the account, as shown in in Figure 2-8, and then press Text. A text message with a verification code will be sent to this phone number.

   

4. Enter the verification code, as shown in in Figure 2-9, and then then press Next.

   

5. Enter the new password, as shown in in Figure 2-10, and then click Finish.

   

6. The success message “Your password has been reset” will appear on the page, as shown in Figure 2-11. This confirms that the user account password has been reset successfully. You can now close the browser.

   

Working with FIDO2

The Fast IDentity Online (FIDO) Alliance’s goal is to replace passwords with strong passwordless authentication that is both secure and usable. The latest version of the open specification for passwordless authentication, FIDO2, incorporates the W3C Web Authentication (WebAuthn) standard as well as the FIDO Client to Authenticator Protocol 2 (CTAP2). Users can sign in using an unphishable FIDO2 security key stored in a hardware device that can be accessed via commonly used protocols such as NFC (near-field communication), Bluetooth, and USB.

FIDO2 security keys can be used to sign in to Azure AD or hybrid Azure AD-joined devices to achieve single-sign-on to cloud and on-premises resources.

Enabling the FIDO2 security key method

To enable the FIDO2 security key method for Azure AD:

1. Sign in as an administrator to the Azure portal at http://portal.azure.com.

2. Navigate to Azure Active Directory.

3. Select Security from the left pane, as shown in Figure 2-20.

   

4. Select Authentication methods from the left pane, as shown in Figure 2-21.

   

5. Select FIDO2 Security Key from the list of available methods, as shown in Figure 2-22.

   

6. Under the Basics tab, choose the following options, as shown in Figure 2-23.

   • Enable: Yes

   • Target: All users

   

7. Under the Configure tab, choose following options, as shown in Figure 2-24.

   • Allow self-service set up: Yes

   • Enforce attestation: No (Default)

   • Enforce key restrictions: No (Default)

   • Restrict specific keys: Block (Default)

   

8. Click Save.

Register a FIDO2 security key

The user must configure a FIDO2 security key using the steps below before it can be used for sign-in:

1. Navigate to the URL https://myprofile.microsoft.com/.

2. Sign in with the user account for which FIDO2 security key needs to be configured.

3. Select Security info, as shown in Figure 2-25. Make sure there is at least one Azure AD MFA method already registered; otherwise, you must first register for an MFA method before you can register a FIDO2 security key.

   

4. Select Security key from the dropdown and click Add, as shown in Figure 2-26.

   

5. Choose the type of security key, USB device or NFC device, that you would like to use, as shown in Figure 2-27.

   

6. Complete the registration process by creating or using a PIN for the security key and then perform a biometric or touch for the gesture.

7. Provide a meaningful name for the key and select Next.

8. Finally, select Done to finish the process.

Sign in with passwordless credentials using a FIDO2 security key

The steps below demonstrate how to sign in with passwordless credentials using a FIDO2 security key.

1. Sign in to the Azure portal at https://portal.azure.com/ using the account for which a FIDO2 security key is already registered.

2. Complete the sign-in process by providing the security key. For example, Figure 2-28 shows the pop-up message presented by the browser asking a user who has previously registered the security key using a USB device to use it to finish the authentication process.

   

3. After the successful passwordless authentication using the security key, the user will be taken to the Azure portal (https://portal.azure.com), as shown in Figure 2-29.

   

Licensing requirements

The licensing requirements for global and custom banned password lists are as follows:

• Azure AD Password Protection with global banned password list: Cloud-only users require Azure AD Free, and users synchronized from on-premises AD DS require an Azure AD Premium P1 or P2 license to use this feature.

• Azure AD Password Protection with custom banned password list: Both cloud-only users and users synchronized from on-premises AD DS require an Azure AD Premium P1 or P2 license to use this feature.

Configure custom banned password list

The steps below show how to configure a custom banned password list:

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select the Security option located under the Manage section on the left side, as shown in Figure 2-30.

   

4. Select Authentication methods.

5. Select Password protection, as shown in Figure 2-31.

   

6. Set the Enforce custom list option to Yes, as shown in Figure 2-32.

   

7. Specify custom passwords to ban using the multi-line text box available for the Custom banned password list. Make sure to enter one term per line, as shown in Figure 2-33.

   

   Consider the following restrictions while creating a custom banned password list:

   • A maximum of 1000 terms are allowed per list.

   • The minimum term length is 4 characters.

   • The maximum term length is 16 characters.

   • Terms are case-insensitive. For example, Northwind, NorthWind, northwind, northWIND, and norTHwinD are all considered identical terms.

   • The list considers common character substitutions, such as “o” and “0” or “a” and “@.”

8. Click Save. Keep all other settings at their default values. It may take up to several hours before the custom banned password list is fully applied.

Testing a custom banned password list

The steps below show how to test a custom banned password list:

1. Sign in to https://mysignins.microsoft.com/ using the user account. You will change the password for this account in the next step.

2. Select CHANGE PASSWORD, as shown in Figure 2-34.

   

3. On the Change Password page, enter the current password in the Old password textbox and then enter a new password containing a term that’s on the custom banned password list that you defined earlier—for example, “Northwind100%.”

4. Click Submit. You will get an error message, as shown in Figure 2-35. This message indicates that the password you entered contains words or characters that are banned by the administrator.

   

5. Click Cancel to leave the page without changing the password. Alternatively, you can choose a new password that does not contain terms that are listed within the banned password list.

6. Finally, close the browser.

Planning for on-premises Azure AD Password Protection deployment

The Azure AD Password Protection feature allows using the same global and custom banned password lists that are stored in Azure AD for on-premises passwords. Technically, these checks are performed whenever a password is reset or changed using on-premises AD DS domain controllers.

Plan for deployment of Azure AD Password Protection on-premises by verifying the following core requirements:

• Account with Active Directory domain administrator privileges in the forest root.

• Universal C Runtime installation on all machines where Azure AD Password Protection components are installed. This also includes a domain controller.

• Key Distribution Service (KDC) should be enabled on all domain controllers running Windows Server 2012 or later.

• Network access to the following two endpoints from machines where the Azure AD Password Protected service is installed:

  • Azure AD Password Protection functionality: https://login.microsoftonline.com

  • Authentication Requests: https://enterpriseregistration.windows.net

• At least one domain controller must be able to connect with one server running proxy service for Azure AD Password Protection. Specifically, the domain controller must be able to access RPC endpoint mapper port 135 and the RPC server port on the host running the proxy service.

• Download Azure AD Password Protection for Windows Server Active Directory software installation files from the Microsoft Download Center: https://www.microsoft.com/en-us/download/details.aspx?id=57071.

  • AzureADPasswordProtectionProxySetup.exe

  • AzureADPasswordProtectionDCAgentSetup.msi

Install and configure Azure AD Password Protection on-premises

Table 2-8 summarizes the tasks that must be completed for successful installation and configuration of the Azure AD Protection proxy service in your environment. Please use the links provided for each task in Table 2-8 to follow detailed step-by-step instructions provided by Microsoft. These instructions are kept up to date by Microsoft, and it is highly recommended that you follow them as-is without customizations.

Table 2-9 summarizes the task that must be completed for successful installation and configuration of the Azure AD Protection DC service. Please use the link provided for the task in Table 2-9 to follow detailed step-by-step instructions provided by Microsoft. These instructions are kept up to date by Microsoft, and it is highly recommended that you follow them as-is without customizations.

After the successful installation and configuration of the Azure AD Password Protection proxy and DC agent service, follow the steps below to enable Azure AD Password Protection for on-premises environments:

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select the Security option located under the Manage section on the left side.

4. Select Authentication methods.

5. Select Password protection.

6. Set Enable password protection on Windows Server Active Directory to Yes, as shown in Figure 2-36. Leave the Mode set to Audit.

   

7. Click Save.

Configure smart lockout thresholds

Azure AD smart lockout helps safeguard user accounts by locking out potential malicious actors who use brute force, password spray, or similar attack techniques to guess the passwords. Azure AD smart lockout works by locking the user account from sign-in attempts for one minute after several consecutive failed attempts. The lockout acts as a shield to protect the user account from being attacked from bots in an automated fashion. The exact number of failed attempts threshold resulting in the user account being locked depends on the type of Azure Cloud where the Azure AD tenant is located. For Azure Public Cloud and Azure China, the failed attempts lockout threshold is 10; for Azure US Government, the failed attempts lockout threshold is 3.

The default lockout values can be customized to match organizational needs. Please note that customizations to smart lockout values require an Azure AD Premium P1 or higher user license. The following steps show how to change the lockout threshold and duration:

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select the Security option located under the Manage section on the left side.

4. Select Authentication methods.

5. Select Password protection.

6. Set the Lockout threshold and Lockout duration in seconds to values that match your needs.

   For example, Figure 2-37 shows the Lockout threshold set to 5, which means the account will be locked after 5 failed sign-in attempts by the user, and Lockout duration in seconds is set to 90. Keep in mind that if the first sign-in attempt after the lockout also fails, then the account locks out again. If a user account keeps getting lockouts repeatedly, the lockout duration increases over time. The exact duration by which the lockout increases is not released publicly as a safety measure to avoid malicious actors from exploiting it.

   

7. Click Save.

Licensing requirements

The Azure AD conditional access feature requires an Azure AD Premium P1 license or Microsoft 365 Business Premium license. Also, using risk-based signals like sign-in and user-risk requires the Identity Protection feature, which is available as part of the Azure AD Premium P2 license.

If the Azure AD premium licensing required for working with conditional access is not available, the message/banner shown in Figure 2-41 will be displayed. If a required license was held in the past but is no longer valid, the existing policies will be listed but cannot be modified.

Furthermore, certain conditional access policy features, such as the risk-based conditions like user risk level and sign-in risk level, as shown in Figure 2-42, are only available when an Azure AD Premium 2 (P2) license is used because they require the Identity Protection feature.

Deployment planning for conditional access policies

Planning for Azure AD conditional access polices deployment is a critical step toward ensuring that users’ productivity is not negatively impacted while security posture is improved by the conditional access policies enforced. Table 2-11 shows various proven practices that should be taken into consideration while planning the conditional access deployment.

Enforce Terms of Use (ToU) using conditional access policy

Organizations can use Azure AD Terms of Use (ToU) policies to convey information to end users in a simple way. This allows users to read essential disclaimers for legal or compliance needs.

Follow the steps below to add a new Terms of Use, which you will use later in the conditional access policy:

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select Identity Governance located under the Manage section, as shown in Figure 2-43.

   

4. Select Terms of use from the left side pane, as shown in Figure 2-44.

   

5. Click New terms from the top pane.

6. On the New terms of use page, fill in the following information. It should look like Figure 2-45.

   • Name: Employee Terms of Use Agreement

   • Terms of use document: Select any PDF document and upload, it since it is only going to be used for testing purposes. You can use the Microsoft SLA for testing purposes, which is available for download at https://download.microsoft.com/download/2/C/8/2C8CAC17-FCE7-4F51-9556-4D77C7022DF5/MCA2017Agr_EMEA_EU-EFTA_ENG_Sep20172_CR.pdf.

     • Language: Select English (or the language of your choice) from the dropdown menu.

     • Display Name: ToU.

   • Require users to expand the terms of use: On (This will force users to read the entire document).

   • Require users to consent on every device: Off.

   • Expire consents: Off.

   • Duration before re-acceptance required (days): 60.

   • Enforce with conditional policy template: Create conditional access policy later.

   

Follow the steps below to create a new conditional access policy and enforce the Terms of Use (ToU) before users can sign in to the Azure portal.

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select Security from the left side pane.

4. Select Conditional Access from the left side pane, as shown in Figure 2-46.

   

5. Click + New policy and then select Create new policy as shown Figure 2-47.

   

6. On the New Conditional Access policy page, enter Enforce-ToU for the Name, as shown in Figure 2-48.

   

7. Expand Users or workload identities and then set following information options. The result should look like Figure 2-49.

   • What does this policy apply to: Users and groups.

   • Include: All users.

   • Exclude: Select the Global administrator role from the Directory roles dropdown menu.

   

8. Expand Cloud apps or actions and then set the following information options. The result should look like Figure 2-50.

   • Select what this policy applies to: Cloud apps.

   • Include: Click Select apps and then search for and choose My Apps.

   

9. Expand Grant, set the following information options, and then click Select. The result should look like Figure 2-51.

   • Grant access: Employee Terms of Use Agreement.

   • For multiple controls: Require all the selected controls.

   

10. Set Enable policy to On.

11. Click Create.

Enforce MFA using the sign-in risk signal with conditional access policy

Follow the steps below to create a conditional access policy that uses the sign-in risk signal to enforce MFA for granting access to a cloud application.

1. Sign in to the Azure portal, https://portal.azure.com, using a Global Administrator account.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select Security from the left side pane.

4. Select Conditional Access from left side pane, as shown in Figure 2-46.

5. Click + New policy and then select Create new policy.

6. On the New conditional access page, enter CA-SignIn for the Name.

7. Expand Users or workload identities and then set the following information options. The result should look like Figure 2-49.

   • What does this policy apply to: Users and groups.

   • Include: All users.

   • Exclude: Select the Global administrator role from the Directory roles dropdown menu.

8. Expand Cloud apps or actions and then set the following information options.

   • Select what this policy applies to: Cloud apps.

   • Include: All Cloud Apps.

9. Expand Conditions, select Sign-In risk, and set the following information options:

   • Set Configure to Yes.

   • Select the sign-in risk level this policy will apply to:

     • High

     • Medium

     • Low

   • Press Done to save your choices.

10. Expand Grant, set the following information options, and then click Select.

    • Block access

    • For multiple controls: Keep the default option.

11. Set Enable policy to On.

12. Click Create.

Test conditional access policy to enforce Terms of Use (ToU)

The steps below show how to test a conditional access policy to enforce the Terms of Use (ToU) that you created earlier:

1. Sign in to the My Apps portal, https://myapps.microsoft.com/, with a user account that does not have a Global Administrator role assigned and has not read and accepted the Terms of Service (ToU).

2. Expand the Terms of Use (ToU), and then select Accept, as shown in Figure 2-52. You must review the entire terms of use document by scrolling through it before you can accept it.

   

   The sign-in process will complete, and the browser will redirect to My Apps Portal.

   You have successfully tested the conditional access policy that enforces the Terms of Use (ToU) before the user can access the resource.

Test Enforce MFA using the sign-in risk signal with the conditional access policy

The Tor Browser (https://www.torproject.org/) is required to complete the steps below in order to simulate sign-in risk and test the conditional policy. If your organization prohibits the use of the Tor browser, you may need to install it on a virtual machine.

1. Launch the Tor browser.

2. Sign in to the Azure portal, https://portal.azure.com, with a user account that does not have a Global Administrator role assigned.

   Due to the high sign-in risk posed by the use of the anonymizer proxy Tor, user access will be blocked, and a message will display, as shown in Figure 2-53.

   

Troubleshooting conditional access policy

When a conditional access policy is imposed, the user is given an explanation, as shown in Figure 2-53. This provides users with just enough information to understand why the policy is behaving as it does, but IT administrators may need more information to troubleshoot.

More information can be gathered to begin troubleshooting by expanding the More details option, as shown in Figure 2-54, which provides critical information useful for troubleshooting.

Administrators can further troubleshoot the issue by searching the Sign-In logs for Correlation ID, Timestamp, and other attributes available to them, as shown in Figure 2-54. To access the Sign-In logs and troubleshoot, follow these steps:

1. Sign in to the Azure portal, https://portal.azure.com, with a user account that has the Global Administrator role assigned to it or has the necessary permissions to view the Sign-In logs.

2. Navigate to the Azure Active Directory dashboard by using the Azure Active Directory option available in the sidebar of the Azure portal.

3. Select Sign-In logs located under the Monitoring section.

4. The Sign-In logs are displayed in chronological order, as shown in Figure 2-55. You can filter based on Correlation Id or other information.

   

5. Select the Sign-In log entry with Failure and matching Correlation ID from the information collected earlier. As shown in Figure 2-56, the Failure reason, Additional details, and Sign-In error code provide useful information for troubleshooting.

   

6. You may now close the browser.

Licensing requirements

Microsoft offers two flavors of premium licensing: P1 and P2. Aside from any additional licensing for workload identities, the Identity Protection feature set is divided up across these license options, as shown in Figure 2-57.

As shown in Figure 2-57, P2 licensing contains all the bells and whistles, including:

• The ability to remediate risk by end-users through risk remediation policies.

• The ability to monitor risk and view details of the risk detected and remediated.

• Stream into your existing framework, Security Information and Event Management (SIEM), for threat and incident response by using Microsoft’s extensible Graph APIs.

Throughout this skill, we will assume P2 licensing on the tenant to understand the full depth of concepts and capabilities.

Prerequisites

Configuring Identity Protection requires the administrator to assume one of the following roles depending on the action needed to be taken within the Identity Protection blade:

• Global Administrator—giving them complete access to AADIP

• Security Administrator—allowing them everything a global administrator (GA) can do except reset a user’s password

• Security Operator—allowing access to Identity Protection reports and alerts

• Security Reader—allowing access to Identity Protection reports and read-only access to alerts configuration

Configure user risk security policy

Azure AD Identity Protection offers native options to remediate risk within the Identity Protection blade. These are called Security Policies (also called IPC policies, where IPC stands for Identity Protection Center), and these are great for enabling end user risk remediation quickly and easily in your tenant.

To configure a user risk security policy:

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Conditional Access > New policy.

2. Choose a user/group to be included in the policy, as shown in Figure 2-58.

   

3. Select the risk levels that you’d like to trigger end-user risk remediation for. Microsoft recommends setting up the policy for High user risk to have a good balance between security and productivity. Setting up a policy for all levels of risk might trigger too many requests to change the password, leading to more predictable and less random passwords.

4. You can set the Grant Control to either Block or Allow access requiring MFA.

5. Remember to select Enforce policy before selecting Save.

As you can see, security policies don’t give us options to apply remediation with any sort of useful granular control. Therefore, risk remediation via Conditional Access was developed.

Configure risk-based conditional access user risk policy

The advantage of configuring risk-based conditional access policies is the granular control it offers in both Condition Control as well as Grant Control. You can also combine Session Controls with the Grant Controls. You may create multiple policies for each sign-in risk and/or user risk, for different risk levels and scoping different users, applications, locations, etc. If multiple sign-in risk policies conflict with each other, the most stringent action will be taken from among the two Condition Controls.

To configure a user risk remediation conditional access policy:

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Conditional Access > New policy.

2. Choose a user/group to be included in the policy.

3. For user risk remediation CA policies, it is recommended to choose All cloud apps as the applications you want access to be monitored for risk remediation.

4. Under Conditions, shift the Configure slider to Yes and choose User risk. Then choose the levels of risk to be targeted for end-user remediation. Microsoft recommends setting the policy for High user risk.

5. You can combine multiple condition controls (except sign-in risk) with the user risk condition control to lend granularity to your risk remediation scope.

6. You can get creative with your Grant Controls by combining them. For example, as shown in Figure 2-59, you can see how user risk can be remediated in combination with forcing another action on the user: The default grant control that must be chosen is Require Password Change. This is the only grant control that remediates risk on a user. Here, you will see a note that says that this grant action is allowed when policy is assigned to All cloud apps, which is why user risk policies are recommended to be applied to all cloud apps, above.

   

7. Press Select.

8. Finally, Press Create.

Configure sign-in risk security policy

To create a sign-in risk security policy:

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Identity Protection.

2. Select Sign-in risk policy, as shown in Figure 2-60.

3. Choose a user/group to be included in the policy.

   

4. Select the risk levels that you’d like to trigger end-user risk remediation for. Microsoft recommends setting the policy for Medium and High sign-in risk to have a good balance between security and productivity. Setting up a policy for all levels of risk might trigger MFA fatigue or accidental approvals.

5. You can set the Grant Control to either Block or Allow access requiring MFA.

6. Remember to select Enforce policy before selecting Save.

Sign-in risk CA policy

To configure a sign-in risk conditional access policy:

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Conditional Access > New policy.

2. Choose a user/group to be included in the policy.

3. Choose the applications you want access to be monitored for risk remediation.

4. Under Conditions, shift the Configure slider to Yes and choose Sign-in risk. Then choose the levels of risk to be targeted for end-user remediation. Microsoft recommends setting up the policy for Medium and High sign-in risk.

5. Set the Grant access to Require multi-factor authentication.

6. Finally, select Create.

Note the following regarding choosing custom controls as a grant control with risk-based conditional access. Although this can be chosen as a grant control action, this does not remediate risk on the sign-in. If a sign-in risk based conditional access policy is configured with custom controls as a grant option, the end-user will be prompted for the relevant custom control when attempting a risky sign-in, and if the control challenge, multifactor authentication (MFA), is satisfied, the end user will be granted access but the risk on the sign-in will not have been mitigated. The reason is because custom controls as designed today don’t apply an MFA claim on the issued refresh token. All it does is provide a binary signal of Satisfied/Not Satisfied to the conditional access engine. Since there is no MFA claim issued on the refresh token, Identity Protection does not recognize it as a valid remediation action. Also, a third-party IdP (Identity Provider) federated with Azure AD will issue an MFA claim (if the third-party IdP is configured to do MFA) on the token it issues to Azure AD. Therefore, in such a case, Identity Protection respects the completed MFA and remediates risk provided that conditional access policy is set with grant control and requires MFA where MFA is completed through the federated IdP.

AADIP and B2B

The Azure AD ecosystem classifies B2B users into many types:

• An Azure AD B2B user is defined as an identity using their organizational credentials in one Azure AD tenant to access resources in another Azure AD tenant.

• There are B2B users using Microsoft (MSA) personal accounts like Hotmail, Outlook, etc.

• There may also be B2B users hosted in non-Azure AD/vendor tenants.

• There is the scenario where B2B users are homed in non-Microsoft personal accounts from popular vendors like Gmail, Yahoo!, etc.

• And finally, there are accounts hosted on third-party on-premises identity systems.

There are a couple of principles to note when considering protection of B2B users using risk remediation policies:

• Identity Protection is officially supported for Azure AD B2B users only.

• Sign-in risk for an Azure AD B2B user is considered a property native to the resource tenant that the B2B user is attempting to access.

• User risk for an Azure AD B2B user is considered a property of the user, and hence native to the home tenant that the B2B user belongs to.

This brings about curious behaviors that one must keep in mind when deploying risk remediation policies for Azure AD B2B guest users:

• If an Azure AD B2B guest user develops sign-in risk while accessing a resource not in the home tenant, they will be prompted for MFA in the resource tenant and will be able to remediate risk through authentication methods registered either in the home tenant or in the resource tenant.

• The risky sign-in is visible in the home tenant as well as the guest tenant.

Configuration steps

Configuration can be a bit confusing, since Azure Active Directory has a separate MFA blade under Security. But the MFA registration policy is actually available for configuration in the Identity Protection blade.

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Identity Protection > MFA registration policy.

2. Choose the users and groups to be scoped for MFA registration. You can also set exclusions by user or group.

3. You have one compulsory control checkbox: Require Azure AD MFA registration.

   • Slide the Enforce policy slider to On.

   • Select Save.

Deployment considerations

Some deployment considerations to note:

• The MFA registration policy is a P2 offering.

• This feature is different from what is offered under portal.azure.com > sign-in > Azure Active Directory > Authentication Methods > Registration Campaign, popularly known as the “Nudge” feature. The registration campaign “nudges” a user without a deadline to onboard to a stronger authentication method, like the Authenticator app. This is therefore a feature complementary to the MFA registration policy.

• The registration campaign offering is a P1 offering.

Understanding risk reports

Identity Protection offers three reports for three entity-level triage views of risk seen on the tenant:

• Risky Users report

• Risky Sign-ins report

• Risky Detections report

Each of these reports can be viewed in the Azure portal by browsing to Azure Active Directory > Security > Identity Protection. The report allows for data export via CSV/JSON format. General functions like searching/sorting by any column is available as standard. By default, the risk reports are filtered (to optimize page load times). Be sure to remove all filters depending on the needs of your investigation.

Risky Users report

The Risky Users report is a table of all the risky users in your tenant. By default, it is filtered for all active users that are risky. Look at the various options the report offers for triaging risky users, as shown in Figure 2-61.

• Risk State: This depicts the current risk state of the user. It can take the following values:

  • At Risk (determined to be still risky)

  • Confirm Compromised (a special type of “at risk” state to denote that the administrator determined the user risky)

  • Remediated (determined to be no longer at risk, remedied by end user secure password change)

  • Dismissed (a special type of “no longer at risk” state, where the user is determined by the admin to be not risky)

• Risk Level: This depicts the risk level calculation by AADIP at the time when the risk was last updated. This can take the values High, Medium, Low, or None.

• Risk Detail: This offers more information about the transition of Risk States from the first Risk Level determined. It can take the following values:

  • User performed secure password change/reset

  • Admin confirmed compromised

  • Admin dismissed all risk for user

  • Admin generated temporary password for user

• Risk last updated: This is a key value to check when trying to understand why a user is risky. You might look into a user’s associated sign-ins or risk detections to understand the contributions of risk to that user. In case you find nothing in either, then this field becomes useful, for if the date/timestamp is greater than 90 days from its log-rotation, that is the reason for not seeing any risk detections associated with the risky user.

• Risk processing state: This is useful when admin actions (such as Confirm Compromised/Dismissal) are taken.

In the User Details pane, as shown in Figure 2-62, additional triage and investigation options are offered:

• User’s risky sign-ins: Takes you to a filtered view of the Risky Sign-ins report.

• User’s risk detections: Takes you to a filtered view of the Risk Detection report.

• Reset password: Allows the admin to reset the user’s password to a temporary string (a useful option for help desk staff, especially when a Block risky user policy is configured).

• Confirm user compromised/Dismiss user risk: Options to manually control the risk state of a user.

• Block user: Disables access for the user.

• Investigate with Azure ATP: This is a useful option for users that have accrued risk from detections that are non-native detections. Today, it takes you to the Microsoft Defender for Cloud portal, but as new detections from other products in the Microsoft Suite are surfaced/integrated, that link will change to a redirection to the Microsoft 365 Defender portal, where you can investigate the scenario in depth.

Risky Sign-ins report

The Risky Sign-ins report, as shown in Figure 2-63, is a table of all the risky sign-ins occurring in your tenant. By default, it is filtered for all unremedied sign-ins.

Pay attention to the following:

• Configure Trusted IPs: In triaging risky sign-ins, one may often find risk attributed to legitimate sign-ins from known IP addresses. In such a case, this option can be used to configure all the trusted IPs for the environment. Identity Protection ignores risk calculations for sign-ins sourced from trusted IPs.

• Risk level (real-time): Reports the real-time risk calculated against the sign-in.

• Risk level (aggregate): Reports the cumulative risk (real-time and offline) incurred against the sign-in.

• Confirm sign-in compromised/Confirm sign-in safe: Like the options for risky users, these admin actions also elevate/nullify the risk score associated to the sign-in.

Neither “Confirm compromise” nor “Confirm safe” actions “familiarize” features for a sign-in or user today. So if you have a block policy and a user is blocked because of Identity Protection calling out risk due to unfamiliarity in the conditions around the sign-in, simply confirming the sign-in to be safe will not resolve the issue for the user. In all likelihood, if they log in from the same location again, they might be called out for risky behavior again. Microsoft always recommends setting grant controls such as “Require MFA” or “secure password change” for sign-in and user risk policies, respectively.

You can select an entry from the report to bring up the Risky Sign-in Details pane, as shown in Figure 2-64, which contains more information, including:

• Sign-in time: Records the timestamp of the sign-in.

• Time detected: Records the timestamp when Identity Protection first deemed the sign-in risky.

• Detection last updated: Records the timestamp when the last end-user, AI, or admin action was taken on the sign-in.

When looking at the activity of a user at risk—be it their account risk or session (sign-in) risk—it is important to look at the entirety of their activity. Identity Protection does not just protect user activity during interactive sign-ins but also monitors and evaluates risk for non-interactive sign-ins as well. These sign-in types can be sorted through a filter available in the Risky Sign-ins report. Thus, while you might find a user to be risky with no associated sign-ins, it is possible that their silent non-interactive sign-ins are contributing to aggregate/account risk. Non-interactive user sign-ins are those performed on a user’s behalf by a client application or a background service. These sign-ins, unlike interactive user sign-ins, do not require the user to provide an authentication factor. Instead, a token or code is used by the device or client app to authenticate or access a resource on behalf of the user.

Risk Detections report

The Risk Detections report, as shown in Figure 2-65, is a table of all the risky detections in your tenant. Risk detections form the basis of all risk incurred on users and sign-ins in the tenant. One or more risk detections may be associated to a particular sign-in or user. By default, it is filtered for all active detections.

When thinking about risk reporting for B2B users, there are a couple of things to note:

• If an Azure AD B2B guest user develops or possesses risk and attempts to access a resource in the non-home tenant, and if the user is covered by a user risk policy and is subsequently blocked (per the above!), this phenomenon is not visible in the resource tenant risky user reports.

• Administrators cannot dismiss risk for Azure AD B2B guest users in the resource tenant.

Identity Protection has recently improved the signal-to-noise ratio (SNR) for low-risk risky sign-ins. The detection systems now run both in real-time and offline (post authentication) to understand whether sign-ins and users are compromised. The offline machine learning model scores sign-ins with different features and algorithms to determine whether a sign-in was compromised. The output of this offline model is the aggregate sign-in risk level, which represents the most recent evaluation of whether that sign-in was compromised.

Risk remediation considerations

Remediation involves reversing the contribution of risk to the entity’s risk score. Remediation can be performed on a sign-in or a user. When a risky sign-in is remediated, all contribution to the sign-in risk score, by the associated risk detections to that sign-in, is reversed. When a risky user is remediated, all contribution to the user risk score, by the associated risk detections to that user, contributing either directly or indirectly (via aggregate risk), is reversed.

When a user, workload, or a user’s sign-in is deemed to be at risk, it needs to be alleviated to ensure that a certain level of security is maintained in your tenant. Risk indicates the possibility of compromise. To mitigate that risk, an administrator may either manually remediate user/sign-in risk or choose to utilize end-user remediation options by configuring a risk remediation conditional access policy. Risks on workload identities don’t support remediation methods today, and the only action allowed upon detecting risk is “Block.”

The advantage of using end-user remediation via policies is that the remediation signal is fed back into Identity Protection to improve the precision of the risk determination in your tenant. This results in:

• Helping achieve balance between security and productivity

• Reduced time-to-response (TTR) toward risk detected, since this responsibility is passed on to the end-user

• Reduces help desk/Identity admin overhead by reducing the volume of risk data to be triaged manually

There are two types of risk remediation methods supported today:

• Sign-in risk remediation via MFA

• User risk remediation via a secure password change

Identity Protection offers two independent methods to remediate risk via policy:

• Identity Protection Security Policies

• Risk-based Conditional Access Policies

Identity Protection notifications

AADIP sends two types of automated notification emails to help you manage user risk and risk detections:

• Users at risk detected email—To enable immediate investigation of users at risk

• Weekly digest email—Offering a summary of new risky users and real-time risky sign-ins detected over the last calendar week

To configure the Users at Risk email in the Azure portal, browse to Azure Active Directory > Security > Identity Protection > Users at risk detected alerts.

To configure the weekly digest email for recipients in your tenant, in the Azure portal, browse to Azure Active Directory > Security > Identity Protection > Weekly digest.

There are two corner case scenarios related to notifications:

• The corner case scenarios with User at Risk email notifications: To prevent a barrage of emails, only one email is sent over risk detected in a 5-second period. Also, if risk is detected for an older sign-in (offline risk) and an email has already been sent for a more recent sign-in, then email notifications are throttled for the older sign-in. Finally, if end-user remediation via policies is deployed, it is quite possible that a user remediates their risk state before you address the email notification sent to alert their risk state.

• The corner case scenarios with Weekly Digest email notifications: Users in the Global Administrator, Security Administrator, or Security Reader roles are automatically enrolled to receive the weekly digest emails. An attempt is made to send it to the first 20 members in each role. Only users who hold one of the above roles at the time the email is sent can receive the email. Those eligible for the role but who are not elevated into it at the time the email is sent won’t receive the email.

SIEM Integrations

An essential part to managing identity security at scale is the ability to spool authentication and threat events to a SIEM to aid incident response, threat hunting, and troubleshooting. AADIP generates the following kinds of logs:

• User Risk Events (User risk detections)

• Risk information in sign-ins

• Risky users

• Audit data

• Risky Service Principals

• Service Principal Risk Events

Exporting risk data

Using this method, organizations can choose to store Identity Protection-related risk data for longer periods than the default retention period in Azure AD. To do so, on the Azure portal, simply browse to Azure Active Directory > Diagnostic settings > Edit setting, as shown in Figure 2-66, and select between archiving data to a storage account, streaming it to an event hub, or making it available to Log Analytics or a partner solution.

Microsoft’s own version of cold storage would be to stream data into a storage account. However, if you want to make the data available for use within the Microsoft ecosystem, you could choose to stream it to Event Hub. Event Hub supports first- and third-party (non-Microsoft) connectors that allow integration of third-party SIEMs to pull the data off Event Hub. You could also make the data available in Log Analytics to write threat-hunting queries on a sample set of data on-the-fly. Finally, Microsoft supports direct integration with some partner vendor solutions such as Apache Kafka, Datadog, ElasticDB, and Logz.io.

Configure risk-based Conditional Access policy for workload identities

Today, Conditional Access for workload identities offers only “Block” as a grant control. Therefore, Conditional Access offers mitigation of risk rather than remediation (at the time of writing this book), but it is expected that there will be automatic remediation options in the future. To create a Workload Identity risk policy in Conditional Access:

1. Browse to portal.azure.com > sign-in > Azure Active Directory > Security > Conditional Access > New policy.

2. Choose a workload identity to be included in the policy. Here, although Microsoft regresses to an older term (viz., service principal), this is only because, as part of public preview, only single-tenant service principals are in scope—i.e., third-party SaaS applications and multi-tenanted applications that you may have published, as well as Managed Identities, are out of scope for now!

3. Under Cloud apps or actions, choose All cloud apps.

4. Under Conditions, for Service principal risk (preview), shift the Configure slider to Yes and choose Service principal risk. Then choose the levels of risk to be targeted for end-user remediation. Here, you can also combine this with a location condition limiting access for the scoped service principals. Service principals usually have fixed/finite IPs; therefore, the Location condition is a convenient option to narrow down access.

   As mentioned above, only the Block grant condition is supported today. But watch for remediation options in the future! See Figure 2-67.

   

Monitor, investigate, and remediate workload identity risk

The options available for security administrators to monitor, investigate, and remediate risk on user identities is now also extended to workload identities. Risk data is available via:

• The Risky Workload Identities blade

• Graph APIs

• Azure Monitor

There are some important differences to these options from those offered for User Identities.

As mentioned earlier, Workload Identity risk policies in Conditional Access today offer only mitigation of risk. However, Microsoft strongly recommends that further action be taken upon detecting risk on Workload Identities, including:

• Inventory credentials on the identities called out at risk.

• Delete credentials when the identity is suspected to be compromised.

• Add new credentials, preferably X.509 certificates.

• When using workload identities with Azure KeyVault (AKV), remediate any AKV secrets that the workload identity has access to, by rotating them.

Microsoft has published a detailed guide for Security Operations teams to help them in their monitoring and incident response effort around securing Applications: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/security-operations-applications. There is also an Azure AD Toolkit, a PowerShell module, that offers easy CLI options for performing some of the above recommended operations: https://github.com/microsoft/AzureADToolkit.

Another major difference to note is that, for user identities, there are two types of risk reported:

• User Account Risk

• Sign-in Session Risk

All risk detections for user identities fall under the above two risk classifications. For Workload Identities today, all risk detections offered contribute to workload identity account risk only—i.e., there are no risk detections for workload identities contributing to risk determined at the workload identity sign-in or session level (as of this book’s writing, which is not to say this will remain so in the future!). For details on the different types of workload identity risk detections, refer to https://docs.microsoft.com/en-us/azure/active-directory/identity-protection/concept-workload-identity-risk#workload-identity-risk-detections. Therefore, it follows that while there are two risk reports, as shown in Figure 2-68 and Figure 2-69, respectively, offered for User Identities, for Workload Identities today, administrators can monitor, investigate, and remediate risk via the Risky Workload Identities report.