Deactivated users vs Zee Auditors

[Francis Noël]

Hello HP Forums !

In an ongoing effort to please the auditors we are now addressing the issue of policing the deactivated accounts on our HP-UX hosts.

We pretty much have the human accounts under control but the built-in accounts are still triggering the audit tools.

The message we get is that we have deactivated accounts on the systems and we should remove them. This is not entirely accurate since the accounts pose no threat but we are getting hit by the negative score nonetheless. Problem is those accounts were never active in the first place...

Here is what a fresh(ish) install of 11.31 looks like under truster mode.

# awk -F: '{print $1}' /etc/passwd | while read list
> do
> user=`echo $list`
> state=`/usr/lbin/getprpw -m lockout $list`
> echo $user $state
> done
root lockout=0000000
daemon lockout=0000001
bin lockout=0000001
sys lockout=0000001
adm lockout=0000001
uucp lockout=0000001
lp lockout=0000001
nuucp lockout=0000001
hpdb lockout=0000001
nobody lockout=0000001
www lockout=0000001
smbnull lockout=0000001
tftp lockout=0000001
sfmdb lockout=0000001
sshd lockout=0000001
iwww lockout=0000001
owww lockout=0000001
hpsmh lockout=0000001
ora10ge lockout=0000000

I understand that any value other than 0 in the lockout field will flag a user account as inactive. The manpage for getprpw stipulates that a value of "1" means "past password lifetime".

Although the system is in trusted mode the password expiration policies have not been enabled for these users (yet).

My guess is that a password has never been defined for these "built-in" users and that they had a "*" in the password field of /etc/passwd before the system was converted to trusted mode. Under trusted mode this situation seems to be interpreted as an expired password.

I definitely do NOT want to delete these accounts since I am sure that will result in breakage....

Here are my questions :
Are my interpretations of the lock field and user states correct ?
Can I define arbitrary, complex passwords for these built-in "users" in order to get a 0000000 in the lock field and please the auditors without adverse effects on my systems ?
Do any caveats come to mind ?

Thank you for your time !

[Patrick Wallek · Accepted solution]

Actually the position of the '1' on the accounts above indicates that they have a '*' as a password.

See the 'getprpw' man page for the position dependent meaning of the output you see.

Here's an excerpt:

lockout
returns the reason for a lockout in a "bit" valued string, where 0 = condition not present, 1 ispresent. The position, left to right represents:

1 past password lifetime
2 past last login time (inactive account)
3 past absolute account lifetime
4 exceeded unsuccessful login attempts
5 password required and a null password
6 admin lock
7 password is a *


If you wanted, you could potentially write a script to periodically change the password on these users and run a 'modprpw' to make the lockout string all 0's. However, this would be slightly LESS secure in my opinion.

If there is a password, then there is a chance, however small, that it could be cracked. With a '*' as the password there is absolutely NO CHANCE of anyone logging in as those users. The only way to become one of those users is to 'su - ' as root.

The auditors need to better understand Unix security and not ding you here. But then that is the inherent problem I see with all auditors, they don't understand the stuff they are auditing.

[Tim Nelson]

IMHO.. A locked account is more secure than one with a password.

Tip: When running reports for auditors, skip the mutually agreed upon system accounts. i.e. awk -F: '$3 > 99' /etc/passwd

They will then stop asking the same questions about these locked out system accounts that are required to run the OS.

Someday system auditors might be trained with knowledge on the systems they are auditing (doubt it).

[Steven E. Protter]

Shalom,

sshd is a secure account out of the box. You can't log in with it. Messing with these accounts as an example in any way risks breakage.

If your auditors are concentrating on this, they are either incompetent, trying to justify their fees in a very secure shop or some other silliness.

Don't touch the files, do a little googling and provide the auditors documentation of two things:
1) These built in accounts are delivered secure.
2) Messing with them could cost you a lot of money with broken and down systems and any auditor recommending messing with this is risking a lot.

That being said, if you are forced to play, I'm a lock advocate.

I work at a company that provides security products for cable tv. We get audited every year. This issue has never come up on the audits of any of our 500 server class boxes.

SEP

[Francis Noël]

Thank you all for your very relevant replies.

I was interpreting the lockout field as a binary value instead of a "bit array", thanks for clearing that up Patrick.

I agree with all comments posted. Our auditors are not technical people so they are "slaves to the audit tools" if you will but they do listen to us admins. I will be able to justify the existance of these users and I will also be able to demonstrate that they pose a negligible security risk. The existance of these accounts will be documented and that should be the end of it.

Thank you everyone !