Re: Administrator elevation via RPC fails on Vista, why?

Hi Skywing,

Skywing wrote:

IIRC, any privileges that are in the token but not enabled get stripped away
across impersonation boundaries, so - you might try turning on all
privileges present before the security context is captured by impersonating,
transmitting the "real" privilege state with an RPC message or whatnot, then
restoring the original privilege state on the impersonating end when you get
the appropriate message.

(Note that I don't really know if this will do what you need to do in
Vista -- however I have succcessfully used techniques similar to this to get
the "important" parts of the token saved across an impersonation boundary in
<=Windows Server 2003. So it's probably worth a shot, at least.)


I am aware of the fact that those privileges that the client process has
not explicitely enabled before making the RPC are stripped from the
token that the impersonator gets. Actually, my test client tries to
enable all poossible privileges. However, privileges are not the primary
problem with admin elevation on Vista. The restricted token of a
non-elevated administrator manifests itself first and foremost in the
group sid of builtin\administrators being SE_GROUP_USE_FOR_DENY_ONLY (it
is SE_GROUP_OWNER in a full token) and two new SIDs of type label
(which apparently is not yet documented). These two label SIDs can
successfully be elevated to the values in a full admin token using
SetTokenInformation(..., TokenIntegrityLevel...) and (obviously)
well-known SID using the approach outlined here:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/IETechCol/dnwebgen/ProtectedMode.asp

but the group SID for builtin\administrators with
SE_GROUP_USE_FOR_DENY_ONLY cannot be replaced because
SetTokenInformation(..., TokenGroups, ) won't succeed (if that would
work, any service running as LocalSystem could masquerade as any user).

Anyway, thanks for helping.

--
Stefan
.

Relevant Pages

  • Re: CreateProcessAsUser "loses" privileges, why?
    ... impersonation that happens via SSPI does not strip privilegs (since it ... while impersonation that happens by the kernel trusting itself, ... (since it does not require authentication). ... The rationale being that across a network authentication hop privileges may ...
    (microsoft.public.win32.programmer.kernel)
  • Re: CreateProcessAsUser "loses" privileges, why?
    ... It seems like the process started via CPAU has only ... privileges are non-existent in the token of this process. ... conversation the PID of the client process to the server. ... the token from impersonation as before, ...
    (microsoft.public.win32.programmer.kernel)
  • Re: Logging, Login API and SSPI
    ... the log files would be created/written under his credentials. ... but the problem is that login API and SSPI can require ... work properly (The impersonation level does not allow resource access). ... SSPI doesn't require elevated privileges. ...
    (microsoft.public.win32.programmer.kernel)
  • Re: CreateProcessAsUser "loses" privileges, why?
    ... You can google for "non enabled privileges are stripped" in the `groups` ... > conversation the PID of the client process to the server. ... > the token from impersonation as before, ... > with the access token that I got from opening the process token via PID. ...
    (microsoft.public.win32.programmer.kernel)