Switching to Trusted Mode and Planning for proper Admin of Auditing

[MAD_2]

I have been told to start working on conversion from non-trusted to trusted mode. I am not too concerned about the switching to trusted mode because I have already done some reading and seen some of the messages posted on the forums about some of the problems I should be aware of, I have already made changes to be proactive.

For example I found one where there is a dicussion about improper configuration of file /etc/nsswitch.conf, that misconfiguration was also apparent in the file of the server I am planning to convert (passwd and grp had the compat entry, I already changed to files) See:

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0x1d7142308663d611abdb0090277a778c,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xb1a4d5fab40ed6118ff40090279cd0f9,00.html

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xcf7937f45ef7d4118fef0090279cd0f9,00.html

I also have consulted with the developers of the application we use on our call center to find out if it is compatible with HP's trusted mode. I was told the application is compatible but to be aware that the passwords need to be re-synchronized if the application is later on upgraded to a new release (the application creates four accounts with no passwords). By the way, when the day comes, how do I re-synchronize passwords? One more silly question, this application allows for multiple simultaneous logins of the same account (all clients use the same Unix account), should this be a concern in Trusted Mode?

I have also made sure that prior to conversion my system's passwords are 8 characters long or shorter.

My main concern is auditing, I would like to hear recommendations based on previous experience about how I should approach setting up auditing and how I should prepare before I even decide to enable it. What should be my main concerns (I know space is one and overhead depending on events to be audit). Maybe I can also get some recommendations about where I should store the audit log files (I do not think the default paths for these logs are proper for my environment)

I have included a bdf of my system here so that it can serve as a baseline.

Please provide all feedback any of you can, show me links to related discussions (although I read a few already), some of the things I should be really concerned about, how to clean up audit logs without having to store them on tapes (I do not think we will keep more than 30 days of audited data in any case). If anyone has a script that does an automatic cleanup or trimming of the logs (that would be excellent!) I would really appreciate it.

I will definetely assign points as I implement the changes and see the effectiveness of the recommendations and immediately if it is guidance or advise. But please be patient with me if I do not assign points immediately on some responses.

Thanks,

[harry d brown jr]

Adam,

It appears you have done quite a bit of work, and there isn't a lot I can add other than I think it's very IMPORTANT to keep ALL users OUT of SHELLS. USERS should ONLY have access to their APPLICATIONS, PERIOD! If you can pull that off (be able to remove that access), then your task as an administrator is a TON easier, and audit's become a brain dead exercise!

live free or die
harry

[Michael Tully]

Hi,

One thing you definitely need to know is that *all* passwords expire immediately after changing to a trusted system. Make sure that your users are aware of this prior, because if they are not, you could have a mutiny.

If you have *application* related accounts that sign-in or whatever, they will expire also.

HTH
Michael

[MAD_2]

Well, about the immediate password expiration, here are my questions:

Once switched to trusted, can the passwords be set to the same they were before the switch occurs? Currently all my passwords are 8 characters long or less and all have combinations of letters and numbers (non-english words, and with the numbers in between they are really not of any language). Is the immediate password expiration a fact even though the accounts comply with "trusted system" guidelines (lenght of password). My main concern is that there is one application account password that is used by many clients simultaneously and allows them to log in automatically into the system. I want that password to remain the same for now because otherwise I have to change about 80 system application connection setups.

Also, I read something about generation of "Authorization Numbers" when new accounts are created under the "Managing Passwords and System Access" of the HP-UX System Administration Tasks manual. How does this work? Is this number used the first time as a password for new users before their password generation?

[MAD_2]

Oh, one more question before I forget. When using "passwd " can the system administrator still change passwords to whatever desired or will the options available in trusted mode appear?

I have never used a trusted HP-UX so I am not sure if it will be something similar to SCO Openserver's menu, which will give you a series of options based on what you have specified (i.e. pick a pronounceable password or allow system to generate a pronounceable password)

Thanks,

[Dirk Wiedemann]

Hello Adam,

I've convertet a view servers (HP-UX 11.00) to trusted mode.
Most of our applications works with a single account and a own user management.
Here are in short my experiences:
First: the convertion runs quit simple (using sam), fast and without problems.
When converting you can configure various parameters on system security behaviour. So I haven't enabled password aging no password as far as I can remember has expired.
I've set password length to 16 char but the old passwords are still valid.
You can check inconsistencies with the protected password database with the command pwck -s.

hope this helps
Dirk

[MAD_2]

Dirk, excellent, those are the types of answers I was expecting.

From what I remember reading, at first, when switching to "trusted" the default lenght is 8, so any passwords longer than that before the change "will be truncated", this is what I have understood. This is telling me that passwords are not expired at that moment (I am getting two different versions of the story here, do all expire or just those longer than 8?). Based on that, I acted proactively and had already shortened all possible passwords to between 7-8 characters. From what I read on your message, after switching to trusted then I can change the maximum password lenght from 8 to whatever may be appropriate.

In my case, the situation is similar to yours, there is one application which uses only one Unix login (configured on the communications setting of the application for each client, which allows them to log into the server automatically with the respective environment and permissions to access the database). After that each uses their individual database Login and password.

[Dirk Wiedemann]

just crossing my mind:
I remember that on one server the conversion hangs and no user (inclusive root) could log in. Luckily I was still logged in on the shell I've startet the conversion. To undo the trusted mode it was quite enough to remove the /tcb directory and remove the "*" in /etc/passwd in the password entry for user root. After that I've changed the password for root to the old value to secure the superuser account. In this case all passwords of the users had gone :-(. To be save you should make a safety copy of your old /etc/passwd file before converting and also staying logged in until tested a succesful login with user root.
In another case I've tentatively reconvert a trusted system by using sam. It works fine. Admittedly I must say that I hadn't make noteworthy changings changings in the trusted mode.

regards
Dirk