Problem with accounts not being inactive

[Kevin (Gonzo) Bushman]

I have two systems that are giving me a problem I can't figure out.

A few accounts (less than 5) on these two systems will randomly become inactive. That is, when the user tries to log in, they are told the account is locked. I then go in to find out why and it's locked due to inactivity. The thing is, these accounts are accessed almost every day and the inactive limit is set to 30 days. The weird part is that it's not all accounts on these systems, just a few.

The systems are also trusted systems so they are using the tcb DB as well.

Anyone have any thoughts? I've tried to look for patterns as to when these accounts get locked and any differences between how these accounts are set up versus those that don't get locked and haven't found anything yet.

Any help would be greatly appreciated.

-Gonzo

[Steven E. Protter]

Shalom,

Check lastb

This happens when a human or script fails to submit the correct password.

There is always a trail.

Also after a trusted conversion once my Corporate VP's ID kept locking up. I had to mess with it with sam for three hours to fix it after he got mad.

Real Sysadmin's don't use GUI's.

Unless it saves your job.

SEP

[Kevin (Gonzo) Bushman]

Steven - thanks for the reply.

Unfortunately, I checked lastb and it doesn't show anything unusual either. Also, there's three issues with the idea of it being a script or something similar that was using a bad password. First, the passwords for one of these accounts hasn't been changed for several months. Second, if it was due to a bad password, the account would be locked because of too many unsuccessful login attempts, not for inactivity. Third, if they had a bad password, it wouldn't let them in when they do try after I unlock the account because they would still be trying to use the bad password. Plus, the script or whatever is causing this wouldn't work most of the time - it's just randomly happening, say once a week to 10 days or so.

That's why I'm lost as to what is causing these accounts to get locked. I can't find any kind of pattern like it only happens on certain days (indicating a script) or even certain users trying to use bad passwords (again, the reason they get locked is due to inactivity, even though they were just accessed in the last couple of days or even sometimes the day before).

Any other suggestions?

Thanks!

-Gonzo

[Mel Burslan]

Did you think about checking for a script running out of cron or some other job scheduler, against these users' authentication records (files under /tcb/files/auth//) and changing their last login times, effectively locking them due to inactivity ?

[Kevin (Gonzo) Bushman]

Mel - To answer your question, it's very unlikely that something is changing the last successful login date in the TCB DB. There's a couple of reasons for this.

First, the TCB DB is limited to root access. That is, all files and directories below /tcb only have root permissions. So no else could be doing this (and root certainly doesn't have anything running in cron to do this). And second, why would it only be changed for these few users? If someone could change them, why wouldn't they do it to other users as well? Seems to me that if you wanted to mess with a system, even if you wanted to do it this way, you wouldn't pick on a couple of low access accounts. If you could get access to do this, you'd want to go straight for the root account or some other high profile ID. As I said before, it's just a couple of accounts on these systems. One has well over 100 accounts the other about 40 or so.

I have developed a plan of attack though. What I aim to do the next time this happens (this may take a couple of days), before I unlock the account, I will go in to the TCB DB and get the last login date for the locked account. I can then convert it to a calendar date and see when they last logged in, according to the TCB DB, which is what would be used to count inactivity. THEN, I would have a good idea if there is a problem with the system or not. My suspicion is that there's an error in a patch somewhere that for whatever reason, thinks these accounts aren't being accessed. Doing this will prove that one way or another. Right now, the dates are valid/current. If/when one gets locked again, I can validate it again. If is less than 30 days old AND the system says it is locked due to inactivity, then I'll have an issue to take to support.

Thoughts?

I'll post whatever I find here so we will all have current info.

Thanks to anyone who has any suggestions!

-Gonzo

[V. Nyga]

Hi,

is NIS involved?

Or maybe dublicated uids?

Volkmar

[Kevin (Gonzo) Bushman]

Negative on both. NIS is not being used and there are no duplicate UID's.

I'm leaning more and more to the idea that there's something wrong with a patch somewhere as both systems are patched identically (one's development and the other production for the same set of app's so the two systems are identical in many ways). But, until I have evidence of that (I have a last_successful_logon date within the last 30 days AND the account is locked due to inactivity), I'm hesitant to call support.

I'm continuing to watch and research the problem. If I find anything more, I'll post here.

Thanks to all for any input you may have.

-Gonzo

[Bill Hassell]

Attached is my userinfo script that saves a lot of time tracking down login status.

[Kevin (Gonzo) Bushman]

OK. So I've watched the accounts and have found accounts that are locked, yet when I go in and check the last successful login date for that account in the TCB database, it's more than 30 days out (our default is set to 30 days). HOWEVER, the account was logged in within just the last couple of days. My user account (not root) is a good example. It was locked this morning. When I checked the TCB database, it said that I had not logged in since mid-August, yet I was just logged in on Friday! So when I reactivated the account (I'm doing this through SAM to get the error from the system) it said that the account was locked because it was inactive for too long. Which makes sense as the date in the TCB DB was in August. However, like I said, even lastb shows that I was logged in last week.

So, why is there erroneous data in the TCB database?

-Kevin

[TTr]

> So, why is there erroneous data in the TCB database

Maybe it is not. Did you look into the possibility of tcb being overwriten from somewhere. I know you said you check root's crontab and it is not doing it. But it could be another job running as suid-root such as a backup/restore job, ftp/scp or a job at another server that has access to this server.