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.