This is an interesting script. It has some room for error but I have an idea about how to avoid that.
Some fellow who seems to work for Microsoft in some capacity has written a batch script called MakeMeAdmin that uses runas in clever ways to make a program run as the user but with admin privileges. The advantages over simply running programs using a local admin account are the program will use the user's profile instead of the admin account's and the programs will have access to domain resources.
Here are the phases of the script:
1. Open a command prompt as a local administrator (user is prompted for this account's password)
2. Current user is added to the local Admin group
3. Open command prompt (or another specific program) as current user (user is prompted for their own password)
4. Current user is removed from the local Admin group
Changes to group membership don't affect existing login sessions, only new ones. Therefore when runas is used in step 3 to start a program as the current user, it's a separate session and therefore the Admin group membership takes affect. Step 4 can happen immediately because the user's removal from the Admin group won't affect the session opened in step 3.
It's a clever script and probably useful for admins and developers who are cautious with their own logins but I'm not sure it would be advisable to have regular users in an organization use it (not that the author is advocating such use). First, the fact that you have to enter two passwords when you run the script is a turn-off and a step back from an ordinary runas script. Second, there is a risk of the user's privilege elevation not being removed. If the script is exited before step 4, *every* subsequent login by that user on the computer will be as a local Admin. I'm not thinking about this being done intentionally (you're already trusting the user with a local admin password) but accidentally by closing the command prompt window before logging in with their own password.
The risk could be mitigated by a system scheduled task that would check the Admin group membership, say, once an hour and removing anyone who shouldn't be there permanently. Ooh, this could be incorporated into the script! After step 2 but before step 3, the script could create a one-time scheduled task to remove the user from the Admin group 5 minutes in the future. The user would then have to login to the second runas with their own account within 5 minutes for them to have admin privileges. This would remove the window of time in which someone could accidentally be added to the Admin group for an extended period.
Looking at the script, I think the thing to do would be to add a line like the following someplace before the 2nd runas:
soon.exe 300 net localgroup %_Group_% "%*" /DELETE
%_Group_% is a variable containing the name of the Administrators gropu and %* is the current user's name. Soon.exe is a Resource Kit program for scheduling tasks X number of seconds in the future. The problem with using soon.exe is has to be in the path of the local admin user and since the local admin can't access domain resources, that means it has to be on the local drive. A nuisance but as long as you're installing this script on a computer, I guess you can install soon along with it. I'm sure there are other ways to schedule a task to run X minutes in the future that don't involve separate executables but I'll leave those as an exercise for the reader.Posted to Wintel by extra88 at August 11, 2004 10:30 AM | TrackBack