Converting to Trusted System

[Ivette Perez]

Hi, where can I find information about the requirements to convert HP-UX systems to C2 level trusted systems. What could be the potential impact of this convertion?? I have Oracle DBs in all the servers and we have 10.10, 10.20 11.00 and 11i systems

Thanks

[erics_1]

Ivette,

There's plenty of documentation available at:

http://www.docs.hp.com

Search on c2 or trusted system.

Eric

[Michael Tully]

Besides the document link provided by Eric:

*All* passwords will expire immediately after changing to a trusted system. Be aware that some users will not like having their passwords expire and regularly depending on the frequency of how you set up your security plicies. Using 'sam' to do this is a good guide. Once the conversion is done, you will on many occasions where users will lock their own accounts after a number of un-successful attempts to login.

[W.C. Epperson]

My recollection is that if you set "Password Aging" to "Disabled" under "System Security Policies" before doing the conversion, your passwords won't automatically expire. I've done this conversion on 11.0 Oracle database servers without a hitch.

[Ken Hubnik_2]

Look at the man pages for tsconvert. This is the actual commance that is run in the background. There will also be a new command set to deal with logins and login accounts. /usr/lbin/modprpw. Make sure no applications are using the current password file for authentication.

[Bill Hassell]

Actually, you'll have problems locating man pages for tsconvert: it is a 'backend' command which means it is used only by some other subsystem (SAM) and subject to undocumented changes.

To start with, a Trusted System (C2 security level) will not affect Oracle at all. You have MUCH bigger problems to worry about with 10.10 and 10.20. 10.10 has been obsolete and unsupported for a long time. 10.20 is obsolete (not orderable) and will be unsupported in just a few months.

It turns out that tsconvert has been stable for quite a while and can be used to freely convert to and from Trusted, even with users logged in and running applications. The only window of incertainty would be when someone tries to login during tsconvert, so I would convert using a quiet system. tsconvert -c to convert and tsconvert -r to revert back to a standard system. ALWAYS run pwck prior to converting! (and fix any errors)

There is nothing to do except use SAM. Now it is cryptic...no button that says convert to Trusted. Instead, you select Auditing, then pick system defaults and an unTrusted system will ask if you want to convert.

Trusted simply protects the password database and offers much more flexibility in restricting password choices. It can add a bit of a load to the system administrator when people try to login with the CAPS LOCK set. You'll get a lot of deactivated accouts for a while. The good news is that fixing a locked account is simply:

/usr/lbin/modprpw -k user-name

[MAD_2]

Here are a few pointers (just my 0.02) I came up with before proceeding with a switch to a trusted system (which has not ocurred yet!). This became a matter of discussion with management and it has postponed switching to Trusted mode for about 2 months now, after they took it seriously. Some you may care about, most you may say "I already knew that"... I'll say get management and key users involved in the brainstorming process.

A BIG PIECE OF ADVICE: Backup your /etc/passwd before you do attempt to switch... I started a thread a while ago, read:
http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x23e9ed6464a6d611abdb0090277a778c,00.html
(READ MICHAEL TULLY'S LINK; HE ALREADY POSTED ONE RESPONSE IN YOUR THREAD)

As mentioned before, with your planning to switch to Trusted Oracle should not be a major concern, but maybe checking about your applications compatibility should.

NOTE: The application compatibility is something you will have to research, since there are some applications that are not compatible with trusted systems. Do any of your client applications read /etc/passwd directly? See Waine Buttie response on the thread provided above.

Also, as posted in other threads, you need to be concerned if running NIS instead of NIS+. I'll say do all of your "consulting" and brainstorming first a while before you plan for the switch, and do it during down time (if your applications accept it).

Some (or maybe most) users will not get accustomed to the changes overnight (some will plain hate it) and if no fair warning of the changes is given it WILL become the root for a lot of complaints.

When switching to trusted:
- Password may not be originally longer than 8 characters long, if longer they will be truncated (this limit, I think, can later be changed)
- A minimum amount of time can be set between password changes. This may discourage a user from changing the password right back to what it was before when password expiration occurs.
- Passwords can expire after a set time (number of days). Be really careful with this feature, as there may be the case a client application uses a password already set on the client PC that allows users to automatically log into the server, once the password expires the application stops responding while waiting for the new password to be set (we have that case where there are around 80 clients where the application might use only one Unix ID).
- Number of days before expiration of password when warning will be displayed.
- Whether passwords can be chosen by user or system generated.
- If passwords can be user generated, whether the system will be trivial on checking (if password may be easily picked, the system will not allow the change)
- Maximum number of logging attempts before account is locked. Rule of thumb is 3, but you know your users better than anyone. This change (as most of the others) can be system or individually set. You may also have those users who just "can't type" -- if you have them, they will have a locked account every day.
- Time periods when account may be used for login.
- Maximum time between logins before account is locked.

Another consideration, and the major headache I think is AUDITING (this really needs some planning):
After switching to trusted mode, auditing is possible, but what is it you would like to audit?
Things to consider:
1. What type of events will be monitored and what accounts (the more selected the more overhead on the system -- system performance can be a concern!) Oh gosh and there are so many events that can be monitored.
2. How much space are you will willing to sacrifice with audit logs? Do you plan to let them grow in their default location?
3. How much data do you want to save and for how many days? Do you want to save it on tapes for a period of time or would you just discard older logs?

YEAH, LOTS OF PLANNING!