In this article: Talking points for Identity AADP P2: Risk-based Conditional Access (RBCA) scenarios
Scenario 1
“We cannot use Risk-based Conditional Access (RBCA) / Identity Protection because we have a third-party Identity Provider (IdP) / Multi-factor Authentication (MFA) / Self-service password reset (SSPR) solution.”
- For risky sign-in policies, third-party IdP/MFA will work if the customer sets the federatedIdpMfaBehavior flag to “enforceMfaByFederatedIdp.” The federatedIdpMfaBehavior setting is an evolved version of the SupportsMfa property.
- If a customer’s third-party MFA solution is integrated with their third-party IdP (such as Ping Federate or Okta) and you set the federatedIdpMfaBehavior flag to “enforceMfaByFederatedIdp”, then Azure AD accepts MFA that is performed by the federated identity provider. If the federated identity provider didn't perform MFA, Azure AD redirects the request to the federated identity provider to perform MFA for Privileged Identity Management (PIM), Conditional Access (CA), Identity Protection / RBCA policies, etc.
- For customers leveraging Active Directory Federation Services (AD FS), the Microsoft recommendation is to migrate from AD FS to Azure AD Authentication with Azure MFA. If the customer is unable to migrate or is leveraging a third-party MFA integration with AD FS, then they can set the federatedIdpMfaBehavior flag to “enforceMfaByFederatedIdp” so that Azure AD can redirect the user back to complete MFA against the third-party IdP.
- Note: The above scenario is true for Microsoft first party cloud applications as well as any third-party SaaS applications integrated in Azure AD. If the third-party SaaS application is integrated directly with the third-party IdP, we cannot target and protect the application with RBCA policies.
- When user risk is deemed “high,” the recommendation is to have the user perform a secure password change to self-remediate the user risk. This requires Azure MFA and Password Writeback enabled for synced accounts.
- Remediate risks and unblock users in Azure AD Identity Protection - Microsoft Entra | Microsoft Learn
- If the customer is not enabling password writeback, then they should still consider implementing a “Block” policy to until the admin can review the high-risk user and reset their password administratively and then dismiss the user risk event.
Scenario 2
“There is too much alerting noise for me to manage for Identity Protection. We get too many false positives.”
- If users are enabled for self-remediation (i.e., MFA for medium/high risky sign-in and MFA/secure password change for high-risk users), then admins shouldn’t need to address most alerting. The users should be able to remediate themselves, which will dismiss the existing alert.
- Key talking point: Allowing self-remediation helps the machine learning algorithm learn from false positives, so that it can continue to reduce the number of false positives.
- *If the customer is still experiencing high levels of alerting noise, add the tenant to this Feedback Item: Home (powerappsportals.com).
- For network location alerts, ensure that all corporate IP addresses are set as “Named Locations” in Conditional Access and in Microsoft Defender for Cloud Apps to help reduce the number of false positives.
- If the customer is in a position where they have too many alerts that have not been addressed, there are scripts / graphAPI options available to clear the alerts and start fresh once users are enabled for self-remediation.
- Scripting is not supported within the FastTrack scope. See links below for further guidance on this topic:
Scenario 3
“Should we configure RBCA or Identity Protection policies?”
- Policy configuration should be done as RBCA instead of Identity Protection. RBCA provides additional granularity that is not available in Identity Protection.
- Risk policies - Azure Active Directory Identity Protection - Microsoft Entra | Microsoft Learn
- *Customers will now see a banner in identity protection advising them to set up risk policies in Conditional Access.
Scenario 4
“We don’t provide cell phones or cellular reimbursement for MFA.”
- There are other MFA options available, including call to phone or Oath Token support.
- Educate customers on the importance of MFA:
- If the customer is unwilling or unable to provide a way for the end user to complete MFA, then there is no way for the user to self-remediate a risky sign-in. In this scenario, the user identity is not protected by MFA.
Scenario 5
“We are not using Identity Protection and haven’t had any breaches. Why do it now?”
- “For 83% of companies, it’s not if a data breach will happen, but when. Usually more than once. When detecting, responding to, and recovering from threats, faster is better. Organizations using AI and automation had a 74-day shorter breach lifecycle and saved an average of USD 3 million more than those without.”
- $9.44M average cost of a data breach in the US and $4.35M global average cost in 2022
- *Reference: Cost of a data breach 2022 | IBM
- Zero Trust is a cumulative set of controls and RBCA is an important maturity that your CIO/CISO may ask about if a breach is verified. When Microsoft DART (Detection and Response Team) is engaged after a breach, one of the first controls they will ask for is RBCA. Being proactive and implementing this capability may be the “hero” control that limits the breach.
Scenario 6
What's the value of the risk-based access policies when tenants already always require MFA or/and are using passwordless sign-in?
- Our machine learning system automatically remediates the sign-in linked risks when end users use strong authentication methods like MFA/passwordless to sign in, while User-linked risk detections like leaked credentials still elevate the risk level regardless of the sign-in methods. Therefore, deploying a risk-based access policy protects you from both types of risks - risks detected during sign-in, and risks detected on user accounts.