#205798 - 2012-09-22 08:48 PM
Step by Step guide to running a script with elevated or admin privileges
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
In this post, I am writing down my step by step guide on how to setup your kixtart login script so that all settings are applied irrespective of whether you are a standard user or a local administrator. In this document I have written down all the instructions on how to accomplish this. The only thing that you will require if you are over 18 or 21 depending on where you live, is a large case of beer to get you through the process. Trust me you will need it!
Like many other people, I found it easier to make end users a local administrator of their computer running Windows XP. The hassles in getting certain parts of the script to run as a standard user in addition to the fact that many Windows programs just don't seem to like running as a non admin, just made it easier to make the end user a local admin.
However, this really is very poor practice and over the last several months I have setup several windows 7 networks where all the users are standard users on their computer and I have addressed the issues with regards to certain programs not running as a standard user and the last step was to determine exactly what part of the script requires admin privileges and what part of the script can run as a standard user.
The first step is to ensure that your scripts are running from a group policy object and NOT from the Netlogon folder. Running the script from the netlogon folder had its uses in its hey day, but by using group policy one can take advantage of the fact that one can run the script in the end user context or in the computer context.
When one runs a script in the logon script area of the GPO, the script runs with the security credentials of the logged on end user and the settings are applied to the HKEY_CURRENT_USERS part of the registry.
When one runs a script in the startup script area of the GPO, the script runs with the security credentials of the System account which means that the script runs with full admin privileges and settings can be applied to the HKEY_LOCAL_MACHINE area of the script as well as being able to write to system protected areas such as the system32 directory.
So the procedure is that you need to break your script up into two sections. Everything that writes to the HKEY_LOCAL_MACHINE area goes into the startup script and everything that writes to the HKEY_CURRENT_USER will need to go into the logon script. If the script needs to write to system protected directories, then this will also need to be placed into the startup script.
So on the face of it, it would seem very straightforward to enable the script to run with admin privileges even if the end user logging on is not a member of the local administrators group. All one has to do is put the HKLM part of the script and system protected directories in the startup script and put the rest in the logon script. However there are some limitations to this.
Limitation 1: Because the startup script runs as system it by default means that there is no network access, so if you need to copy files from the server, you need to explicitly assign NTFS permissions to the directory on the server hosting the files to be copied.
A quick and easy solution, if you have only got two or three files that need to be copied across would be to place this in the Netlogon folder as this folder by default grants the system account network access.
Limitation 2: What happens if you want to hide certain drives for certain logged on users. The registry key policies in the HKEY_CURRENT_USERS area under currentversion does not permit standard users to write anything under this key. You cannot use the startup script, because the startup script applies to the HKLM area not to the HKCU area. This means the startup script will apply the setting for ALL users and not just the users that you want as its applied to the computer and not the logged on user.
Limitation 3: If for some reason you want to run a specific program or script or install a specific program when a user logs on (ie you have to run the script in the logon script), then you will face the same problem if the action or the script requires admin privileges. There are many times when the script needs to be applied to the user logged on and not systemwide and unfortunately this means occasionally that it is required to run the script with elevated privileges to step around the problem that the end user running the script does not have the appropriate permissions to execute the actions.
So simplify your coding to ensure that as much as possible runs under the computer context in the startup script, bearing in mind that anything applied here will apply to all users.
Separate your logon script into two parts and make the first part everything that can run without admin privileges and in the second script which you call from the first script via a scheduled task, ensure that you have everything that you need to run in the context of the logged on user that also needs admin privileges.
Over the years most people have developed different ways to run the script as admin, using sanur, runas and various other tools to elevate the script. The prime problem with that method has always been the requirement to include the username and password within the script, which is not desirable for security reasons.
Faced with this dilemma myself, I search high and low and asked of various people how exactly one could run a script or rather a small section of the script with elevated privileges without exposing the password within a script.
The solution turned out be of all things - using the task scheduler. With scheduled tasks the password is set once and then never exposed.
So how do we go about using task scheduler to accomplish this?
The first step is to modify the coding in the script that needs elevated privileges. We need to change the location of the registry from HKEY_CURRENT_USERS to point to HKEY_USERS\SID XXXX. The xxxx being whatever the SID number for the logged on user is. The reason that the change needs to be made is because when you run the script as a scheduled task, then the script is running in the user context of the scheduled task and not in the user context of the logged on user and as such is writing to the wrong HKEY_CURRENT_USERS location ! The HKEY_CURRENT_USERS part of the registry is actually contained within the HKEY_USERS\SID area and what we need to do is extract the correct SID key of the logged on user and tell the script to write to that location.
The Second step will be to create the scheduled task and instruct the scheduled task to run the Kix32.exe file and specify the name of the .kix file that we want it to run. We also need to ensure that the scheduled task runs with the highest privileges and runs on demand as well. We do not need to schedule the task as the main logon script will call the scheduled task.
The Third step will be to export the scheduled task and save it in the netlogon folder.
The Fourth step that we need to take once we have modified the coding in the script is to ensure that that the startup script copies the script that needs elevation to each computer. In addition we need to copy the scheduled task from the netlogon folder to each computer. Why because the System Account will be the account running the scheduled task and the System account in task Scheduler is not able to access any network resources even the netlogon folder. Therefore the script that needs elevation will need to be copied to each computer prior to execution. And obviously the scheduled task needs to be copied to each computer as we will want the system account on the local computer to run the scheduled task. This step is working as is, but I will be trying to find a way to avoid having to copy the kix scripts across to each machine as this wastes bandwidth. Using a batch file would be desirable, but even if the scheduled task calls the bat file, it doesn't help, because the scheduled task has no access to the netlogon folder if running as the system account.
The fifth step will be to modify the main script so that it runs the scheduled task for whichever users require that script to be run. In addition, the main script needs to be modified to enumerate the SID of the logged on user and this information needs to be extracted and saved to a file, where the script requiring elevation can pull the information from in order to write to the correct SID key in the registry.
Step One:
You want to write to a protected area of the registry in the HKEY_CURRENT_USERS such as:
("HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer", "NoDrives", 04008000","REG_BINARY")
This needs to be changed to read
($HKSID + "\Policies\Explorer", "NoDrives", "04008000", "REG_BINARY")
The $HKSID variable will be read from a file that will have the location of the \HKEY_USERS\SID xx location.
So you need to write coding in the beginning of this script to read the the logged on users SID and ensure that the variable as saved as $HKSID so that the script will apply the user Sid location to all the registry settings that need to be written using the $HKSID variable.
CheckUserSid ("UserSid.txt")
As you can see I have used a function. Within my function file, I have created a CheckUserSid function
;================================================================================================
; Extracts the correct User Sid for the logged on user to enable the scheduled task to write to the HKU SID location of logged on user
;================================================================================================
Function CheckUserSid($SID)
$Handle = Freefilehandle ()
if $handle > 0
if Open ($handle, "c:\profiles\policies\" + $SID) = 0
$printsetup = Readline($handle)
WHILE @ERROR = 0
$HKSID = "Hkey_Users\" + $printsetup + "\Software\Microsoft\Windows\CurrentVersion"
$HKSIDONLY = "Hkey_Users\" + $printsetup
$printsetup = ReadLine($handle)
LOOP
IF Close($handle)
Beep
? "Error closing file!"
ENDIF
else
? "Unable to open" + "c:\profiles\policies\" + $SID
Endif
else
? "Unable to obtain a free system handle."
Endif
EndFunction
So step one is pretty easy.
Step Two:
Create a scheduled task on the windows 7 client machine. Essentially what you need to specify are the following:
Name of the task,
that it must run under the System account,
that it must run on demand
That it must run whether the user is logged on or not
that it must run kix32.exe in the programs/script setting and in the "add arguments" section you specify the name of the kixtart file that you want to run. My recommendation would be to create a directory on the local computer, I created a folder called profiles\policies. Within this folder copy the kix32.exe, the kixtart file that you want to run with elevated privileges and if you have a separate kixtart file that you use to call functions from, that needs to be copied across as well.
Thats not too difficult isn't it? One caveat with windows 7 task scheduler is that if you set the task to run whether user is logged on or not, then the task will NOT run interactively, so if you need to show the user something eg pc shutting down in 10 minutes, its not going to work. The pc will shutdown in 10 minutes, but the user will not see the message as task scheduler will not run interactively if you set task to run whether user is logged on or not. Irritating bug that!
Step three:
Export the task to the server. Then simply copy the task to the netlogon folder. Ensure that the script that you copied in step two is also present in the netlogon folder as obviously we want to copy the script to every computer using a script and not manually !
So step three is pretty straight forward isn't it
Step four
In the startup script, we need to create code to copy the scheduled task, the kix32.exe file and the kixtart script and any scripts containing UDF's - all of this needs to be copied to the local computer so that the scheduled task is present on each machine and the scheduled task can run the script locally as the system account in task scheduler has no network access by design.
So in the startup script, we need this.
;============================================================================================================================================
; Copies the Task for the Policy Task so that standard users can run the Policy Script
;============================================================================================================================================
if exist ("%windir%\system32\tasks\microsoft\windows\policies\MYPolicy") = 0
? "Setting MYPolicies "
$ShellCMD = "schtasks.exe /create /RU SYSTEM /TN \Microsoft\Windows\Policies\MYPolicy /XML " + "\\" + $MyDomain + "\netlogon\patches\MYPolicy.xml"
Shell $ShellCMD
Else
? "Policies already scheduled "
Endif
;===============================================================
; Set NTFS permissions so that domain users can run scheduled task
;===============================================================
shell 'ICACLS %SystemRoot%\System32\tasks\Microsoft\Windows\Policies /Grant "%UserDomain%\Domain Users":(OI)(CI)F'
;==================================================================================================================================================
; Copies the policies kixtart script to each computer so that the scheduled task can run the script as system cannot access network resources
;==================================================================================================================================================
Filexist("\\" + $MyDomain + "\netlogon\Policies\", "c:\profiles\policies\", "kix32.exe", "Kixtart Executable")
Filexist("\\" + $MyDomain + "\netlogon\Policies\", "c:\profiles\policies\", "policies.kix", "Policies Kixtart Script")
Filexist("\\" + $MyDomain + "\netlogon\Policies\", "c:\profiles\policies\", "MyUDFS.kix", "MyUDF Kixtart Script")
Just a quick explanation of exactly what is happening in the above script. Filexist is a UDF that I use to check if any given file exists and if the file does not exist, then the script copies the file across.
As you can see I have told the script to copy the task to the Policies folder within the area where all the tasks are stored. The reason I have created a directory called Policies is twofold. It means that I can have one location where all my custom made scheduled tasks will be stored and secondly in order to enable the standard user to run the scheduled task we need to grant NTFS permissions to the directory where the scheduled task is located. As such it is preferable to grant execute NTFS permissions to a subfolder of the main Tasks folder otherwise you are allowing standard users too much access.
This step is where I had the most problems i.e. working out why the scheduled task was either not running or the script was not doing what it was supposed to be doing. Windows 7 task scheduler is damnably tricky.
Step Five:
In the main logon script, you will need to extract the UserID of the current logged on user and then save this information to a file somewhere, so that when the scheduled task runs, it can read this information from the file and thus modify the correct registry keys. You will also need to tell the script to run the scheduled task which in turn will run the script that requires elevated privileges.
;=======================================
;Calling the Policies script
;=======================================
SetUserSid (@SID)
shell 'schtasks /run /tn microsoft\windows\policies\MYPolicy'
As you can see in the above script, I have told the script to run the scheduled Task called MyPolicy and I have used a function to save the SID information of the logged in user to a file.
The function that I created is as such:
;================================================================================================
; This Writes the User Sid for the logged on user to a file
;================================================================================================
Function SetUserSid($SID)
IF Open( 3 , "c:\profiles\policies\UserSid.txt" , 5 ) = 0
$x = WriteLine( 3 , $SID)
IF Close(3)
Beep
? "Error closing file!"
ENDIF
ELSE
BEEP
? "failed to open file, error code : [" + @ERROR + "]"
ENDIF
EndFunction
So essentially what happens is the following:
1. The computer boots up and copies from the netlogon folder the kix32.exe Myudfs.kix and policies.kix files to the c:\profiles\policies location on each computer.
2. The startup script also copies the MYPolicy.xml task to the Policies subdirectory within the Tasks\Microsoft\Windows folder where all the other tasks are stored.
3. The startup script sets the appropriate permissions to allow a standard user to run the task from that location which is the policies subdirectory.
4. Once the user logs in, the logon script extracts the SID information for the logged on user and saves this information to a file called UserSid.txt within the c:\profiles\policies directory
5. Then the logon script runs the MYPolicy task. From this point on, we will be running the script within the user context of the scheduled task and not the logged on user.
6. The first thing the script that is run by the scheduled task does, is reads the User Sid information from the Usersid.txt file and stores that information in memory.
7. Then the script writes the settings to the protected keys within the registry using the SID information extracted from the file to determine the correct location in the registry where to write the files.
Following disclaimers apply:
The above information is correct for windows server 2008, Windows 7 Professional and kixtart version 4.62
I am not responsible if you mess up your computer. You backup first and then attempt to use this step by step guide.
I will at some point in the near future, tidy up the coding of the functions as not desirable to have the actual directory paths contained within the function. But I need a massive break from this particular project as it was a nightmare getting the task scheduler working properly. It looks so easy following the above, but the above was done by trial and error.
If the moderators of the forum like my Guide to elevating the script, I will endeavour to get the coding tidied up so that you can move this step by step guide to the FAQ section where this should really go. I tried to post it there, but I don't have permission to post in that forum. I think that this guide would be very useful to have as too many people (myself included) over the years have used insecure methods in order to get scripts to run as administrator.
I have used this method as I only wanted to write to 8 registry locations that are protected, however if you have a system where you require a considerable amount of your script to be elevated and/or you have a huge network, my method is not the most desirable particularly as at this point in time, I am obliged to copy the scripts to each computer so that the system account can run the script due to the fact that system scheduled tasks cannot access network resources.
If you require a more scalable solution or a simpler solution, I would recommend that you contact Glenn Barnas on this forum, who has developed a paid for solution that allows for a much more scalable solution in that his solution is almost entirely server based in that very little if any bandwidth is used transferring files across the network
Any questions or suggestions welcome. Rob
Edited by Robdutoit (2012-09-23 10:50 AM)
Edit Reason: removed a typo
|
|
Top
|
|
|
|
#205801 - 2012-09-23 10:57 AM
Re: Step by Step guide to running a script with elevated or admin privileges
[Re: NTDOC]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
Oh you are most welcome NTDOC. I have had quite a few people help me on this forum with different things, so its the least that I can do. Also I feel that there is a lot of information out there on how to write scripts, but very little with regards to elevating scripts in a secure manner.
I totally agree with you. I don't want the kixtart script that needs elevation to be copied to each machine. Very undesirable, but until I can find a way to run the scheduled task as a domain admin without exposing the password, I will have to copy the kix files across. The problem with the schtasks command is that I would be required to enter the password within the script which defeats the whole point of the exercise. By using the system account, I don't need a password, but then you can't access network resources. so you are basically damned if you and damned if you don't.
Today, I actually feel like working on this issue to see if I can find a way to import the task with the username and password intact within the xml file.
I hope that somebody finds this of use!
If you want to thank me, I am very fond of chocolates 
|
|
Top
|
|
|
|
#205802 - 2012-09-23 11:29 PM
Re: Step by Step guide to running a script with elevated or admin privileges
[Re: Robdutoit]
|
Robdutoit
Hey THIS is FUN
Registered: 2012-03-27
Posts: 363
Loc: London, England
|
For further reading, I came across this article on the kixtart forum which may be relevant for some people. This technique won't work for me because I require admin privileges to set 8 reg keys on user login whereas the technique mentioned in the article below uses a system where the server schedules the task by which time its too late for my purposes as I need the settings applied when the user logs on, not an hour later!
but I will post the link just for reference purposes
http://kixtart.org/forums/ubbthreads.php?ubb=showflat&Number=12784#Post12784
I have decided that what I will do with my method is at some point in the future I will endeavour to find a way to write the registry keys to a file on the netlogon folder and run the server task scheduler on demand remotely from the script to run the elevated script from the server and apply the settings. I am not happy with the approach of having to copy the scripts from the netlogon folder down to the client. So in the near future when time permits I will address the issue. It will also eliminate the requirement to copy the task down to each client, so this will be the approach that I will implement in the near future.
I attempted to do this today, but while I could write the registry keys that needed modifying to the text file, I couldn't work out how to extract the information from the text file in the manner of breaking up the line in the file into regpath, regkey, regvalue and regtype. So I will get this sorted out when I feel like coming back to it.
|
|
Top
|
|
|
|
|
#205803 - 2012-09-24 09:04 AM
Re: Step by Step guide to running a script with elevated or admin privileges
[Re: Robdutoit]
|
NTDOC
Administrator
Registered: 2000-07-28
Posts: 11629
Loc: CA
|
|
|
Top
|
|
|
|
|
#206133 - 2012-11-07 07:02 PM
Re: Step by Step guide to running a script with elevated or admin privileges
[Re: Robdutoit]
|
Glenn Barnas
KiX Supporter
Registered: 2003-01-28
Posts: 4401
Loc: New Jersey
|
IMPORTANT!! You don't need to run any task as a DOMAIN ADMIN, only as a LOCAL ADMIN. Thus, any domain account (such as ComputerAdmin) that is a member of local Administrators group (either directly or by something like Computer Administrators or Server Administrators group) will have all access rights necessary to a local workstation or server without being able to perform any domain management tasks. Thinking that you need Domain Admin rights to manage servers or workstations is one of the biggest security holes around.
As for our web site - we've been impacted by Hurricane Sandy - UPS batteries drained, standby generator failed, 9 days and counting without power. We hope to be back up by Monday, 11/12/12, if the Nor'Easter that's hitting right now doesn't make things worse.
The tcLib UDF library has all the components you need to perform a task remotely, from creating the task event to triggering it on command. Just define the command, arguments, and credentials, call the tcSetEvent UDF, and then the tcExecute UDF. As little as 4 lines of code in your script [tcInit(), tcDefineTask(), tcSetEvent(), and tcExecute()].
Glenn
_________________________
Actually I am a Rocket Scientist! 
|
|
Top
|
|
|
|
|
#207146 - 2013-04-21 04:42 AM
Re: Step by Step guide to running a script with elevated or admin privileges
[Re: Lonkero]
|
Easter_bunny
Fresh Scripter
Registered: 2013-04-11
Posts: 18
Loc: hong kong
|
Hello Lonkero
I followed your suggestion and made a new posting
here http://www.kixtart.org/forums/ubbthreads.php?ubb=showflat&Main=27755&Number=207138#Post207138
There is more information there, concerning use of Linux server and the keys needing to change.
I would appreciate your wise and experienced comments.
If there is more information required, no problem I will add to the post.
Thank you
Berni
|
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 1179 anonymous users online.
|
|
|
