su-ing problems for root user when trusted is enabled

[Becke]

Guys,

I have a problem when I turned on tcb on the machine it now prompt root user for a password, so when a root user tries to su to a normal user it prompts root user for a password, however when I turn off tcb then root user can su to any user without supplying a password.

Any suggestions on how to resolve this problem???

I have checked the root user id it is set to zero....

thanks
Raf

[Indira Aramandla]

Hi Raf#,

When you conver to tructed then the passwords are expired. There is a command pwconv that checks the passwd files and the
/tcb/files/auth directory and if they dont match moves only the entry's out of passwd to tcb directory.

run the modprpw command to unexpire the passwords.


IA

[Becke]

Thanks for your response mate, I'm running hp version 10.20 which doesn't have this command ie modprpw...????

Raf

[Becke]

Hi Indira,

Thank you so much for your help, modprpw resides in /usr/lbin and when I ran it with 'V' option it worked like a charm, I have just tested and i can su from root to any user without supplying a password...

Let me perform another check and i will let you know, it looks good, if you don't hear from me then assume its all working..

Thanks for your help

Cheers,
Raf

[Becke]

Hi Indira,

What is the correct procedure, I have all the user passwords which I want to use in the /tcb/files/auth directory but when I turnoff tcb I lost all the passwords and /etc/passwd file show * in the password field which means I think all the passwords are locked...

I have run the modprpw V command and it recreates the /tcb/files/auth directory but it doesn't restore the same passwords or i'm not following the right procedure.

Please let me know on how I can use user's same passwords and also it doesn't prompt root user for a password when a root user is su-ing to another user...

Thanks
Raf

[Arunvijai_4 · Accepted solution]

Hi Raf,

This guide should be useful to manage trusted systems.

http://docs.hp.com/en/B2355-90950/ch08s08.html

-Arun

[Becke]

Thanks Arun,

All the user's passwords are in /tcb/files/auth directory and if I turn off the trusted on the machine it should by default restore all the passwords into the /etc/passwd file but it doesn't do that when I turn off the 'tcb'.

The main problem is that when tcb is enabled i can't su to a normal user without supplying a password as it prompts root user to supply normal user's password, and when I disable the trusted, root can su to any user without supplying a password. But the problem is when you disable trusted i can get root su working but all the user's password were lost...any idea???i'm also reading tcb documents on the net

[Arunvijai_4]

Hi Raf,

You may need to check these threads,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=963444
http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=119194

-Arun

[Muthukumar_5]

Are you using DCE environment. So that is asking password for root user. Try as,

# su -d

It will not ask password now. See su man page with DCE string search.

--
Muthu

[Muthukumar_5]

For converting to trusted or reverting back use Bharat's document which is in,

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=655039

--
Muthu

[Arunvijai_4]

Hi Raf,

Here is the doc attached here.

_Arun

[Muthukumar_5]

arun(ars),

previous reply is giving the same document of Bharat's one :).

Anyway, credit has to go to bharat.

--
Muthu

PS: Assign 0 points

[Becke]

Thanks Arun, Muthu and Bhrat for your detailed info and prompt responses guys.

I apologise for the late response as I wasn't at work, I was actually at the vendor site performing the Disaster recovery exercise for HP-UX.

I don't have access to the DR machine anymore as it is at vendor's site, however I have temporarily disabled trusted on the DR machine and everything worked fine.

Next time when I will be performing DR I will use your documents and information to resolve this problem.

Its great to see that we have an excellent team here guys, I have now assigned points...

Many Regards,
Raf

[Bill Hassell]

We probably assumed that when you said you turned off tcb, you meant to say that you ran the tsconvert command. You cannot turn off the Trusted System environment by removing the /tcb directory (or any other method except using tsconvert). The tsconvert is a 'backend' command which means it is not documented and designed only to be used by SAM. But it can be called directly with -u and -c which un-trusts and trusts respectively. NOTE: tsconvert always expires all passwords when converting to Trusted, which is why (without using SAM) you must run modprpw (another backend command) to reset the expiration time for all users.

Now after conversion to Trusted, there are a couple of possible messages for failed logins. One is that the password has expired (see the above comment about modprpw) and the other says the user is not logging in correctly, probably due to the wrong password. If the user tries too many times, the user ID will be disabled (which is not the same as expired). Even though the user is sure of the password, if the password is longer than 8 characters, it will not work in the Trusted system. The reason is that an untrusted "throws away" all characters after 8 no matter how many the user types. So only the first 8 are significant. But a Trusted system honors all password characters. So in a Trusted system, users should only type up to 8 characters for their OLD password. Once they login, they can change their password to a longer one and it will be honored.

And as you might expect, if users change to a longer password, conv erting back to untrusted means their password will never work and a new one must be created by the root user.

[Becke]

Thanks for your elaboration Bill, I have certainly got the better understanding now. And no I haven't deleted /tcb directory, I have used sam to unconvert the system which disables the trusted.

The problem occurs while cloning the HP prod machine onto the DR machine. I had to restore all users password manually into /tcb/files/auth directory on the test machine, but before doing the above I had enabled trusted using sam.

Users were able to login using their existing passwords after I restored the /tcb/files/auth directory from prod to test machine, but as a admin user I couldn't su from root's account to other users account without supplying the password, as su-ing from root to normal user prompted for a password, where it shouldn't prompt for a password, and I just wanted to sort this out, however I was also performing the AIX DR and AIX is my expertise, I was unable to resolve this problem as I was stuck with other things, so finally I decided to untrust the system which has allowed me to su to other people's account, but I had to reset user's password who were performing the application test on the DR machine.

Your and everyone else's information will certainly help me next time when I will perform the DR exercise.

Cheers,
Raf

[Bill Hassell]

Note that /tcb does not stand by itself as a directory structure -- it requires a matching /etc/passwd file, and for completeness, /etc/default/security and /etc/group should also be ported. The connections between /etc/passwd and /tcb include the user name and the user ID number. Rules for both untrusted and Trusted system are contained in the security file (if it exists).

[Becke]

Hi Bill,

Your comments does make sense, so next time when I will restore the /tcb/files/auth directory I will make sure that I restore /etc/passwd file as well, mind you /etc/passwd file has an * entry in the password field in prod machine, so you say that restoring /etc/passwd from prod to test would help even if it doesn't contain any passwords entries for users, and also I don't have security file in /etc/default directory in prod.

Next DR test would be a good learning exercise.

Thanks
Raf

[Bill Hassell]

That is correct. The password fields are * on a Trusted system but the /tcb passwords are not useful unless the matching /etc/passwd file is also restored. The security file, while optional, should be created aqs you develop your security procedures. Use the command:

man security