|
|
|||||||
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: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.$schedulercmd = 'jt.exe' 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 ] |
||||||||
|
|
|||||||
Jens, You got my vote and interest on this topic. I'm all for anything that meets the needs without having to install anything on all the client's PC and that doesn't compromise security! Looks good. can't wait to see what's "under the hood". |
||||||||
|
|
|||||||
Yes, I'll second that Les's vote. At first I was impressed by the idea and concept, then later impressed with your style and presentation ... Is this kinda like a roll-you-own Tivoli ? I was pondering the idea that Bryce threw out last night (custom SU service, taking requests only from authenticated logon script context) and how this would mesh with that idea. But really, your talking about different approach here ... I think both ideas have merit ... -Shawn |
||||||||
|
|
|||||||
Yeah, you hit the holy Grail !! You get my vote too, and after digging into IE 4 SP2, it seems to have the same task scheduler, so maybe no need for IE 5.x So long with a such possibility under our eyes, thanks Sealeopard to open them |
||||||||
|
|
|||||||
MS finaly released a command line interface for their new task scheduler sevice! Yea the client/server model really is the best way to go. Just a few keypoints, be sure to validate that the request are being generated from the logon script, this is easy to do using see this thread "finding a programs parrent process"
Bryce |
||||||||
|
|
|||||||
Bryce, So what is the logon script's parent process (winlogo(i)n?) ... and could one "spoof" that ? -Shawn |
||||||||
|
|
|||||||
yea, the winlogon would be the parent process of a logon script. a user ran script will show up under the shell (explorer, taskmgr, cmd.exe...). I don't think that a user could spoof this. Bryce |
||||||||
|
|
|||||||
You vultures of the Kixtart BBS. Here's a script to take apart, disect, piece back together and gain universal wisdom ;-) Download the demo scripts that I talked about in my little how-to at this location: http://people.bu.edu/jenmeyer/kixtart/kixtart_demo.zip (This link will no longer work because the information contained in this ZIP file has been superseeded with the information in the following article: http://81.17.37.55/board/ultimatebb.php?ubb=get_topic;f=2;t=002897) Please be advised that I do not take any kind of responsibility for lack of sleep resulting from the reading/implementing/disecting/reconfiguring of these scripts. Enjoy, Jens [ 27 March 2002, 14:53: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
I'm not a vulture ... I'm a Dingo ... A dingo ate your script !!! |
||||||||
|
|
|||||||
I hope you had fun digesting it Jens |
||||||||
|
|
|||||||
Wow Jens, quite a bit to digest. Looks great from a minor review. Some great ideas for other things in here also. Looks like your almost running your own Policies from within a script. Thanks for sharing the info and ideas, all I can say is SH*T great stuff. How long have you been working on this script? Can't wait till a release version of KiXtart 2001 - There is some really cool stuff in the new version. I just can't deploy till it is a release version. But I will try to do some of these ideas in v3.63 code for now. [ 04 October 2001: Message edited by: NTDOC ] |
||||||||
|
|
|||||||
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 |
||||||||
|
|
|||||||
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.
|
||||||||
|
|
|||||||
No documentation whatsoever. I had to do a code:for each command in order to get a complete list of JT commands. Also, there is virtually no documentation on the Web (especially the Microsoft websites). It's almost as if microsoft doesn't want us to use the command line version. first not including it in the Reosurce Kit but in a supplement, then I had to download it from their FTP server, then I can't find any documentation,...JT.EXE /? AAAAHHHHH!!! Jens [ 04 December 2001: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
You can now find a simple task scheduler UDF at http://kixtart.org/cgi-bin/ultimatebb.cgi?ubb=get_topic&f=12&t=000060 |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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. |
||||||||
|
|
|||||||
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 [ 05 December 2001: Message edited by: Will Hetrick ] |
||||||||
|
|
|||||||
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? |
||||||||
|
|
|||||||
Hi Jens, Sorry for reopening this thread all over again. I read your article in detail and followed it but ran into a problem. I am sure you have a fix for it. So, here goes... I took your code and put it in a batch file for testing. Here is what batch file looked like: code:The credentials it is using in the JT.EXE commandJT.EXE /CTJ StartDate=TODAY StartTime=NOW line are of a Domain Admin account and I am scheduling the job on the local computer with a non-privileged account (that is how I am logged on). It works great the first time and the job executes and gets deleted when finished. The problem is that when execute the same batch file a second time, I get the following error: code:Looking at the c:\winnt\SchedLgU.txt reveals the following problen:[TRACE] Created trigger 0 code:Doing some research, found the following KB article at Microsoft:"Test.job" (test.exe) 11/8/2002 10:27:00 PM ** ERROR ** Scheduled Task Does Not Run... It sounds like even though the job is getting deleted, the security descriptor is still being kept in the database against that job name and deleting ity is breaking it and can never be used again. So here I am seeking the advice of the masters of this trade. Please help! Thanks! Anupam Agarwal [ 09. November 2002, 05:56: Message edited by: Anupam Agarwal ] |
||||||||
|
|
|||||||
Anupam, Please edit your last post and break the long lines as it really messes up the entire thread. |
||||||||
|
|
|||||||
Long Line Police in action |
||||||||
|
|
|||||||
Thanks Les. I just fixed it. |
||||||||
|
|
|||||||
quote:That's right, as a safety measure it wil not continue. Comment the return if you don't want this feature. ; delete a potentially existing task $shellcmd=$jtexe+' /SM \\'+$computer+' /SD +$taskname shell '%COMSPEC% /e:1024 /c '+$shellcmd if @ERROR $scheduletask=@ERROR ; return endif |
||||||||
|
|
|||||||
In my original post, I have the flag code:So the job gets deleted as soon as it is finished running.DeleteWhenDone=1 If I run the above recommended script to delete the job, I get an error because the job does not exist. I tried setting the flag code:and then run the above script to delete the job in which case,DeleteWhenDone=0 the job gets deleted without errors. In either case, my original script still fails with same error. There are couple other interesting things to note: 1. Once I run my batch file with the specified credentials and successfully schedule the job, run it, and delete it, I cannot schedule any job with those credentials again (that is, even if I change the job name). I get the same error. 2. I was able to run my batch file and schedule the job this morning with the same credentials which was failing last night. And now I cannot run it again. But I am sure it will start working in several hours. Which tells me that the local security database eventially purges the credentials. I don't know what governs that time out or if I have any control over it. 3. Another piece of information is that when my batch file fails and I get the error, the job still gets set in the scheduler but with the logged on user's credentials instead of the credentials supplied on the command line. And the job never runs either. It just sits there and does nothing. Sorry for these long emails but I think I need to explain as much troubleshooting informatiuon as I already have. Thanks you again for helping me out with this. Anupam |
||||||||
|
|
|||||||
I've never seen this behavior, however I've never scheduled anything other than once-a-day schedules. Nevertheless, it sounds more like a problem with either the Task Scheduler or the JT.EXE CLI. In any case, there's nothing I can do about. I'll play around with JT.EXe a little bit and see what I can find. Do you have the same behavior if you manually schedule tasks with the Task Scheduler wizard? P.S.: It would have been better to create a new thread with this specific problem and reference this thread as outlined in ABC's of KiXtart board etiquette and message to new forum users [ 10. November 2002, 03:20: Message edited by: sealeopard ] |
||||||||
|
|
|||||||
Jens, Looks like the problem is with the scheduler service itself. Scheduling the job manually using the wizard generates the exact same error. However, if you are logged on with admin rights, everything works okay. This tells me that the credentials are stored in tha local secutiry database. The database purges old information after some time by itself (don't know how long). Admin rights are needed to overwrite information in this database. I am not sure where we go from here. The only thing I can think of is to figure out a way to change the database refresh interval if possible or delete the credentials from it when the job is deleted. I guess I am expecting magic or miracle here. Thanks, Anupam |
||||||||
|
|
|||||||
Question: Did your problems start around the same time your computer switch 'Daylight Savings Time'? Then it is a documented problem with the Task Scheduler. See also Scheduled Task Does Not Run After You Push the Task to Another Computer about a comment regarding the protected storage database. |
||||||||
|
|
|||||||
I hve seen that article. It was a link in the article I posted in my original post. Where is the article about the daylight savings problem? In my earlier posts, when I mentioned local security database, I was actually referring to the protected storage database. I was expecting that when the job is deleted, the password should also get deleted from the protected storage database. As I said earlier, the password does enevtually get dropped from it but I don't know if we have any control over the timing of it from the registry etc. Thanks, Anupam |
||||||||
|
|
|||||||
There are discussions in a couple of newsgroups about this issue, however no solutions. Use Google to search the newsgroups for your specific error code. |
||||||||
|
|
|||||||
I found the article about Daylight Savings Time issue with the Task Scheduler unless you were referring to a different one. According to this article, the problem only happens during the one hour of fall back and one hour of spring forward. So, I am thinking that this is probably not what is causing my issue. |
||||||||
|
|
|||||||
Jens, If you want to prune off Anupam's portion from this thread then just ask Howard to move the entire thread to one you are moderator of, making sure he doesn't delete the original. You will then have two copies. On your copy, delete everything up to Anupam's first post, rename it, and move it back. Howard could then delete Anupam's portion from the original and you'd have effectively split it into two separate threads. |
||||||||
|
|
|||||||
Les: Sounds good. Just be aware that I'll be offline from about this post until around 6pm. I will then remove these last two posts in order to clean up the thread. |
||||||||
|
|
|||||||
Guys, I am really sorry about messing up the old thread and making you guys go through all this work. I do want to put another update here. I ran a test batch file that scheduled and deleted the job at one minute interval with the same credentials and recorded the time and status in a log file. It turns out that there are exactly 12 hours between successes which means that once a job is scheduled and deleted, it cannot be rescheduled with the same credentials for the next 12 hours. Thanks, Anupam |
||||||||
|
|
|||||||
Then why not set up a continous task that e.g. repeats itself every 4 hours or whatever else the interval is? |
||||||||
|
|
|||||||
If you setup one 'generic' task that runs a KiX script, you need only change the acompanying script. The task itself can remain. |
||||||||
|
|
|||||||
Both of those are good ideas but then I don't have as much control over when I want things to happen. For example, I wanted to add this in the logon script such that if there is a missing element on the workstation, it would fire off a job and make the required change which requires admin permissions. A set interval will only happen whenever the interval expires. I could live with it but not an elegant solution. I wil continue my research on this and keep this (or the new thread if you decide to create one) posted for your information. Thanks again for all the valuable help. Anupam |
||||||||
|
|
|||||||
Take a look at KiXtart Systems Management Server (Part III, The Client) [a.k.a The Complete Package] |
||||||||
|
|
|||||||
Anupam, What you might want to consider is to move the workload from the logon script to the scheduled one. Why burden the users with it during logon? That is when they are the most annoyed. Also there's the issue of users that never logoff. You can't catch them until they logon again. |
||||||||
|
|
|||||||
I have two cents.... I have read all the info on getting the script to run with admin powers and what not. I haven't tried the scheduler, I will be trying that soon. But a little while ago I found a small scripting utility called AutoIt that will allow me to use the Win2K "run as" command. I use the login script to call the AutoIt script which in turn calls the kix script that needs admin privs, HKLM hacks and what not. It ships with a compiler so I just package it into an exe and put the exe on the domain controller. The compiler has a password feature so you can have some added protection. Just a thought.... |