Many thanks to: Denise Dumas, Joseph Senulis and Ann Majeske
Interesting problem this one and as I received many replies relating to the
administrative_lock feature rather than disabled accounts I shall relay them
all in full.
Original Question
I want to be able to re-enable disabled (not administrative lock) accounts
from the command line but am unsure of which entry to reference with edauth.
I have run some tests but I don't see what changes when an account is
disabled, unless it is perhaps that the :u_flogins#n: field exceeds
the:u_maxtries#n: field?
Tru64 V5.0a PK3, TruCluster with C2 Security
Denise Dumas says
The locked_out_acct_es manpage will give you this information, but trust me,
you don't want to go this route manually. Use grace_limit to grant the
ability to log in for a short time, and let the "successful login" code
reset the account fields in the correct way.
Joseph Senulis says
A couple of possibilities:
- in dxaccounts, use the enable button to temporarily enable the account. If
the user makes a successful login, without many a login failures during the
requested time period, then the "disable" should be removed.
- the same thing can be done from the command line with:
usermod -x grace_limit=1 >username>
which would set the grace period to 1 day.
- if you really want to muck with edauth, do a "man prpasswd". I think that
setting the field
n_numunsuclog=0
will clear it. (I did this some months ago and it worked, and I think that
this was the field that I played with.) However, I would recommend setting
the grace_limit instead and this is what I decided to do.
Ann Majeske says
I cut-n-pasted some stuff that I've sent in response to previous queries on
this and similar subjects. Hope this helps.
Ann
"man locked_out_acct_es" describes the process used by Enhanced Security to
determine if an account is disabled. See "man prpasswd" for a description
of the database fields that correspond to the programming fields used by
locked_out_acct_es. Some of these fields might be defined in the default
database (see "man default") rather than the prpasswd or "auth" database.
The edauth tool (see "man
edauth") can be used to modify the database fields from the command line.
If you look at the man pages above, you will see that there
are lots of different ways an account can be disabled or locked.
Since most of the causes of a disabled or locked account are found by
checking an interaction of two or more of the u_ fields, checking for all
locked accounts can get complicated. Also, some of the fields might be in
the default database rather than the user's protected password database
entry, so it can get even more complicated.
Some of the fields involved are:
u_lock
u_life
u_succng
u_numunsuclog
u_maxtries
u_unlock
u_unsuclog
u_retired
u_expdate
An example of one cause of a disabled account:
You can tell if the password lifetime has expired by
checking if the current time is greater than
u_life + u_succhg
Checking to see if a user's account is currently disabled due to too many
unsuccessful login attempts is probably the most complicated, since the
account is only temporarily disabled. This is done so that automatic breakin
attempts are thwarted, but the user can log in the next day, for example.
The check goes something like this (I'm not looking at the code, so this
might not be exact):
if ((u_maxtries NOT EQUAL 0) AND
(u_numunsuclog GREATER THAN OR EQUAL u_maxtries) AND
(current time LESS THAN (u_unsuclog PLUS u_unlock))
then login refused
I think there are people out there who have written scripts
to check this stuff, but I can't think of any pointers offhand.
Kind regards
Lawrie Smith
Capita Technical Services
West Malling
email: lawrie.smith_at_capita.co.uk
Tel: 01732 877266
Received on Thu Feb 07 2002 - 10:04:05 NZDT