Logged in user runas get original user?

[mikethetechguy]

Essentially I have a program that changed a HK Current User setting via gui (as a side-effect changes "HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects", "VisualFXSetting", though changing this directly will NOT change the settings themselves)

I have a program that pretty much RunAs for users when I set up programs to run at start. So like using @username reveals a different username then the user logs in with. When I remove the "RunAs" option the program runs fine, changes what I need changed, and exits. When I use the RunAs it does "nothing" (it does not change the setting for the user). This seems to indicate that a change is made for the RunAs user, not the logged in.

Before I get asked, I could remove the RunAs option but this change would not allow restricted users (who can't run .exe files) run my program.

Is there a way I can log off the runas command in order to run the rest of my script as the "user at the terminal"?

[Jos]

Did you look into the suggestion I made in the other thread to update the HKEY_USERS hive in stead of the HKCU ?

Jos

Edited July 25, 2008 by Jos

[Jos]

You could also try to retrieve the SID first by doing:

#Include <Security.au3>
$aAcct = _Security__LookupAccountName(@ComputerName & "\" & @UserName)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[0] = ' & $aAcct[0] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[1] = ' & $aAcct[1] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[2] = ' & $aAcct[2] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console

Ofcourse you need to define your AD domainname in stead of the @Computername!

Then use the result in $aAcct[0] to fine the correct registry hive in HKEY_USERS .

[mikethetechguy]

Did you look into the suggestion I made in the other thread to update the HKEY_USERS hive in stead of the HKCU ?

Jos

I have made changes to the registry value and restarted, it does not actually cause this setting to take effect.

[mikethetechguy]

You could also try to retrieve the SID first by doing:

#Include <Security.au3>
$aAcct = _Security__LookupAccountName(@ComputerName & "\" & @UserName)
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[0] = ' & $aAcct[0] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[1] = ' & $aAcct[1] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console
ConsoleWrite('@@ Debug(' & @ScriptLineNumber & ') : $aAcct[2] = ' & $aAcct[2] & @crlf & '>Error code: ' & @error & @crlf);### Debug Console

Ofcourse you need to define your AD domainname in stead of the @Computername!

Then use the result in $aAcct[0] to fine the correct registry hive in HKEY_USERS .

Aye, wish it worked. Regkeys won't make this change for me sadly. The other beast of it is that the user logged in cannot run exes, so as I said the @user = different than who I want to change.

[Jos]

I understand your issue when using the runas() command the user hive of the elevated user is loaded. since you start the script.exe with another utility I understand now that this will not allow you to retrieve the SID of the "normal" user, but you could still enumerate all possible userhives in the HKEY_USERS and update the ones that belong to domain users. To my knowledge, all user information is loaded from that place to the HKCU hive at login time. Did you say you tested updating the HKEY_USERS hive and it didn't work for you?

Jos

PS: do you have the option to specify the %usrname% at shell time of the script as parameter?

Edited July 25, 2008 by Jos

[mikethetechguy]

I understand your issue when using the runas() command the user hive of the elevated user is loaded. since you start the script.exe with another utility I understand now that this will not allow you to retrieve the SID of the "normal" user, but you could still enumerate all possible userhives in the HKEY_USERS and update the ones that belong to domain users. To my knowledge, all user information is loaded from that place to the HKCU hive at login time. Did you say you tested updating the HKEY_USERS hive and it didn't work for you?

Jos

PS: do you have the option to specify the %usrname% at shell time of the script as parameter?

I have changed the registry settings for the user to what I want ("2" instead of typically "1"), when I reboot the machine the settings do not take effect. If I look at where to change the settings via Windows GUI it is as if the settings have changed but not been applied, it's pretty weird but I've heard it from a lot of people and reproduced the problem myself. I'm sure that sounds like as much BS as I thought it was when I first heard it, but it seems to be the case.

I'm assuming you are saying can I record the login name before I do the runas (third party program runas, not scripting runas), and the answer is probably no, they don't let you peek into their source code.

Maybe changing the thing that runs the script is more the answer. Can I go this through just a vanilla logon script? Do they run as admin? Or as current user with temp elevated privelages? Really as long as I can run the .exe from a user account I'm good. Or if I can script it to runas admin then find the username of the logged in (not runas) user.

PITA I know, thanks for your help.

[Jos]

I have changed the registry settings for the user to what I want ("2" instead of typically "1"), when I reboot the machine the settings do not take effect. If I look at where to change the settings via Windows GUI it is as if the settings have changed but not been applied, it's pretty weird but I've heard it from a lot of people and reproduced the problem myself. I'm sure that sounds like as much BS as I thought it was when I first heard it, but it seems to be the case.

I'm assuming you are saying can I record the login name before I do the runas (third party program runas, not scripting runas), and the answer is probably no, they don't let you peek into their source code.

Maybe changing the thing that runs the script is more the answer. Can I go this through just a vanilla logon script? Do they run as admin? Or as current user with temp elevated privelages? Really as long as I can run the .exe from a user account I'm good. Or if I can script it to runas admin then find the username of the logged in (not runas) user.

PITA I know, thanks for your help.

The thing you are not explicitly answering is where you made the registry change but a hope you did it in the HKEY_USERS/users-sid keys and not the HKCU.

Other than that I don't know how to get around it in your setup.

Jos

[Juvigy]

Why not using the windows GUI to do it ?With a script. Try that verify if it works and then move on to the registry things:)

[mikethetechguy]

Essentially I have a program that changed a HK Current User setting via gui (as a side-effect changes "HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects", "VisualFXSetting", though changing this directly will NOT change the settings themselves)

I have a program that pretty much RunAs for users when I set up programs to run at start. So like using @username reveals a different username then the user logs in with. When I remove the "RunAs" option the program runs fine, changes what I need changed, and exits. When I use the RunAs it does "nothing" (it does not change the setting for the user). This seems to indicate that a change is made for the RunAs user, not the logged in.

Before I get asked, I could remove the RunAs option but this change would not allow restricted users (who can't run .exe files) run my program.

Is there a way I can log off the runas command in order to run the rest of my script as the "user at the terminal"?

I am doing it through the GUI, sorry if my original statement was too vague.

I'm not making a registry change (in my script), what I'm saying is that my script goes through the gui to modify a setting, after doing that the registry has changed at "HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects", "VisualFXSetting". If I modify this regkey myself and restart the computer, no changes take effect.

[mikethetechguy]

The thing you are not explicitly answering is where you made the registry change but a hope you did it in the HKEY_USERS/users-sid keys and not the HKCU.

Other than that I don't know how to get around it in your setup.

Jos

http://www.autoitscript.com/forum/index.ph...rt=#entry557616

[Jos]

http://www.autoitscript.com/forum/index.ph...rt=#entry557616

If you mean this : "HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects", "VisualFXSetting"

...then you haven't understood what I was trying to tell you. probably my Dutch-English translator.

[Albuquerquefx]

I think I get what you're saying... You've got two users: LimitedUser and AdminUser

Since LimitedUser is, well, limited in what they can do, you're firing up something like Control Panel with AdminUser's credentials. Now, you want LimitedUser to take over and change the settings they require, but using the control panel that was spawned using AdminUser's credentials.

If I got all of that right, the unfortunate part is this: it doesn't work that way. If you spawn a process under someone else's credentials, then any / all the changes made by that application will be under the user context of the alternate credentials as well.

You really do only have one option: your EXE needs to determine the GUID of LimitedUser, then use the AdminUser's credentials to elevate up, and then make the registry change to HKEY_Users\<GUID>\...

[mikethetechguy]

I think I get what you're saying... You've got two users: LimitedUser and AdminUser

Since LimitedUser is, well, limited in what they can do, you're firing up something like Control Panel with AdminUser's credentials. Now, you want LimitedUser to take over and change the settings they require, but using the control panel that was spawned using AdminUser's credentials.

If I got all of that right, the unfortunate part is this: it doesn't work that way. If you spawn a process under someone else's credentials, then any / all the changes made by that application will be under the user context of the alternate credentials as well.

You really do only have one option: your EXE needs to determine the GUID of LimitedUser, then use the AdminUser's credentials to elevate up, and then make the registry change to HKEY_Users\<GUID>\...

Well, all except that the directly changing the registry bit, it does not seem to change anything (the key changes, the settings do not) when I change it. The way I see it, log in as limiteduser occurs, RunAs as admin , perhaps makes the user a local admin, runas terminates or uses control panel with runas limiteduser, makes changes, changes occur because currently running as limiteduser (with local admin rights), limiteduser is then removed from the localadmins group, program terminates.

The problem with this, and why I haven't tested it, is that I cannot get their username in order to add them to the local admins. I do not know how to stop using the RunAs credentials in order to make the change to the XP visuals as themselves (please keep in mind this is a third party tool that does the running as admin account bit, not autoIT).

[mikethetechguy]

If you mean this : "HKEY_Current_User\Software\Microsoft\Windows\CurrentVersion\Explorer\VisualEffects", "VisualFXSetting"

...then you haven't understood what I was trying to tell you. probably my Dutch-English translator.

I think that's so cool that you are helping through that language barrier, I appreciate your effort.

If I re-read it and my second guess is correct this is your answer. The change does get made in the HKCU, not the hkey_users/user-sid, it probably gets changed to the hkey_users at some point though absolutely. I'm unsure how to find the original users user-sid so I could directly make that registry change to the original users SID. The other issue is that I've never been able to change the regkey and actually have it take effect (changing the XP visuals). What it DOES change is where you go to set the visuals to like "best performance" and "best look" best performance will be selected, but it looks as it has never been applied.

I hope that answers your question Jos.

Jos

[Albuquerquefx]

Ok, I have a seperate question:

You mentioned that LimitedUser cannot open executables -- how are they opening your AutoIT?

[mikethetechguy]

Ok, I have a seperate question:

You mentioned that LimitedUser cannot open executables -- how are they opening your AutoIT?

A third party program runs a script after login that runs gives me the option of running scripts under an admin account.

[Albuquerquefx]

So then, even your AutoIT script would be run under AdminUser's context?

I've done a small bit of googling for that registry entry you mention, and even did another small bit of hacking on one of my Dell test rigs here at the office. Given all the constraints you've mentioned up to this point, that setting is effectively impossible for you to manipulate so far as I can tell.

If you can "fix" the machine so that LimitedUser is able to launch your AutoIT executable (as in, with their own credentials) it may be possible to use RUNDLL32 to open up the performance pane and make the adjustments via the user interface. Otherwise, I can't find anything else that would help you.

Edited July 28, 2008 by Albuquerquefx

[mikethetechguy]

So then, even your AutoIT script would be run under AdminUser's context?

I've done a small bit of googling for that registry entry you mention, and even did another small bit of hacking on one of my Dell test rigs here at the office. Given all the constraints you've mentioned up to this point, that setting is effectively impossible for you to manipulate so far as I can tell.

If you can "fix" the machine so that LimitedUser is able to launch your AutoIT executable (as in, with their own credentials) it may be possible to use RUNDLL32 to open up the performance pane and make the adjustments via the user interface. Otherwise, I can't find anything else that would help you.

Yeah that's kind of what I'm coming up with. I was hoping to be able to somehow find the user that was physically logged in and promote to admin, then run as them to make the change, then close the app. I think this should work except I donno how to get the name of the logged in user, or how to switch to demote the running user (AdminUser) to the reg user to make the change.

[Albuquerquefx]

I think this should work except I donno how to get the name of the logged in user...

You could probably do this via a search of the system event log for the most recent WinLogon event that wasn't your admin account...

...or how to switch to demote the running user (AdminUser) to the reg user to make the change.

Physically impossible in the current windows threading model. An application started under a user context will forever stay in that user context until it terminates. You can't hand-off control of a thread or process like that...

Here's something that you might be able to try, but keep in mind that it may not be entirely reliable -- run the script as the LimitedUser account. Now you know who is running it... Then use the internal RunAs command to elevate to AdminUser, but use the special flag '0' to ensure that you don't load the admin's profile.

RunAs("AdminUser",@LoginDomain,"Password",0,"rundll32.exe shell32.dll,Control_RunDLL sysdm.cpl,,3",@SystemDir,@SW_SHOW)

I haven't tried this yet, but by not loading the profile of the Admin user, you may be able to force it to update the HKCU of LimitedUser instead...

Edited July 28, 2008 by Albuquerquefx