trusted system -id getting locked.

[Johnson Punniyalingam]

>>they are still logged in, that is why i am amazed at the counter. something is wrong!!! <<<

Hi Mike,

Do you have any script and application hardcode the password for user account ? will also cause this problem.

Sharing same user id among the group of people will cause this problem.

last -R --> to check from destination the user account has been login

also for while you can change unsucessfull login counts 0.

Hope This Helps,

Rgds,
Johnson

[Bill Hassell]

The password is checked only once during login. It does not matter that the user logged in successfully, authentication will occur when a user *OR* a process like ftp *OR* a script *OR* another user tries to login. Failure can occur while the user is still logged in. The account will be locked out for future logins but the current user session is not affected. Thyere is nothing of interest in the /tcb file...the system is behaving correctly. You have to locate the user or process that is trying to login with the wrong password.

Run the command: lastb -R dmqmgr

These are the failures including time+date. Look at syslog and authlog and ftpd.log.

[MSwift]

We reset this application account yesterday and again this am the account is locked, here is the getprpw

/usr/lbin/getprpw dmqmgr
uid=110, bootpw=NO, audid=21498, audflg=1, mintm=0, maxpwln=-1, exptm=0, lftm=0,
spwchg=Wed Oct 21 09:26:14 2009, upwchg=-1, acctexp=-1, llog=0, expwarn=0, usrp
ick=DFT, syspnpw=DFT, rstrpw=DFT, nullpw=NO, admnum=-1, syschpw=DFT, sysltpw=DFT
, timeod=-1, slogint=Thu Oct 22 20:04:40 2009, ulogint=Fri Oct 23 07:30:46 2009,
sloginy=pts/td, culogin=25, uloginy=pts/tc, umaxlntr=-1, alock=NO, lockout=0001
000

strangely lastb does not report bad login
(but lastb works for other id's)
lastb -R dmqmgr

btmp begins Mon Oct 20 05:30

Please help!!!!

Thanks

Mike.

[MSwift]

i did not find any authlog on this box, here is the syslog.conf

mail.debug /var/adm/syslog/mail.log
*.info;mail.none /var/adm/syslog/syslog.log
#*.alert /dev/console
*.alert root
*.emerg *
local7.debug /var/adm/syslog/tcp.log

*.notice;mail,auth,security,syslog,lpr,news,uucp,cron.none /dev/console
mail,auth,security,syslog,lpr,news,uucp,cron.alert /dev/console

Thanks

Mike

[Robert Salter]

You didn't see any failed attempts in the /var/adm/syslog/syslog.log file? For ftp, ssh, login, etc.

Does this user have any scripts running that would try to access this server? maybe they forgot to change the password in them. Of course having a hardcoded password is a no no, but then there are those folks who ...

You could try changing his ID on the server. Doesn't find the problem but gets the user back in business.

[MSwift]

There are no scripts running!

I have verified that

Mike

[Viveki]

Please try the below command and check

#/usr/lbin/modprpw -m lftm=0,exptm=0,mintm=0,acctexp=-1

[MSwift]

What would this do? and why do u think this would help?

Mike

[MSwift]

I just noticed the /etc/default/security says MIN_PASSWORD_LENGTH=6. this id has a password of 3 characters (appln id). would that be an issue? will it get locked because of that? even if it gets localed then how can it work with the same passwd when i unlock it?

Mike

[Patrick Wallek]

>>will it get locked because of that?

No.

>>even if it gets localed then how can it work with the same passwd when i unlock it?

You're just unlocking the account. You're not changing the password.

>>#/usr/lbin/modprpw -m lftm=0,exptm=0,mintm=0,acctexp=-1


In a nutshell, the above is setting the account lifetime (lftm), password expiration time (exptm) minimum time between password (mintm) and account expiration time (acctexp) to null values so they are not enforced.

I really don't think this would help you as it isn't touching anything that would make much of a difference in this case. Have a read of the 'getprpw' and/or 'modprpw' man pages for a better understanding.