locked
UAC swallows processes! RRS feed

  • Question

  •  

    I had, for XP/2000, built a service, running under LocalSystem, that would create, upon detecting (with the help of a GINA) that a user logged-on at the console, a second log-on session that would "shadow" this user; this second log-on session would model, in most every way (profile, environment-block, etc.), the console log-on session, with one very important addition -- admininstrative rights!  I employed a strategy of tweaking the DACL of the console's (Terminal-Services-session-0's) interactive-window-station and its default-desktop.  This worked beautifully!

     

    I, now, must enable this same functionality -- empowering the user's log-on session with administrative rights -- for Vista, maintaining UAC on.  The prior strategy -- tweaking the DACL of the console's window-station and desktop -- no longer works, as Vista has forced user-processes out of TS-session-0 and as I know of no way to get a handle to a window-station of a foreign TS-session.  I have, in the meantime, read something about SetTokenInformation and how I might be able to employ it to set, to 1 (for instance), the TS-session-ID of the token of the second, shadow log-on session.  I, in fact, tried it, and it works, but only partially.

     

    With UAC off, the processes get spawned, are visible, and run to completion (great!).  With UAC on, however, the processes, seemingly launched (from the service, using CreateProcessAsUser, supplying the token of the shadow log-on session) successfully (no errors returned), never show up; they seem to be swallowed whole!  They do not register in Process Explorer and show no visible trace to the user.  They do leave one tiny trace -- they get kernel-time (a quick exit after entry), but no user-time, in Process Monitor, another free tool built by SysInternals.

     

    Can anybody shed some light on this?  What's happening here?  Why are they being swallowed?

     

    Is SetTokenInformation the wrong approach?  If not, must I duplicate the token? Must I impersonate the shadow log-on session, before calling SetTokenInformation to change the session-id?

     

    For the record, my sequence of calls, from the service, goes more or less like this:

     

    1) LsaLogonUser, returning a token modeling the user logged-on at the console, with adminstrative rights added

    2) WTSGetActiveConsoleSessionId

    3) SetTokenInformation(..., TokenSessionId, 'session-id returned from step 2', ...)

    4) LoadUserProfile

    5) CreateEnvironmentBlock

    6) CreateProcessAsUser

     

    What am I missing?

     

    Thanks,

    Erik S.

    Wednesday, November 7, 2007 2:56 PM