#12765 - 2001-10-03 04:41 PM
HOW-TO: Running scripts with ADMIN powers
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
Everybody:
Every couple of days I'm reading postings about how to use SU.EXE to run something under an administrative account. A lot of people have difficulties getting it to work since it requires a service to be installed on the computer running SU. Additionally, providing the account name and password is not entirely secure.
I have been working on a client-server-based maintenance script for the last couple of weeks that runs under Kixtart 4.0.
I opted not to use the SUSS service and SU due to security concerns. Alternatively, one can set the scheduler service in Windows NT to run under an administrative account instead of the SYSTEM account. This is also not a practical solution if you're maintaining tens or hundreds of computers. Fortunately, all our computers are running at least Microsoft Internet Explorer 5. IE 5.x+ comes with a component ('offline synchronization') that replaces the scheduler service with the 'Task Scheduler'. The task scheduler runs under the SYSTEM account which cannot be changed. The advantage of the task scheduler over the scheduler service is that the task scheduler allows to run scheduled commands under arbitrary user accounts.
What does that mean? It means that I can scheduler a command to run every night under the user account COMPUTERNAME\Administrator. This command runs with all the rights of the assigned user regardless of whether another user is logged in or not. Additionally, the task scheduler prevents users to see what other users have scheduled. Thus, I can schedule administrative scripts without ordinary users knowing that there is something running in the background.
How do I do it? The easiest solution is to use the task scheduler wizard to set up a task for a specific user. This task is saved in a special task scheduler folder under %SYSTEMROOT% and can be copied for one computer to another. Another solution is to download the Task Scheduler Command line Interface which is part of the Windows 2000 Resource Kit Supplement 3 (ftp://ftp.microsoft.com/reskit/win2000/jt.zip).
This CLI is the holy grail to the task scheduler and explaining every option is beyond the scope of this HOW-TO. Thus I will only hightlight features: - remote scheduling of tasks - load and save predefined tasks - execute tasks once, daily, weekly, on-idle, at-startup, at-logon (useful features for laptops) - delete tasks - triggers
I really recommend downloading the CLI and reading the documentation, it comes very close to all the powerful *NIX schedulers.
Following is an example of how to use the CLI:
code:
$schedulercmd = 'jt.exe' $schedulercmd = $schedulercmd + ' /CTJ StartDate=TODAY' $schedulercmd = $schedulercmd + ' StartTime=NOW' $schedulercmd = $schedulercmd + ' HasEndDate=0' $schedulercmd = $schedulercmd + ' KillAtDuration=0' $schedulercmd = $schedulercmd + ' Disabled=0' $schedulercmd = $schedulercmd + ' Type=ONCE' $schedulercmd = $schedulercmd + ' /SC DOMAIN\adminuser adminuserpassword' $schedulercmd = $schedulercmd + ' /SJ ApplicationName="maintenance_server.bat"' $schedulercmd = $schedulercmd + ' Parameters=""' $schedulercmd = $schedulercmd + ' WorkingDirectory="%SYSTEMROOT%"' $schedulercmd = $schedulercmd + ' Comment="Kixtart Maintenance Server Script"' $schedulercmd = $schedulercmd + ' Creator="Administrator"' $schedulercmd = $schedulercmd + ' Priority=Normal' $schedulercmd = $schedulercmd + ' MaxRunTime=21600000' $schedulercmd = $schedulercmd + ' DontStartIfOnBatteries=0' $schedulercmd = $schedulercmd + ' KillIfGoingOnBatteries=0' $schedulercmd = $schedulercmd + ' RunOnlyIfLoggedOn=0' $schedulercmd = $schedulercmd + ' SystemRequired=0' $schedulercmd = $schedulercmd + ' DeleteWhenDone=1' $schedulercmd = $schedulercmd + ' Suspend=0' $schedulercmd = $schedulercmd + ' StartOnlyIfIdle=0' $schedulercmd = $schedulercmd + ' KillOnIdleEnd=0' $schedulercmd = $schedulercmd + ' RestartOnIdleResume=0' $schedulercmd = $schedulercmd + ' Hidden=0' $schedulercmd = $schedulercmd + ' TaskFlags=0' $schedulercmd = $schedulercmd + ' /SM \\'+@WKSTA $schedulercmd = $schedulercmd + ' /SAJ maintenance_server_once.job' $schedulercmd = $schedulercmd + ' /SAC maintenance_server_once.job' $schedulercmd = $schedulercmd + ' /RJ'
shell $schedulercmd
The batch file I'm calling creates a drive share to the Z: drive and connects to a hidden fileshare on the PDC containing the Kixtart scripts and utilities. Thus, the real stuff is hidden from the user.
How to implement this? I created an administrative group called KIXTART on my PDC and created a user KIXTARTUSER wich is a domain administrator. Thus, this user has full administrative rights on all client computers and has access to networked resources, something that a local administrator might not have. I'm running a script called MAINTENANCE_SERVER on my PDC which reads an INI file containing a list of Windows NT/2000 computers and the type of scheduler they are using (scheduler, or task scheduler). This INI file is updated throught a login script, thus if somebody logs into a computer, the information gets written into the INI file and tasks can be scheduler the next time the MAINTENANCE_SERVER script runs. The server script checks whether the computer is accessible through an admin share ADMIN$. If this is not the case the server script sends a magic packet to the specified computer and if the computer has a WOL ethernet adapter, it'll start up. Then the server script waits a couple of minutes until either the computer woke up or no successful wake-up is detected (no access to ADMIN$ after five minutes). If the computer is accessible the server script sends a task scheduler command via the JT.EXE CLI to the remote computer. The remote computer then executes the scheduled command at the specified time under the KIXTARTUSER administrator context. The maintenance client script does its thing, mainly adjusting registry keys in the HKEY_LOCAL_MACHINE part, installs software updates, and whatever other task requiring admin privileges. I'm also using the Kixtart SHUTDOWN command to reboot computers and use the auto-login to set up e.g. Internet Explorer 5.5 SP2 with a package prepared with the Internet Explorer Administrator Kit 5.5.
I hope this rather long post give you some food-for-thought. The setup I'm using in our production environment consists of a simle login script, the maintenance_server and the maintenance_client scripts. The maintenance scripts are only accessible to administrators, thus there is not chance that users will discover admin passwords since the Task Scheduler does not provide a clear-text display of the account passwords.
Jens
P.S.: I'm willing to sanitize my scripts a little bit and make them publicly accessible if there is interest. The complete package will be about 1 MB uncompressed and will contain the scripts, UDFs, required executables and some configuration files. [ 02. June 2003, 21:51: Message edited by: sealeopard ]
_________________________
There are two types of vessels, submarines and targets.
|
Top
|
|
|
|
#12773 - 2001-10-03 11:11 PM
Re: HOW-TO: Running scripts with ADMIN powers
|
Shawn
Administrator
Registered: 1999-08-13
Posts: 8611
|
I'm not a vulture ... I'm a Dingo ... A dingo ate your script !!!
|
Top
|
|
|
|
#12776 - 2001-10-04 05:06 PM
Re: HOW-TO: Running scripts with ADMIN powers
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
NTDOC:I originally started some work on it in May because I wasn't satisfied with the Kixtart 3.63 login script that I was using. It first started out as a login script port to 4.0. Now I'm already using 4.0 RCx for about eight weeks in our production environment, and if you ask me, Kixtart is definitely ready for deployment (I'm not using WMI). Then I got out of control because of the flexibility that Kixtart UDFs allow. Finally, I found the Task Scheduler command line interface and went crazy over the options presented within. The main thing I like about my solution is that most of the work has been moved outside the standard login script, making it fast and simple. Since our computers are switched on 24/7 it's very convenient to do the serious maintenance at night. Finally, I tried to implement most of the stuff in such a way that it does not require changes to the scripts itself. It should be sufficient to change an INI file or e.g. add a link to the LNK directory in order to have that link installed on the client machine. Jens
_________________________
There are two types of vessels, submarines and targets.
|
Top
|
|
|
|
#12777 - 2001-12-04 05:03 AM
Re: HOW-TO: Running scripts with ADMIN powers
|
tech_guy
Fresh Scripter
Registered: 2001-12-02
Posts: 17
|
First, I want to suck up. Not only is this Bulletin Board great software, the people on it are great as well!I don't find jt.exe in my Technet stuff. Is there a *.chm to go with the jt.exe program? The download was only the exe and a license file. Thanks again to the folks on this list that have helped me. Mike
|
Top
|
|
|
|
#12780 - 2001-12-05 12:26 AM
Re: HOW-TO: Running scripts with ADMIN powers
|
Brian Parris
Fresh Scripter
Registered: 2001-12-03
Posts: 9
Loc: US
|
MS needs to add the option of having the login script run as administrator, then kixtart could simply process it's commands as the user it's logging in unless you specify a username to run a command as. This method would be very secure as the workstation would get kix32 and the script right from the Domain Controller. While your script will help with alot of things, it will not work with items that need to run as administrator WHILE the user is logging in.
_________________________
Brian Parris
Manager, Ameritech Reliability Center
PC LAN Administration & User Support
Email: bp3959@sbc.com
Office: (312) 424-2084
Pager: (312) 514-2921
|
Top
|
|
|
|
#12781 - 2001-12-05 12:34 AM
Re: HOW-TO: Running scripts with ADMIN powers
|
Sealeopard
KiX Master
Registered: 2001-04-25
Posts: 11164
Loc: Boston, MA, USA
|
Sorry, but I have to diagree. The user login script should be run under the suer context. If the login script needs to perform a certain task under an administrative account, then there are a couple of solutions for that. You could schedule the task via Task Scheduler, or use SU. Personally, I'm using a client-server maintenance script based on Kixtart. If the login script detects that something needs to be done on a certain computer that requires administrative privileges, then it's scheduled for nightly maintenance. This way, I'm currently distributing Office 200x updates, install/update Norton Antivirus, and make all kinds of configuration changes.A user should never have administrative privileges for anything. There is always a workaround.
_________________________
There are two types of vessels, submarines and targets.
|
Top
|
|
|
|
#12782 - 2001-12-05 12:48 AM
Re: HOW-TO: Running scripts with ADMIN powers
|
Brian Parris
Fresh Scripter
Registered: 2001-12-03
Posts: 9
Loc: US
|
The user would not have administrative privledges with my suggestion, only the login processor would, and the login processor could allow the login script(not the user) to run certain commands as administrator instead of running them as the user. SU is a huge security risk, by doing that you are giving the user administrative rights, they can simply look at the script and get the administrator pass, duh.
_________________________
Brian Parris
Manager, Ameritech Reliability Center
PC LAN Administration & User Support
Email: bp3959@sbc.com
Office: (312) 424-2084
Pager: (312) 514-2921
|
Top
|
|
|
|
#12783 - 2001-12-05 02:54 PM
Re: HOW-TO: Running scripts with ADMIN powers
|
Will Hetrick
Hey THIS is FUN
Registered: 2001-10-02
Posts: 320
Loc: Harrisburg, PA USA
|
I am not sure if this is what you are talking about, but I have been using this kix script from my PDC to install Mcafee using the task scheduler. Take a look.
code:
break on ? "Please input the Computer name to connect to. " Gets $remote_pc if @inwin=2 exit endif Do $tempfile = "timestamp.txt" $source = "c:\source\*.*" ;'disconect j:\ and map j:\ to to remote pc's C$ $drive = "\\" + $remote_pc + "\c$" use j: /delete use j: $drive if @error = 0 beep ? "Connected to Remote computer Successful." else ? "Cannot connect to the share " Goto getpc endif ;'copy source of the program instal to remote C:\instaldir (including instal.bat) ----- ;'You can leave the source also on a win95 share, but not on a NT share ;'that's because te remote NT scedule service runs under system acount ;'This acount can not logon to NT shares. ;'At least instal.bat should stand on c:\instaldir ;'Instal.bat (YOUR UNATENDED instal file) should install the program ! ;'This script let the remote machine acount run instal.bat instead of the user ;'As users cann't install apps on NT, and users are potential security risks. if exist("j:\instaldir\*.*") else md "j:\instaldir\" endif if exist("J:\instaldir\zcheck.txt") else ? "Copying Files" copy "$source" "j:\instaldir\" endif ? "Finished Copying Files" ;' start the schedule service remotely ---------------- ;' this part is later because need to give service time to enable itself $runner = "SC.EXE \\" + $remote_PC + " start Schedule" run $runner sleep 10 ? "Schedule is started." ;'retrieve remote time by reading remote file creation time stamp ;'That's a importend one of the clevar idea's behind it ;'Because my problem was always time differences between target and remote machines ;'now this works against the remote time ;'The function is a bit complex as remote time could be in different formats ;'And Also because of a bug in IExplorer 5.x need at least to schedule remote over 15 minutes :gotime $filetime = @TIME $MINUUT = Val(substr($filetime,4,2)) $UUR = Val(substr($filetime,1,2)) if $Minuut > 44 $Uur = $Uur + 1 $Minuut = $Minuut - 45 else $Minuut = $Minuut + 15 endif ? $minuut ? $Uur $FILETIME = "$UUR:$MINUUT:00" ; $Filetime = "10:45:00" $Command = "AT \\" + $remote_pc + " " ? $Filetime shell $command + $FILETIME + " c:\instaldir\setup.exe -s" ; run $command + $FILETIME + " %windir%\zawsys\wkix32.exe %windir%\zawsys\rv-logon.kix" ? ? "Setup is scheduled" ? sleep 5 ;' Remove the temporaly mapped drive from this machine use j: /delete ; Get another computer name :getpc ? "Type exit to quit" ? "Please input the Computer name to connect to. " flushkb Gets $remote_pc Until $remote_pc = "exit" exit
[ 05 December 2001: Message edited by: Will Hetrick ]
_________________________
You have at least 2 choices. Each choice changes your destiny. Choose wisely!
|
Top
|
|
|
|
#12784 - 2002-01-21 04:19 AM
Re: HOW-TO: Running scripts with ADMIN powers
|
Mills
Lurker
Registered: 2002-01-21
Posts: 1
|
In the example scripts I noticed that the maintenance server scripts are located in a hidden share which may be readable to all users. The log and db directories within that share are written to from the login script.What keeps a user from reading your maintenance scripts and getting the domain admin account you have there?
|
Top
|
|
|
|
Moderator: Jochen, Allen, Radimus, Glenn Barnas, ShaneEP, Ruud van Velsen, Arend_, Mart
|
0 registered
and 557 anonymous users online.
|
|
|