Problem with accounts not being inactive

[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