Sign in to follow this  
Followers 0

RunAsSet not working for system account for XP SP2

15 posts in this topic

Posted

We've noticed that the system account on XP SP2 can't do a RunAsSet successfully. The same is true if we try to do a windows RUNAS command or use the freeware CPAU command. The CPAU forum has a thread that tries to explain that Microsoft changed the way things work in XP SP2 which causes this problem. Here is an excerpt of that thread:

--------

Thank You for contacting Microsoft Support in regards to your question with CreateProcessWithLogonW() not working on XP SP2 from the localsystem account.

In our internal support database Ive found the following answer from an American colleague to exactly the same question:

The code for CreateProcessWithLogonW() was changed in SP2 to have the same behavior as Windows Server 2003. One of the things CreateProcessWithLogonW() will do ensure that the child process has access to the windowstation/desktop if lpDesktop member is specified to NULL or empty string. On Windows XP SP1, the operating system

would grant explicit access to the child process for the windowstation/desktop of the parent process. On Windows XP SP2, the API determines the logon SID of the parent process and adds this to the token of the child process so the API doesn't need to modify the DACLs for the windowstation/desktop. This will not work with the localsystem account since it doesn't have a Logon SID.

If you would like to launch the process interactively (ie winsta0\default) with XP SP2, you'll need to do the following:

1. set lpDesktop to "winsta0\\default".

2. grant the user in the CreateProcessWithLogonW() call access to

"winsta0\\default". The following KB article has sample code on modifying the security using VB:

316440 How To Use Low-Level Access Control APIs from Visual Basic

http://kb/article.asp?id=Q316440

The function you need to look at is: UpdatePermissionsOfUserObject()

To determine what type of permissions should be granted. Please take a look at the following article:

165194 INFO: CreateProcessAsUser() Windowstations and Desktops

http://kb/article.asp?id=Q165194

#define WINSTA_ALL (WINSTA_ACCESSCLIPBOARD | WINSTA_ACCESSGLOBALATOMS |

WINSTA_CREATEDESKTOP | WINSTA_ENUMDESKTOPS |

WINSTA_ENUMERATE | WINSTA_EXITWINDOWS |

WINSTA_READATTRIBUTES | WINSTA_READSCREEN |

WINSTA_WRITEATTRIBUTES | DELETE |

READ_CONTROL | WRITE_DAC |

WRITE_OWNER)

#define DESKTOP_ALL (DESKTOP_CREATEMENU | DESKTOP_CREATEWINDOW |

DESKTOP_ENUMERATE | DESKTOP_HOOKCONTROL |

DESKTOP_JOURNALPLAYBACK | DESKTOP_JOURNALRECORD |

DESKTOP_READOBJECTS | DESKTOP_SWITCHDESKTOP |

DESKTOP_WRITEOBJECTS | DELETE |

READ_CONTROL | WRITE_DAC |

WRITE_OWNER)

The values for the above defines are in winuser.h.

I have tested this from localsystem account with XPSP2 and it works using the code from the above article, 165194.

------

The entire thread is at http://www.joeware.net/phpBB2/viewtopic.php?p=202

I hope that autoit could be updated to make RunAsSet work for XP SP2 from the system account.

Share this post


Link to post
Share on other sites



Posted

Argh. I wish they'd stop breaking my code. :idiot:

Share this post


Link to post
Share on other sites

Posted

Hello,

i have the same problem when i use RunAsSet on a Windows XP SP2 system :D

Can anybody give me a tip for a work around, or can AutoIT say if it is possible to fix this "bug" and when yes, when it is fixed :lol:

I don't now why MS must change this code :idiot:

I think this problem is explain on this site: http://support.microsoft.com/default.aspx?...kb;en-us;165194

Big thanks

motzel

Share this post


Link to post
Share on other sites

Posted

For those of us using the Tivoli environment for push packages

you need to look into using wrunuiep.exe

wrunuiep

arguments:

-e program

This fixed our problem of running our push packages.

Share this post


Link to post
Share on other sites

Posted

Jon, here's my thought on this. RunAsSet() could get a new option "Interact With Desktop". When that option is specified, then do what's described earlier in the thread to allow the program to access the default desktop. That will allow people to avoid the issue described here by just passing the option. It will also provide a new feature which may be useful in the process. The above sounds rather straight-forward so shouldn't be too hard to do.

Share this post


Link to post
Share on other sites

Posted

I looked for the code on MSDN for running as SYSTEM at the time, and IIRC it was like "yeah, in about 10 years when I can even understand the first line" :)

Share this post


Link to post
Share on other sites

Posted

I looked for the code on MSDN for running as SYSTEM at the time, and IIRC it was like "yeah, in about 10 years when I can even understand the first line" :)

same to me, perhaps easy for Valik ...

Share this post


Link to post
Share on other sites

Posted

I looked for the code on MSDN for running as SYSTEM at the time, and IIRC it was like "yeah, in about 10 years when I can even understand the first line" :)

Yeah, and once upon a time you wouldn't look at assembly, either.

Share this post


Link to post
Share on other sites

Posted

Yay, I see somebody assigned this to me... bastards.

I'll try to take a look over the weekend but if I don't get to it then it's going at the bottom of the pile.

Share this post


Link to post
Share on other sites

Posted

Good god this takes a long time to write. It's all very straight-forward, but it's probably about as long as or longer than what Run()'s code already was.

Jon you're a pansy.

Share this post


Link to post
Share on other sites

Posted

Done in 3.2.11.0. See the new RunAs() and RunAsWait() functions (RunAsSet() has been removed).

Share this post


Link to post
Share on other sites

Posted

Done in 3.2.11.0. See the new RunAs() and RunAsWait() functions (RunAsSet() has been removed).

Valik,

Thanks for looking at this. It looks like it will solve my problem that I listed here: My problem

I have downloaded the 3.2.11.0 Beta to try to test/use this new functionality.

My AutoIT application is started as a service and all run commands in my script are executed under the context of local system account which is quite frustrating cos it's one thing that I have not managed to find a way around using AutoIT. But I got directed to this thread when I did a search for CreateProcessAsUser which I found on Google :-)

But I still don't understand how to use the new RunAs command after reading the 2.11.0 Beta help file. How does one use the RunAs command if one does not know what the username/password is of the logged in user?

Share this post


Link to post
Share on other sites

Posted

One doesn't use the RunAs() function if one doesn't know the credentials to log on as.

Share this post


Link to post
Share on other sites

Posted

Ah, I mistook the reason for the change.

I was hoping to have the script launch an application using the users context instead of the system context when the script was started as a service using the localsystem account. Is there any way to do this? Or have I reached the end of the road? :-(

Share this post


Link to post
Share on other sites

Posted

That's a separate feature and isn't implemented.

Share this post


Link to post
Share on other sites
Sign in to follow this  
Followers 0

  • Recently Browsing   0 members

    No registered users viewing this page.