WinBatch Tech Support Home

Database Search

If you can't find the information using the categories below, post a question over in our WinBatch Tech Support Forum.

TechHome

wNT
plus

Can't find the information you are looking for here? Then leave a message over on our WinBatch Tech Support Forum.

wntRunAsUser Windowstation and Desktop Permissions on WinXP


FYI - We ran across something on the Usenet that directly affects how the permissions are set on windowstations & desktops and which can have a major impact on WinBatch scripts in certain situations. Here's the summary of the problem:

There is a limit to the size of the DACL, or perhaps to the SD in general, for windowstations & desktops on the NT platform family. This limit is 2 KB in size. If the size of the DACL grows too large then the DACL gets corrupted. The DACL of the windowstation "winsta0" and the desktop "winsta0\default" will be modified any time that a user logs on to the system or logs off the system. The modification involves adding or removing ACEs in the DACL that grant the logon session SID for the interactive session to have access to the windowstation & desktop.

So far, all of this is very common and there's nothing tricky.

Now, when the wntRunAsUser() function is called to create a primary access token to perform impersonation in an interactive session, this same sort of DACL manipulation is performed in the extender. The same sort of thing happens when the "Run As..." functionalilty is used in Win2K/XP, and the actual work is done via the CreateProcessWithLogon() Win32 API function. This same API function is used by the RunWithLogon() function in WinBatch.

The tricky part is now here.... On WinXP, the WINLOGON.EXE program has been modified so that it now completely resets the DACL on the windowstation & desktop at the time an interactive session starts and when the interactive session ends. The goal is to keep the DACL & SD from getting to large, which happens when they are polluted with ACEs that are no longer needed and which have not been properly cleaned up by the applications that created them in the first place.

The net result of this change in behavior is that if any impersonation is being done by a service that interacts with the desktop then the ACEs that were placed in the DACL for the impersonation logon session SID [or for any other SID] will be stripped from the DACL. This, in turn, can result in loss of access to the windowstation & desktop by the process that is currently impersonating another user.

In practice, We don't know how often this problem will occur. The thread of discussion that We found involved 3 different people in Germany all encountering the same problem at the same time, with each of them working for different companies. All of them had software that ran as native services and which performed impersonation while needing to interact with the desktop. It may just be a funny coincidence, but none the less it has happened and thus there was a discussion about it on Usenet.

The recommended solution is to set up a separate thread that sits & waits for a special event to be signaled with happens whenever the active desktop changes. Since a logon results in changing from "winsta0\winlogon" to "winstat0\default", and a logout reverses the process, it is possible to use the signaling of this event as a means of determining that it is necessary to re-apply your customized ACEs in the DACL of the windowstation & desktop.

There seems to be an increasing # of scripts being run as native NT services so I'm thinking that sometime soon we should see the symptoms of this problem mentioned.

As it pertains to the NT extender, We are considering implementing the "fix" that allows for the desktop change to be noticed and handled appropriately. There's already some code in the NT extender that handles special-purpose multi-threaded tasks anyway, so that could be expanded upon to enhance the wntRunAsUser() function so that it detects active desktop changes and re-applies the ACEs to the DACL of the windowstation & desktop as necessary on WinXP systems.


Article ID:   W16533
File Created: 2005:02:18:12:21:18
Last Updated: 2005:02:18:12:21:18