Find interactive user name / token (again) problems
in [Win32 Kernel]
|
Prev: How to Hook ZwReadVirtualMemory and ZwWriteVirtualMemory
Next: Vista Magnification API: MagSetImageScalingCallback() doesn't work?
From: jim clark on 23 Apr 2008 11:49 This question looks like it has been asked many times before - I think I have a new version.... I've been writing a service that needs to enumerate and ultimately impersonate the interactive user(s). I'm using LsaEnumerateLogonSessions to do this because I need to support systems where the TermService (WTS) is not running (including Windows 2000 professional) this means I cannot use WTSEnumerateSessions. However, LSA allows multiple users to logon with the Interactive flag - what is the best way to find the *real* interactive user (if any)? I've looked at the following (commonly used) methods: 1. WinLogon notification package - Discounted because it would not be supported in Vista (and later) and also would make installing/updating the service problematic because a reboot is necessary to change the notification package. 2. Using a process launched by the user (e.g. from HKCU/Software/.../Run or StartUp folder) - Discounted for similar reasons 3. NetUserEnum - Discounted because it needs the Server service to be running (which it may not be) I noticed that some people try to solve this by enumerating processes and looking for processes with an Interactive token - this seems a very complicated way to do it. Is there a better way? I also wondered about enumerating Window Stations - but I don't think this will be productive without allowing the service to interact with the desktop (which I would like to avoid) If anyone has any suggestions I would be very grateful. Best Regards James
From: Stefan Kuhr on 24 Apr 2008 03:44 Hi Jim, jim clark wrote: > <snip> > However, LSA allows multiple users to logon with the Interactive flag - what > is the best way to find the *real* interactive user (if any)? > What is your definition of "the *real* interactive user"? Is it the user who logged in at the glass terminal but not the user who is used with runas or an su clone to run a dedicated process with an interactive logon session? If this is your definition I would definitely go with a Winlogon Notification package for W2K, XP and W2K3 Server and use WTSEnumerateSessions on Vista and later. Cheers, -- Stefan
From: jim clark on 24 Apr 2008 07:26 Yes, my definition of "the *real* interactive user is the guy who logged on to the glass console. A Win notification package is not suitable because: a. The solution needs to be compatible with Vista b. Notification packages create problems with installation/upgrade (because the DLL is always locked) and security concerns Similarly, WTSEnumerateSessions is not suitable because I need to support systems where the Terminal Services service is not running Therefore the LSA functions appear the best bet but obviously have this problem with the interactive flag. I probably wouldn't have even noticed it (my initial sense being there would only be one interactive user on a typical system but on my dev machine there is a __vmware__ user who has the flag set). This leaves me wondering if the only way is to enumerate processes and try and link this back to the results from the LSA functions? James "Stefan Kuhr" <kustt110(a)gmx.li> wrote in message news:%23fmy59dpIHA.4848(a)TK2MSFTNGP05.phx.gbl... > Hi Jim, > > jim clark wrote: >> <snip> >> However, LSA allows multiple users to logon with the Interactive flag - >> what is the best way to find the *real* interactive user (if any)? >> > > What is your definition of "the *real* interactive user"? Is it the user > who logged in at the glass terminal but not the user who is used with > runas or an su clone to run a dedicated process with an interactive logon > session? > > If this is your definition I would definitely go with a Winlogon > Notification package for W2K, XP and W2K3 Server and use > WTSEnumerateSessions on Vista and later. > > > Cheers, > > -- > Stefan
From: Stefan Kuhr on 24 Apr 2008 10:13 Hi Jim, jim clark wrote: > <snip> > Similarly, WTSEnumerateSessions is not suitable because I need to support > systems where the Terminal Services service is not running > Why can't you call WTSEnumerateSessions? I just made a tiny program that enumerates TS sessions and ran it on W2K Workstation Gold. WTSEnumerateSessions failed with a last error 1151 ("The specified program is not a Windows or MS-DOS program", yes a very meaningful last error in this case), but the API can be called. -- Stefan
From: jim clark on 24 Apr 2008 14:14
WTSEnumerateSessionsn fails if the Terminal Services service (TermService is not running) on XP (Error 1702). I hadn't tried it on Windows 2000 yet but I anticiated that it would be the same. When this service is not present the multiple session functionality used by TS (and FUS etc) isn't available and only one user can logon at a time to session zero. This seems to have changed in Vista because the function is always available even if the service is stopped. You can recreate this senario by using the QUERY program (in Windows 2003 and Vista) with the QUERY SESSION command. This works fine when the service is running but fails when it is stopped. I suspect the cause is the same. Some of my customers disable this service for security reasons which means I cannot use WTSEnumerateSessions. I thought the LSA route would be okay but there is this problem that there can be more than one 'interactive' logon at a time. I suppose what I'm asking is - Is there a way to find the owner of the current 'glass console' session (maybe the Windows Station/Desktop) from a service? James "Stefan Kuhr" <kustt110(a)gmx.li> wrote in message news:eOjGnXhpIHA.5916(a)TK2MSFTNGP04.phx.gbl... > Hi Jim, > > jim clark wrote: >> <snip> >> Similarly, WTSEnumerateSessions is not suitable because I need to support >> systems where the Terminal Services service is not running >> > > > Why can't you call WTSEnumerateSessions? I just made a tiny program that > enumerates TS sessions and ran it on W2K Workstation Gold. > WTSEnumerateSessions failed with a last error 1151 ("The specified program > is not a Windows or MS-DOS program", yes a very meaningful last error in > this case), but the API can be called. > > -- > Stefan > > > |