Is there a way for local ADB2C users to receive password expiration notifications to their email?
We are planning to set the DisablePasswordExpiration flag to false, but it's not clear if users will be getting notified that their password is about to expire.
The only way I can think to do this is to run a script on all users to set extension_passwordResetOn claim to the current date and time as per this sample.
Then every time the user logs on, get the date. When it's got to (say) 80 days, call a REST API in the custom policy to send an email stating "Password will expire in 10 days".
Yes, For Local Account users in AzureAD B2C tenant we can set notification for exipring password by applying the password policy.
Note: This Password policy won't apply on External Users.
Steps to Set password expiration policy.
In the Microsoft 365 admin center, go to the Security & privacy tab under Org Settings. If you aren't a global admin, you won't see the
Security and privacy option.
Select Password expiration policy.
If you don't want users to have to change passwords, uncheck the box next to Set user passwords to expire after a number of days.
Type how often passwords should expire. Choose a number of days from 14 to 730.
In the second box type when users are notified that their password will expire, and then select Save. Choose a number of days from 1 to 30.
Reference from MS Document , Please have a look in Set password expiration policy
Related
Is it possible to check if the user is in account locked state and within the account lockout duration?
The requirement is to provide an error to the user that account is locked and he/she needs to wait until lockout duration is completed on custom sign in journey. During the lockout period even if the user enters a correct password we should not let them in. I checked user attributes but could not find a corresponding attribute to work with. Is accountEnabled the right one to check? Is it possible to use
AAD-UserReadUsingEmailAddress-emailAddress
as a first step before login-noninteractive kicks in and read
accountEnabled
attribute and provide a custom message and stop the flow if it is set to false? If this attribute is not designed for locked state which attribute/way to use for this purpose?
You need to:
Have a self asserted screen that asks for the email address
Call a user read by email address - add accountEnabled as an output if not there
Check accountEnabled. If false check the time. If within lockout period, display error message.
If not, call login-noninteractive.
Set accountEnabled to true
In self-service password reset (SSPR), to prevent users from multiple attempts to reset a password, if user try only five wrong password reset attempts it lock user for 24 hours. I would like to confirm, if there is a way for Admins to reset the counter for the locked user account and/or unblock user to login to the Azure portal?
Reference article: https://learn.microsoft.com/en-us/azure/active-directory/authentication/active-directory-passwords-faq
In the scenario, where a bad actor try to lock some user’s then it could easily be done by knowing the username and users will not be able to login for 24 hours. Is there a way to prevent it?
enter image description here
enter image description here
Thanks in advance
Administrator can block/unblock users from Azure portal. To do that login to Azure portal from administrator account. Go to Azure Active Directory --> User Section. Select particular user and edit the setting section and select "Yes" to Block sign in the user. Below is the screenshot.
Above process is same for Azure AD B2C.
I hope this helps.
Any help is really appreciated for the following scenario:
How Amazon.com is managing different level of authentication, once at when you visit the site and second when you go to "Your Account"-> "Login & Security" as a security feature?
User logs in (i.e. authenticates) to a website and there is no activity for 7 days. The user revisits the website then user is asked to authenticate again. This can be implemented using cookies but due to security issue, it was implemented using the session token from the server side. After 7 days, when the expired token is provided by the browser, user is challenged to re-authenticate again.
Now, the new requirement is that if the user logs in and visits "Your Account" page then,
if the user still on "Your Account" page and there is no activity for 10 minutes, then user should be challenged to re-authenticate again.
OR.
if the user comes out of the "Your Account" page and revisits the "Your Account" page after 10 minutes, then user should be challenged to re-authenticate again.
So with the token, I can manage only one time period of inactivity, how can I handle multiple states, i.e. state (7 days) and partial state (10 minutes).
What is the industry practice to handle this scenario? Don't want to use cookies as security issue. And as an SSO provider is being used for authentication, use of database will be the last option.
-- David.
How you could handle this is going to boil down to the implementation details of your current expiring session token logic.
A common way to do it is to store your session tokens in a database or in-memory cache. If that's the case, you could simply add a new column that indicates when the user opened the accounts page.
As an example, your new column could be called accountSettingsStartTime. Normally it would have no value, but when the user navigates to the accounts page, it would be populated with the current time. When the user navigates away from the accounts page, you could clear it out. Then, when you check a security token, you just need to check your standard 7 day expiry as well as checking the accountSettingsStartTime column and ensuring it's within the last 10 minutes.
Alternatively, you could give the user a whole new session token with an expiry of 10 minutes when they navigate to account settings, and enforce the usage of that token for operations that involve account settings. You could then check that token when account settings are changed and ask the user to re-authenticate if it has expired (and invalidate their standard 7 day token). Of course, this would require more effort on the client side.
As they say, there's more than one way to skin a cat :)
Using AzureAD, users can log in through https://portal.office.com/myapps to their assigned apps. Some of them use the password-based sso with the option "User manages credentials".
This works fine, the user gets a question for his password and this password is used for SSO. Exept when this password changes or is mistyped the first time, then the user can't change his own saved credentials unless two factor authentication is activated for this user.
What is the best way to let the initial password prompt reappear for an user, or give another way to reset the password without activating 2FA?
To answer my own question, there are two portals, the Office 365 version at https://portal.office.com/myapps and the Azure version at https://myapps.microsoft.com. At the second portal, you can click on the three dots and select "update credentials". This can only be done by the users themselves.
Another way, is via the Azure admin portal. There you can assign permissions to an app. We do this normally based on groups. If you assign the permission individually, you can set or change the password, but also empty the fields. This way the user will be re-prompted for their password. After this, you can delete the individual permission, so it's again only group assigned. This can only be done by an admin.
We have a requirement where we are creating users in azure active directory with a temporary password. Requirement is such that we need to give the user a temporary password with expiry time limited to 1 Hr. In case user doesn't login within an hour, password need to reissued using a workflow.
Question is,
Is there a way to create temporary password for an user in AAD with
expiry time as low as 1 Hr? I am aware expiry of password can be set
at active directory level which can be limited to minimum 14 Days.
I would really appreciate any help on this.