0

I have a tool written in C# which performs impersonation of users to perform administrative tasks on remote machines.

I have found that using LOGON32_LOGON_NEW_CREDENTIALS with LOGON32_PROVIDER_DEFAULT defeats UAC when impersonating the built-in administrator account of the remote machine, or when impersonating a domain user who is in the administrators group. However, when a non built-in local user is impersonated (local to the remote machine), a non-elevated token is returned. Creating a user with the same credentials on both machines does not alleviate the problem.

This table shows success in acquiring an elevated token for use on the remote computer:

graph showing working scenarios http://img521.imageshack.us/img521/3605/fo69.png

All users are in the Administrators group.

Is there a know solution to this problem that does not involve turning off UAC or doing anything drastic on the target computer? The remote computer is customer controlled and no modifications can be made. It is assumed UAC is and should be running on both ends.

As a point of interest but not to detract from the above question, the exact same behaviour is found when using remote WMI.

Robin
  • 698
  • 6
  • 25
  • On the remote machine, what is the setting: 'Local Computer Policy\Windows Settings\Security Settings\Local Policies\Security Options\User Account Control: Admin Approval Mode for the built-in Administrator account' set to? (gpedit.msc) 'Disabled' is the default setting and is likely the explanation for the behavior you see. – Bill_Stewart Jun 21 '13 at 18:08
  • Both local and remote machine is under future customers' control - no policy modification possible local or remote (this tool is part of an installer than installs to remote servers from an admin's workstation). – Robin Jan 04 '14 at 21:13

1 Answers1

0

This might be because the remote server has UAC enabled. This means that when you connect to the remote machine, even though you are an administrator, you are stripped of those powers when you operate on the remote machine.

There is a Group Policy option that controls this:

LocalAccountTokenFilterPolicy

Edit: Fixed the link to the proper KB article "Description of User Account Control and remote restrictions in Windows Vista":

As to why does it only apply to local admins, and not domain admins? Because that's what the option does - it only limits "members of the local administrator's group":

A user who has a domain user account logs on remotely to a Windows Vista computer ..., the domain user will run with a full administrator access token on the remote computer, and UAC will not be in effect.

vs

When a user who is a member of the local administrators group on the target remote computer establishes a remote administrative connection ..., they will not connect as a full administrator.

The policy treats domain admin accounts differently from local admin accounts. That's why it's different.

Try disabling the group policy and see if it fixes it. It seems to describe your case exactly. Try disabling the group policy option on the remote machine

To disable UAC remote restrictions, follow these steps:

  1. Click Start, click Run, type regedit, and then press ENTER.
  2. Locate and then click the following registry subkey:
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
  3. If the LocalAccountTokenFilterPolicy registry entry does not exist, follow these steps:

    a. On the Edit menu, point to New, and then click DWORD Value.
    b. Type LocalAccountTokenFilterPolicy, and then press ENTER.

  4. Right-click LocalAccountTokenFilterPolicy, and then click Modify.

  5. In the Value data box, type 1, and then click OK.
  6. Exit Registry Editor.
Ian Boyd
  • 246,734
  • 253
  • 869
  • 1,219
  • That's not the case for the domain user or built-in admin, why should it be the case for a built-in user? It's odd. Also, UAC is surely designed to protect against applications that don't have your password - if you provide an app with valid admin credentials that's a larger level of trust that UAC elevation itself so I'd hope it could elevate programmatically at that point. – Robin Jan 02 '14 at 10:35
  • *"why should it be the case for a built-in user?"* That's mostly what the policy does. It doesn't affect domain admins, only local admins. And might not affect local Administrator account. – Ian Boyd Jan 02 '14 at 15:55