Can We Control MFA Frequency? - azure-ad-b2c

Can we control the frequency with which a user needs to perform the MFA step? i.e. only force MFA once per day?
I don't see anything under the MFA documentation for this.
I'm thinking the answer is no, and we need this UserVoice item, MFA Remembering Device, to be completed, correct?

You can allow users to "remember authentication on devices they trust" in the Azure portal and set the number of days from 1 to 60. See this documentation for details.

Related

In Azure AD, how to exclude a subset of users from requiring authentication info when first signing in

In my Azure AD tenant, I currently have it configured so that users logging in for the first time must register at least one authentication method (e.g. an alternate email, a phone number). This is useful for MFA and self-service password reset (SSPR) - screenshot here.
I want to have several non-interactive service accounts that will not be configured for either MFA or for SSPR. Therefore, these non-interactive service accounts do not need alternate authentication methods. However, under my current setting, these service accounts are prompted to enter alternate authentication methods on first login:
First with the "More Info Required" screen (screenshot), which you
cannot cancel out of
And then with the "don't lose access to your
account!" screen (screenshot), which actually does allow for the user
to cancel the operation
This is extra inconvenient because, when adding an email, email verification is required, which doesn't allow us to do this programmatically (screenshot).
If I do just click "Cancel" on the "don't lose access to your account!" screen, I can simply proceed to sign-in without inputting alternate authentication methods (screenshot).
So the question is: how can I exclude a certain subset of users (e.g. non-interactive service accounts) from requiring alternate authentication info when first signing in?
We can include only a certain subset of groups for SSPR under Password Reset->Properties. This feature does not have an "Exclude" list, which makes it more difficult to implement.
More details in an MSDN forums post:
https://social.msdn.microsoft.com/Forums/en-US/51affd2c-a2c8-4faa-bbd8-bd1773c985d4/how-to-exclude-a-subset-of-users-from-requiring-authentication-info-when-first-signing-in?forum=WindowsAzureAD&prof=required

Is there any way to limit count of Sign In user flow in AD B2C?

Edit
It is not a duplicate: The other question is about Sign Up, this is about Sign In. What's more: That question is about email verification, this question about quotas/throttling. Those are different elements of a middleware policy. Although the consequences could be similar, the issue itself and also the solution is different. Please remove the duplicate flag
In case of a malicious user scripts her/his Sign In/Sign Out against your application/web site, which uses AD B2C it can cause millions of Sign In within a reasonable short term.
Because of you will be billed based on the count of Sign Ins (free for < 50 000, then pay) this will not be a happy hour.
Question
Is there any way to prevent the scenario above? (limiting payment is not an option, this case after the attack your site will be unable to serve Sign In user flow)
Azure AD B2C has mitigation techniques against malicious attacks like you the ones you described, and B2C will automatically lock out the user for a certain period of time.
More info: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-threat-management#password-attacks
At the moment, with smart lockouts(as mentioned in the link above) admins cannot control the number of attempts. But if you want to be able to configure that and maybe, even take an action (like MFA) you can do that with custom policies: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-get-started-custom
Azure AD B2C community on GitHub has a sample to lock out the user after 6 unsuccessful sign-ins.
https://github.com/azure-ad-b2c/samples/tree/master/policies/lockout

Azure B2C - security questions

I have a client using B2C on a small scale looking to scale up to support 100,000 users.
Questions are as follows:
1 The documentation suggests lockout after 10 failed login attempts. Is it on the roadmap to allow users to configure lockout policies? (The client sees this as a security weakness)
2 To change the UPN for a user do we still need to use Graph API?
3 B2C user feedback messages to end users does not meet internal stakeholder expectations (they don’t like the error messages as they give information about if a username is valid or not) the customer seeks to customise this and understand how to customize look and feel in line with internal guidelines (The client sees this as a security weakness)
Thanks!
In the future, I recommend making three separate posts for the three questions. Helps to make each question more searchable - and also follows the Stack Overflow guidelines. In the meantime:
Smart lockout is on the roadmap, but you should vote for the feature here to help the team prioritize - https://aka.ms/aadb2cfeedback
You cannot change the UPN, but why would you want to?
You can customize all strings in Azure AD B2C - see here for built-in policies: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-reference-language-customization

Azure B2C Identity Experience Framework for MFA

How to enable Phone number verification in custom policy or MFA ? Default policy allows so , is it possible to do so in custom policy?
My requirement is to use e Phone Number as user id in Azure b2c? Is it possible to have user id accepting both phone # or email id?
Similar to Facebook accepting either phone # or email id. Appreciate your help.
A starter pack with MFA can be found at:
https://github.com/Azure-Samples/active-directory-b2c-custom-policy-starterpack/tree/master/SocialAndLocalAccountsWithMfa
Phone number based sign up and sign in could be possible but it will require you to determine your user journeys in detail. You will need to create a separate experience for phone number sign up and email sign up because their verification and storage in Azure AD is different.
Similarly, when a user needs to sign in, the country code for their phone number needs to be determined. Currently, there is no easy way to do this on the sign in page.
In short, I do not think there is an easy way to support Facebook like support for phone no and email address simultaneously. However, it is an area that Azure AD B2C team wants to invest in so we may see support in the future.

WIF STS with multiple applications going out of sync

Assume I have two web applications and single STS service:
1. Administration portal where I can grant privileges to users.
2. Sales portal where users can do things based on those privileges.
Now assume I have STS that provides security tokens with 8 hours expiration to Sales portal. Token contains claims that carry information about privileges for user, among other things.
Now imagine a scenario where on the Administration portal privilege is removed for the user and change has been saved to the database. Since user is already logged in to Sales portal with security token that has not yet expired, Sales portal will not be aware that privilege has been removed.
Question is - how to handle this scenario. To me the only solution that I can see here is complete removal of STS, but I'm looking for a smarter way to handle this.
Is there a better approach to this out-of-sync issue?
Removing the STS is a little bit drastic :-). You have it for a reason (SSO, federation, etc). You have a few options: decrease the expiration time of the token to a reasonable value for the volatility of your changes (8 hours might be excessive), or move the sensitive authorization information (e.g. privileges) to the app so it is checked each time.
You can do "claims enrichment" at the app level (through a custom AuhtenticationManager in WIF) and still use claims model from your app code.
Technically there's no synching between the app and the STS. The Token is a snapshot of user attributes at the time of issuance and valid until it expires.

Resources