I have requirement to show status (locked or unlocked ) of all accounts in OpenDS 2.2.
I have come to know that pwdAccountLockedTime is present if account gets locked due to too many unsuccessful attempts. So by checking this attribute, I am able to pick account locked due to this reason.
Now I need to identify accounts which were locked due to password expiration. Is there any attribute which tells this?
I need to retrieve this attribute in my java client application.
Any help in this regards would be greatly appreciated.
P.S. - I have checked other threads and forums but none of the solutions given seem to be working - like checking pwdLockedTime (I could not find this attribute).
You can check the status of an account and get details of locked account using the manage-account utility.
When the password has expired, there is no marker that it's locked. The server uses the pwdChangedTime and the currentTime to see if the difference exceeds the expiration time.
Kind regards,
Ludovic.
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.
Hi there stack exchange,
We're seeing numerous issues in our environment of misconfigured systems repeatedly trying old passwords and causing the accounts to be locked out.
I can see no value in locking out accounts where the same password is tried multiple times, this does not get a (potential) attacker any closer to guessing the password as far as I can work out? I would like to know if there is a way to securely configure a system to count the number of distinct/unique password attempts per user, rather than just the number of attempts before lockout occurs?
I can appriciate that recording password attempts using a reversable derivitive might be bad for security, but surely there's a way to distinguish if the same password is attempted multiple times? Recording recent attempts in a long hash or something?
At the very least is it possible for a system to know that the immediately previous password has been attempted, or even a few back, and not count those as failed attempts? I have seen this implemented and it would seem simmilar to the need to judge uniqueness/distinction?
If the only purpose of a lockout policy is to prevent online brute force password guessing, rather than as a tool to DoS accounts, why is incrementing failed logon counters after only distinct password attempts uncommon?
Lots of question marks sorry, but for clarity the main question is again;
I would like to know if there is a way to securely configure a system to count the number of distinct/unique password attempts per user, rather than just the number of attempts before lockout occurs?
Thanks for any thoughts!
Kind regards,
Xeotech
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?
I would like to change the expiration time of my OpenDS-installation. First I'd like to know how to determine what the actual timeout is set to. Later I'd like to edit the timeout but didn't manage to find the information within the documentation.
All i managed to find was the description of the process that describes when a user is marked as 'locked': OpenDS: Which attribute tells that an account was locked due to password expiration
The background is that I would like to set the password expiration time to a very low amount so I can test against some locked users.
All hints are greatly appreciated.
Password expiration time is computed based on the last time the password was changed. If no pwdChangedTime is set, the server will use the createTimeStamp attribute if present, otherwise, it's impossible to determine when the password is due to expire.
So the easiest way to test password expiration, is to configure it (use dsconfig to set max age in the default password policy), and change the password of the test user.
BTW, OpenDS is no longer active, so I suggest you look at OpenDJ and its documentation.
Regards,
Ludovic.
In our system one client may have multiple operators. However there is a "wish" from client.
One company has an account, however there can be mulitple operators assigned to this company. Client wants us to prepare a solution that only one operator from company can log in to the system at same time. How can I achieve this?
Just by making sure they system has the ability to validate the login on each request. Either
Actively (by querying state -- possibly a database to compare some secrets) or
Passively -- using some form of cryptography and tokens (possibly in the cookie).
Option one is easiest, option 2 is fastest. If you validate on each request you can make sure that only one user remains logged in -- if another user signs in you can invalidate the existing active login -- perhaps with a cooldown period of n amount minutes.
You have to develop some form of login scheme -- kerberos is the defacto scheme -- read this easy to follow tutorial on kerberos Designing an Authentication System: a Dialogue in Four Scenes It should show you what you really need to do.
You could use a database field to flag that they are logged in. Update the field to 'logged in' when they do so, and then update it to 'logged out' when they log out.
You'd also need to monitor login sessions for expiry to update the field if a user never bothered to explicitly logout.
The best approach I've used:
Create a table used to track whether an operator is logged in (e.g. userid and last_accessed_dt)
On each page request by the operator update the last requested date/time
When an operator attempts to login they can only do so if the last requested data/time > timeout period of sessions on your website (E.g. 30 minutes) or if they are the Last Operator User ID ... this way they can quickly recover from a logoff etc.
When an operator logs off have the Last Accessed cleared
When the session times out have the Last Accessed cleared
"I am using WPF application and the server is written in WCF, however this can be achieved. But what in situation when user has an application opened and was inactive for 30min?"
This system is going to be single-user, so I suggest you start a counter thread when a user logs in. When counter reaches 30 minutes, write a value to the db indicating that user has timed out and other users are free to login. Obviously, you should do the same thing when user explicitly logs out.