Trusted system disables user accounts

[Brendan Newport_2]

Hello,

I have an old 10.20 K420 established as a Trusted server.

Problem is user accounts are repeatedly rendered Disabled. Using sam or modprpw -k has no apparent effect (the accounts do not appear as disabled in Sam to start with). Converting the system back to untrusted sees all the accounts affected returned to enabled. Re-converting back to Trusted sees them Disabled again.

The workaround found is to delete the account, using another UID. However entually even these accounts are caught.

Any clues anyone?

[Pete Randall]

How are you converting to trusted? Are you using SAM or running tsconvert manually? If you use SAM it takes care of enabling the accounts, I believe.


Pete

[Brendan Newport_2]

Is was originally converted I believe using Sam. I've been toggling back and forth using tsconvert -r and tsconvert -c and -p. By the way authck -vp returns no errors about the TCB database.

[Jeff Schussele]

Hi Brendan,

One other thing to be aware of when converting is PW length. IF users have > 8 char PWs *only* the first 8 chars are hashed & placed in the user's tcb entry. The old PW will still work but *only* if the users enters just the first 8 chars. If they enter all of the orig PW it will be evaluated that way & will fail.

HTH,
Jeff

[Rick Garland]

Converting to a trusted system required that the passwds be reset. So accts will have to input new passwds. This is especially true if the passwds before trusted did not conform to the restrictions of a trusted system.

Accts are not disabled per se, but the passwds need to be updated

[Steven E. Protter]

I've seen this behavior before. The default setting for trusted systems are three bad consecutive login attempts and you are locked out.

At the JUF, I generally saw this behavior with users who insist on using passwords that don't pass standards set by the organization. We had a user who kept trying to set his password to cubs1 when a capital letter was required. This user ignored the prompt and though his password really WAS cubs1. It wasn't.

Also there were the mystery users who claimed not to have logged in but their accounts were locked.

Upon investigation there WERE entries in the lastb command (strings /var/adm/btmp) for those users. Seems that recent bad login attempts since btmp was cleared counted against those users at login time.

The only user I remembner having an actual problem was my department VP who's account was changed from standard and actually locked on its own. Every other case including my VP(bad karma for me) was traced to user or operations department errors.

Good thing my boss had a decent sense of humor about the whole thing.

SEP

[Bill Hassell]

Very important about tsconvert: it is an undocumented command located in the 'back-end' directory /usr/lbin. When you use SAM to convert to Trusted, it correctly runs modprpw -V which 'refreshes' all passwords as if they had just been changed. If you use tsconvert -c then 100% of your users (including root) will instantly have expired passwords. To avoid having to remember all this, use SAM to convert to Trusted. You can use tsconvert to revert *BUT* remember that anyone who created a new password longer than 8 characters in Trusted mode will not be able to login--the encrypted password will be truncated and unuseable in the untrusted mode.