GINA Winlogon Desktop and Winbatch

 Keywords: GINA Winlogon Desktop IntControl 84 Winbatch

Question:

Looking over the web boards I have found a few discussions dealing with the xxGINA.dll files and the WinLogon Desktop. However none of them seem to address my question.
It is well documented that Winbatch operates in the Application Desktop and the Windows lock screen (via CTRL+ALT+DEL or WINDOWS+L) operates in the Winlogon Desktop by having xxGINA.dll listen for the CTRL+ALT+DEL SAS event. Which is then passed to WinLogon with the current state of the Application Desktop.
Because of the Winlogon being a separate desktop from the Application desktop, is there any possible way to reference the window handles of the Winlogon desktop from the Application desktop? or is this a 'hard' boundary that Winbatch cannot pass through?
It is my understanding that Microsoft explicitly did not develop an API for interacting with this, probably for obvious reasons.

Second Question, if Winbatch cannot see the Winlogon desktop, would it be possible to have Winbatch trigger pass SAS events to either xxGINA.dll or Winlogon?

Answer:

As of Vista & newer, the GINA DLLs are obsolete and are no longer part of the O.S., so keep this in mind when looking at any solution that involves the installation of a custom-written GINA DLL. Products like PC Anywhere used to use a secondary GINA DLL to provide support for sending the SAS event.

There are a couple of issues associated with accessing the Winlogon desktop, the content of that desktop and interacting with application windows on that desktop. I'll cover the ones that come to mind as being most important.

WinXP w/FUS disabled and Win2K & older w/o Terminal Services installed in application server mode only support a single user session on the system, which is session #0 and is traditionally known as the "console" session.

On WinXP w/FUS disabled and Win2K servers w/Terminal Services installed in application server mode, session #0 is still the console session, but other non-zero user sessions may exist.

On Win2K3, Vista & newer, non-zero user sessions may exist, but session #0 is reserved for native NT services. On Vista & newer, even the physical console has a non-zero session #.

In each user session, there may be one or more "window stations", with the default window station being named "winsta0" in each user session. A window station has its own set of permissions applied to it.

Each desktop exists as a child of a window station. By default, the "winsta0" window station in each user session has both a "Default" desktop and a "Winlogon" desktop. Each desktop has its own set of permissions applied to it.

Each process running on the system has a primary access-token associated with it, which provides the identity of the user whom the process runs as. That access-token specifies the user session to which the process belongs, and thus dictates which window stations the process can attach to. When the CreateProcess() function is called to create a process, it can accept a pointer to a STARTUPINFO structure that can contain the name of a window station & desktop for the process to be associated with.

The first time that the main thread in a process makes a function call into the USER32 or GDI32 subsystems, the process is bound to a window station. The choice of window station will be the one specified when the process was created, or the default window station "winsta0". Once a process has been bound to a window station, all of the threads that can ever exist in that process will also be bound to the same window station.

Each thread in a process can be associated with a single desktop, and the thread will be bound to a desktop the first time that it creates a window or creates a window hook. The choice of desktop will be the one specified when the process was created, or the default default "Desktop". The thread will remain bound to the desktop for as long as it has any open window handles or any open window hooks. If the thread owns no open handles to objects on a desktop, the thread may switch which desktop it is bound to.

What does all this mean?

In a nutshell, WinBatch scripts run as processes. Unless the process that executes the WinBatch script is created via some low-level code that can call CreateProcess() directly, it will inherit the default window station & desktop of "winsta0\Default". This tech support database article [W17024 ] demonstrates calling CreateProcess() via the usage of binary buffers and the DllCall() function in WinBatch.

Once you've created process that has been told to attach to the "Winlogon" desktop, you need to understand that the process may still not be able to interact with that desktop.

There are only 2 ways to work around such a limitation... either escalate your privileges by creating the process with a privileged access-token or alter the permissions on the window station & desktop to be more permissive. There are, in fact, limits on the size of the permissions list for a window station & desktop, so you can't add an arbitrary # of additional permissions w/o rendering your window station & desktop inaccessible due to corrupted security settings. The wntAccess*() method in the Win32 Network extender are capable of get/set operations for the permissions on window stations & desktops, so it is possible that sufficiently privileged script could grant permissions for less privileged processes to access the "Winlogon" desktop, but doing so would introduce all sorts of additional security concerns.

The escalation solution is where you see native NT services getting involved. Prior to Vista, that method of escalation would work reliably since a native NT service could be configured to run as "Local System" and thus have the same privileges as the O.S. itself and all services would run in session #0, which was guaranteed to be the console session. However, as of Vista, services no longer have access to the interactive desktop, are confined to session #0 and the console is no longer associated with session #0. In effect, this escalation method has been made unusable on Vista & newer.

Article ID:   W17931

Filename:   GINA Winlogon Desktop and Winbatch .txt

File Created: 2014:07:18:09:51:38

Last Updated: 2014:07:18:09:51:38

	Backups
	Ctrl Alt Del Issues
	Determine Platform - OS
	Get EXE Name
	Get Machine Name - Workstation
	Icons
	Reboot Issues
	Recycle Bin
	Resource Lock
	System Information
	User Profiles

Database Search

TechHome