Determine RDP Session on Windows 7

[chrislegarth]

Is there a way to identify if an RDP session is connected to a Windows 7 computer?  The wtsEnumSessions command works when I check a server but get "106: Windows Terminal Server Extender: Unable to enumerate sessions" when I point it to a Windows 7 computer.

Thanks!

[td]

Assuming you are attempting to check remote sessions remotely, I not aware of any way to make that work when the remote system is Windows 7.  You might be able to do it if the Windows 7 system is part of a Windows network and you connect to the that system from a domain account with "Query Information" privileges on the Windows 7 system.   In the past , I know I have tried using the wntAddDrive with an administrative share trick to connect to a remote Windows 7 system as an administrator of that system before performing a sessions query with not success. 

There are many ways to perform the task locally using the WWWTS44I.DLL extender, using WMI objects, or the "query session" command line utility.  None of them appear to work when targeting a remote Windows 7 system.  I guess the trick would be to figure out how to set the required privileges on Windows 7.

[td]

Did a little more checking and discovered that I made an incorrect assumption the last time I attempted to remotely list sessions on a Windows 7 computer.  The assumption was that when terminal services are enabled on a Windows 7 system, RPC is also enabled.   This assumption is false.   It is easy enough to verify by check the list of running services for the RpcSs service.

When RPC is enabled on a Windows 7 system, you can check for remote sessions by using the "query session /server:mywin7compure" where "mywin7computer" sans quotes is the name of Windows 7 computer you want to check.   I was not able to get the information using WMI or the Terminal Services extender - just with the command line "query session" command.  Will need to do some more research to determine why WMI and the extender cannot list sessions.

[ChuckC]

A few ideas come to mind...

1)  There may be a remote admin RPC service for terminal services that needs to be enabled.

2)  There may be a firewall rule blocking inbound access to the aforementioned RPC service.

3)  There may be a more general "remote admin" setting that needs to be enabled in the "advanced system" properties [which keeps on getting moved around in terms of how you access it] for workstations that is enabled by default for servers.

[td]

Thanks for weighing in on this one Chuck. 

The part I don't understand is why the query session command line tool works but the extender does not.  The Windows 7 system has the terminal services AllowRemoteRPC registry setting set to 0x1 and the appropriate firewall ports open.  The fact that "query session" works bares evidence of this.  In fact, "querry session" works when executed from a restricted Windows 10 admin account. 

On the other hand the extender does not work from either a restricted or elevated Windows 10 account.  The system error is consistently 5 so your suggestion that is is account related in some way seems to have merit.  Perhaps it will require some low level investigation of a "query session" process to try and determine what it is up to.

[ChuckC]

Right... error 5 is access-denied, so it's definitely a security-related issue, such as restrictive permissions, lack of membership in a necessary group, or a missing LSA privilege in the process/thread access-token.  Looking on MSDN, I see that the documentation for the underlying Win32 API function WTSEnumerateSessions() now shows some requirements for "Session Permissions" that may be of relevance to this issue.

Can you clarify a bit regarding your mention of "Windows 10" accounts?  I'm not clear on where that comes into play regarding how the WTS extender is [mal]functioning on Windows 7.  Perhaps lay things out in a table/grid of extender functioning yes/no, operating system version and user account type + UAC restricted/elevated state.

[td]

I just happened to be attempting to check sessions on a remote Windows 7 system from my local Windows 10 workstation.   I can execute the Windows built-in "query sessions" command line program from a command prompt and it works.  It doesn't matter whether the command prompt is running with elevated or restricted Admin privileges.  It still works.    On the other hand, the extender does not work either way.   It is not surprising that the process execution level does not affect the outcome in this case but thought it worth mentioning anyway.

Neither computer is on a Windows Active Directory based network and all accounts are local.  They just share a common subnet.  I think I will have to break out the top-secrete, handy dandy toolbox to solve this one.   

[ChuckC]

Have you used the extender in a script running locally on the Windows 7 system to see if it can enumerate the sessions that exist w/o having to go out over the wire with a remote admin RPC call?  It would be helpful to know if the usage of the WTSEnumerateSessions() API function by the extender is failing in that situation, too.

I suspect that your top secret handy dandy toolbox contains a debugger suitable for tracing the API calls made by the command line "query sessions" utility and also a network packet sniffer to examine the RPC calls that are being made by both the "query sessions" utility and the WTS extender?

[td]

Have you used the extender in a script running locally on the Windows 7 system to see if it can enumerate the sessions that exist w/o having to go out over the wire with a remote admin RPC call?  It would be helpful to know if the usage of the WTSEnumerateSessions() API function by the extender is failing in that situation, too.

The extender works fine locally- Windows 7 or Windows 10.

I suspect that your top secret handy dandy toolbox contains a debugger suitable for tracing the API calls made by the command line "query sessions" utility and also a network packet sniffer to examine the RPC calls that are being made by both the "query sessions" utility and the WTS extender?

Yup for both, among other spanners and thingamajigs.

[ChuckC]

I highly recommend the 3/8" wing-nut extractor, but stick to metric sizes with whatchamazogs.

As regards the extender working correctly when enumerating TS sessions on the local system, but failing when going over the wire while "query session" is working properly over the wire, that leads me to think think that something basic has changed regarding how applications consume the WTS*() API functions.  The first one that comes to mind is the possibility that the newer WTSOpenServerEx() function is doing something important but not documented that's different than what WTSOpenServer() is doing, with the current extender calling the older WTSOpenServer(), iirc.  Ditto for WTSEnumerateSessionsEx() vs. WTSEnumerateSessions(), and corresponding usage of WTSFreeMemoryEx() & WTSFreeMemory() if you happen to modify the extender to use the newer *Ex() versions of those functions.

[td]

The command line tool qwinsta.exe - called by query.exe session -  appears to be using the crypto API to access the credentials stored in the registry for the targeted server.   However, the extender is not and using wntAddDrive with remote credentials does not change the credentials the extender uses on Windows 10.

My understanding was that the "EX" versions of the terminal services functions were added to support virtual desktops but, as you suggest, they may have some addition features.  Will have to do some more checking.

 

[ChuckC]

OK, so it looks this particular problem may in fact be related to going over the wire when both workstations are standalone [e.g. not part of a domain] and you're using local user accounts where some remote connection credentials are being stored by Windows itself.

Depending on the UAC restriction/elevation level of the access-token in use, the sharing of DOS device name spaces between restricted & elevated environments and how wntAddDrive() or the NET USE command was used to connect to the IPC$ share, it may well be that WTSOpenServer() and/or WTSEnumerateSessions() doesn't have the necessary level of access, with the result being error 5.

[td]

It looks like the previously mentioned command line utility calls a server side SAM based authentication function via RPC using the stored credentials.  So it would appear that being logged in to a domain account is the only way to get the extender function to work for now when targeting a Windows 7 system remotely.   

[td]

This problem appears to be the result of a change MSFT made to how Windows handles null sessions under certain circumstances.    A potential workaround involves making a slight change to a Network Extender function.