After N failed login attempts with a wrong password the account get's locked.
Documentation says the lockout interval increases after further failed login attempts: https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-password-smart-lockout#manage-azure-ad-smart-lockout-values
Is there a way to query this information, how long the account is still locked? With Graph API for instance.
I would like to show this information to the user.
The subsequent lockouts duration times are not published. Its also not recommended to create customized error messages providing a possible attacker the lockout period. However, please free to provide your # https://feedback.azure.com/forums/169401-azure-active-directory.
Related
I am creating a login screen with ADB2C.
I has two questions.
1:I want to limit the number of simultaneously active users to 150.(Maximum number of simultaneous connections)
Where can I set it up?
2:I want to display an error when the configured limit of active users is exceeded.
Where can I set this up as well?
thank you.
AFAIK, In case of azure ad B2C ,limiting concurrent active users is
not yet supported.
According to token-issuance-rate
Each type of User Flow provides a unique user experience and will
consume a different number of requests. The token issuance rate of a
User Flow is dependent on the number of requests consumed by both the
static and dynamic endpoints.
Reference for userconsumption related limits
If you already knew the users characteristics and want to restrict
users based on that , the recommended way to control the access in
Azure B2C is defining custom attributes and check the claims in
token. If the expected claim is included, you allow the user to
continue.
You can check and handle the possibility of microsoft graph
throttling from this link
Throttling limits the number of concurrent calls to a service to
prevent overuse of resources. Microsoft Graph is designed to handle a
high volume of requests. When throttling occurs, Microsoft Graph
returns HTTP status code 429 (Too many requests)
References:
azure active-directory-b2c service limit
b2c userflow identity-protection-investigate-risk
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
In on premises active directory, how a stale user is defined depends on last logon and last password reset activity. I want to know how to define a user as a stale user after some period of time in azure active directory.
Azure AD does not provide direct feature for identifying stale user.
Below article can help
https://www.undocumented-features.com/2018/06/22/how-to-find-staleish-azure-b2b-guest-accounts/
Below text borrowed from the above blog:
This script uses the RefreshTokensValidFromDateTime property from the user in conjunction with one of the following:
default token refresh lifetime in Azure AD (90 days)
the actual token refresh lifetime if a policy has been configured and is able to be read
a user-specified value
This will help you identify when users last logged on (using the RefreshTokensValidFromDateTimeProperty), and then, based on the tenant’s refresh token setting and a “stale” value (how long you want to specify without a refresh token being updated), lets you calculate a stale user.
Script available at
https://gallery.technet.microsoft.com/scriptcenter/Report-on-Azure-AD-Stale-8e64c1c5
I'm trying out the new model for unified app authentication using passport-azurea-ad from this reference https://learn.microsoft.com/en-us/azure/active-directory/active-directory-v2-devquickstarts-node-web
The integration is successful,but every time I do login,I get redirected to a page where I get to choose from my existing microsoft accounts or add a new one.
Why is the session or account not getting picked up automatically, if the user is already logged into his azure or microsoft account?
My requirement is user session should be picked up automatically(not for the first time where he gives consent) if he is logged into his azure account or micrososft account
this page needs to be avoided , if he is already signed in
The reason is a technical limitation. Let me see if I can explain briefly:
When a request comes to the v2 endpoint (login.microsoftonline.com), the v2 endpoint can not detect the presence of an existing consumer account session (login.live.com).
Therefore, the v2 endpoint must make a query (via an iframe hosted on the login.microsoftonline.com page) to login.live.com to detect if a consumer session exists or not.
If a consumer session exists, the v2 endpoint should show the user an 'account selection' screen, like the one you depict in the question.
If a consumer session does not exist, and the user only has one business session, it could auto-login the user with that business account. However, by this time the user has likely already been waiting for a second or so for the query to login.live.com to complete. It might be a strange user experience if the page auto-completed after a second.
The v2 endpoint could definitely show a loading spinner or something to hold the user until the decision can be made, but it was decided that having the user click a tile was an acceptable alternative.
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.