Password Aging

[Jennifer Hanson]

Hello,

I'm running HP-UX 11i (non-trusted) on a R5470. Every time I set up users for password aging - it starts diappearing. I.E. On the 3rd of this month I set up all users for password aging.. now, on the 13th - 35 people no longer have password aging.

I'm somewhat new to sys admin and researching these types of issues - but I thought (according to docs I've read) that password aging is supposed to stay on an account, even if they change their password... right?

If it is supposed to stay, any ideas on why it's disappearing?

Thanks,
Jennifer

[A. Clay Stephenson]

First look at the passwd field for a given user. If passwd aging is in play there should be 4 characters separated by a comma at the end of the encrypted (hashed to be more precise) passwd. Man 4 passwd will explain how the data is encoded. Note that the actual resolution is in weeks that count off every Thursday because Jan 1, 1970 was a Thursday --- the beginning of the universe as fas as UNIX is concerned.

If the passwd aging subfield truly is disappearing then the most likely explanation is human; you have more than one
root user who is "helping" you.

[Jennifer Hanson]

Hello,
I guess I should give myself more credit. I am familiar with how to tell if a user ID has password aging and how to figure out what the info means in the passwd file...

I can say with 100% confidence that I am the only one doing unix admin duties - so the human factor doesn't make sense in this situation.

Any other ideas?

Thanks,
Jennifer

[Michael Tully]

Yes password aging is supposed to stay on a given userid once it has been implemented.
Have you checked for any later patch revisions pertaining to this?

You can start here:
http://www1.itrc.hp.com/service/patch/search.do?pageContextName=hpux:::&BC=patch.breadcrumb.main|patch.breadcrumb.pdb|

[Sanjay_6]

Hi Jennifer,

Try this link. It may help.

http://www1.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000072401010

The itrc doc id is KBRC00014139.

Hope this helps.

Regds

[Robert True]

I have fought the same battle - you are not crazy - but I can't remember the exact resolution.

Question: How did you add the pwd aging? Some os's you can edit the /etc/passwd and add ,.. (meaning passwd aging, expired passwd) to the passwd field, but HPUX will ignore it and delete with the next passwd change. (I never tried ,.... that I can recall.) I solved the problem with building templates in sam for each unix group. Go into the UserTemplates and drill down until you hit the "Password Specification..." button. You can add the passwd aging there and it will stick when you add new users using the template.

You should be able to add valid info in the form ",B0iP" to the passwd field though and it should be ok though. The first 2 charators need to make sense (ie: in the correct order and value) and the last 2 need to be a valid time (ie: in the correct order) since unix epoch (0001,Jan 1, 1970). I would let the system build one with a template per your specs and copy that if you were going that route.

Rt.

[A. Clay Stephenson]

I would still like to know what the raw data is rather than knowing what some tool reports. Are the four characters plus comma there or not? Is the mode of /etc/passwd set to 644 and owned by root? Is the passwd set only with the passwd command or do you have some other tools? I also assume that you have not created a custom passwd command.

The only thing that occurs to me is that on 11.11, the libpam routines are used when passwd expire rather than the older method of calling passwd (or yppasswd if NIS). Check for the latest PAM and passwd patches.

[Jennifer Hanson]

Thank you all for your thoughts. Robert I'm glad to hear I'm not alone.

I initially added all password aging through SAM, editing a user. After the user was created already. Because that is a hassle (they cannot be logged in) this last time I added the password aging by command line "passwd -n 0 -x 91 user" (for 0 and 13 weeks). Since I did this the other day, I haven't seen any evidence either way of these users working still.

A. Clay, to answer your questions. For those that have lost their password aging the 4 characters and comma are not there. The permissions on the file are "-rw-rw-rw" and owned by root. The passwords are setup within SAM when creating a user. However a script that uses command line is used to change passwords if needed. Your last question - custom passwd command - yes, I used the command mentioned above, but only recently. To recent to tell anything.

To be honest with you, actually modifying the passwd file directly scares me - I'm not sure why. I guess by nature I'm overly cautious... Should I not be about that? Robert, do you feel this would fix the problem? I'm thinking I'm going to start using a template to help get new users setup correctly...

Thanks again,
Jen

[A. Clay Stephenson · Accepted solution]

STOP. GO DIRECTLY TO JAIL. DO NOT COLLECT $200.

Immediately change your passwd mode to 444 and owned by root. Anyone change remove the aging subfield with nothing more than vi.
Root doesn't need write permission and all the other utilities use setuid to change the file. You are sitting on a security bomb waiting to explode.

[Robert True]

I agree with A. Clay: change perms to 444 and root owner on /etc/passwd asap.

The 'passwd -n 14 -x 91 username' works on my system and will add ',B0xP' to the passwd field for the username. Subsequent passwd cmds will change the passwd correctly.

If however, the value inserted is not valid, (lets say 'passwd -n 0 -x 0 username' which the system will accept but add ',..xP to the passwd field), then the next passwd command will remove the invalid aging bits entirely when it changes the passwd for the username.

You said you used a script to run the passwd cmd with the -n and -x options. Did the script function correctly and add valid values for the aging bits? It sounds like it did not.

Again change the perms to 444 before you do anything else.

Rt.

[Jennifer Hanson]

Hey guys-

Thanks for your input. We run a database on top of the unix stuff - so I do have to check with that company to make sure I am able to change the permissions on the file. I'm assuming it could cause trouble... but at least I understand now what most likely is the problem!

Thanks for your help. I'll let you guys know if I'm able to change it and it's successful.

Thanks again!

Jennifer

[Robert True]

If someone is doing something hokey with the passwd file, it would be a good thing to break.

However in the real world, best to do a little diligence and find out what is going on. If something needs to access /etc/passwd directly (and I can think of no reason that it should - but who knows!), then look into the utility sudo. It can be configured to allow for things like that, but the best thing would be using std Unix cmds to manipulate the /etc/passwd file.

Perms of 666 on the passwd file is asking for disaster (666 just happens to also be the sign of the devil), anything tighter than 444 and a lot of stuff will break.

Rt.

[Marvin Strong]

Regardless what the company you check with says, do not leave the password file 666.
Find another solution in the future, if they say it needs to be 666. sudo as mentioned above is a good one.

Of course my first question if they say it needs to be 666 would be: Why, do you "think" it needs to be set that way?

Allowing anything, or anyone that is not admin controlled access to write to the password file is asking for disaster.

[Jeff Schussele]

Hi Jennifer,

I agree with the others - CHANGE THE PERMS ON /etc/passwd IMMEDIATELY. It's your system that can be compromised & no bonehead should be allowed to leave the door unlocked to your house.

Also I would immediately check that passwd file & make sure there are no other users with UID=0 and/or GID=0 or 3 - as these would be root level users no matter what their username was.

My 2 cents,
Jeff

[A. Clay Stephenson]

Just to make you sleep even less there is a possibility that someone TEMPORARILY changed their UID to 0; logged in again to become root; and then started creating setuid programs and/or scripts owned by root. They could then change their uid back to original and no one is the wiser. They now have a backdoor to become root no matter what you do to tighten up the security of the passwd file itself. You need to start a find looking for files with the setuid and/or the setgid bits set. Some are normal and neccessary (e.g. the passwd command) but if you find in strange places then you should remove them. Even worse, someone could now have commands that should have the setuid bit set (again, like passwd) but these comands are a new "improved" version of the original that behave exactly like the original command unless invoked with a special command-line argument. Now, don't you feel better?

[Jennifer Hanson]

Hello all,

I checked and I am able to change it. I did and I will continue to watch for loss of the aging. I would speculate that it won't happen anymore!

Thanks for all your help. I'm now going to try and do a little research to understand how the permissions got changed to be that in the first place. I imagine the app we are running did it at some point. I'll have to watch that in future upgrades.

As I mentioned in the beginning, I'm still newer to unix admin .. I appreciate all of help - I hope someday to work up to the level you guys are at!

Thanks again!
Jennifer