I have a legacy Windows 95 app that needs to be run as an Administrator. This is used by students in a school domain.
My predecessor set up a domain administrator account for this purpose and a "Run As.." batch script to start the program, but this still requires a teacher to enter a password. I'd like a simpler way for students to start the app, without giving them increased local privileges or the password to a domain administrator account.
What's the best way to do this?
I normally start by finding the HKLM key that the software uses - hopefully something sane - and using regedt32 (note regular regedit won't work) give thier group full control of that registry key. Then I'll give them full control of the installation directory. 99% of the time this resolves issues with needed local admin. Normally at this point if it doesn't work out i start lobbying to upgrade the app sometimes that works sometimes it doesn't. If you are really lucky and it's a common program searching google will give you the exact places you need to give permissions to run as a non admin.
I hope you mean that you a user in a group that is in the local computer's administrator group, and you don't give out an account that is a member of domain admins. There is absolutely no reason, that the account should need to be a member of the domain administrator group. If you have given out an account to the teachers that is a member of domain admins I strongly urge you to change this ASAP. You should create another group in the domain, and make that group a member of the local administrators group on the computers. You should be able to add the group you create to the local administrators group with a startup script applied by a GPO.
Anyway back to solving the issues for the program. What you may need to do is figure out what the application is doing that needs administrative access and then modify the permissions of the filesystem and registry so that students have those privileges.
The sysinternals tools filemon, and regmon will be very useful in figuring this out.
If you haven't already, try searching Google for information about that specific program, perhaps someone else has already solved the problem and fixed it.
If using active directory
Navigate to C:\program files\the win 95 app folder. On security tab (properties) give "Domain Users" Read and Write Access. I usually avoid the "Full Control".
Open Regedit and Navigate to "LOCAL MACHINE\SOFTWARE" and find the win 95 app. On permission tab give the "Domain Users" Read and Write access. Again, I try to avoid the "Full Control" thing here as well.
Here is an unusual one - then run the app for a minute as if you are one of the users (but logged in as admin) open a few of the screens and so on. Then close the app, and open windows search. Search for files recently modified with timestamp during the time you were using the app. You may find some .ini which some programmers back then (win 95) put in the windows directory. I go to their properties and give the "Domain Users" "Full Control"....NOT ON THE WINDOWS DIRECTORY...JUST THE FILE WHICH BELONGS TO THE APP.
That should do the trick. It worked for me several times.
Check out the site nonadmin started by the excellent Aaron Margosis. It is a great resource as you roll out limited users on XP. Some applications that want to run as admin need additional tweaking beyond the good answers already given to be able to run as a limited user.
The filemon and regmon tools mentioned previously have been consolidated into process monitor. Look under http://live.sysinternals.com/ for procmon.exe
9 times out of 10, it is just writing to HKLM\Software\vendor or c:\program files\vendor but for the complex cases you will want to learn process monitor and how to filter it down to the specific executable you are tracking and start by focusing on write operations rather than read (otherwise you will have hundreds of thousands of entries).
Another option is application virtualization using products like Thinapp (VMWare), App-V (Microsoft) or SVS (Altiris/Symantec). While I haven't used Altiris in depth I think there is a free personal version that can allow you to test it out and get familiar with the methods used. Vista also has a virtual registry and file system but I have never used Vista for this purpose.
As a quick fix, you may find that running the application as a member of the Power Users local group will be sufficient permissions. Power Users has modify rights on almost all of the registy and local file systsem. So it is a good indication that if the app works as a Power User, then it can be made to work as a normal user by editing registry of file system permissions.
If you change the batch script to use PSExec (from Sysinternals) instead of "Run As", you can embed the password in the script instead of requiring a teacher to enter it. I use encoded vbscript for this purpose.
'**Start Encode**
Const SET_PRIVELEGE_CMD = "%comspec% /c psexec -i -u User -p Password "
Set objWShell = CreateObject ("WScript.shell")
objWShell.run SET_PRIVELEGE_CMD & "c:\MyApplication.exe"
To encode a vbscript file you need to place the "Start Encode" text as a comment in the script before any of the code, and also download and install sce10en.exe from Microsoft. Once those are done, open a command prompt, and navigate to the folder the encoding software is installed.
Usage: screnc [/?] [/s] [/f] [/xl] [/l ScriptLanguage] [/e DefaultExtension]
<source> <destination>
Encode embedded script.
/? - Help
/s - Silent: display no messages
/f - Force: allow file(s) overwrite (source == destination)
/xl - Exclude Language: does not add the language directive in asp files
/l ScriptLanguage -
Script Default Language: specify the default script language to be
used when encoding
/e DefaultExtension -
Default Extension: override actual file extension. Control the
encoder to be loaded.
<source>
The file to encode. It can have wildcard characters.
<destination>
The destination file. When <source> contains wildcard characters,
<destination> is the directory where to place the encoded
files; files will keep the same name. When <source> and
<destination> are the same /f must be used.
Example:
C:\Program Files\Windows Script Encoder>screnc C:\temp\MyScript.vbs C:\temp\MyScript.vbe
Note that this is encoding not encrypting. Someone who knows what they are doing can easily decode the script to get the password making this solution unusable in some settings.
