Is there anything a Windows domain administrator might need to do while configuring a workstation for a new user that absolutely can't be done without the user's domain account password? To avoid asking users for their passwords the admin could, theoretically, change the password, log in as the user, and do whatever it is they wanted to do, but would that actually give them any additional permissions that they don't already have by virtue of being a domain administrator?


The answers so far have referred to "tuning" or changing the user's profile. However, there's this article from Microsoft on modifying the default profile which gets applied to users when they log on for the first time and these instructions for changing another user's Windows registry settings at any time. What would an admin change while logged in as a user that the admin couldn't change using these or other available techniques that don't involving logging in as the user? Just "logging in as the user" isn't a reason to ask for or change the user's password. I'm looking for a practical reason for doing so.

  • 2
    My suspicion before asking this question was that, twisted though Windows administration may be at times, there was nothing that would be impossible for an admin that would be possible for a less-privileged end user. The motivator for asking for a user's password, or changing their password, and logging in with their account would be inexperience or convenience; either the admin doesn't know how to do something or doesn't want to fiddle with registries and editing configuration files by hand and doesn't have tools available to make the required changes. – Isaac Truett May 24 '11 at 0:11
  • 1
    You might want to rewrite this question as at first you ask about user passswords then you change to to logging in as the user at all. These are 2 seperate issues – Jim B May 24 '11 at 0:21
  • How about installing an application that requires access to the user's Outlook profile (like a CRM app that uses Outlook)? You're at the mercy of the application developer's installer script. – gravyface May 24 '11 at 0:21
  • @Jim Actually, I tried to head off the password reset avenue in the second sentence of my original question. If you reset a user's password, then you DO now have that user's password. You don't have their OLD password. I was getting vague answers about changing a user's profile, so I provided links showing how you could do that without impersonating the user. I also specifically called out "logging in as the user" as not being an acceptable end goal because that was mentioned in a comment as something you couldn't do without requesting/changing the user's password. – Isaac Truett May 24 '11 at 0:28
  • @gravyface So your answer is "to install poorly written software?" Interesting. Care to post it as an answer? – Isaac Truett May 24 '11 at 0:33

It is neither acceptable nor necessary for an administrator to request a user's password.

Under the circumstances where it may be necessary for an administrator to log in as a user (and I don't believe that such circumstances exist), the user should log in and supervise the administrator's activities.

The reason for this is accountability. It is the responsibility of each user to ensure that their password is secure. If malicious activity were traced back to a user's credentials, that user could be held accountable. Therefore they need to ensure that their credentials remain secure.

It is also the responsibility of the organisation to ensure that this is not only adopted, but enforced. There was a legal case where somebody in an organisation sent a malicious email using somebody else's mailbox. The owner of the mailbox was ultimately dismissed. While they argued that they had given their password to someone else, the company insisted that it was their responsibility to maintain the integrity of their credentials, and they were therefore accountable, as was dictated by their company IT policy. This was then overturned by a court when this user proved that there was a culture of password sharing endemic within the organisation. The court ruled that if the company could not be seen to actively enforce their IT policy, they could not rely on it for accountability under these circumstances.

That said there is clearly a gulf between theory and practice. I've contracted for a major multi-national firm that provides, amongst other things, IT advisory services, and as part of the documented procedure for an SOE upgrade we were instructed to request the end user's password.

Personally, I take a hard line approach to this. I don't believe that requesting passwords (or re-setting them to access a user's account) is necessary. If there is a vastly increased workload to get around this, then so be it. It's no excuse to compromise security. I guess I'm just fortunate that I'm not a manager, and so don't have to take responsibility for these decisions when instructed to do so by someone higher up.

  • 5
    Are you seriously suggesting that you know what is acceptable or necessary in every conceivable situation on the planet? – John Gardeniers May 24 '11 at 3:55
  • 3
    Of course not - if somebody can give me an example to the contrary I'll happily accept it. I'm not talking about every conceivable situation on the planet, but with that said I cannot possibly conceive of any goal which is only achievable by compromising a user's login credentials. – Matt May 24 '11 at 4:26
  • 2
    You say "of course not", which completely invalidates the first sentence of your answer. I suggest you edit it accordingly. – John Gardeniers May 24 '11 at 4:30
  • 7
    Perhaps I wasn't clear. I'm taking a scientific approach. Just because the sun has risen every day for the past five billion years does not mean I can say with absolute certainty that it will rise tomorrow. But if you ask me, "will the sun rise tomorrow?", I will say yes without feeling the need to further qualify that. So I take your question regarding "every conceivable situation on the planet" to be an equally hypothetical and abstract qualification. – Matt May 24 '11 at 4:44
  • 4
    off the to of my head new user setup comes to mind - and your mind obviously is stuck here. New user = "No user has the password", so IT sets up the user, then gives the user the password (who changes immediately). They never ask the user because - ah the user at this point does not know the password. – TomTom May 31 '12 at 11:22

Let's be clear: if you're a Domain Admin, you can install a piece of software–a device driver comes to mind–that can literally do anything. However, it's varying degrees of impractical, ranging from "What's the registry key for the desktop background, again?" all the way up to "And then we hook onto the file read call inside the encrypted-profile layer so as to spoof Firefox into thinking that they have disabled cookies from doubleclick.net".

You're asking for an absolute, and I think that's the wrong way to look at this, because the answer's going to be "You never need the user's password, really," which is very misleading. The reality is that until Microsoft delivers (or you install third-party software to allow) a capability like *NIX's su/sudo, you'll never be able to perfectly imitate a user's account for all purposes while maintaining a semblance of sanity, without requiring occasional usage–note I didn't say "disclosure!"–of their password.

  • A very fair point. One point I was making in my own summarily deleted answer was that there appears to be a lack of tool support in this area. – Isaac Truett May 24 '11 at 1:40
  • on the point of sudo as far as that goes, the windows security model precludes the use of a sudo type utility, as it means you could run applications in the context of another user without authenticating as that user first (there are ways around it but they all make effort to go around the security model). – Jim B May 24 '11 at 2:33
  • 1
    +1 - This answer nicely covers the realities, as well as the theory. – John Gardeniers May 24 '11 at 23:48

Many of us have worked in environments where password disclosure was required for various reasons. I'll even go so far as to say all of us consider it a bad idea. If such needs to be done, the end user needs to consent to it, not be coerced.

Back in the day, like 1998, my IT department used to request a user's password when we were doing a PC replacement so we could get it set up exactly like they had their old one. Down to the icon locations. As we were in a Novell NetWare environment with no corresponding WinNT domain, changing their network password didn't change their local password so we needed to have that password if we wanted to deliver that level of seamless service.

That was 13 years ago. You specifically asked about Windows Domains. At the job I just left, a large University, it was up to the end user whether or not to disclose a password or be there for whatever work was being done. In other words, the end-user opted in to it rather than forced by IT. Certain very busy executive-types high up the org-chart generally had their admin assistant log in for them so it was easy for IT people to slip in (consent had already been delegated).

In Windows, the only way to hand tune a user's Profile is to log in as that user. If that profile needs hand-tuning for some reason (a bad uninstall left remains that are getting in the way of a reinstall, or other weird stuff), the IT person will need to log in as that user. This can be done by forcing an administrative password change, having the user disclose their password, or having the user log the IT person in as themselves and letting the IT person work.

  • What sort of profile tuning could you do as the user that you couldn't do by modifying the default profile as described here before the user logs in? – Isaac Truett May 23 '11 at 23:22
  • For the most part, no, there are still things that need to be configured for that specific user. For example, before Outlook 2007/Exchange 2007, you had to configure Outlook manually for that user. Now with autodiscover, you could possibly consider letting them try it themselves, but still, most administrators would not as users just want it to start when they log in. – KCotreau May 23 '11 at 23:30
  • @KContreau Microsoft says here that Outlook profiles are stored in the registry, which an admin can edit from their own account. Any other ideas? – Isaac Truett May 23 '11 at 23:42
  • 4
    @IsaacTruett Technically everything can be done directly through regedit or hand-editing those desktop.ini files. However, a lot of IT people are far more comfortable with UI tools. As a short-cut, ill-advised though it may be, the IT person may ask a user to do any of the three things I mentioned (login for them, go through a password reset, or give the password) and use the tools they know well, the GUI. – sysadmin1138 May 23 '11 at 23:59
  • 2
    @KCotreau @Isaac Technically you could copy their registry hive to the admin's profile temporarily, use whatever's necessary to edit it, then put it back. This is Not a Good Idea™ in 99% of cases. I know of very few circumstances where knowing the users password is necessary these days; and all of them are related to dumb conveniences (like the Netware example SysAdmin1138 gave). – Chris S May 24 '11 at 1:52

Some applications during installation require the ability to make changes or reference the user's profile (i.e. CRM applications that integrate with Outlook) by use of environmental variables like %userprofile%, modifying HK_CURRENT_USER, and the like.

While you could certainly "reverse engineer" an installation with tools like procmon and then manually modify the user's profile, registry, etc. after the fact, this is highly inefficient, impractical, and error prone.

  • 1
    +1. I could definitely seeing this being a factor. As a software engineer, I would argue that there are better ways to write installation processes than to require the end user to be logged in during installation. There are, in fact, existing software products that allow for different single-user and multi-user installation processes, such as Google Chrome. – Isaac Truett May 24 '11 at 1:15
  • @Isaac, I believe you have overlooked the fundamental principle of per user configuration, which cannot be taken care of by the installer. Take for example a package that's going to be used by multiple users on a given machine, where each user needs/wants/requires a different configuration and they need to be in place before those users start using the package. – John Gardeniers May 24 '11 at 2:33
  • @John/Isaac: I'm assuming, John, you're speaking of completing this customization on behalf of the user? If so, yes, another good point for why you'd want or need to login as the user, especially if the configuration is not modifiable outside of the application (stored in a binary format) and is bound to the currently logged in user. – gravyface May 24 '11 at 2:36
  • that is correct. Resetting the user's password in such a situation merely causes problems, as well as interferes with their ability to do whatever they are currently doing on another machine. – John Gardeniers May 24 '11 at 2:42

Absolutely 100% not. Anything that needs to be done with another users account should be done by resetting the users password, logging in, and then either having the user call the helpdesk or restting the password to something uthe users is told and setting the account to force password to change on next login. While admit I've worked in fairly large and or secure environments disclosing your password to anyone was usually grounds for termination (and that should be the case in most situations)

  • 1
    That's too broad a statement. There are many environments where that just won't work. I'd go for maybe 98% but certainly not 100%. – John Gardeniers May 23 '11 at 23:43
  • 1
    @John Can you offer a specific example of something that is impossible to do without being logged in as the end user? – Isaac Truett May 23 '11 at 23:46
  • 1
    @Isaac: there are many applications that, during installation, reference %userprofile% for file placement, perhaps make changes like installing toolbars in Word or Outlook, etc. Sure, you could sit there with procmon running, diligently record every registry, profile, etc. change, but why on earth would you bother? – gravyface May 24 '11 at 0:18
  • @john, can you give me an example of where it would be impossible to reset the users password as explained? I'd agree that there are places where users are too complacent or admins too lazy, but I've yet to encounter a place where that simply could not work. – Jim B May 24 '11 at 0:19
  • 1
    @Jim, where I work we frequently need to log on as others and resetting passwords simply pisses people off without good cause. We have an environment where passwords (for most users) are not secret within the company. I know that goes against the grain for anyone who works in larger companies and it was a real culture shock for me when I started here. It's a management choice, not mine, and that's that. – John Gardeniers May 24 '11 at 2:29

Most of these posts seem quite old, but hopefully some knowledgeable folks are still active on the thread, since this would seem to continue to be a current topic.

Arguments certainly can be made that you shouldn't ever have to request a password. I'd much prefer to tell my users "don't ever share"... and yes, configuration can in most cases be handled by an administrator for a user. But troubleshooting is another affair.

We support a one-to-one program with 2600 students and 500 employees. We address "weird" software problems on a daily basis. It is quite often the case that we must experience the problem as the user in order to resolve the issue (or determine with some confidence that a reload is going to be needed). Absolutely, we try to do this with the user present - but that isn't always practical; they have a schedule to maintain.

What about smartcards? Is there any feasibility in a 2010/2012 AD Environment that a smartcard could be associated (temporarily) with a domain account? This would permit access to the user's account in full reality, while not exposing their password specifically. The card could then be deactivated when the troubleshooting was complete. Technicians could utilize the account, but the cards could be well supervised.

We've used fingerprint readers for years, but the process for setting that up for a specific tech, then clearing that print simply isn't feasible. I'm not sure how complex the process would be to "authorize" and then "deactivate" a smart card for a particular user would be, but it seems like it could be a decent compromise.

  • StackExchange operates on a different model than traditional forums in that this is not a discussion thread but rather a question followed by a selection of potential answers. On the downside this is also a poor example of a question per our FAQ. – Scott Pack Oct 10 '13 at 13:25

Yes: Anything that needs to be done to their profile. When that happens, you either must know their password, or set it, as you said. Then they can change it when you are done.

If you log in as that user, you are not giving them additional permissions. You are logging in as them with their permissions.

  • beat me to it. Was thinking of applications that integrate with Outlook especially. – gravyface May 23 '11 at 23:11
  • Yes, obviously you aren't giving the user extra permissions. The question is, what could an admin do with an individual user's permissions that they, the admin, couldn't do with their own admin permissions? So, what would an admin do to a user's profile that they couldn't do from their own admin account? – Isaac Truett May 23 '11 at 23:13
  • The answer to your question what can't the admin do: Simply log in as that user. When that user logs in, only then can changes be made to the profile that is associated with that user. When you log in as administrator, you log in with your administrator profile. – KCotreau May 23 '11 at 23:25
  • I thought I misread the question but no you do not need the users password to do anything to the profile. – Jim B May 23 '11 at 23:34

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