centralpressure Posted September 23, 2009 Share Posted September 23, 2009 I have a situation where computers sent out in the field that have no internet access and only limited user accounts need to have the Daylight Savings Time patch installed. We do not want to give the administrator password out, and so I was looking to create a Runas file that the limited user could apply. I created a test script, but on a limited user account when you double click the file, you get the hour glass then nothing. Any thoughts? I am a complete newbie at this, and appreciate any help. Here is what I had written: Local $sUserName = "Admin" Local $sPassword = "test1" $comp = @ComputerName RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe") Link to comment Share on other sites More sharing options...
PsaltyDS Posted September 23, 2009 Share Posted September 23, 2009 I have a situation where computers sent out in the field that have no internet access and only limited user accounts need to have the Daylight Savings Time patch installed. We do not want to give the administrator password out, and so I was looking to create a Runas file that the limited user could apply. I created a test script, but on a limited user account when you double click the file, you get the hour glass then nothing. Any thoughts? I am a complete newbie at this, and appreciate any help. Here is what I had written:Local $sUserName = "Admin"Local $sPassword = "test1"$comp = @ComputerNameRunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe")Coding admin credentials into a script makes Bad JuJu! Create a batch file to simply run "D:\WindowsXP DST Update.exe" and then schedule that batch file to be run once by the task manager using SchTasks.exe. You can schedule the task remotely to run under an admin user, the console user is not involved, and no credentials have to be passed around. Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law Link to comment Share on other sites More sharing options...
centralpressure Posted September 23, 2009 Author Share Posted September 23, 2009 Coding admin credentials into a script makes Bad JuJu! Create a batch file to simply run "D:\WindowsXP DST Update.exe" and then schedule that batch file to be run once by the task manager using SchTasks.exe. You can schedule the task remotely to run under an admin user, the console user is not involved, and no credentials have to be passed around. PsaltyDS, thanks for the heads up. Something new for me to learn. I appreciate the help. Since I would have to create the batch file on a CD to send to the site, wouldn't I still have to put the admin credentials into the file? Link to comment Share on other sites More sharing options...
PsaltyDS Posted September 23, 2009 Share Posted September 23, 2009 PsaltyDS, thanks for the heads up. Something new for me to learn. I appreciate the help. Since I would have to create the batch file on a CD to send to the site, wouldn't I still have to put the admin credentials into the file?Ouch! I thought you had at least LAN access to them and would be doing it all remotely. Just keep in mind that a compiled script is NOT secure and any credentials you put in there should be considered compromised as soon as you mail it out. Maybe that's not a big deal if it's only the admin credentials on that one machine, but if the same credentials are used on many machines you have opened a new hole in your security config. Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law Link to comment Share on other sites More sharing options...
rvn Posted September 24, 2009 Share Posted September 24, 2009 Local $sUserName = "Admin" Local $sPassword = "test1" $comp = @ComputerName ;RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe") RunAs($sUserName,$comp,$sPassword,0,"D:\WindowsXP DST Update.exe") ; apps full path must valid $sUserName & $sPassword must be valid rigth?! Link to comment Share on other sites More sharing options...
centralpressure Posted September 24, 2009 Author Share Posted September 24, 2009 Local $sUserName = "Admin" Local $sPassword = "test1" $comp = @ComputerName ;RunAs($sUserName,$comp,$sPassword,0,"D:\ WindowsXP DST Update.exe") RunAs($sUserName,$comp,$sPassword,0,"D:\WindowsXP DST Update.exe") ; apps full path must valid $sUserName & $sPassword must be valid rigth?! I double checked the username and password (obviously not what I have in the example) and they are correct. It works now, I believe I had an extra space in the executable path. New question though, it has been brought to my attention that certain laptops may have the CD-ROM drive labelled as E:, is there code that I can use to determine drive letter and to direct the script to run from there? Thanks. Link to comment Share on other sites More sharing options...
TurionAltec Posted September 24, 2009 Share Posted September 24, 2009 I double checked the username and password (obviously not what I have in the example) and they are correct. It works now, I believe I had an extra space in the executable path.New question though, it has been brought to my attention that certain laptops may have the CD-ROM drive labelled as E:, is there code that I can use to determine drive letter and to direct the script to run from there?Thanks.Easy thing would be if the script was on the CD as then you could use @ScriptDir.Another option:DriveGetDrive ( "type" )type Type of drive to find:"ALL", "CDROM", "REMOVABLE", "FIXED", "NETWORK", "RAMDISK", or "UNKNOWN" A potential risk if the update is a separate file is "WindowsXP DST Update.exe" could be replaced by any other executable, which could give the limited user full access. In which case you may want to either use Fileinstall, and/or check the integrity of the executable by comparing the CRC or MD5 or somesuch. Link to comment Share on other sites More sharing options...
TurionAltec Posted September 24, 2009 Share Posted September 24, 2009 (edited) Local $sUserName = "Admin" Local $sPassword = "test1" $comp = @ComputerName FileDelete(@tempdir&"\WindowsXP DST Update.exe") If FileExists (@tempdir&"\WindowsXP DST Update.exe") ==1 Then msgbox(16,"Error", "File Exists, setup aborted") Exit EndIf Fileinstall("c:\script\WindowsXP DST Update.exe",@TempDir) ;File must by in c:\script\WindowsXP DST Update.exe on the computer used to build the script ;Will be stored in @tempdir of the target machine once the script is compiled. RunAsWait($sUserName,$comp,$sPassword,0,@tempdir&"\WindowsXP DST Update.exe") ;Waiting until complete FileDelete(@tempdir&"\WindowsXP DST Update.exe") ;Cleanup after we're done. Edited September 24, 2009 by TurionAltec Link to comment Share on other sites More sharing options...
centralpressure Posted September 24, 2009 Author Share Posted September 24, 2009 Easy thing would be if the script was on the CD as then you could use @ScriptDir.Another option:DriveGetDrive ( "type" )type Type of drive to find:"ALL", "CDROM", "REMOVABLE", "FIXED", "NETWORK", "RAMDISK", or "UNKNOWN" A potential risk if the update is a separate file is "WindowsXP DST Update.exe" could be replaced by any other executable, which could give the limited user full access. In which case you may want to either use Fileinstall, and/or check the integrity of the executable by comparing the CRC or MD5 or somesuch.The @ScriptDir seems like the best option, but as I am still learning and this is an ETREMEMLY basic script by comparison, do you have an example?What I have done so far is this:MsgBox(64,"DST Update", "An update for daylight savings time is being applied to your computer. Installation will begin in a few seconds.",10)Local $sUserName = "Admin"Local $sPassword = "test"$comp = @ComputerNameblockinput(1)RunAs($sUserName,$comp,$sPassword,0,'D:\WindowsXP DST Update.exe') WinWaitActive("Software Update Installation Wizard") Send("n") WinWaitActive("Software Update Installation Wizard") Send("{Tab 2}") Send("{Space}") Send("{Enter}") ProcessWait("Software Update Installation Wizard",30) Send("{Enter}") WinwaitClose("Software Update Installation Wizard",5) Blockinput(0) MsgBox(64,"Installation Complete","Update installed succesfully. Please click ""OK"" to exit.")I then compile the script and save it as an autorun_DST.bat. This file, the autorun.inf and WindowsXP DST Update are all burned to CD-R. I have tested it and found it to work, but I need to tweak it to ensure that the correct drive is used.Thanks for any thoughts. Link to comment Share on other sites More sharing options...
TurionAltec Posted September 24, 2009 Share Posted September 24, 2009 (edited) When the script is compiled it will be an EXE NOT a BAT file. Also, Most Microsoft updates have the ability to run unattended If this is the daylight savings update you're running: http://support.microsoft.com/kb/970653/en-us Here's the options found by running the executable with the /? switch: --------------------------- KB970653-v3 Setup --------------------------- AVAILABLE SWITCHES: [/help] [/quiet] [/passive] [/norestart] [/forcerestart] [/warnrestart] [/promptrestart] [/overwriteoem] [/nobackup] [/forceappsclose] [/integrate:<fullpath>] [/log:<fullpath>] /help Displays this message SETUP MODES /quiet Quiet mode (no user interaction or display) /passive Unattended mode (progress bar only) RESTART OPTIONS /norestart Do not restart when installation is complete /forcerestart Restart after installation /warnrestart[:<seconds>] Warn and restart automatically if required (default timeout 30 seconds) /promptrestart Prompt if restart is required SPECIAL OPTIONS /overwriteoem Overwrite OEM files without prompting /nobackup Do not backup files needed for uninstall /forceappsclose Force other programs to close when the computer shuts down /integrate:<fullpath> Integrate this software update into <fullpath> /log:<fullpath> Create log file at <fullpath> --------------------------- OK --------------------------- So running: WindowsXP-KB970653-v3-x86-ENU.exe /passive /norestart will install the update without any clunky send() and Winwaits(), which is generally preferred as it's more robust. Edited September 24, 2009 by TurionAltec Link to comment Share on other sites More sharing options...
centralpressure Posted September 24, 2009 Author Share Posted September 24, 2009 When the script is compiled it will be an EXE NOT a BAT file. Also, Most Microsoft updates have the ability to run unattended If this is the daylight savings update you're running: http://support.microsoft.com/kb/970653/en-us Here's the options found by running the executable with the /? switch: --------------------------- KB970653-v3 Setup --------------------------- AVAILABLE SWITCHES: [/help] [/quiet] [/passive] [/norestart] [/forcerestart] [/warnrestart] [/promptrestart] [/overwriteoem] [/nobackup] [/forceappsclose] [/integrate:<fullpath>] [/log:<fullpath>] /help Displays this message SETUP MODES /quiet Quiet mode (no user interaction or display) /passive Unattended mode (progress bar only) RESTART OPTIONS /norestart Do not restart when installation is complete /forcerestart Restart after installation /warnrestart[:<seconds>] Warn and restart automatically if required (default timeout 30 seconds) /promptrestart Prompt if restart is required SPECIAL OPTIONS /overwriteoem Overwrite OEM files without prompting /nobackup Do not backup files needed for uninstall /forceappsclose Force other programs to close when the computer shuts down /integrate:<fullpath> Integrate this software update into <fullpath> /log:<fullpath> Create log file at <fullpath> --------------------------- OK --------------------------- So running: WindowsXP-KB970653-v3-x86-ENU.exe /passive /norestart will install the update without any clunky send() and Winwaits(), which is generally preferred as it's more robust. Thanks for the thoughts. You are correct that the compiled file is an .exe, but I just change the name to reference the autorun and the file extension to .bat. Again, these computers are at remote locations and set with limited user accounts. I can't seem to get the file to run an install without the admin account. Link to comment Share on other sites More sharing options...
TurionAltec Posted September 24, 2009 Share Posted September 24, 2009 You still have Autorun enabled on theses machines? Autorun is a security nightmare. Are you talking about renaming the line in the autorun.inf file, or renaming the finished autoIT executable? Also, you'd still have to invoke it via runas, but passing the Update exe those commandline parameters prevents having to try and automate the interface, and is useful to automate the installation of any MS update. If you're concerned about preventing users having admin level access on the machines, you really should look at Fileinstall. And I also hope that the account "Administrator" has a password set. Link to comment Share on other sites More sharing options...
Confuzzled Posted September 26, 2009 Share Posted September 26, 2009 Dumb question: If these computers don't have Internet access, why all the fuss? Just ask the users to change their time when they come in on the appropriate day. A manual solution to a non-existent problem... Link to comment Share on other sites More sharing options...
TurionAltec Posted September 26, 2009 Share Posted September 26, 2009 By default limited access users don't have the ability to change the time. And the software may rely on time + timezone to log stuff. Link to comment Share on other sites More sharing options...
centralpressure Posted September 28, 2009 Author Share Posted September 28, 2009 By default limited access users don't have the ability to change the time.And the software may rely on time + timezone to log stuff.Thanks TurionAltec, that is correct. The limited user account really hamstrings us, so the user cannot change the date/time. Which was coincidentally the reason the systems were set to limited in the first place, so sites couldn't make it look like something happened before/after it actually did. I am playing with makemeanadmin, and trying command line prompts. At this point, this project has spiraled to a place that is becoming difficult to control. To add an additional layer of fun, my predecessor named a sub-set of 60 systems with differing admin accounts. The names are different, but the password is the same. Fun. Thanks for all of the help to a newbie, I have learned more in the last week than I thought possible. If anyone has a really great idea, I am all ears. Link to comment Share on other sites More sharing options...
TurionAltec Posted September 28, 2009 Share Posted September 28, 2009 Regardless of what you do at somepoint you're going to end up having the credentials stored somewhere. I think if you can contain everything including the patch (using Fileinstall as mentioned above) you can try to minimize the risk. Here's a script that will attempt to enumerate all users that are part of the Administrators group, but discount the "Administrator" account (which again I pray in your setup has a password or is completely disabled). #include <Constants.au3> #include <array.au3> $pid=Run("net localgroup Administrators",@SystemDir,@SW_HIDE,$STDERR_MERGED) ProcessWaitClose($pid) $output=StdoutRead($pid) $offset1=StringInStr($output,"------"&@CRLF)+8 $offset2=StringInStr($output,"The command completed successfully.")-2 If $offset1=8 or $offset2=-2 Then Msgbox(16,"Error", "Can't detect users") Exit EndIf $userlist=StringMid($output,$offset1,$offset2-$offset1) $userarray=StringSplit($userlist,@CRLF,1) _ArrayDelete($userarray,0) ;Deletes count element of array $i=_ArraySearch($userarray,"Administrator") If $i <> -1 Then _ArrayDelete($userarray,$i) _ArrayDisplay($userarray) Alternatively if you KNOW what the username is for a given machine you could try a lookup table that will will compare @computername and find the admin name As well if you wish, while you're at it you can create a new admin user for future use: net user admin password /add net localgroup administrators admin /add Link to comment Share on other sites More sharing options...
centralpressure Posted September 29, 2009 Author Share Posted September 29, 2009 Regardless of what you do at somepoint you're going to end up having the credentials stored somewhere. I think if you can contain everything including the patch (using Fileinstall as mentioned above) you can try to minimize the risk. Here's a script that will attempt to enumerate all users that are part of the Administrators group, but discount the "Administrator" account (which again I pray in your setup has a password or is completely disabled). #include <Constants.au3> #include <array.au3> $pid=Run("net localgroup Administrators",@SystemDir,@SW_HIDE,$STDERR_MERGED) ProcessWaitClose($pid) $output=StdoutRead($pid) $offset1=StringInStr($output,"------"&@CRLF)+8 $offset2=StringInStr($output,"The command completed successfully.")-2 If $offset1=8 or $offset2=-2 Then Msgbox(16,"Error", "Can't detect users") Exit EndIf $userlist=StringMid($output,$offset1,$offset2-$offset1) $userarray=StringSplit($userlist,@CRLF,1) _ArrayDelete($userarray,0) ;Deletes count element of array $i=_ArraySearch($userarray,"Administrator") If $i <> -1 Then _ArrayDelete($userarray,$i) _ArrayDisplay($userarray) Alternatively if you KNOW what the username is for a given machine you could try a lookup table that will will compare @computername and find the admin name As well if you wish, while you're at it you can create a new admin user for future use: net user admin password /add net localgroup administrators admin /add This is along the path I think I need. The Administrator account is disabled. These machines only have one admin user, with the same password for all units. Can I define a variable based on the array results, without displaying the information? I think I would just delete the last line, _ArrayDisplay($userarray)[/autoit] but how do I pull out the username the script you showed? Link to comment Share on other sites More sharing options...
TurionAltec Posted September 29, 2009 Share Posted September 29, 2009 That's correct, you can delete that line, I was just doing it for testing purposes. $userarray is an array that could have one or more elements. If you will only have one admin user, it could be pulled out with: $user = $userarray[0] Which specifies the first admin user found If there were more users they would be in: $userarray[1] $userarray[2] etc. Link to comment Share on other sites More sharing options...
centralpressure Posted September 30, 2009 Author Share Posted September 30, 2009 (edited) That's correct, you can delete that line, I was just doing it for testing purposes. $userarray is an array that could have one or more elements. If you will only have one admin user, it could be pulled out with: $user = $userarray[0] Which specifies the first admin user found If there were more users they would be in: $userarray[1] $userarray[2] etc. This was awesome. I think it solved my problem. I have to validate a few more systems but in initial testing it worked perfect. I am not too concerned about the end user in these cases doing something malicious, as most of them barely know how to turn the computer on. I had one person once ask how do you open the laptop? They couldn't figure out how to lift the screen. Edited September 30, 2009 by centralpressure Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now