Many thanks to the following:
George Gallen
Randy Rodgers
Craig Rodrigues
Spider Boardman
The original question was:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++
I am running DU 3.2c with C2 security and NIS (life in the fast lane).
Under the "XIsso" utility I have set the login parameter 'Max Attempts'
to be 3. I assumed this would equal 3 retries within a time frame and
then reset the counter.
I have been getting the a fair number of accounts being 'locked' after
reducing this figure.
1. Could someone assist with any info on how this parameter really
operates.
2. Is there anything out there that will allow tracking of these
attempts at login ?
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
The replies follow:
------------------------------------------------------------------------
---- ----------------------------
There is actually two parts to this, there is the max attempts as well
as a
time period of "locked"ness. For instance you can set it up so after 4
attempts the account will be locked for 1 hour (I believe 1 hour is the
min
vs. no locking) In order to unlock the account earlier you need to go
into
the xlsso menu and click unlock and apply or edit the account in
/tcb/files...
directory to remove the locking parameter.
------------------------------------------------------------------------
---- -----------------------------
Max Attempts is the maximum number of login attempts before the account
is locked. When this is set to 3 & a user attempts to login
unsuccessfully 3 consecutive times their account is locked. You can use
Xisso-Accounts-Modify User Accounts to unlock the account.
We are converting from an IBM mainframe environment to DU. I wanted to
be able to allow the operators to handle unlocking accounts. I have
written a C program that displays fields out of the TCB to determine why
an account is locked. I am currently working on a C program to unlock
the account. With this I can setup using sudo for the operators to be
able to unlock the account. I have found that most often a locked
account is a result of a user forgetting their password. I am also
planning to write a program to change a user's password. I can then use
sudo to allow operators to handle this as well.
If you check the /tcb/files/auth/a-z/xxxxxx file for the users you will
find the field u_numunsuclog#3 when an account is locked out due to too
many consecutive unsuccessful login attempts when Max Attempts is set to
3. You will also notice a u_lock field. As far as I can tell this is
only set when you click on the Account Locked button in XIsso. There is
information on this in the Security manual Chapters 13 thru 16. If you
are interested I can send you copies of my programs.
------------------------------------------------------------------------
---- ---------------------------------------------------------
Running C2 Security and NIS is one major pain. I am doing it here, and
have non-stop headaches. The default account programs (XSysAdmin,
XIsso)
don't work very well with C2 + NIS.
When I have some time, I want to try modifying Randy Hayman's C2 account
management utilities....
------------------------------------------------------------------------
---- ----------------------------------------------------------
Craig> I am running DU 3.2c with C2 security and NIS (life in the
Craig> fast lane). Under the "XIsso" utility I have set the
Craig> login parameter 'Max Attempts' to be 3. I assumed this
Craig> would equal 3 retries within a time frame and then reset
Craig> the counter.
It would have if the tags shipped in the /etc/auth/system/default
file were spelt correctly. That file is shipped with
"u_unlockint" and "t_unlockint" tags, each of which should have
been without the "int" if they were going to work. Adding a line
like the following into that file would work (I don't use XIsso
for this, so I can't remember how to do this that way any more,
sorry):
:u_unlock#86400:t_unlock#86400:\
That causes another (single? gah!) try to be allowed after 24
hours. If that one try is successful, the count gets cleared,
and all is fine. Otherwise, another 24 hours has to elapse.
Digital developers have acknowledged that this is a bug, but
there is not a committed 'fix' date.
Craig> I have been getting the a fair number of accounts being
Craig> 'locked' after reducing this figure.
I'm not too surprised, since without the "u_unlock" value, the
default is never to re-open the login window for the account.
Craig> 1. Could someone assist with any info on how this
Craig> parameter really operates.
See above.
Craig> 2. Is there anything out there that will allow tracking of
Craig> these attempts at login ?
I use auditd and audit_tool for this. I did not accept the
default setup of auditing everything in sight, however. I only
audit "trusted_event". I plan to get my daily audit status
reporting script into shape for others to see and use soon, and
post it to the alpha-osf-managers list (well, actually I'll post
a WWW pointer). However, with auditing, one can do simply this:
audit_tool -e login:0:1 -e auth_event
One of the auth_event types possible will show "Account lockout
denies access" aloing with the count of failed attempts.
I hope this helps you out.
Received on Fri Sep 06 1996 - 03:18:39 NZST