We help IT Professionals succeed at work.

Restricting local administrator group from accessing administrative shares on remote computers

schilste
schilste asked
on
We currently have a user vbs startup script that adds the AD group domain\LocalAdmin to the local Administrator group for the machine. This script command gets run when an IT admin joins the machine to the domain the first time and logs in (since any standard user would not be able to execute a script adding a user or group to the administrator group). This was set up so that we could centrally grant and remove administrative rights to select  users without visiting their machine. An unforseen consequence of this is that members of the AD group LocalAdmin has access to administrative shares on all remote machines. So if a user knew the name of any computer on our network they would be able to browse the root of c by going to \\computername\C$
We want members of LocalAdmin to only be the admin of the machine they are sitting in front of. I know there are ways to disable admin shares but am concerned about doing this because it seems as if it turns off features that are essential to IT administration.
Comment
Watch Question

Why are you granting admin rights to users?

Author

Commented:
So they can add printers at home, install certain software, some programs require admin rights to run. It is only for a small group of select laptop users

Commented:
Actually it would seem that this creates other problems as well.  If you add a user to Domain\LocalAdmins, they can log in to any computer in your domain (where this script has been executed) and have full admin rights.

And worse (from my point of view) is that the users are always an admin, even when just reading mail or browsing the web.  Which means there is an increased likelihood that they will do something ill-advised and end up with a virus.

In our org, we do have people who sometimes feel the need to do admin-y things.  What I have done for those people is to create a local admin account on their machine (ie not a domain account).  They get to choose the pw.  The intent is that they use the admin account to do admin-y things (install sw, etc), then log back in with their normal account for day-to-day computing.
ubound's suggestion is good.

Another possibility would be to use the free, open-source utility SuRun. SuRun lets you set up users so that they can do certain admin tasks, or run certain programs with admin privileges, from within a limited user account.
http://kay-bruns.de/wp/software/surun/
http://www.dedoimedo.com/computers/surun.html

Top Expert 2014

Commented:
I know of no way to do this programatically.  If the group of users is really that small, just go to the machines and change it so the user is a member of the Administrators group, and remove the LocalAdmins group.  Actually, since these users are already local admins, you might be able to script this change through the use of the a command like
net localgroup "Administrators" <username> /add
which the users could run.  In the script you'd have to pull the value for currently logged on user into the <username> variable.   Or combine the above with something like psexec, in which case you'd have to modify the command for each computer and user combination you were targeting to run it on individually.

Author

Commented:
Thanks for the suggestions. My goal was to retain the current settings and just restrict the ability for the group LocalAdmin to access remote admin shares.

Footech is closest to responding to my question. Is there any setting anyone knows about that can restrict this ability?

Commented:
While Footech's solution may be the closest to what you asked for, I'll make one last pitch for NOT having users be full-time administrators of their computers.  The few times we've done this, those turned out to be the most virus-prone.

Having an admin account that they can log in with or use with RunAs is going to be a safer solution.
Most Valuable Expert 2011
Top Expert 2011
Commented:
GPO possibly.....

Deny access to this computer from the network
http://technet.microsoft.com/en-us/library/cc758316(WS.10).aspx

If this is set on the WORKSTATIONS only, and as long as your people dont share between each other, should work fine.

Author

Commented:
I am going to test this solution in a test OU.

This seems as if it might result in breaking my ability to remotly manage the workstations.

Author

Commented:
I tested this locally on 2 test machines and it worked correctly in terms of blocking the defined group from accessing the machine's hidden shares via the network.

I have expanded the test to a GPO set at one of our sites with a test group composed of some of the LocalAdmin users.

The plan is to let policy be applied and run for a few days hopefully with no unexpected problems. If there are no issues I will expand to container with all WORKSTATIONS with Deny Access to this Computer policy enabled for group LocalAdmin
Be warned that although the "Deny access to this computer from the network" policy will stop them connecting remotely to admin shares with their account, there's nothing stopping them logging on locally to those machines then creating a new administrator account ( in "administrators" group, not in your domain "LocalAdmin" group) which they could then use to access the admin shares remotely.

Giving your users admin rights removes your ability to restrict them at all.  Any hurdles you put in their way they can remove - to the extent that they could remove the machines from the domain & render all policies useless.
Regarding "We want members of LocalAdmin to only be the admin of the machine they are sitting in front of."  -  there is the "interactive" security principal/group which automatically contains whoever is logged into the machine locally.
If you put interactive into administrators then anyone logged on locally would have admin rights but that wouldn't give them any remote admin rights - however I don't know of any way to restrict it to only certain interactive users.

Author

Commented:
Set this GPO up and is working correctly.