Hi all,
thanks to all who responded. I append below the suggestions I got.
I am now trying some of them to understand which suites my needs better.
Regards
Claudio
============================================================================
My original request:
> I have a DU 4.0f system running enhanced security (C2). When an
> user mistypes his/her password for five times, the account gets locked,
> and I have to unlock it manually. When you have a number of student users
> who often forget their own password, this becomes a boring task.
>
> What I'd like to do is: when an user mistypes his/her password for
> five times, the account gets locked, but it gets automatically unlocked
> after some time (let's say: 15 minutes, or more, if that helps).
>
> I played a little with the u_numunsuclog, u_unsuclog, u_unlock and similar
> parameters, but the solution I got was not satisfactory: in fact, I got
> the above result, but after just ONE wrong attempt; this stucks the user
> for 15 minutes every time he/she mistypes his/her password, not after
> five retries.
============================================================================
Richard Rogers suggested:
u_unlock does indeed specify the lockout period, and u_maxtries the
maximum number of failed attempts before the account is "locked". I
did some experiments with this a few weeks ago, and I think the
problem you may be seeing is that the account is locked for u_unlock
seconds from the time of the _last_ unsuccessful login, and
u_numunsuclog does not appear to be considered reset when this period
expires. Thus, if a user exceeds u_maxtries unsuccessful login
attempts, then waits u_unlock seconds, then fails again _once_, he
has to wait another u_unlock seconds before any further attempt can
succeed.
============================================================================
Nikola Milutinovic suggested:
dxaccounts -> user -> Security -> Login Restrictions -> Unlock Interval
Or beter yet, modify default template, so it affects all users.
Or, if you are a big "edauth" fan, you're looking for "u_unlock#n"
field, where n is number of seconds. Commands "useradd" and "usermod"
have no mention of this field.
So,
# edauth -dd (and add that field to the defaults)
============================================================================
John Ferlan suggested:
I just tried adding the u_unlock parameter to a test account and things worked
fine for me. I also lowered the value in my defaults file from 86400 to 60
and that worked as well. That is I was locked out for 1 minute when I failed
more than 5 times and if I only entered the wrong password once I was not
locked out.
Did you happen to also change u_maxtries to 1 or 0? Did you modify a test
user account or the /etc/auth/system/default file?
I replied:
I tried something similar, in a template for a group of users, but
it works strangely. Here is the case:
- I mistype the password 5 times
- The next attempts it says the account is disabled (OK)
- Let's suppose my u_unlock is 900 (15 minutes). After 14 minutes, I try
again, with the right password
- It says the account is disabled (OK) but.... apparently it resets the
unlock counter, and I'll have to wait again 15 minutes (not 1 only!)
before I am able to log in
Finally, he suggested again:
OK - next time do the following:
edauth -g accountname
fail a few logins
edauth -g accountname
wait a few minutes, but stay within your unlock interval
do a "good login" - that results in a locked out message
edauth -g accountname
I'll wager that for each of the edauth -g outputs the "u_suclog" never
changes; however, the "u_unsuclog" does. Using a good password within your
lockout window doesn't necessarily mean you had a successful login attempt
(successful authentication yes, login no). You were still locked out and thus
still had an unsuccessful login which caused u_unsuclog to change. The "key"
is the math "if ((u_unsuclog + u_unlockint) > time(0), then account is locked
out" - that is while the most recent unsuccessful login plus the unlock
interval is greater than the current time, then the account is locked.
I'm sure we could agree to disagree as to whether this is a bug or a feature.
What if you had a hacker that somehow magically got the right password after
many failed attempts. Forcing them to wait a day (which is the default
u_unlock) may give you the opportunity to determine that you had hacker
activity and to do something about it. Them seeing the account is locked
message after getting a successful login may also deter them from trying
again, but one never knows the mind of the hacker that well anyway...
============================================================================
William H. Magill suggested:
For student accounts, we use the following settings:
u_maxtries#10:t_maxtries#15:t_logdelay#2:t_unlock#1:
For our student systems, we discovered that 5 failures to lock an account
was too low because students would discover that they could "bugger their
buddies" by trying to login to their friends accounts and failing. Then
when their friends went to do their assignments, they had no computer
access.
By upping the number to 10, we eliminated 99% of this behaviour.
Students were just too lazy to keep trying above 10.
We went from 10-15 requests PER DAY to 1-2 request per month.
And 10 is a low enough number to prevent any active "war-dialers" from
playing password guessing games.
============================================================================
Frank Wortner suggested:
Here's one way. Get the University of Alaska user management software from
ftp://ftp.alaska.edu/pub/randy/zuausr/.
Install it. Now you will be able to list all locked users like this:
/usr/local/sbin/user_list -l
You can unlock users like this:
/usr/local/sbin/user_unlock -n username
Now, for a project, write a shell script that unlocks all the locked
users. ;-) You may use sed and awk to isolate the user names from the
output of user_list -l.
Run this script every half hour. Your problem is solved. You are happy,
the people are happy.
============================================================================
Hoai TRAN suggested:
You can set up the unlock interval so the account is automatically unlocked
after the failed attempt.
Received on Thu Jul 13 2000 - 06:23:21 NZST