stop users from changing password

[Mike Burk]

How do I stop users from changing their password on a trusted system? When you convert to a trusted system the option for "only allow superuser to change password" is no longer available.

[harry d brown jr]

Are you serious?

live free or die
harry

[Roger Baptiste]

You can remove the execute permission on the /usr/bin/passwd binary.
chmod 5550 /usr/sbin/passwd

Or since this is a trusted system, you can set the minimum time required between password changes to a very largenumber.

Any reason to do this?

-raj

[someone_4]

I agree with RajMan ..
I dont see any other way.

Richard

[Christopher McCray_1]

Why would you want to prevent your users from changing their passwords?? If anything you should be completely opposite, stricly enforcing password policies and educating your users accordingly. You wouldn't even want the burden of that responsibility anyway, especially if you have any real number of users on your system(s).

Hope this helps
Chris

[Craig Rants]

Since it is a trusted system I would go with the previous suggestion of setting the minimum time between change to the same amount of time that the password lifetime is set to. But this kind of defeats the purpose of using trusted system policies. You could change the password format to be stricter if you are concerned about users picking easy passwords. Or have th system generate a password for them.

Good Luck,
C

[Mike Burk]

Yes Harry I am serious. Sorry if it is such a dumb question but I thought the purpose of this forum is to ask and answer hp-ux related questions. If the question is not hard enough for you then just don't answer it.

[linuxfan]

Hi Mike,

Haven't seen this request for a while now. why would you want to do this?
In any case, just remove the setuid bid off on the /usr/bin/passwd, or remove the execute permissions of the binary.

chmod 4550 /usr/bin/passwd or
chmod 555 /usr/bin/passwd

The user will get different errors based on how you change it.

-HTH
Ramesh

[Justo Exposito]

Hello Mike,

I suppose that you want to know and contol the password that your users have. But you don't need it because you as user root can change th passwords when you want and can use the "su" command to change to any users. Then you can give license to your users to change their passwords and if there are problems you can solve it.

Hope this help you.
Justo.

[Bernie Vande Griend]

This is an example when those of us who ask questions, shouldn't be so negative. We have no idea what Mike's system is doing or how it is configured, what applications are on it. I can think of at least one example where this may be a necessary configuration: An application server that has only a generic user id such as "oracle" where you don't want them to change the password unless it is done by an admin. Remember, there are benefits to having a Trusted system besides password aging. Granted, I probably still wouldn't be it this way, but thats not the point. This should be a forum where we can ask any question, and be warned where it may not be the wisest approach, but negativity should always be avoided.

To answer your question, I see 2 solutions:
1) Change the permissions on the passwd command so only root can run it.
2) Set the minimum time to change a password to the same amount as the password life, but set the password life as high as you can.

[Anthony deRito]

Mike, I can understand your situation if your concern is to avoid help desk calls becasue people have issues/problems when they change their password and then forget the one they changed it too. It is a common problem actually. Users can't seem to remember their passwords and when they finally have it burned into their brains, they change it and the help desk calls start coming in. However the inconvienence needs to be weighed against the risk. There is a password aging parameter that prevents users from changing their password before x days have expired.

Tony

[Christopher McCray_1]

I agree totally with you, Bernie, in that their should be a alevel of tact in dealing with any question, no matter what. Consider this; although this certainly not one of those instances, isn't it our duty to prevent one from doing possibly the wrong thing instead of telling them how, just for the sake of helping out? I also have generic accounts, but we ahve specific people who manage them. oracle belongs to our dba group, for example. I just wanted to put in my pro and con and in no means want to be inflammatory; I just want to hopefully provide the most feasible solution. Thanks to all who will tolerate my ramblings and for everyone's outstanding support.

Chris

[Justo Exposito]

Yes Chris and Bernie it's ok.

Regards.

Justo.

[Bernie Vande Griend]

Yes Christopher, we're on the same page. We should warn someone if we feel another course of action is better. It should be done in a professional manner of course. Then the author can decide what to do with the information. I just wanted to point out that we don't always know the intentions or the exact scenario that an author is dealing with, and should be careful to jump to conclusions. That is all, and I appreciate everyone's input and involvment as well. Thanks.

[Craig Rants]

(music playing in background) All we are saying, is give peace a chance

[Justo Exposito]

Good music, Craig.

Regards,

Justo.

[Mike Burk]

Thanks, to everyone for the support. To answer some of your questions, I have a requirement for the minimum password length to be no less than 8 alpha-numerics. I can not set the min to anything more than 6. So I have to set the users password and remove the permissions to change it. If anyone has any suggestions on how to set the min password to 8 then I would be greatfull.

Thanks again.

Mike

[harry d brown jr]

o MIN_PASSWORD_LENGTH (introduced in 11.00 via PHCO_24390)

http://www.faqs.org/faqs/hp/hpux-faq/section-67.html


live free or die
harry

[harry d brown jr]

Mike,

We get a lot of "strange" questions here, were people could make their systems open to hackers.

First you stated that the machine is "trusted", then you say you don't want users to change their passwords, which in my mind is an oxymoron. So, it wasn't an attack on you, just a clarification as to the goals you are trying to accomplish.

live free or die
harry