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

WinBatch
Networks - Servers
Microsoft Client
wNT
plus
Services

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

wntRunAsUser 713 Unable to Set Window Station Access

 Keywords: wntRunAsUser 713 Unable Set Window Station Access

Question:

I'm seeing this error intermittently on a file my users run via a W2k login script while using "ret = wntRunAsUser(".",uid,pswd, 5, 1);. The error is WIL Extender Error: 713: Unable to set window station access

On line: 

ret = wntRunAsUser(".",uid,pswd, 5, 1)
Any clues?

Answer:

I highly suspect the problem is due to the fact that you are running this from within the logon script. During the Windows logon process, some things are happening in the background and this has an effect on what you can[not] do. One of these things that the windows desktop and windowstation security have not been set up properly until you actually see that the Windows Explorer desktop shell has started. Until the windowstation & desktop security have been set up properly, it is not possible for wntRunAsUser() to function properly.

The safest thing for you to do is to allow your script to run in the background while the main logon script completes and the desktop initialization continues. Have your script wait until it detects a hidden window named "Program Manager" [e.g. use WinWaitExist()], which is the window name for the Windows Explorer desktop shell. Once this window has been found, it is then safe for your script to call wntRunAsUser.

Question:

I just started getting this error 713: Unable to set window station access in my scripts that use: 
ret = wntRunAsUser( serverdomain, user, password, 2, 1)
My script is running as a service. I use wntGetUser to retrieve the credentials and it seems to give me the emulated user, but this bothers me because some of my VBS code now fails with Access Denied Errors. They are child processes.

I have an exs Service File running as SYSTEM. This is happening on systems that have been up for a long time. I have tried all the variations in the login-type to the same results.

Answer:

Ok, I have traced the problem down. 
AddExtender("WWWNT34i.DLL") ;These Extenders are loaded by default If you need more enter them here
curuser=wntGetUser(@DEFAULT)
Display(10, "Results", "User:%CurUser%")
ret = wntRunAsUser( "DOMAIN", "USER", "PASSWORD", 2, 0)
error=LastError() 
curuser=wntGetUser(@DEFAULT)
Display(10, "Results", "User:%CurUser% Error %error%")
TimeDelay(10)
Using the wntRunAsUser Flag 0 works, using the Flag 1 (Allow new child processes to inherit security privileges) causes the error 713

Note: The key part is the "up for a long time". If you use wntRunAsUser() repeatedly for a long enough period of time between reboots, you'll exceed the maximum size of the SD [Security Descriptor] as additional permissions entries are added for each unique logon session that is created each time that wntRunAsUser() is called. The only cure for the problem at this time is to reboot the system.

More:

Using the RunWithLogon command yields the following results. Seems to be a similar error than before. 
AddTheAceWindowStation: SetUserObjectSecurity error: 1816

WinExec Error: Access is denied.
I rebooted some test machines with some positive results. Because of the new error I was able to bring up 2 articles.

http://support.microsoft.com/kb/165194/EN-US/

http://support.microsoft.com/kb/185292/

I guess the question is could the credentials that Winbatch is asking for not getting deleted at the end of the script's completion?

Answer:

Sort of.... your understanding is close to what's really going on.

Logon Sessions, Security Contexts, Windowstations, Access Tokens, Security Descriptors and Impersonation are all related to the work being done when wntRunAsUser() [and also RunWithLogon()] is being executed.

In a nutshell, whenever the underlying LogonUser() API function is called, it creates a new logon session identifier known as a Logon Session. The Logon Session is reperesented by a SID value that is guaranteed to be unique during the entire time that the O.S. remains up & running; Logon Session SID values get recycled at each reboot. This Logon Session SID value is stored in the access token that is created by LogonUser().

During the interactive logon process, the MSGINA.DLL does the same sort of work to authenticate a user's credentials and to create the access token used by the root process of the user's logon session.

Every process that runs on the system has an access token. Whenever a child process is created, it gets a copy of its parent process' access token *UNLESS* the child process is being created with a different specifc access token that was explicitly thru the use of the LogonUser() API function.

There is an O.S. object known as a Windowstation, and it contains other objects known as desktops. There are 3 desktops that are commonly used, with their names being "Winlogon" [the desktop you see when the workstation is locked or doesn't have any user logged on], "Default" [the desktop on which the Explorer shell displays what you commonly think of as your "desktop", the taskbar, systray, etc...] and "Screensaver" [which is the desktop on which a screensaver's output is displayed].

The Windowstation and its associated desktops all are securable objects, meaning that they have a SD [Security Descriptor]. The SD contains, among other things, the list of permissions [the DACL, or Discretionary Access Control List].

Normally, when a Logon Session is created for an interactive logon session, the logon process applies some permissions to the Windowstation and its desktops that allow any process with an access token that contains the Logon Session SID value to have access to those objects.

It is possible for certain types of impersonation to be performed such that the impersonation access token shares the same Logon Session SID as the one used by the process that initiated the impersonation. Network mode impersonation typically works this way. However, when you tell wntRunAsUser() to perform interactive user impersonation, a new Logon Session is created along with a new SID value. In order for the current process to continue to access the Windowstation & desktop[s] after impersonation has been done, it is necessary to alter the DACL in the SD on the Windowstation to grant the new Logon Session SID permissions to access the Windowstation. the wntRunAsUser() and RunWithLogon() functions make these security changes.

The SD on a Windowstation has an architectural size limt of 2KB. If ACEs are added to the DACL for Logon Session SID values each time that wntRunAsUser() or RunWithLogon() is called, eventually, this size limit will be encountered and an error will occur indicating that the SD on the Windowstation could not be modified.

The hard part about remedying this problem is that there's no automatic removal of ACEs for Logon Session SID values that are associated with Logon Sessions that no longer exist. As long as even a single process remains running with an access token in use that belongs to a Logon Session, then the Logon Session's SID value is valid and the permissions must remain in the SD on the Windowstation.

What I'm working on is an exception handling routine which gets called whenever the SD of the Windowstation cannot be modified. This exception handler will then attempt to enumerate all of the Logon Sessions that exist on the system and then analyze the current permissions in SD on the Windowstation in an attempt to find orphaned ACEs that belong to non-existent Logon Sessions. All orphaned ACEs would then be removed from the SD in attempt at freeing up valuable storage space in the SD to allow new ACEs to be added for new Logon Session SID values. This process is a non-trivial task to perform, requires elevated privileges and doesn't happen "lightning fast", so it's not something that will be done unconditionally everytime that wntRunAsUser() is called.

Also of interest is a change that Microsoft implemented in WinXP & Win2K3 that relates to this problem with the SD of the Windowstation being limited to 2KB in size. When the interactive logon session is terminated due to the user logging off, the O.S. automatically purges the DACL in the SD on the Windowstation to remove all ACEs and then it applies some default ACEs in the DACL. Although this allows the problem to be remedied with a logout rather than a reboot, it also means that any program [e.g. a compiled WinBatch script] running as a native NT service which has performed impersonation or which has created child processes that are doing impersonation has just lost access to the interactive desktop.

Ultimately, Microsoft plans to eliminate all interactive desktop access for native NT services. These restrictions are beginning in Vista and should be 100% iron-clad in Longhonrn. I suspect that it will be necessary to alter wntRunAsUser() to accept some sort of flag value that tells it not to attempt to alter the permissions of the Windowstation to become compliant with these impending restrictions. 

Article ID:   W16049

File Created: 2006:05:25:11:31:42
Last Updated: 2006:05:25:11:31:42