Our office uses a Windows Domain with Active Directory to manage user access to machines and network resources. The IT staff maintains a record of everyone user's password, which is used mainly for troubleshooting. E.g. sometimes problems appear only when logged in as a "regular" user, not an admin. Also, this lets IT admins configure software for local users, check settings, etc.

Is it considered bad practice to keep this list of passwords? In theory, only administrators have access to it. Is there some way to use admin credentials to log in as a local user, which would obviate the need to store the user's password?

(A little background: the office has about 30 users, with 2 IT admins. Some users have remote access via VPN.)

  • 3
    Is it considered bad practice to keep this list of passwords? -- Yes
    – GregD
    Oct 17 '11 at 17:42

This is considered bad practice, both for password-security, as well as identity management. Having a clear-text password list available anywhere is something that just should not be done, or if it is done at all it needs to be kept offline and with rigid (and auditable) access controls in place. The identity management violation is that such password lists allow users with access to the password list to impersonate anyone on that list without that person's knowledge.

It has been Microsoft's policy that if such local-profile access is required, that technical staff requiring access either:

  • Be logged in by the user themselves.
  • Have the technical staff reset the user's password.

In both cases, the user is aware that their electronic identity is being impersonated by someone who isn't them. Yes, this can lead to "unneeded" password resets as work is done on the local profile to identify problems, but the password policy in place needs to accommodate such actions. Is this an inconvenience to both technical and non-technical staff? Yes it is.

Consider this though. Should one of your users get caught with something They Should Not Have on their workstation, the kind of thing that can lead to firing or criminal prosecution, having such a password list makes it impossible to prove that they and only they put such data there. This will become a very important point if it ever ends up in court (either wrongful-termination, or defending the criminal charge). It's for your own protection that passwords need to be confidential even from the system's administrators.

  • The legal ramifications argument is interesting, and not something I had really thought about.
    – Hank
    Oct 18 '11 at 14:39
  • @HenryJackson The first thing a user will say after Bad Things (tm) are found on their machine is, "It wasn't me, someone else put it there." I've seen this happen multiple times. This is why you really want a 1:1 relationship between username-password pairs and people who know them.
    – sysadmin1138
    Oct 18 '11 at 16:42

VERY bad practice. Nowadays you should NEVER record a users password in my opinion. If you want to troubleshoot issues relating to non-admin permissions, set up a dummy account in your Active Directory. If the issue then turns out to be related to a single account then you visit the user and work through it with them, or take remote control of their session with their agreement, once they've already logged in.

I would never keep a list of anyone's password, it's just asking for trouble and if any of your employees do something stupid/malicious, it gives them a perfect get out clause and they can just say their password must have been stolen from you and not related to anything they might have done.


Why do you need to logon as a user? You can always create a test user in AD and put the test user into the same groups as the person that you need to test.

The answer to your first question, "Is it considered bad practice to keep this list of passwords?" is resounding YES from me.

  • The IT admins like to log in as a user to configure software, check settings, etc. This can't always be done from the admin account. Some programs store settings per-user, and so they must be configured by that user.
    – Hank
    Oct 17 '11 at 17:46
  • 4
    Well "liking" to do something isn't a generally acceptable best practice as far as I'm concerned. And in an environment with only 30 people, any reason the admins can't look over the shoulder of end users once in a while?
    – GregD
    Oct 17 '11 at 17:50

Very old question but I want to leave my opinion here.

I work as system and network administrator (and security adviser too) on a government institution with 600+ computers in 7 buildings.

There is a lot of government (very old code) software that is installed ONLY to the specific user. So when I need to troubleshoot something I need to log in to remote desktop using that specific user. Due to this old software policy (and security), this program can be installed just 1 Time, in one PC.

Sometimes people take vacation.

So, being admin, logging-in as someone else is not that "bad", all those "legal thing" concerns are over-reactions.

It's the same thing as an Admin resetting a user's password & impersonating them, as log in as that user being admin. Using that legal "thing" you change your user password, do illegal things and then claim that the admin changed the password?, no fundamentals.

Actually I'm using radmin or vnc witch need to be installed by hand on each PC.

But guys, may be you don't lived it, but there is a lot of scenarios when you need to log in as specific user, and no a dummy one, need to be the exact user. And resetting the password is not even an option some time (local file encrypted... for example).

Anyway, the actual solution that I use is remote software like vnc or radmin (may be applied via GPO or pushed remotely) or resting the password.

  • If there's software bound to a specific user & computer, one tactic is to setup a server & dedicated accounts for such software. Access to the server (and the accounts) can be managed through normal ACLs (eg: AD group membership or sudo rights). What you are doing would strike some as irresponsible or an outright violation of several security standards that, as a gov't entity, you may be personally liable for (depending on if you "inherited" such an abysmal configuration, or actual designed it yourself).
    – Signal15
    Jan 22 '15 at 17:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.