I have a requirement that user account will be locked if user tries with multiple incorrect password and alternatively admin can also lock the account, for incorrect pwd attempts I can use the attribute "pwdAccountLockedTime" but is there any recommendation for the admin lock?
Generally, depending on your schema and password Policy, and as used within the popular slapo-ppolicy - Password Policy overlay and as defined in the "Draft-behera-ldap-password-policy"
pwdAccountLockedTime
This attribute contains the time that the user's account was locked.
If the account has been locked, the password may no longer be used to
authenticate the user to the directory. If pwdAccountLockedTime is set
to 000001010000Z, the user's account has been permanently locked and
may only be unlocked by an administrator.
Related
I have a user who is attempting to sign into their account on our domain, and whenever they do so they are presented with the message 'The referenced account is currently locked out and may not be logged on to'.
However, when I view their profile in AD, I can see that their profile is unlocked and there is no unlocking to do. Their password has also not expired and is still valid, but they have possibly entered their password wrong a few times - but not enough to lock the profile.
I don't think their computer is attempting to login to a local user profile and I tried to sign them on with domain\username and that still did not work. However, after I reset their password (through AD) and had them sign in with that password, they were able to sign in again.
Any clue why this might be?
Checked in AD if the user was locked, which they weren't. I expected it to be locked.
Checked when their password was made/when it expires, and it was valid. After it not being locked, this is the next likely option.
Checked that they weren't trying to sign in with a local account as opposed to a domain account, which they weren't. Was curious to see if this was the issue, but seemed unlikely.
Reset their password and afterwards they were able to sign in. Expected this to work based on previous accounts of this happening, but do not know why the issue occurs in the first place.
An OTP (TOTP, SMS, email whatever) provides an additional check in order to authenticate.
What MINIMUM SET of operations should be protected by the OTP check to ensure the additional authentication check is not pointless?
My starting list is:
Login
Remove or modify OTP protection
Modify email address
Change password
Is my list overboard or incomplete (as a minimum set)?
After implementing and experimenting with MFA in our application, this is my conclusion. The minimum set of operations that should be protected by MFA once it has been set up are:
Login
This is a big catchall to protect all account operations by having to go through at least one MFA check.
Removal of MFA (additional check after login)
Obvious. We protect removal of MFA during an unattended logged in session.
Changing of email address or any identifier used for logging in (Additional check after login).
This is critical to prevent the account effectively being moved to different ownership.
We found that password reset/update was not actually a desirable operation to be protected with MFA. Reset required access to the account email address and update required knowledge of the existing password.
If a cognito user lost his confirmation email is unable to reset his password, or ask for resent if his is in "force_change_password" status, and no error is displayed to him.
Is there any known fix on that?
Doesn't completely solve my issue, but it does provide an error message to the user.
If you go to User Pool -> General Settings -> App clients -> under Prevent User Existence Errors -> change from enabled to legacy.
So when the user clicks on the forget password will see this error message "Could not reset password for the account, please contact support or try again".
If a user is in "force_change_password" it is often because you performed an Admin create user operation, where the user is then sent a temporary password to use. After using that temp password the user will be asked to set a new password.
If this is the password you are referring to you can perform admin create user again for the same user and set MessageAction to 'RESEND' [1].
"Set to "RESEND" to resend the invitation message to a user that already exists and reset the expiration limit on the user's account."
[1] https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_AdminCreateUser.html
Using com.facebook.login.widget.LoginButton is there any way to make the user reauthenticate if the permissions change?
Right now if I put different permissions every time on mFacebookLoginButton.setReadPermissions(); and the user is already logged it dont grant the permissions and the user logs in.
If the user is already logged in, then adding more permissions won't change the behavior on the login button (since it won't actually do anything if there's already an access token). If you want to incrementally ask for more permissions, of if you need additional ones because of an update, you should use the LoginManager directly.
What you can do is put the new set of required permissions on the LoginButton so that new users will accept them as they login, but for existing users, get the current set of permissions from the AccessToken, compare them against the permissions you need, and use LoginManager to ask for the new ones.
You should do this anyways because users can decline to give you certain permissions with the login dialog, and if you need those permissions later, you need to use the LoginManager.
I could be wrong about this, but it is my understanding that it is a very common practice to handle permissions like so:
The user goes to the login page and provides a username and password.
The username and password are verified. If valid, the user's information (including permissions) is set to a session variable.
As the logged in user navigates the site, certain features are available to the user based on their permissions, which are referenced in the session.
This makes sense since it would be impractical to frequently query the database for the user's permissions. However, from a security standpoint, I'm not sure what the best approach is. A simple example would be if you were to remove a certain permission from a user while they're logged in. An extreme example would be if you were to mark a user account as inactive while they're logged in. I don't know how you could get that user's web browser to know about the change other than to code database permission checks (as opposed to session permission checks) into every part of the website. Again, that seems like overkill, but is that really the only way if you want a secure website?
Thanks!
I believe you've got it stated correctly:
I don't know how you could get that user's web browser to know about the change other than to code database permission checks (as opposed to session permission checks) into every part of the website.
Depending upon how your site is designed, it might make sense to invalidate the user's session when you perform drastic enough modifications to the user's privileges. Deleting sessions mean the user will be faced with a new request to log in, but if you've just disabled their account or severely downgraded their privileges, that might be acceptable.
But you wouldn't want to invalidate the session for every little thing and certainly not for almost any permission enhancement operations.
If you expire all sessions N seconds after the last authentication you can place an upper limit on the amount of time that your application code would grant permissions that have actually been revoked. This might be suitable when the stakes are not very high anyway.