TRUSTED SYSTEM

[Pat Limaco]

What adverse effects would a convertion to a trusted system from an untrusted system have on application systems? could a trusted system possibly interfere with how a shell program runs? Thanks =)

[Steve Steel]

Hi


It should have no effect on a normal shell but with remsh usage it is possible.

Go to

www.docs.hp.com

Search on trusted

You will find everything explained

Steve Steel

[Ricky B. Nino]

Hi,

You may check on this thread http://bizforums.itrc.hp.com/cm/QuestionAnswer/0,,0x672606350fe2d61190050090279cd0f9,00.html to further understand trusted vs untrusted system.

regards...

[Rainer von Bongartz]

I converted my systems a couple of months ago from untrusted to trusted.
The boxes are acting as database and file servers and I didn't find any influence on the performance.

Regards
Rainer

[BFA6]

Hi,

I converted one of my servers to a trusted system 3 months ago. This server runs shell programs from cron and there has been no problems at all.

Regards,

Hilary

[Colin Topliss]

It depends on what applications you are running and how they are written.

I had numerous problems with a client/server data management tool which relied on a PC client connecting to a UNIX based Oracle database. Part of the problem stemmed from the client logging in. Some of the system calls change between an un-trusted and a trusted (C2) system on HP-UX. As long as the application code can cater for this, then all will be OK. The particular problem I had stemmed from the client code only calling getpwent instead of getprpwent. It always worked fine against an untrusted system, but not a C2 system.

Also bear in mind that if you enable auditing you need to check cron carefully (assuming you use it). Many cron jobs started to fail as soon as we enabled auditing.

Finally, try and ensure that your passwords are all C2 compliant BEFORE you tsconvert the password file. I had problems with ( certainly older) versions not allowing you to change the password if the original was not compliant (and you guessed it - I had trouble with the root passord)! :-)

Bottom line is - if you have a test setup, try it there first. If not, be prepared for some potentially weird problems.

[Darren Prior]

Hi,

I have previously heard of applications that won't run under trusted systems as they directly access the passwd file. Of course on a trusted system the password is not kept there, and there are alternative system calls that should be used.

The application vendor should be able to tell you if they've tested their app on a trusted system.

regards,

Darren.

[Michael Tully]

You should be aware of a things. One of the features is that all passwords expire immediately, even 'root'.

The best ways are to not only test this out on test server, with as much of the application as you can, but also verify with the application vendor, as to whether it is supported or not first.

[Sridhar Bhaskarla]

Pat,

As mentioned before, I did see applications accessing the encrypted passwords from /etc/passwd file to authenticate the users internal to themselves.

So, check with your vendors/developers to see if they do any such things.

Also, once you convert the systems, the passwords will expire and will create quite a mess for you. It will also enable bad login attempts thereby locking the users and you will have to be ready for an initial battle.

However, you can change all these options by using the commands 'modprdef' (systemwise) and 'modprpw' (per user). Or SAM can easily do it for you.

-Sri