1

Many systems (such as Linux's su or Meditech's emulate) allow an admin to dynamically emulate another user.

I am new to a Windows server/domain environment, how can an administrator emulate another (Active Directory) user? For example, I would want to login a Windows XP machine/server (under the domain) as another user (that is not mine, via emulation). Let's assume I have administration rights.

I understand there's a "Run As..." but it's not the same as you still need the password. I'm just looking to emulate the environment so I can reproduce user issues without the user being present. I know there are things like copying the users profile folder, but doesn't grab everything (registry etc) and is somewhat a hackish approach.

2
  • Basically, you can't. Related reading over here. serverfault.com/questions/330891/…
    – Nic
    Apr 22, 2013 at 15:19
  • Your best bet here is a remote session like Teamviewer or similar with the user. Even changing their domain password and logging into your PC is unlikely to garner the same results since the profile will be fresh on your PC without the same software/changes/etc.
    – TheCleaner
    Apr 22, 2013 at 15:23

3 Answers 3

1

Cannot be done. Even if you could, it would be highly improbable to accurately reproduce the user's issues without them being present to show you exactly what their doing. RunAs is the closest thing, but if you want to troubleshoot user issues it's a multi-step process that I recommend:

1)Keep a workstation configured the same way a user's machine is configured, and 2)Log in with a local non-privileged account. Once that's done, 3) Try to reproduce the issue. This will help you narrow down the problem to either an issue with the user's computer, account, or the environment respectively. I know I'm telling you things you probably already know but I felt like my first paragraph wouldn't have made a complete answer by itself.

If you want to grab a user's profile from a machine, there is Microsoft's USMT tool here, which was made for transferring a user's files and settings from one machine to the next.

0

The closest you can get under Windows is to create a test user with the same group memberships. If you need to debug something with their profile, the accepted process is to do this via Remote Assistance or similar tool, which allows the user to keep an eye on what you're doing.

It's about audit trails. Windows account information is often used in creating logs and audit trails, and for this reason when using Active Directory it is entirely inappropriate for an admin to log in as a user. You want the admin's name rather than the user's attached to anything done, even while debugging an issue.

A big part of the reason for this is to protect users from administrators. When I issue an account to a user, as an administrator I can still do a lot of things, but the one thing I cannot do is sign that user's name to something. I can even take over a user's account; it's just that to do it, I must change their password first.

This is a good thing! It helps protect end users from rogue admins. If an admin takes over a user account for bad things, that user's name will still end up on any logs. But the user will know, because they won't have access to the account any more. Admins are never privy to user passwords, and so the admin will be unable to silently restore the account to the user. This gives the user a chance to log a complaint and defend against the admin's actions.

At least, that's idea. As a practical matter, if I were really that underhanded and I wanted someone else's name on something, I could probably craft a script to accomplish the deed and assign it to user as a login script or similar. Additionally, I suspect most admins could talk themselves out of a password reset case before the user knew what had happened... or even leave it up to a level 1 help desk tech. So nothing is perfect. But at least in that latter case a record of the reset would exist somewhere as well.

0

There is a real need for domain admins or the like to emulate users, but you can't do it right now.

An example would be an instance where a user was not present when the admin/tech was available to assist. If the admin could emulate the user (log into the user account without changing the password) and fix whatever issue, there is nothing to indicate that an audit trail could not still occur, indicating that the users account had been emulated by whatever admin. Given that admins essentially have full control over all users accounts, there is no reason to exclude emulation as a solution.

Like all good tools, emulation would also get abused by attackers who believe they can utilize it in order to compromise Windows. Perhaps to combat this, emulation could be enabled or disabled via group policy for the sys admins that would opt to use it. Or perhaps this could be joined into the users account in AD in such a way that it could be toggled on and off with a check mark just as it's possible to enable or disable an account in said fashion.

I have sent feedback to Microsoft regarding this potential feature. I hope to see it get implemented.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .