Trusted systems- can't login even from console.

[Ishmael Vestas Lesolame]

Has any one of you run into this one before?

One of my system administrators converted his system to a trusted system environment "unintentionally". A few minutes later he realised none of his users could log onto the system. The system was saying the account for root( or any user) was disabled, he should contact the system administrator but console login was possible.

Unfortunately none of the users including root could login. Eventually we booted to single user mode and unconverted the system to standard through SAM.

What beats me is why root could not login in the first place or why root was not prompted for a new password?

Why Root could not change his own password through #passwd? I noticed the /etc/passwd file was not being used. All password fields were *'s and changing those would not help either.

Is this a normal behaviour? If so, how does root (or even ordinary users) gain access to the system after converitng?

Whilst still st it, what is the advantage of trusted systems?

All oppinions will be highlt welcomed.


Kind regards


Ish.

[gil paz_2]

Hi
Do you can login in single user mode ?
If yes check the /etc/passwd
You mast have for the root /sbin/sh

[Victor BERRIDGE]

Hi,
Its difficult to answer not knowing on what version you are...
The general behaviour of a trusted HPUX would be if you leave the default settings:
1)after 3 unsuccessfull attempts, the accounts are disabled.
I dont remember having root account disabled after install exept 2-3 years ago, only at that time many people were using the root account, and I put some order since, Im not sure if the system prpompted you to change the passwd and we didnt pay attention or if straight after conversion to trusted the users were trying to connect root...
2) Yes you will have * instead of cripted passwd in /etc/passwd
the passwd are in
/tcb/files/auth/
...

The easiest way to manage user accounts after would be to use SAM and give permission to users to do the job: reactivate accounts initialize new passwd create new accounts..., using restricted sam

The advantage is to have less security breach by not allowing easy to find passwd deactivate accounts after unsuccessful loggins (possible intrusion!?) etc...

All the best

Victor

[David Rodman]

Ahh, yes. I have had most of this happen. First the root password probably failed one or more of the restrictions placed by the trusted mode security policies (expired, changed too soon, or others).
But even when I had this on I could still login to the console with the existing password. I could just never change the root password.

You found one of the ways out... unconverting from trusted.

Advantages of trusted:
Try setting a password of more that 8 chars.
Ability to audit what people execute or edit
force password policies such as expires, format, change no more than once per day, etc.

[Philip P. Hartl]

I had a similer occurance once converting to trusted systems. During the process I set the password size limit to 8 characters, unfortunately the current root password was 9 characters. All attempts to enter the "known" root password failed and eventually disabled the account. I finally realized what was happening, entered only the first 8 characters of the password and it worked. Also note during trusted system conversion you have the option of expiring all passwords.

[Barry O Flanagan]

Looks like it might have been a >8 char password, but this might be of some use to you:

All password entries and audit info are held under /tcb/files/auth/X/username (where X is the first char of the username) for each user in a trusted system. If you remove the /tcb/files/auth/X/username file for the user in question, all auditing information is removed, incl the password for that user.

Also a trusted system keeps a cache of user information in /tcb/files/auth/system/pw_id_map - removing that can also solve niggly password problems. The system will recreate it itself.

[Account Not Used]

Phillip H. is correct. Trusted system will only
look at what the Character length for passwords is set to. If it's set to 8 characters and you passwords is 9 or 10 it will only authenticate with the correct 8 character password.

[Ishmael Vestas Lesolame]

Okay guys, my administrator might have disabled the root account through >3 login attempts, afterall the password was more than 8 characters & it took a lot of persuation for him to confess what he had done, but I find it difficult to believe he could have attempted that for all the 275 users coz theirs were disabled too.
Like Philip is saying, he might have chosen to expire the passwords, but this as far as I know would prompt for a "new password"on the next login and couldn't have disabled all the accounts.

Thanks a lot guys for your responses.
By the way he is ruuning HP-UX 10.20


Ish.

[zhi wang_1]

I ran into this situation once. The problem was due to the sequence of events you execute. While building a new system I did not find the file system /tcb/files/auth/system/* there so I manually ran mkdir -p /tcb/* then tried to make the system trusted using SAM. Guess what? that is where the confusion comes from. The passwd field in /etc/passwd is already replaced with *, including the root passwd. The real passwd for each user is moved to /tcb/*/system/a-z. SAM gave me an error saying it could not run (forgot the exact error message)xxx. The correct sequence should be run SAM to make the system trusted first (it creates the file system /tcb/*/default). Then copy over or make your own /tcb/files/auth/system/default file. This way, the passwd field from /etc/passwd is moved to the proper place in the correct order and the original passwd is kept. Depending on your policy, passwd longer than required by the rule will be truncated and may have to be reset.

I ended up take this system down to single user mode. rm -r /tcb/*, removed the root passwd field (left it blank) in /etc/passwd. rebooted the server and logged in without a passwd. Set up a new passwd.

[Bill Hassell]

Most likely, the sysadmin did not use SAM to Trust his system, but used tsconvert. That's one of those 'backend' commands, used to support SAM bu not documented for general use. The warning (which SAM knows about) is that tsconvert EXPIRES all passwords on the system once the conversion is done. So SAM follows up with: /usr/lbin/modprpw -V

So in this case, SAM is the preferred method to convert a system to trusted. Otherwise, use modprpw -V right after converting to Trusted with tsconvert. And as mentioned, untrusted allows up to 8 significant characters for a password, Trusted allows lots more. But untrusted ignores everything after the 8th character, Trusted pays attention, thus the problem with root's password.