kcnychief

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.

Although you must log on to get benefits of new group memberships, you do NOT have to log off before you can log on. Each execution of "runas" essentially launches a new logon session. So adding to admins, doing a runas to run a program, and removing again from admins immediately keeps the user limited in their current session, launches the program at question with the user's credentials as an admin so that HKCU changes and whatnot can be made and network resources can be accessed, and immediately removes admin access so nothing else the user does gets done as an admin. It operates very much like the sudo command in Linux.


The Good:

• 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.

The Bad:

• 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.

Thoughts? Alternatives?

---

fitz

This is really one of the few ways to do this.. and is fundamentally the same as Aaron Margosis's MakeMeAdmin script.

The drawbacks are as you have already described. Personally, we don't allow our users to have admin rights at all which, yes, can be a pain at times.

---

kcnychief

Yeah I read over that blog, stumbled upon it about a week ago when researching. Simply AMAZING resource for everything running as a lower admin

-edit-

How do you guys circumvent this problem within your own environment if you don't mind me asking?

---

mlakrid

The problems I see with this:

A) you need to have an audit file of what is being done after the rights have been changed to admin to ensure the user (if smart enough) does not give him/herself local admin privelages (to the box) while they are the admin from that script.

B) Wouldnt it be easier to set scripts to install programs using RDP, SMS, or whatever remote management software you have after a work order or ticket
has been submitted? Instead f having the user do it?

Maybe its just me, but I do nt like anyone (except developers who HAVE to be) to be admin or local admin...

Just my $.02...

---

kcnychief

I agree with you 100% mlakrid, trust me those are very valid points.

Problem is our Help Desk is only about 9 people strong, and we have a 2000 user support environment. They are already taxed enough as it is, and we would like to avoid such requests for every Tom/Dick/Jane request.

I understand there isn't a foolproof way to do this, but it's a bit out of our control as the parent company who owns us is pushing it down.

If I had my way, they'd all be non-admins and S.O.L. when they need stuff done until it gets done based on busines criticality.

I have even tried to go the other way, in regards to demoting only certain applications. Most noteably I would demote IE to least possible access rights, such as how it works as Protected Mode in Vista (not available in XP).

Came across this yesterday, unfortunately it isn't an option though

http://msdn2.microsoft.com/en-us/library/ms972827.aspx

---