█▄█ ▀█▄ █
- Apr 8, 2005
I've been researching ways to temporarily elevate a user's privilege to administrator for a single instance of an execution. This will be used as a driving force to implement a "lockdown" environment. I've actually found several utilities that will do this, but they have either been command line things that work in a DOS box or require the .NET Framework to be installed, neither of which is acceptable in my current work environment. So, I am dabbling with writing one myself. The concept is pretty simple, so building it will hopefully be equally so. Here's the basic idea:
- We query who the logged on user is.
- If it's being run by the user, this will return their user name.
- We issue a "net localgroup" command to move the ID into local admins. If in the user's context, we'd need to use "runas" and either hard-code admin credentials (generic local admin) or read them in from a file of some sort (binary?).
- Once the user is in local admins, issue a "runas" with their credentials (prompting for password) to run the program. Do NOT wait for the program to finish before moving on.
- Once again use "runas" (if necessary) and "net localgroup" to remove the user from local admins again.
- Let's a non-admin user run an install as an admin. Perhaps the desired target program can be added to an INI file like I'm planning to do with the fullupdate utility. Although this would prompt the user for most basic actions, installations and running of programs could be scripted
- Effect only lasts for the session of the desired execution, and not outside that session.
- Can maybe do other behind-the-scenes updates (SDA) without messing with NTFS permissions.
- Could use it as a launch mechanism for any apps that don't run properly as a limited user.
- Every install done this way would at least prompt for the password, and if through LANDesk, the ID as well. Can't do it silently unless the user's password is known up front (not an option).
- Chance the user could figure out the scheme and plant their own commands in the command INI file.
- User still has to call for help to install software (VERY undesirable)
- Have to stay on top of the admin ID used in the script -- make sure its password is always up-to-date and that the config file with the credentials is current.