Logon as different user, without needing a password?

[twhite68]

As a Windows Administrator, I often need to logon to various desktops
as the user who I am helping. For various reasons, it would be
_very_helpful_ if I could logon as that user, but without needing their
password. For one thing, the user feels compelled to change their
password after I help them. Also, I don't always have access to the
user at the time I'm trying to help them.

I know of various RunAs or SU tools (like RunAs, RunAsEx and Superior
SU to name just a few) but all of them seem to require a password, even
though I'm in the "Domain Admins" group.

Does anyone know of a tool with the capabilities I describe above?


Tony

 

[Carey Frisch [MVP]]

No, you need the User's password.

--
Carey Frisch
Microsoft MVP
Windows XP - Shell/User
Microsoft Newsgroups

Get Windows XP Service Pack 2 with Advanced Security Technologies:
http://www.microsoft.com/athome/security/protect/windowsxp/choose.mspx

-------------------------------------------------------------------------------------------

"twhite"wrote:

| As a Windows Administrator, I often need to logon to various desktops
| as the user who I am helping. For various reasons, it would be
| _very_helpful_ if I could logon as that user, but without needing their
| password. For one thing, the user feels compelled to change their
| password after I help them. Also, I don't always have access to the
| user at the time I'm trying to help them.
|
| I know of various RunAs or SU tools (like RunAs, RunAsEx and Superior
| SU to name just a few) but all of them seem to require a password, even
| though I'm in the "Domain Admins" group.
|
| Does anyone know of a tool with the capabilities I describe above?
|
|
| Tony

 

[twhite68]

Thanks for the quick reply. I'm pretty sure that what I'm looking for
is possible, but it may not be implemented anywhere. See
http://www.codeproject.com/system/RunUser.asp by Zhefu Zhang. His
article describes a tool for developers called RunAsEx (but not, I
think the RunAsEx that most people are familiar with) which uses an
undocumented API call named ZwCreateToken which does _not_ require a
password to create a token using another user's account.

In any case, even if this is not possible, do you know of any security
concious way to do what I want? The accepted way of doing things at
the company I now work at is to use a password template so that you can
figure out what a user's password is. I have a pretty dim view on this
practice. However, I have nothing better to offer right now.

 

[Henners]

change thier password to something else with your tools, or even the net
user command, and then get them to change back later.

That way they dont worry about you knowing their pattern or something.

-Henry

 

[Guest]

It's not recommended to login as a particular user due to the security
thinking. If you login as that user, the system will not recognize whether it
the user itself or a remote admin who did the operations on that machine. If
some security issues happened such as data loss or file deleted, etc., who
should take the responsibility?
As a professional admin, you must alwasys keep security in mind. It must be
the top-priority when you do the administration, not the convenience.

The normal way is to add Domain Admin group into the local admin group, then
you can remote manage the client with the admin privilege. You can do that
when you are building a client OS. Another way is to have a NetMeeting with
user so that both of you can see the operations clearly.

The purpose of RunAs command is to give you a chance to run command with
another user privilege. Just like SU in Linux, it will definately prompt for
password.

 

[twhite68]

Yes, thanks -- I understand and agree with all you just said. However,
my circumstances are that my users are not always available, so a
NetMeeting is not always possible. I already have no problems logging
in as admin if necessary or using RunAs as a non-privileged user to
increase my privileges, etc. My problem is not gaining increased
privileges... it's more seeing what the users see in a particular
situation. Sometimes you don't see the problem the user sees unless
you logon as the user.

As for the responsibility issue... well -- I _am_ the Admin and I do
have responsibility to help the users. If I screw something up, it's
my fault and I take responsibility. I'm not particularly worried about
that, since messing up one user's files or something is trivial
compared the damage I could cause in other areas. In other words, I
always try to be careful in any case.

As for SU on *nix... I thought you _could_ avoid supplying the password
for su'ing to a non-privileged user, provided you are root or in the
wheel group. Is that not correct?

Thanks again,

Tony