Extra88

MakeMeAdmin script

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.

Bug & workaround for Sysprep'ed machines

We haven't used Sysprep yet but we probably will. This will impact procedures for using Sysprep.

Opportunistic Locking May Not Be Granted If Windows Is Installed by Using Sysprep

The workaround is to delete the data from this Value after running Sysprep on the master but before shutting it down.

Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet \Services\lanmanserver\parameters
Value: GUID

Lookup NetBIOS names from OS X

This falls under so many categories. MacOSXHints has this storyAn AppleScript to look up NetBIOS names. but Real Men use the Terminal. Here's the command line bit that does the real work:

nmblookup -T -U <WINS server IP> -R <NetBIOS name>

Here's an example for work and its output:

cwcx% nmblookup -T -U 128.151.209.155 -R esmdc
querying esmdc on 128.151.209.155
esmdc.esm.rochester.edu, 128.151.209.155 esmdc<00>

In this case I used the WINS server to look up the WINS server's NetBIOS name.

Disable Outlook's "Reply to All"

I thought this was sort of an interesting Microsoft KB article.
OL2000: Preventing Reply All to Large Aliases

In a nutshell the offer 3 methods. The first is simply to use the Bcc: line (duh). The second is the most interesting and clever to me, create a custom Mail Message Form which has no Reply to All button. Recipients could still use other Reply to All methods but it would foil the unconscious hitting of that button because IT WOULDN'T BE THERE! The third is to use a system policy which disables all Reply to All methods in Outlook. If you're the kind of sysadmin who roots for the "bulls" in prison movies, that's the option for you.