UNIX for Advanced & Expert Users

I am running Solaris 10. Occasionally, my id gets loked. I want to know who/which rougue process locked it.
How do I find out?

Thanks,
KNK

What do you call locked?
Is it you cannot connect (but others can at that precise time) with your account, or more you cannot execute anything more like opening a new session or execute a program e.g. vi a file (and again: others can...)

There is a security check put up by the sysadmin. If a user logs on with the incorect password for 5 times in a raw, the password gets locked. The sysadmin should reset it again.
Off late, the id is getting locked often and I suspect an automated job or something rather than a manual attempt.

Question - have ever written any code with an embedded password or given your passwd to another programmer/user?

If you can answer yes, there is your problem.

This in reality is a application id. I just happen to know the password. The application uses this id to ftp files in and out. There are some other FTP jobs too that login using this id.

---------- Post updated 04-17-10 at 12:53 AM ---------- Previous update was 04-16-10 at 10:44 PM ----------

That just makes me think of the password locking (after x invalid attempts) as a bad practice. If I want to bother you, I would type your password wrongly for x times everyday.
Unless there is a way to identify (atleast the originating ip address) of the machine from which wrong attempt has been made, this see this as a bad practice.

I had this problem with DBA's trying to login as "oracle" and fat-fingering the password several times which locks the account. That by itself is not bad ... but ... then the cron jobs for "oracle" stop running and I get paged. So, to prevent this from happening I added the following line in /etc/user_attr:

Code:

oracle::::lock_after_retries=no

This prevents the account from being locked if the password is not entered correctly after a few tries. There are security risks in doing this (brute force password guessing among others) so be careful if you implement this method.

HTH

Another possibility is there is an outside attack on your system by some one who knows a valid user but not the password.
There is usually a record of failed ftp passwords in the syslog file.