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.

[Kevin (Gonzo) Bushman]

No, nothing that I can find is overwriting the data in the TCB DB. Yes, we do backups, but they are a read operation, not a write. NOTHING should have access to this DB except the usual tools. That is, nothing should write data TO this DB except the tools that SHOULD write data to it.

[Kevin (Gonzo) Bushman]

Plus, this is only a specific field within the DB, u_suclog. All other info appears to be correct.

Like I said, the TCB DB (u_suclog in the account file) shows that the account was last logged in over 30 days ago, yet lastb shows 3 days ago and the system default inactivity is set to 30 days.

Now, when I reset the account and log in, the u_suclog field is updated... Yet for some unknown reason (the reason I started this thread), on occasion an account will get an old date put in this field and the symptom is that the account becomes locked due to "inactivity", even though it has been active.

[Dennis Handly]

>even lastb shows that I was logged in last week.
>yet lastb shows 3 days ago and the system default inactivity is set to 30 days.

lastb(1) shows you when you did NOT login.
You need to use last(1).

[Kevin (Gonzo) Bushman]

Dennis - That's correct. lastb shows your bad login attempts (hence lastB). And maybe I wasn't clear. My point was that since I am the SA, I wouldn't have attempted to log in with my "normal" user account (the only way for me to become root remotely), had it be bad, and then not correct the situation. Implying that I would have logged in shortly after any bad (unsuccessful) attempts as soon as I corrected the situation. So in a way, my bad (unsuccessful) attempts were indications of when I actually did log in.

I guess the real point here is, and the question remains, how is bad info getting put into the TCB? I've clearly shown that a user has been logged in within the last 30 days, yet their account is locked "due to inactivity" and the date in their TCB file shows their last successful login was over 30 days ago, which isn't accurate as they were just logged in withing the last couple of days. Where's the problem?

[Dennis Handly]

>my bad (unsuccessful) attempts were indications of when I actually did log in.

Ideally you would also find an entry using last(1) that would be a little more accurate. If you don't find any entries, that may explain things?

>which isn't accurate as they were just logged in within the last couple of days.

Does it show that in /var/adm/wtmps?
(Did you ever mention your OS version?)

[Kevin (Gonzo) Bushman]

>Ideally you would also find an entry using last(1) that would be a little more accurate. If you don't find any entries, that may explain things?

First off, that may not be true either. What if I DID find entries in wtmp? What then? The info in the TCB is still wrong and the accounts are still getting locked because the corresponding entry in the TCB is outdated. And yes, wtmp is getting updated as users log in each day. On the other hand, if I don't find entries in wtmp, the info in the TCB is still wrong. As I've said, I've verified that users have logged in and their account still gets locked. What more do you want me to do?

Here's the thing. We have to clear wtmp every day for security purposes. That's why I was using lastb as a reference. And again, I've verified (physically, not via the system) that users WERE logged in in the last few days.

As I said, this has also happened to _MY_ normal user account and four days later it was locked. I checked the entry in the TCB for _MY_ account and it showed that my last successful login was over 30 days old, yet I just logged in to that very account just days prior. So it's not a case of the "users" not telling me accurate information (which I think is what was being implied and I agree that can happen, but that is clearly not the case here). As I've said several times, I've verified the accuracy (or lack thereof) of the information in the TCB. IT'S WRONG. As I have asked several times, why?

Yesterday I also verified that the entries (u_max_llogin for example) in /tcb/files/auth/system/default were also set correctly. They are. Yet the accounts are still getting locked after a few days (it appears to be 4). And it's because their u_suclog date is over 30 days old, yet they were logged in within just the last couple of days. So it seems very clear that this entry is getting updated with bad information. My question is, why? What would cause this?

This is on 11.11, BTW.

[Dennis Handly]

>What if I DID find entries in wtmp? What then?

I just wanted to determine how systematic is the inaccurate reporting of login info. Is it only in the TCB or does it include wtmp?

>What more do you want me to do?

Have you reported the problem to the Response Center?

[Kevin (Gonzo) Bushman]

I discovered an important piece about this problem.

It appears that the u_suclog entries are not being updated at all. I reset my account on one of my systems Monday morning (Sep 21) because it was locked "due to inactivity" (which has a 30 day waiting period as mentioned before) and have logged in to the system every day since. Yet when I just checked the u_suclog entry on that system for my account, it shows a date of 1253539162, which is actually the time when I reset the account! So it does not appear this entry is being updated, at all. I checked another system that I log in to every day and it shows a date of August 14th. Even though I've logged into these systems every day of the week.

So I guess it's not time to call support to open a problem case...

I'll post what they tell me.

-Gonzo