Would IT ever need a user's domain password?

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?

UPDATE:

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.

Solution 1:

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.

Solution 2:

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.

Solution 3:

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.

Solution 4:

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.

Solution 5:

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)