Jump to content

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Find out more here. X
X


Photo

RunAsSet not working for system account for XP SP2


  • Please log in to reply
14 replies to this topic

#1 pietrog

pietrog

    Seeker

  • New Members
  • 8 posts

Posted 07 December 2004 - 04:11 PM

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 I’ve 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.







#2 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,420 posts

Posted 09 December 2004 - 10:49 AM

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

#3 motzel

motzel

    Seeker

  • Active Members
  • 11 posts

Posted 18 December 2004 - 09:11 AM

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

#4 GaryFrost

GaryFrost

    I don't need your attitude. I have one of my own

  • Developers
  • 7,854 posts

Posted 28 July 2005 - 11:02 PM

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.

SciTE for AutoItDirections for Submitting Standard UDFs

Don't argue with an idiot; people watching may not be able to tell the difference.


#5 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 26 December 2007 - 11:41 PM

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.

#6 Jon

Jon

    Up all night to get lucky

  • Administrators
  • 10,420 posts

Posted 27 December 2007 - 10:17 AM

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" :)

#7 jpm

jpm

    a Real GUI/debug lover

  • Developers
  • 9,626 posts

Posted 27 December 2007 - 11:33 AM

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 ...

#8 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 27 December 2007 - 02:39 PM

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.

#9 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 29 December 2007 - 04:30 AM

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.

#10 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 02 January 2008 - 03:24 AM

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.

#11 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 20 January 2008 - 08:45 PM

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

#12 Broots

Broots

    Seeker

  • Active Members
  • 16 posts

Posted 04 February 2008 - 11:54 AM

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?

#13 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 04 February 2008 - 03:13 PM

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

#14 Broots

Broots

    Seeker

  • Active Members
  • 16 posts

Posted 05 February 2008 - 10:01 AM

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? :-(

#15 Valik

Valik

    Former developer.

  • Active Members
  • PipPipPipPipPipPip
  • 18,879 posts

Posted 05 February 2008 - 03:35 PM

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




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users