Why is a user 'locked out' of a computer and unable to sign back in even though they are unlocked in Active Directory? - authentication

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.

Related

How to force the user to enter his recent password before changing it?

I'm building a page for a Flutter web application using Firebase Auth where the user can change his password. For security reasons, I want the user having to enter his recent password before being able to set a new password.
To achieve this, I tried to use the reauthenticateWithCredential()-method from Firebase.
Problem is, this only seems to work if the user hasn't signed in recently. If, on the other hand, he has just signed in, he can change his password without giving the right credentials (or even without giving any credentials at all).
So is there a possibility to prevent the user from changing his password without providing his correct recent password, no matter if he just signed in half a minute ago? Did I overlook something?
As far as I know it isn't possible to get the password from Firebase, so the only two solutions I can think of atm are
To sign out and re-sign-in the user, given he has entered the correct credentials, and then change the password, or
pass his password from the login to a variable on the change-password-screen, just in case it should be needed...
However, both methods don't seem to be appropriate for practical and/or security reasons.

Cannot login to Paypal sandbox with first account, but second, third account work

I'm always told I write "biblical length" emails, but hey, I'm trying to characterize the situation the best I can for ya.
I created my sandbox. The Business account was auto created. I created a Personal account.
I successfully paid to the Business account with the Personal account with my Buy-now setup and my IPN works correctly (after changing the fsockopen to use SSL, changing \n to \r\n, etc). No problems with the "front side" of all the account business.
Part of the "Backend" needs are to transfer some of the Business account money to another account after 3 days (my Business account is a middle-man).
I switched from Firefox to Chrome. I had done all the account setups in FF, so I didn't want to try to have two logins running under one browser, sandbox or not.
I tried to login as the Business account and it failed and ended up in the "make sure your email and password are correct" loop.
I tried to login with the Personal account (the one which successfully paid into the Business account via the application). Same error.
I tried changing the password on the original Business account, flushed cache/cookies, still cannot login. There should not be any password errors because the accounts have the same password!!! I cannot use the "forgot my password" logic to see what it thinks my password is, because the email is fake and it won't get sent anywhere.
I created a second Business account, and I tried to login and it logged in correctly and showed my balance correctly. I logged out and tried the other two accounts, but the only one that ever logs in is the second Business account.
I could solve the issue by changing the target of my front side Business transfers to the second Business account, because I know I can log into that one, but that would be condoning the fact that the system is flawed, and I'd rather push this issue to find out what is wrong.
I switched to IE (argh!)
I tried the original Business account. Failed.
I tried the Personal account. WORKED!!!!
I tried the second Business account. WORKED !!!! and I didn't have to flush cache or cookies. It still won't allow the original Business account, even with IE.
I don't have time to wait 2 hours (in case it's the "too many times" problem). There was nothing wrong with the account/passwords in the first place, and since I'd never tried logging in with any of the accounts directly before, there was no history of failed transactions.
I switched to Safari.
Once again, original Business account fails, but the other two accounts work correctly!!!!
I switched back to Chrome.
Again, original Business account fails, but the other two accounts work correctly!!!!
So, it appears once I have successfully used an account, it will work regardless of the browser, cookies or cache. IE, Chrome and Safari all work with two accounts but none of them work with the original Business account.
Finally, I tried changing the password again for the original Business account. Still doesn't work.
My suggestion is to add a button to the "test accounts" setup page, "LOGIN AS" and just let us automatically login as that user (after first successfully logging into the sandbox with our validated paypal account) and bypass the whole password thing, if you aren't going to get it to work.
2 things.
1) Apparently I should have used "Paypal" in the initial title, I had assumed the tool was already in a Paypal specific sub-forum (wrong) and I have added the word to the title. Sorry for the confusion.
2) To answer my own question ...
I tried to login to the orig. Business account first thing this morning and it worked. I tried to do a transfer and it wanted login validation and failed again and again. If your results do not prove out your premise, then there is probably something wrong with your original premise in the first place, right? So I went back to my original course of action, which was to switch from Firefox to Chrome when I went to login (because I didn't think someone would have you logging in as two different users within the same window). WRONG AGAIN. I logged in as Developer, but instead of going to a different window or browser, I logged in a second time by using the "Enter Sandbox" link, and was able to succesfully login with each of the accounts.
You have to be logged in as a developer in the top portion of the sandbox interface window, while you login as one of the Business or Personal accounts in the lower half of the test window or else it doesn't work. If that is the case, and I am now doing it as it was designed, then that would explain why it was failing when trying to login when using Chrome/Safari/IE, since I wasn't logged in as the Developer account in those browsers. Why it did occasionally PASS is crazy. Software should be consistent, if anything.

Should user auto-login after registration?

Is it safe to login user automatically after registration?
User fills registration form, some info message is sent to his mailbox, and what then:
User redirected to login page asking him for credentials;
OR
User auto-logins as his newly created user?
I feel something not safe enough in auto-login, but can't figure it out!
If they just filled out the login information and you're not concerned about confirming that the email address is legit, then there shouldn't be a problem just logging them in directly.
However, you open yourself up to people/bots creating bogus accounts (at least ones without legitimate email addresses). If you're concerned about that (not sure it this is a public facing app or intranet, etc) then you should at least verify the email address by sending a link with a guid or some identifier that you can track back. Then you can let them log-in once they are confirmed.
You could also just tie it to their StackExchange/Facebook/OpenID/etc account and not make users fill out yet another form and worry about maintaining all that information.
They should need to login. Also the confirmation email should not contain their password. If they managed to give you the wrong email address and you automatically log them in then someone else has access to their account now. This holds even if you have them type their email address twice. Sometimes people make the same mistake twice in a row.
It can be safe to auto login if the user already has an active session as the correct user during the confirmation step. If you think about it, it's not actually "automatically logging them in" but simply keeping them logged in as they was before.
User registers
Keep a session identifying the user
User navigates to the confirmation page (linked in email)
You activate the account
During all that time, there was no reason to end the session. The only reason you would want to end the session (or not create one in the first place) is if your permissions are not properly set to allow someone to login / create a session without giving them higher privileges than an unregistered user.
Now, be sure not to automatically identify the user as X simply because this person navigated to the confirmation page of user X. If a user navigates to this page but does not already have a session open, do not assume he knows the password.

Should password reset pages automatically authenticate users?

Many lost password workflows usually result in a page which is reached by a temporary link emailed to the user. This link then takes them to a page that asks for a new password.
Upon entering the new password should a user be forced to logon manually, or should the password reset page authenticate the user automatically which would reduce the number of steps and thus complexity of the process for the end user?
I often encounter password reset pages that make me reset my password and then login which feels like I'm logging in twice for no good reason.
I quite like drupal's method: The user gets sent an email with a link in it which will log them on once; upon logging in with it they are given the opportunity to change their password.
I don't know of any significant advantage to forcing the user to re-enter the password that they just entered twice. If someone does, I'd be interested to hear about it.
You should make it auto login. Don't see why you would make the user login.
If it's because of bot protection, just add a captcha when the user logins using the link.

How do I prevent dual Login of my users in my web application

how do I prevent my users for more than one simultaneous login per account. I am using Vb.Net SQL.
Just coming from a 'web programmers' point of view, there is one really simple way:
You have to use some sort of central session system, where a Cookie on the user's browser has a hash, or some unique key that is also stored in the database. One each page request, or at set intervals, you check if that hash exists in the database.
Then, whenever you have a user log in, you delete any hashes that are tied to that user in the database, and then you create a new one for the user logging in.
What happens is if a user logs in, and you delete existing hashes from the database, then the other user will be logged out when you go to check for their hash in the database.
Not VB-specific, but: when the user logs in, keep track of the fact they are logged in. You can keep this in a cookie (watching out for the fact that a cookie can be tampered with.) You can keep track of it in a session variable. Or you could keep a boolean field in the database, "is_logged_in".
Then, when the user attempts to log in, you can check to see if they've already done so. If they're already logged in, the script might just return them to the home page (provided they used valid credentials. Otherwise a rogue user could type a username but leave the password blank, and depending on the behavior of your program, could see if a user was logged on at that specific time.)
Also, it is common that when someone is logged in, the webpage itself replaces the "Login" link with some text that says "Welcome, rascher!" and maybe links to their profile or preferences page.
Edit: Also remember to set is_logged_in (no matter how you track it) to "false" if they log out. It might also help to time this out - say, when the user closes the browser, or after "n hours" of inactivity (though that can be really annoying.) It will depend on how long people are generally logged into the system. Also note that someone might log in on their home computer, stay logged in, and then try to log in to the same place from work or their iphone. You might could look at ways of dealing with this (if the IP address is different than the current login, then log the other person out? Or something.)