Giving Users Administrative Rights

Posted on Posted in Security, Windows

Many Windows administrators know that giving users administrative rights on their local workstation has long been a way to avoid issues from applications that need such rights — even if it does open the floodgates for other problems. Some administrators may also argue that with certain measures in place (DeepFreeze, etc.), it decreases the number of help-desk calls since users can do near enough whatever they want on their computer.

Right now I want to make it clear that the best practice is without a doubt to remove administrator privileges whenever possible. In the cases where users absolutely need local admin rights, there are a couple of things to keep in mind, though.

 

Problem

The main issue is that if using Group Policy to place certain AD Security Groups into the BUILTIN\Administrators group, this applies not only to interactive and remote logins but also to network logins. An “interactive” or “console” login is when a user actually logs into a computer (either at the physical computer or via an RDP session) whereas a network login is when a user authenticates to a machine in a way that does not present them with the GUI. Some such examples are RADIUS or RRAS authentication, IIS user authentication, and using a shared folder on another computer.

In each of these network login scenarios, the authenticating client computer must contact a domain controller and verify the user credentials being supplied. This includes the user’s Active Directory group membership. Since the machine GPO for the authenticating computer — the one that modifies the local admin membership — is still in place, and the user is still in a group that would normally be added to BUILTIN\Administrators, the user is recognized to the authenticating computer as an administrator.

For each of the examples of network logins above, granting the “Administrators” group access to the resource in question may inadvertently provide more users with access than is intended, if the computer in question is in an OU that receives the GPO to make users local admins. Note that this does not apply if the “DOMAIN\Domain Admins” group is the one given access in the permissions for the resource.

 

Solution

To make sure that the wrong users are not given access to a VPN, a password-protected folder in IIS, or a shared folder (the default C$ shares come to mind here) that they shouldn’t be able to access, I’d suggest making the NT AUTHORITY\Interactive group a member of  BUILTIN\Administrators instead of an AD Security Group. What this will do is allow users logging into a computer to be local administrators but only  if they are logging in interactively.

To do this, make a new Group Policy Object and name it something sensible. You can disable the “User Configuration.” Under Computer Configuration\Preferences\Control Panel Settings\Local Users and Groups create a new local group. Call the group Administrators (built-in) and update it to include the INTERACTIVE group. You cannot use the Browse function for this.

283b70ec1c36b75352766dea2132825bee44a6efa1974a62c24a8628dabc258e_asdasd

To make sure the policy is applied only once per computer and not at each restart, go to the Common tab and select Apply Once and Do Not Reapply.

This will also prevent execution of commands on remote computers that require administrator rights, even if the Command Prompt is running as administrator on the local computer.

To test it out, try remotely shutting down a computer using the interactive paramater for the shutdown command. It will fail due to insufficient rights.


Leave a Reply

Your email address will not be published. Required fields are marked *