Logon script and user permissions

[allan]

Hi all,

I'm having some problems with logon scripts user permissions, and I would appreciate if anyone in here could give me a hint on how to fix this. The problem is simple, and I’d say there should be some simple solution!

Here’s the problem:

We are a large company, and we therefore install the software on our workstations automatically and unattended. These installations are started from a logon script, so when a new version of a piece of software we use is released, we simply drop in an extra line in our logon script, and the software is installed on the workstations next time a users logs on the workstation. This works great, and we have been using it for many years.

However, we have now been ordered to tighten our security so users can’t install software on their local machines. This also means that the logon script that runs and should install new software won’t work, since it runs as the user who logged on.

Does anyone here have any ideas to how we I could start up this logon script as a user with administrative privileges?

First I tried using AutoIt to type in a password to a runas window. This wasn’t secure enough, because anyone could open a notepad window and let the autoit script type the password to the notepad window instead, or just view the script source...

Then we bough some licenses for an application called ScriptLogic. It claims to be able to securely solve this problem, but it seems very overkill and messy, and has loads of features I don’t need or have already covered in my original logon script.

On Linux/Unix I know a simple solution! I could chmod the sticky bit on the logon script, and in that way force it to run as root no matter who started it. Sadly, I’ve never heard of sticky bits in a Windows environment...

Any hints or ideas are greatly appreciated.

Thanks

Allan, Denmark

[bek]

You really need to look into pushing the SW via GPO (if you are running Active Directory). It is very clean and avoids all the user rights issues (install/uninstall/upgrade) - this all happens at machine startup - before login.

The caveat is it requires an *.msi package, however therer are tools to make those if it doesn't come native.

If no msi, then another option is to install it as part of a machine startup script.

Any of the above allows you to publish the app according to OU and/or Group membership.

[twrizzo]

If you don't have a group policy to do it, try this...

Why not have the users login script import a AutoAdmin login key and force the computer to reboot (shutdown -r -t 30 (30 seconds may be too much)) and login as a different user with the required rights. That users login script could then install the application and then disable the AutoAdmin login and reboot again. I've done this kind of thing in the past.

[un4given1]

You really need to look into pushing the SW via GPO (if you are running Active Directory). It is very clean and avoids all the user rights issues (install/uninstall/upgrade) - this all happens at machine startup - before login.

The caveat is it requires an *.msi package, however therer are tools to make those if it doesn't come native.

If no msi, then another option is to install it as part of a machine startup script.

Any of the above allows you to publish the app according to OU and/or Group membership.

This is clearly the best method without any substantial cost.

If money isn't an issue I really recommend using Systems Management Server (SMS) I believe you can download a trial on the MS website if you wanna give it a run. It's a beautiful piece of software and allows for more than just installing software. It allows you to remote into PCs (even when no session is active... IE: when the PC is at the security screen) It allows you to keep tabs of stats on every PC and query for anything you could imagine.

[Spyder2k]

You can enable the group policy setting @ 'Computer Configuration -> Administrative Templates -> Windows Components -> Windows Installer -> Always install with elevated priviledges'. You'll also need to do it in 'User Configuration'. But that's a great security risk, also it your installaions are gonna have to be MSI based.

Why don't you deploy the software through group policy instead.

[Dahi]

For budget disadvantaged administrators, a cheap rollout solution is possible using an admins PC or server to copy install files to remote PCs and start silent installations with the AT or SOON commands.

[allan]

Hi all, and thanks for the replys.

bek and spyder2k: You're right, that sounds like a very clean solution. However, I don't think it will be the best for my situation. There are about 30 installation packages (most coded in autoit at the moment), so using GPO, it would not be possible to see how far the installation has progressed (or is it?). Also, when big packages are rolled out (like ms-office), as far as i understand, using GPO doesn’t lock the screen, and the user will be able to log on and mess up the system while its installing...

And the last issue here, is as you said that packages have to be MSI. We are installing packages such as java development kit, which do not have MSI installations.

twrizzo: that sounds like a solution that would work with my packages straight away! But, how is the user running the initial logon supposed to get access to write the admin login information to the registry?

Thanks :-)

/Allan

[un4given1]

For budget disadvantaged administrators, a cheap rollout solution is possible using an admins PC or server to copy install files to remote PCs and start silent installations with the AT or SOON commands.

This is a fantastic suggestion...

Create a list of PC names, one per line... save as TXT file

Create a batch file to copy the installation file locally to the PC into a temp folder.

Create a batch file to set an AT command on the remote PCs to run the local install file

Run the copy batch file like this (using a command prompt run as a domain admin or as local admin if passwords are consistent across all desktops)...

for /f %i IN (pcnames.txt) DO copy "c:\file.exe" \\%i\c$\temp >> copylog.txt

Run the scheduler batch file next...

for /f %i IN (pcnames.txt) DO AT \\%i xx:xxpm "c:\temp\file.exe  >> atlog.txt

The install will begin at the designated time. You can then run a check file after they should all have run like this...

for /f %i IN (pcnames.txt) DO AT \\%i >> atcheck.txt

Hope that helps...

[un4given1]

If you don't have a group policy to do it, try this...

Why not have the users login script import a AutoAdmin login key and force the computer to reboot (shutdown -r -t 30 (30 seconds may be too much)) and login as a different user with the required rights. That users login script could then install the application and then disable the AutoAdmin login and reboot again. I've done this kind of thing in the past.

The problem I see with this method is that once the PC restarts and logs in as admin and your batch file begins running, what's to stop them from killing the batch file before it reboots, and being logged in as admin?

[Spyder2k]

Here's another idea/theory; 'GPO -> Computer Configuration -> Windows Settings -> Scripts -> Startup'

Everything run from there is run under the Local SYSTEM account, you can probably put your install script in there.

[bek]

Then, as I mentioned the second option is the startup script. At least it would be: 1) centrally managed, 2) keep source files central, easier to update and not having to copy to the local HD 3) Run under System rights - and before login... 4) not have to hack the reg or local rights 5) You can deploy msi and non-msi packages - whatever supports silent/switches...

FYI - An AD push happens before the login prompt - so, no the user can't interupt - unless they power off the PC (very bad for a SP2 push!).

Office2003 takes about 20 minutes (100MB LAN).

[Raja]

Hi Allan

If you can afford to spend $99, then check ASI Editor at http://www.adminscripteditor.com/editor/.

I am using this and is worth the small investment.

Raja

[ravashaak]

I also run my software installs at system startup. Hell, I even automate my system scanning and patching via startup script. Startup scripts are very nice for performing tasks that need system-level access, when you don't want to grant your users anything above user-level access. I agree, it's too bad MS hasn't seen fit to provide an efficient and secure way to run logon scripts under alternate credentials.

One other tip: you can often use psexec from sysinternals.com to push the same scripts you use at startup, across the network without restarting your clients. However, test thoroughly as some things don't work properly when executed remotely via psexec. Still, all in all, a very good tool. But be aware, psexec performs authentication in clear text, so if you're worried about someone sniffing your passwords, or corporate policies forbid clear text authentication, then psexec is not for you.

- Ravashaak

[RogueSpear]

Whenever it's feasable, I push apps out via GPO. One of the main reasons for this too is that you can rather quickly uninstall a particular app or patch it for that matter, enterprise wide.

There are those apps where a GPO isn't possible or practical, and for that I use the machine start up script.

Then I ran into a doozy a couple months back. I needed to push out a very custom VPN-type of application. I say type because it's not truly a VPN connection, but it's using token/smartcard authentication for web site access. Anyway, try as I might, I could not package this thing into an MSI package (the first time out of literally dozens of apps). So seeing that it was an InstallShield routine, I made up a silent response file and implemented the whole thing into a startup script. Don't you know it wouldn't run at all.

Having tunnel vision at this point, it took me a little while to realize that this was a 16-bit InstallShield routine. Well the 16-bit subsystem isn't intitialized in time for the installer to run from the machine startup script. Ooookay, so now in desperation, I plop it into the user logon script and sure enough the users don't have the rights to install the app. So I did a little bit of searching and found CPAU (Create Process As User) which allowed me to run the install as a user with admin rights. The utility supports encoding of passwords too, so you don't have to worry about someone opening the script file and seeing the password in plain text.

This is completely off topic - I found it interesting that this application used a 16-bit install routine. My guess is that this was to facilitate compatibility with Win9x operating systems. Now anybody who uses this application has to be fingerprinted, complete and pass a background check and polygraph, be bonded, etc. (including me since I administer it at one location). So I find it curious that this application is allowed to run on such a fundamentally insecure OS. There's always something that makes me wonder.. everyday..

[allan]

Hi everyone,

many thanks for all the feedback!

It seems the main opinion is that GPO is the cleanest and most correct method of doing this type of automated remote installation.

However, the app RogueSpear posted, "CPAU", looks really great, since it actually lets me continue using my old logon script that does the checking and installation. So I’ll try with CPAU and spare the time it takes to create MSI packages.

In the future I will definitely use GPO, if I get a chance to start an environment from scratch.

Thanks! :-D

/Allan