From my understanding, when running a distribution package I can run the package as the "LocalSystem" account or the Current user's account. Scripts are executed as the "LocalSystem" account. The msi I need to install doesn't like using the the "LocalSystem" account for some reason and cannot figure out why. I also can not use the Current user's account because our user's do not have the rights to do installs. I would like to run either a distribution package or script as one of our domain admins accounts. I'm able to use a distribution package or a script. I need to know how to get either of them to run as a domain admin account that I will specify. Any help is much appreciated. Thanks.
AFAIK it is only possible to use Local System or Current User Account.
Btw. if you do choose to use "Current user's account" a user needs to be logged in or the job will fail.
You may open a ER for this.
I only know of two practical ways to do what you're asking. The first is to wrap your install in a wrapper that does a runas. You would have to embed your username and password into the wrapper. There are third party tools out there that do this. I've used ScriptCryptor to encrypt some vbscripts that do this. The other way that may be easier, is a unadvertised "feature" in LANDesk. If your delivery method uses "Run from source", it will be run as whichever account you've programmed into LANDesk for said preferred server. So if you were to setup a preferred location, use a domain admin (or system admin) account in LANDesk to allow reading from said share, you could then do a run from source to install as this user.
Thanks for the reply. I've been looking into a way to use the run as, I'll look into the ScriptCryptor for doing this.
As for the second method. Can you provide some more detail on that? Thank you.
Wrap your MSI into an AutoIT package.
In your autoit script you can launch the MSI using specified credential.
In these rare instances we have used a service account that has admin rights on all our devices.
In most cases we have to have the vendor fix their installer.
You could use AutoIT. The script will be compiled and the source is not readable (crypted). The script language is similar to VBS.
You could use the runas function in the script: s. this thread in AutoIT forum http://www.autoitscript.com/forum/topic/132401-flash-silent-install/page__hl__runas__fromsearch__1
A flash installation example from the forum...
; Installing Flash Player 10 ActiveX #include <File.au3> Global $sUserName = "username" Global $sPassword = "password" Global $sNetwork = "domain" ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;uninstall current verison of flash player ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; RunAsWait($sUserName, $sNetwork, $sPassword, 4, "\\server\Adobe\unflash.exe -uninstall") ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; ;install current verison of flash player ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; RunAsWait($sUserName, $sNetwork, $sPassword, 4, "MSIEXEC.EXE /i flashplayer10.msi /qn","\\server\Adobe", @SW_Hide)
Or use the function RunAsWait
"Runs an external program under the context of a different user and pauses script execution until the program finishes."
Do not use an AutoIT package. According to the AutoIT FAQ, they can be decompiled (albeit illegally).
Edit: I meant to say not to use AutoIT as a "Security" measure. You can use it all you want for macro/scripting. You could even include it in a package that is encrypted by something else. Just don't think that a compiled AutoIT script is secure.
Are my compiled scripts safe?
No. Any unscrupulous user may decompile your compiled script. You may use a program like Obfuscator to make the source code harder to read. However, there is nothing you can do to stop decompilation. A determined user will get your source code if they truly want it.
That's not true, with the new versions, since 3.3 (about 2 years in use), it's not longer possible!
See in your link the first line:
"The official decompiler will only decompile scripts compiled with AutoIt v220.127.116.11 and earlier. Any script compiled with a version later than that will not decompile."
I think there exist many tools to crack sources, you could make it a bit more difficult, if you use obfuscator.
But it's not a problem of AutoIT language, it's a problem of every app/programming language... and VBS is much more easier to read (there exist a EXE generator with crypt functionality, but it's cracked in seconds by a AutoIT script LOL)
But, if he create a scripts for his company, how much resources and time a user will spend to crack a installation script? Do they have users with such a deep knowledge outside IT? And which IT collegue is interested in cracking the EXE, if he can get the source or has the admin rights?
AutoIT is a free, fast, well documented scripting language with great forums, runs on all Win OS's (on PE too), include all WMI libs (no additinal WMI inst in PE necessary ), etc.
AND is used by a lot of guys here in forum, for example take a look in HII scripts of Jan Buelens http://community.landesk.com/support/people/jan.buelens/blog/2009/07/10/hardware-independent-imaging--rev-91 or Zman's scripts http://www.droppedpackets.org/technology/database/landesk-query-builder/...
curious what the runasuserutil.exe sitting in LDClient does.
I know the startasuser.exe in LDClient can be used to similate the current user logged in from a package ran from LOCAL SYSTEM.
Maybe the runasuserutil.exe can enumerate another user, Im just not sure what switches it needs, but might be worth something, maybe someone from LANDesk can chime in on what it does...
We could create a ER to document all parameters and functions of the tools they copied on core and clients
Could save time if we can use existing tools except to develop some own... (rebuilding the wheel...)
The official decompliler wont work on the newest version. There are unofficial decompilers. In general, I consider there to be two different levels of security that I should care about.
1) Not GoogleProof - Security that can be overcome by the average user with a basic google search.
2) GoogleProof - Security that can withstand a good 30 minutes of searching on google for a way to bypass it.
In general, if you can't find a way to bypass a security measure in 30 minutes of looking, you probably aren't going to bypass it ever. Does that make it secure? No. That just means that someone would have to be very dedicated/smart to bypass the security. Obviosuly, security requirements change based on what account class you are exposing. For instance, I have scripts that use a special account which has read-only access to a SQL database. The database doesn't have sensitive information. For this type of script, I'd be happy to use obfuscation or something fairly easy to hack. Now, I have another script which I embed an account username and password which has local administrative access on all of our workstations. This script must definitely involve Google Proof security.
I agree about VBScript. If I had to choose between AutoIT and VBScript for security (by themselves), I would pick AutoIT. But I can't tell my CEO that all our data got hacked because I had to pick the lesser of two evils, and if I picked something else, I need to be able to show I did research to make sure what I picked was appropriately secure as anything can be. As an Administrator, I should know that the correct answer is to choose neither. I'm currently using ScriptCryptor which is a cheap utility that encrypts vbscripts using Blowfish. If there is a way to decrypt it, I can't find it.
It depends on the blowfish implementation s. http://www.schneier.com/blowfish-bug.txt..
Bruce Schneier said, use the new Twofish algorithmn. (or Threefish?)
But you're right, if a EXE can be decompiled in 30 min and you should garantee security, you've to choose a other method.
Did they fix the problems with virus scan messages if you use ScriptCryptor?
A little late on this one. We use a ton of Autoit scripts in our environment. I agree NEVER EMBED A USERNAME AND PASSWORD IN ANY COMPILED SCRIPT! What we do is pass the encrypted username and password to the autoit exe as commandline parameters. You would just have to worry about people who have access to the console and the autoit script we use to encrypt the user name and password. It looks similar to this:
We also delete the local LANDesk log file. Nothing is truly secure but do your do diligence.
Also in the old days 8.X if you used run from source in the delivery methods the job would run under the credentials of the user used in the preferred server configuration.