Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Users reset their own password
- Thread starter cctrinh
- Start date
- Thread starter
- #5
When they login it will prompt them to change their password. I don't know why you would want to have third party software to manage passwords locally unless you have a large number of servers.
And the user doesn't have to have administrative privileges to change their own password.
And the user doesn't have to have administrative privileges to change their own password.
The users have to be logged in to change their own password, which doesn't satisfy the original question of handling a user who has forgotten his/her password.
Maybe there is a network integration solution where passwords from another server (like, ugh, Windows) can be replicated to AIX.
Can you imagine a security philosophy where any given user can gain access to the system without knowing their password? If I forget my ATM PIN, would I want the bank to say "Heck, that's OK... Just key in another one. But, please don't bother us."
This sounds like a management solution is required, not a techical one. Dock the users $5 everytime they forget their password. Or make them buy donuts for the IT staff.
Maybe there is a network integration solution where passwords from another server (like, ugh, Windows) can be replicated to AIX.
Can you imagine a security philosophy where any given user can gain access to the system without knowing their password? If I forget my ATM PIN, would I want the bank to say "Heck, that's OK... Just key in another one. But, please don't bother us."
This sounds like a management solution is required, not a techical one. Dock the users $5 everytime they forget their password. Or make them buy donuts for the IT staff.
You could create a dummy root account and create a menu of user functions then lock the menu using trap. The only downside with this is a user could change another users passwd causing more problems. You could also look at webmin/usermin to provide a web based solution. Other than that if your using $soft look at single sign in or payout to introduce biomentric s see
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
If you setup that dummy root menu so that a newly generated user's password is set in the AIX passwd files AND mailed to that user's mailbox, I could see it work and still have reasonable security.
Of course you would need an email system that is external to AIX but is somehow linked to the AIX system (sendmail smart-relay host, /etc/aliases come to mind...)
Have a look at the C-code I posted in thread52-1048291 on how to overwrite a user's password. I also have a program somewhere to generate a random password. If you want to go this way, I 'm willing to go dig that up and post it also.
HTH,
p5wizard
Of course you would need an email system that is external to AIX but is somehow linked to the AIX system (sendmail smart-relay host, /etc/aliases come to mind...)
Have a look at the C-code I posted in thread52-1048291 on how to overwrite a user's password. I also have a program somewhere to generate a random password. If you want to go this way, I 'm willing to go dig that up and post it also.
HTH,
p5wizard
A util called setpass could be used to change the password
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
You all seem to be missing motoslide's point.
If you create a system in which a user that has forgotten their passwd is able to reset that password without anyone else's intervention, then you've effectively created a system without passwords.
Anyone that knows someone else's login id would be able to reset the password of that person and login as them.
If the users are authenticating themselves at their workstation with a password they can remember, and the workstation is secure, you could use ssh with key authentication to give them secure access to the AIX box without a password at all. Of course the setup, and fixing things if/when they screw up their key(s), will be much more hassle than the 20 seconds to reset a password that you're trying to avoid.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
If you create a system in which a user that has forgotten their passwd is able to reset that password without anyone else's intervention, then you've effectively created a system without passwords.
Anyone that knows someone else's login id would be able to reset the password of that person and login as them.
If the users are authenticating themselves at their workstation with a password they can remember, and the workstation is secure, you could use ssh with key authentication to give them secure access to the AIX box without a password at all. Of course the setup, and fixing things if/when they screw up their key(s), will be much more hassle than the 20 seconds to reset a password that you're trying to avoid.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
hi,
One thing you can have is a superuser for that site , this is a user setup on the server which can run a menu written
by you to reset passwords . This users does not login as root or has root privileges you use the pwdadm command to reset passwords , but in order to change the password they must know the user they login as to change the password ; password first .
So what you do is dedicate a site superuser , where the other users go to to reset passwords / lock /unlock accounts
and don't log calls with the hepdesk.
HTH
One thing you can have is a superuser for that site , this is a user setup on the server which can run a menu written
by you to reset passwords . This users does not login as root or has root privileges you use the pwdadm command to reset passwords , but in order to change the password they must know the user they login as to change the password ; password first .
So what you do is dedicate a site superuser , where the other users go to to reset passwords / lock /unlock accounts
and don't log calls with the hepdesk.
HTH
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
mrn said:
<joking>
Users that can't track their passwords, but will diligently secure their workstations so that no one can request a password reset and intercept the email?
No problem, then. Just put Santa, the Easter Bunny, and the Tooth Fairy on pager rotation for password resets.
</joking>
Self authentication is no authentication at all. How is this process going to know that requests are authentic? True, a helpdesk worker could be socially engineered into resetting a password they shouldn't, but nobody's ever written a script to ask a helpdesk worker to reset everyone's password every five seconds (at least not one that worked
).So now we need a fairly complex app to authenticate password reset requests and avoid a DOS, which means more chance for security vulnerabilities. We can avoid that by using some established single sign-on solution, such as Kerberos. But wouldn't you know it, some people are still going to forget that one password and need somebody to reset.
The best solution is probably to delegate password reset responsibilty to a responsible local party, but that's not freeing up the help desk so much as extending it.
Maybe you should use biometrics. That way you only get password reset request when someone loses a digit or an eye.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
Build a menu for the help desk. Create a "helpdesk" accout and allow the helpdesk user to change passwords via sudo with "sudo passwd $anyuser" using this menu. Require new passwords only be distributed from the helpdesk to the manager of the employee requesting the password change. The employee will then have to get their password from a manager ( that knows their face ).
Don't allow people to reset their own password. If you do I would EXPECT a security breach........
Don't allow people to reset their own password. If you do I would EXPECT a security breach........
The Question we're all missing is how secure does the system have to be? Is it open to the outside? If not why not let the users reset their own password the only person who would get the new password is the account owner themselves. Or like has been suggested before promote a couple of superusers shouldn't be hard to find a couple of people who enjoy their own self importance.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
Mike
"A foolproof method for sculpting an elephant: first, get a huge block of marble, then you chip away everything that doesn't look like an elephant.
- Thread starter
- #17
You all have a good point. We all have to balance security and automated process. Orginally, I was wondering if there is any application that let a user change their own password by answering a screct question that they provided like many online web site do. If you forgot your password it asked you a secret question and the user have to provide a correct answer in order to change their password. Or maybe i'm asking too much here. thanks
RodKnowlton
MIS
- Apr 26, 2000
- 1,005
I like hfaix's idea of sending passwords to managers, and streamlining the process for helpdesk employees. Add a template for logging password resets, or adjust policy so they don't have to be logged, and the helpdesk impact is minimized.
However, even though everyone that's been it this forum a while knows what a fan of sudo I am, I wouldn't use it in this case. The one case where sudo can't be trusted, and it's even noted in the documentation, is the case where you give full access to a command and then try to subtract forms they shouldn't have.
If all of your helpdesk employees have root's password on the machine <shudder>, then the simple sudo that hfaix gave is fine. If they don't, then the much (and rightfully) maligned AIX Roles provides the ManageBasicPasswds role that allows use of the pwdadm command for changing passwords of non-administrative users. It's the only usefull thing I've found in roles so far. My favorite is the backup role than gets root privileges for the backup command, but not for the "find" that savevg uses to decide what it's backing up.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
However, even though everyone that's been it this forum a while knows what a fan of sudo I am, I wouldn't use it in this case. The one case where sudo can't be trusted, and it's even noted in the documentation, is the case where you give full access to a command and then try to subtract forms they shouldn't have.
If all of your helpdesk employees have root's password on the machine <shudder>, then the simple sudo that hfaix gave is fine. If they don't, then the much (and rightfully) maligned AIX Roles provides the ManageBasicPasswds role that allows use of the pwdadm command for changing passwords of non-administrative users. It's the only usefull thing I've found in roles so far. My favorite is the backup role than gets root privileges for the backup command, but not for the "find" that savevg uses to decide what it's backing up.
Rod Knowlton
IBM Certified Advanced Technical Expert pSeries and AIX 5L
CompTIA Linux+
CompTIA Security+
That's a good point Rod. Giving "sudo passwd" probably isn't the safest. I wrote this once with the intent to use it, but decided not too. I know you would want to write some logic to keep the helpdesk from running "sudo passwd root". That wouldn't be good.
This is the perfect place for the ManageBasicPasswds role.
This is the perfect place for the ManageBasicPasswds role.
- Status