Hi I have an issue in which a particular user always gets locked because of ldap lookup failure. We would this account shold never get locked irrespective of failure login attempts. Currently, we have mapping as below for password:
expr:user=(user)?(user):user
Now, we want a particular user (like testuser#mydomain.com) to consider some hardcoded password. i.e.
If user is testuser#mydomain.com, then it should always take the password from the mapping section otherwise..it should work as earlier. Can someone suggest the mapping/expression to achieve this?
Related
I need to implement a lock and unlock mechanism in opendj 2.6 based on a fixed failed login attempt. I've already seen that there are two methods (https://backstage.forgerock.com/docs/opendj/2.6/admin-guide/#chap-account-lockout). a manual method (which I don't care about at all because I've already done some testing and found that it only allows manual locking and unlocking) and the second one which was perfect for me because, by modifying the password policy, it allows me to set a fixed number of failed attempts and set a lockout time out.
my goal: I need to find a way to unlock this type of locked users without spending the entire lockout time.
my problem: i have already read the documentation and apparently resetting the user's password is the only way.
ps: I also noticed that, when a user is locked, some attributes are added to his entry, such as: pwdAccountLockedTime and I thought I could delete this attribute manually, but that field was a non-editable field (and also I had no certainty that it would work).
Do you have any suggestions? Or is it simply not allowed?
As you have already identified, the proper way to unlock an account after N consecutive failures is to reset the password. If a user is entering a wrong password 5 times, do you think he will know the correct one the 6th time ?
Otherwise, OpenDJ has a tool called manage-account, where specific operations are possible. This should only be used by an admin with care.
I believe not all operations are documented, but you may read the code to understand them all.
Should I have one login form for ordinary user and admin
Or
should I have separate login form for admin and ordinary user?
It is OK to have the same form.
The purpose of the login page is authentication-- determine who the user is, not what they can do (see What is the difference between authentication and authorization?). So for example you might want them to submit a password or other token to reduce the risk that they are not the person they say they are. That can be the same process for everyone.
Certain features in your site may be available only to administrators or end users, but checking for permissions (authorization) can only be done after you're sure who the user is (they have authenticated). And logic to check for permissions should be present on every single page. So it has little bearing on what the authentication process is like.
You should just use one form for both admins and ordinary users if the log in information required is the same. Having two forms only makes the application more complicated to write. Having one or two login forms would be equally safe. Just remember to implement the correct security measures on the server side so a user does not get admin privileges.
The first step in authentication would be to check if the username exists, then check if the entered password matches the user's password in the database (passwords should be hashed). Then you can do authorization to check if the user is an admin.
While this seems to be asked in the form of an opinion, it makes more sense to answer this based on what most websites (or applications) do.
It really depends on the context. As a general rule, the same login form would be used for regular users and admin users. Generally, a parameter specifying whether the user is an admin would be stored in a database table for the users. The authentication method(s) that are executed upon clicking the login button will verify the user exists, check the password against the hash, then check the database table to see if the user is an administrator.
In some certain circumstances, I have seen a separate login page for administrators, but it is rare. One example might be a webstore that has an administration/management dashboard which is separate from the main site. Generally, though, these will work via the same form.
You are writing the login routine for a password protected website. Give examples of specific user input errors that you might want to catch, and how you might deal with them.
This is an interview question
I answered this as follows
We should add both client side errors and server side errors.
Client side error:
Check if user put nothing in username field. We can show message using javascript that “username not entered”
Server side error:
We can check if username does not exist in database and can throw error message.
We can check if password does not match in database for entered username.
Can anyone suggest. Are these the only error we can catch?
I'd consider syntactically invalid usernames (empty; too short or too long; containing invalid characters like possibly spaces, quote marks or shell/SQL metacharacters; structurally invalid, i.e., starting with dot or number), and syntactically invalid passwords (too short or even empty, too "simple", or equal to username). All these cases you can validate client side with JS, recycling the same code for the "Creating new user, choose user and password" view.
Server side, you might have backend connection error (i.e. not being able to tell whether the user does exist -- not exactly an user error, but we might want to manage it here nonetheless), user not found, password mismatch, and possibly "login disabled" (this is quite common on auto-create-user website: the login exists but must be validated by clicking on a link sent through email. Then again, one might want to place these "not-yet-users" in a storage apart to avoid clogging/churning on the real user database). Of course you might also want to add a special disable state and message ("Your membership fee is overdue"). Other additional "errors" and "warnings" may be added here, e.g. "You're not logging from your usual IP block(s) [, would you mind answering this security question?]" or "password expired, choose another password".
IMO, the main issue (assuming SQL as the database for the users and password) is SQL Injection, that for example adds a specific user as an admin access.
Dealing with it can be done using libraries in the server side to handle all user input — rather then trying to do it on your own.
.. Or is it enough to just check for a session variable that indicates a successful login has in fact been performed?
What are different ways to go about this? The ideal and not so ideal?
Thanks!
Third alternative: HMAC-ed cookie. No need to hit database/session-store at all.
Details.
Even if a user has an active session that is restores via cookie for example, you need to verify his account data.
If you don't check the current database entries for a user, he could possibly login although his profile has been banned or something like that.
The reverse situation can happen if your user opens a session in one browser (at home for example), upgrades his account to some "premium" (or whatever) account with another session (maybe from his office). When he returns home, he would get his old session that has no "premium" privileges.
So, always check the data for your user profiles. I would recommend to check them on EVERY request to your website. Your session data should only say WHO the user is and not WHAT he is allowed to do.
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.)