Conditional Access with Azure AD B2C

This video explains Conditional Access concepts with the Azure AD B2C.
Helpful links:
Azure AD B2C Conditional Access configuration:
learn.microsoft.com/en-us/azu...
Identity Protection and Conditional Access for Azure AD B2C:
learn.microsoft.com/en-us/azu...
Azure AD B2C sign-in with Conditional access:
github.com/azure-ad-b2c/sampl...

[@larrycovert4418]

Great video series. I'm interested in how you implemented both phone and TOTP MFA for the same application. Multiple places I've read say this isn't possible. Thanks!

[@TechMindFactory]

Thank you for watching and kind words! When it comes to two MFA methods for the same application. Let me ask to clarify. Do you want to give the user option to choose between two available MFA options (like SMS and Authenticator)? So the next time user uses one of them during the authentication process? Please provide more details for your scenario. Having multiple MFA options is 100% possible with the custom policies - I can confirm this. :)

[@larrycovert4418]

@@TechMindFactory Thanks for the quick response. Ideally, at the time of sign-up, the user would be able to choose their preferred MFA method (Email, SMS, or TOTP) and then use that method from that point forward. If I can offer the choice between all three methods, great, but if only two (SMS and TOTP) are possible, that's OK. Thank you!

[@Rednunzio]

It is possible that by going from "Enter admin center" in a tenant with an active AD B2C directory, in the "conditional access" section you will not have the possibility to activate the "term of use" policy but can only create new policies from scratch ?

[@TechMindFactory]

This is correct. For Azure AD B2C, "terms of use" option is not available. The same in Azure portal. However, you can create conditional access policies from scratch. Please remember that for AD B2C conditional access policies capabilities are limited. You can read more here: learn.microsoft.com/en-us/azure/active-directory-b2c/conditional-access-identity-protection-overview#feature-differences-and-limitations

[@olofs3107]

Awesome Video. I was wondering if you could do a video on the following scenarios: Using Azure AB B2C SSO Scenario 1 App A allows users to login either email or SMS MFA App B only allows access if you have logged in via SMS MFA (elevated permission required) users logs into App A using email, then in the same session. the user tries to log into App B. App B prompts for SMS authentication. Scenario 2 App C allows users to login either email or SMS MFA App C will have a button visible to navigate to App D based on token ACR/AMR == SMS. A user can only access App D from App C. A user can not login into App D directly. If they try to login: - Are successful, redirected to App C home page - or an error can be displayed.

[@TechMindFactory]

Thank you for watching. When it comes to your questions - I have some other topics scheduled already for the new videos however let me explain. With scenario 1 you could achieve this kind of result using DefaultSSOSessionProvider technical profile to store information about the login method used. When accessing application B you could extract data from existing session: learn.microsoft.com/en-us/azure/active-directory-b2c/custom-policy-reference-sso#defaultssosessionprovider When it comes to scenario 2, it is more complex. ACR claim is no longer supported: learn.microsoft.com/en-us/azure/active-directory-b2c/tokens-overview#claims It means you will not be able to get information about MFA method from this claim. You could use custom claim instead and include it in the token. When it comes to controlling access inside the application I think the better idea is to use authorization mechanism in the application. However, I am not sure if I understood this scenario full picture.

[@nolimitsREAL]

Hello guys, after the configuration of the CA is done. In my case to ask for MFA. A user starts to log in with google chrome browser (never used tor browser), shouldn't be able to log in without requesting the MFA ? Because I noticed that is requesting every time to use MFA, which is weird. I thought that CA is only applied where it sees a risky situation and also if the user passes the security checks, not something that is requesting all the time.

[@TechMindFactory]

Hello, Two questions: 1. Did you disable "security defaults" feature in your Azure AD B2C tenant? 2. How did you configure your CA policy? Here you should user "sign-in" risk set to medium or high and then set grant to require MFA.

[@nolimitsREAL]

@@TechMindFactory 1. Yes I did disable it because, if I remember correctly it was something that it was requesting me to do, because I use the CA functionality. Also please tell me where I can reactivate it. 2. Don't have to many options to choose, because I don't have to option to choose medium or high. I have only Block access, Grant Access and the possibility to check the MFA. That's it. I think to have more options I need to purchase the P2 of the CA. Thank you.

[@TechMindFactory]

@@nolimitsREAL Got it, in this case, you need to have P2 license. Azure AD B2C Premium P2 is required to create risky sign-in policies: learn.microsoft.com/en-us/azure/active-directory-b2c/conditional-access-identity-protection-overview

[@nolimitsREAL]

@@TechMindFactory The only good thing with the P1 license is that announce a risky user and the rest to do it manually. Also could you tell me how to activate the security defaults back again, mentioned at point 1? thank you

[@TechMindFactory]

@@nolimitsREAL To activate security defaults feature again, you have to sign in to your Azure AD B2C directory, then select "Azure Active Directory" (or Microsoft Entra ID) service from the left menu. Then select "Properties". On the page you should see "Security Defaults" section. Please note that you can enable security defaults only when you remove all Conditional Access policies. In other case you will see this information: Your organization is currently using Conditional Access policies which prevents you from enabling security defaults. You can use Conditional Access to configure custom policies that enable the same behavior provided by security defaults.