Password policies prevent users from sharing their passwords, even for tech support. What are some suggestions/best practices to install and test software without requiring the user to share their password? Setting up Microsoft OneDrive for user to redirect documents, videos, pictures to the cloud or transfer their files to a new computer is one example where technicians have to login as the user. Others include troubleshooting the setup and execution of software with the users profile settings/config.
Solution
- Aug 24, 2012
- 675
- 1
- 20,115
As above, except in those cases where the user isn't available. However, this is really IT 101 stuff here and you should already know this.
1. Change the user's password in AD to something you know.
2. Use that password to log in and do all required work.
3. When finished, change the password to your organization's "first use" password (most that I have worked with use something like 'Password1!') and set for "change password on first use"
4. Turn the PC (Laptop) over to the user and instruct on first login procedures.
5. Move on to the next ticket in the queue.
In the event that a password history is being enforced (Always a best policy), inform the user of that policy and that they will not be able to set the password they were using prior to the repair.
1. Change the user's password in AD to something you know.
2. Use that password to log in and do all required work.
3. When finished, change the password to your organization's "first use" password (most that I have worked with use something like 'Password1!') and set for "change password on first use"
4. Turn the PC (Laptop) over to the user and instruct on first login procedures.
5. Move on to the next ticket in the queue.
In the event that a password history is being enforced (Always a best policy), inform the user of that policy and that they will not be able to set the password they were using prior to the repair.
- Mar 16, 2013
- 7,410
- 96
- 40,190
You're asking two different questions here:
1. How to test software installations and deployments
and
2. How to assist a user with some issue
As a general rule, IT, or anyone else, should never, ever know a users password. Ever.
Consider this scenario:
User Joe. A bit disgruntled. He logs in and trashes the main inventory database. Costing twns of thousands of dollars.
Investigation shows that the 'Joe' account logged on and trashed the db.
All Joe's lawyer has to do is to point at the IT dept and say "Well...they know his password as well. Prove it was Joe."
Charges dropped.
For the above scenarios
1. Testing and deployments - the IT dept should have a small 'test network'. Just has to be a couple of machines.
Test and deploy on that, to see how things work.
You should never, ever use the users systems to test your deployments.
To actually deploy? AD and GPO.
Or log in remotely, as an admin account.
2. User assistance and troubleshooting - Go to their desk and watch them make the thing not work. Or set up some sort of screensharing deal.
1. How to test software installations and deployments
and
2. How to assist a user with some issue
As a general rule, IT, or anyone else, should never, ever know a users password. Ever.
Consider this scenario:
User Joe. A bit disgruntled. He logs in and trashes the main inventory database. Costing twns of thousands of dollars.
Investigation shows that the 'Joe' account logged on and trashed the db.
All Joe's lawyer has to do is to point at the IT dept and say "Well...they know his password as well. Prove it was Joe."
Charges dropped.
For the above scenarios
1. Testing and deployments - the IT dept should have a small 'test network'. Just has to be a couple of machines.
Test and deploy on that, to see how things work.
You should never, ever use the users systems to test your deployments.
To actually deploy? AD and GPO.
Or log in remotely, as an admin account.
2. User assistance and troubleshooting - Go to their desk and watch them make the thing not work. Or set up some sort of screensharing deal.
Facebook
Twitter