Trusted System Conversion Risks

[Ben_31]

I inherited many old servers at my job. These HP-UX L-class boxes running HPUX 10.2 and 11 did not have special password policy enforcement, such as:
------90 day expiration
------no password reuse
------lockout after 5 failed attepts (etc...)

I started researching this and it seems that I have to convert these systems to "Trusted System" state before I can define these policies with SAM. These boxes are running very expensive applications (Remedy, Oracle Financials, Netcool, etc..) that have been running for several years in some cases and there are dozens of user accounts on the boxes with lots of old cronjobs and scripts (and god knows what). These "mission critical" apps are crucial to business and heads will roll if they have downtime.
-------------------------------
QUESTIONS:
---1. Am I on the right path to password policy enforcement? (going to trusted systems?)
---2. Are there any risks or "gotchas" that I need to look out for?
---3. Does "revert to untrusted state" work well? (in case there are problems)

THANKS GURUS!

[Mister_Z]

Ben,

in the following link:

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90742/B2355-90742_top.html&con=/hpux/onlinedocs/B2355-90742/00/00/66-con.html&toc=/hpux/onlinedocs/B2355-90742/00/00/66-toc.html&searchterms=trusted%20system&queryid=20031111-092807

you will find information related to the trusted system facility.

[Steven E. Protter]

Check out the docs in this thread:

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


Answers:
1- That depends on your organizations risk tolerance. I think having an enforcing a policy is very good myself.

2. I know trusted systems won't work with the current sam beta. There have been problems with ldap and pam. I don't know if they are solved.

3. It does. I've done it a few times just for grins on a D320 11i.

SEP

[Stefan Farrelly]

1. Yes, you are on the right track. We run all our systems trusted.

2. Yes, a couple of risks. When you convert to trusted for the first time all passwords are expired. You can unexpire them globally with modprpw -V after converting. Also, passwords longer than 8 characters will only be accepted on login if only the first 8 chars are typed in (if you type >8 chars your password wont work). For these accounts you should reset their passwords after converting to trusted, then you can reuse passwords >8 chars.

3. Converting back works fine. Sometimes converting to or from trusted doesnt work, but simply rerunning the command fixes it.

[Jeff Schussele]

Hi Ben,

Two of the main risks involve PWs:

1) All current PWs will be expired, but this can be overcome with a single command.

2) Any user with a PW >8 chars will have trouble even if they type it exactly correct. The conversion ONLY converts the first 8 chars. So IF they only type the first 8 chars then they'll get in. If they type chars beyond 8 they will be interpreted & of course it will not match.

And yes the unconvert works fine.

HTH,
Jeff

[Mark Greene_1]

Be aware of the following:

- login IDs that do not have a password will be automatically given one

- unconverting will not remove these passwords

Follow these steps:

BEFORE activating tcb, edit /etc/nsswitch.conf and change the following:

passwd: files
groups: file

(note: used tabs, not spaces)

Activate tcb & auditing via SAM

Once active, run:

/usr/lbin/getprpw (this will verify if tcb has been setup)

authck -av (this will check the tcb database)

pwck (this will validate the passwords)

to change the root password:

/sbin/passwd will allow for a change without asking for old password

Should that fail, reboot system into single user mode by interrupting reboot and interacting with ISL


HTH
mark

[Robert-Jan Goossens]

Note: By default, on a Trusted system, only the first eight characters
of a password are significant and used for authentication, although passwords
can be longer than eight characters.

Regards and good luck,

Robert-Jan.

[Uday_S_Ankolekar]

It's good to have trusted systems as a security viewpoint
Changing to trusted "may not" give any problem but it depends on your patch level on the system.

Before converting to trusted I would keep a copy of original /etc/passwd file. So incase of problem, you can unconvert the server and copy back the original passwd file.

Goodluck,
-USA..

[Alan Turner]

One thing to watch out for - you may find that your cron jobs fail because they don't have an "audit ID". After converting to trusted mode, you may need to reload the crontab for each user using cron.

[Steven E. Protter]

The post prior to mine points out something I missed. Here is a thread that deals with solving that issue:

http://search.hp.com/redirect.html?url=http%3A//forums.itrc.hp.com/cm/QuestionAnswer/1,,0xc5f2f841489fd4118fef0090279cd0f9,00.html&qt=trusted+%2Bsystem+%2Bcron+%2Baudit+%2Bid&hit=1
http://search.hp.com/redirect.html?url=http%3A//forums.itrc.hp.com/cm/QuestionAnswer/1,,0x6fd10bce6f33d6118fff0090279cd0f9,00.html&qt=trusted+%2Bsystem+%2Bcron+%2Baudit+%2Bid&hit=2
http://search.hp.com/redirect.html?url=http%3A//forums.itrc.hp.com/cm/QuestionAnswer/1,,0xff0a595fae8bd711abdc0090277a778c,00.html&qt=trusted+%2Bsystem+%2Bcron+%2Baudit+%2Bid&hit=4
http://search.hp.com/redirect.html?url=http%3A//forums.itrc.hp.com/cm/QuestionAnswer/1,,0x2eeaf9beca68d511abcd0090277a778c,00.html&qt=trusted+%2Bsystem+%2Bcron+%2Baudit+%2Bid&hit=6

The first and last items contain the solution I used to solve this problem.

SEP

[David Hausman]

Also, make sure you have a handle on any IDs which need to be non expiring. These can be taken care of at the individual ID level in SAM. Good luck!

[doug hosking · Accepted solution]

Re cron jobs and audit IDs, save yourself some grief and be sure you have the most recent patches for tsconvert

PHCO_28980 for 11.00
PHCO_17218 for 10.20

installed BEFORE converting to a trusted
system.

Also, for performance reasons be sure to pick up the most current libsec patches.
PHCO_29028 for 11.11
PHCO_29027 for 11.00
PHCO_11214 for 10.20

Missing these can suck power from your system in non-obvious ways, especially on larger configurations.

[Tunji Olatubosun]

Hi!

After reading all the responses to this topic, I still have a question:

We plan to use SAM and retain PW expiry times. If a user has a PW of
more than 8 chars and the PW has not expired after the conversion does the user type in only 8 chars of the PW?

Thanks

[Jeff Schussele]

Hi,

Yep - only the first 8 chars *should* be entered.
Anything over 8 will cause the encryption to fail.

Cheers,
Jeff

There's a blast from the past.
And you really should submit a new question & simply link to this one.
Now the original poster will have to go back & reassign points - if any - to this post.
It's just simple forum ettiquette.

[Tunji Olatubosun]

Jeff

Thanks for your quick and clear response.

Sorry! I deprived you well deserverd points!
Ben
If you're still there can you help me to assign points to this response.

Thx