Creating logon script to run under administrator privlidges

Good question...
I spent time on this last year and came up with the following solution.
Using psexec from sysinternals (http://www.microsoft.com/technet/sysinternals/utilities/psexec.mspx) I made a VBS script that call it including the password in the command line, along with what I want the admin to do (called a second script)
Then I encrypted it using Script Encoder (http://www.microsoft.com/downloads/details.aspx?FamilyId=E7877F67-C447-4873-B1B0-21F0626A6329&displaylang=en)
Cheers
Stu

Or - just add write permissions for your account to the Default User's Startup folder (using NTFS permissions) - and run the script under your own login...

Script encoder is, i'm afraid, not a very good solution as it is relatively easy to decode it - either by writing your own tool, or using one of those available on the net. and235100 is i think better solution, is still not recommended, as every user would then be able to add program to be started when other user logs on.
I could recommend you using remote installation services, or, if it is not in question, using a client-server architecture, for instance logon script sends a http (or any other) request to the server, which then uses psexec to execute script (from read-only location) that would do the admin work with admin privileges. This would not be as secure as RIS, but at least user would not have access to a file containing admin password in clear or encoded (encoding is not encryption).

Hi IceTim

You can do the following

Download and install the following free scripting program called AutoIT 3 http://www.autoitscript.com/autoit3/
Now Copy the lines below into NotePad

Change Administrator
Change Password
Change the File Location to copy and where to

========Copy below Here========
#NoTrayIcon

RunAsSet("Administrator", @LogonDomain, "Password", 0)

$DFTUSER = StringReplace(@DesktopCommonDir, 'All Users\Desktop', 'Default User')

FileCopy("\\Server\Share\File1.lnk", $DFTUser & '\Desktop\')
FileCopy("\\Server\Share\File2.lnk", $DFTUser & '\Desktop\')
;etc...

RunAsSet()
========To above Here========

Line 1 - Hides AutoIT3 Tray Icon

Line 2 - Is basically a runas, if your users are already Local Administrators or you have other means to run this script, than you can remove this line altogeather .

Line 3. - Creates a variable for Default Users Profile

Line 4 - 5 Copies files from Server to Default Users Desktop.

Line 5 - Resets the Local Admin rights back to the users context.

This was quickly put togeather but hopefully it will give you a starting point.

Save the file as FileCopy.au3

To test you may double click the file on the system you have AutoIT installed otherwise right click the file and select compile (this will create an executable FileCopy.exe within the same folder as the FileCopy.au3 file)

Hope that helps.

Cheers

I think that storing administrator in clear text in any location available to end user is not a good idea. Script Encoder may make it more harder, but I would not trust that slightly modified Caesar cipher is going to protect admin password appropriately (which is what MS script encoder uses).

Personally I use AutoIT (as above) compiled with decompilation unchecked, however I do tend to use the Local Administrator Account rather than a Domain Account.

Any user, if they wanted to, could use one of the numerous tools available to either reset the password: http://www.petri.co.il/forgot_administrator_password.htm or even retrieve the Administrators or a Users Password: http://www.loginrecovery.com/

Cheers

matrixnz: Properly secured machine (bios password, locked physically from opening and limited to booting from hard- drive only) would not be prone to those tools. Unchecking decompilation just means that autoIT adds a flag to the file to prevent its decompiler from running. Using debugger and hex editor, I can circumvent it in 2 minutes. It would be yet another "security through obscurity" (as long as someone would have some time, he would be able to decode the password), while storing password on server and only asking the server to use it is real security - someone would need to hack into the server to get the password, and if (s)he hacks there, (s)he would not need the admin password anymore.

I would completely agree that computer startup script could be a best solution here, as what you want to do affects all users.

Many thanks for all your suggestions.

I have downloaded AutoIT and currently trying to get a script to work using that. The script works when run logged on as an administrator but still not as a user. I guess it doesn't like the 'RunAsSet("Administrator", @LogonDomain, "Password", 0)' line for some reason. I have tried using both the local admin credentials and domain admin credentials, but neither seems to work. I tried using @ComputerName for the local admin account and entering the domain name for a domain admin account, but still no luck!

I will also look at creating a computer startup script via Group Policy.

I'll keep you posted.

Thanks.

Hi icetim

Sorry had to get some sleep, to use local Admin credentials with the AutoIT Script you just need to replace:
RunAsSet("Administrator", @LogonDomain, "Password", 0)

with

'RunAsSet("Administrator", @Computername, "Password", 0)

Cheers

Hi icetim

Sorry looks like I didn't get enough sleep, just reread your post and it seems that you had already tried that, although I should point out a couple of things, if using a variable like @Computername, don't use " " if using an actual name for e.g. Computer1 then it must be surrounded by quotes "Computer1".

Cheers

Thanks Matrixnz.

In the end I created 2 scripts (batch files) and added them both to a GPO. A logon script copies the files to a location on the PC where all users have access to and the computer startup script copies those files from that location to a restricted location on the PC. It's a little bit messy but does the job!

Matrixnz, I will give you the points as you first suggested using a computer startup script via Group Policy.

Thanks for all your suggestions though. I'm sure AutoIT will come in handy in the future!