Domain – prepare a domain user account without the user’s password

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.

As Bernie White mentioned, this is probably due to differences in kerberos configuration. KerbTray will work on WinXP, klist is built in on W7 and above.

Barring that, if the problem you are trying to solve is being able to the SQL servier using windows authentication, you can do so by running, runas /netonly /user:DOMAIN\Administrator application.exe.

The other method I use is to have the user dial-in via VPN, even if they are sitting on the internal network. Doing so causes the network credential to be used for all open applications and has the benefit of allowing SSO for Outlook, SQL Server, LDAP and any other application they can access.