First published on TechNet on Nov 06, 2017

Hello Everyone! Graeme Bray back with you today to talk about how you can reduce the audit and risk surface within your environment. If you can't tell, Microsoft has taken a strong stance towards security. In a previous life, I was responsible for providing results for audit requests from multiple sources. One risk (and management nightmare) that we worked to reduce was the ability to modify Local Admin rights on a remote system (Windows Server). Ideally, we want you to move towards JEA (Just Enough Admin) and JIT (Just In-Time), especially as it relates to Windows Server 2016.

**Note #1** This can be a very dangerous process if you do not have the appropriate backups in place. This should be done in a test environment first, prior to any production implementation. Consider testing and using a script such as this to get a local group membership backup. **End Note**

What can we do to help reduce the risk? Organizations have invested extraordinary amounts of time to support, lifecycle, and enhance their core infrastructure, including Active Directory Domain Services. We can utilize the infrastructure that we've built and leverage the centralized management nature of Active Directory. How does it work? We utilize Active Directory groups to grant permissions to the local server. We then utilize Group Policy to enforce these groups on local systems. What are the requirements? Windows Server 2008 and above (We don't support 2003, remember ?) Active Directory How do I implement it? First, you will need to create the appropriate groups in Active Directory. What I normally recommend is to create a Local Server Administrators group that contains the entirety of each team that administers all Windows Systems. This would tend to be a Windows Administration team. There are other accounts that would fit into this all-encompassing group, such as non-interactive (accounts that are prohibited login rights) service accounts. Examples of these could be your monitoring tools, SCCM accounts, etc. These groups should be handled with care and only the appropriate individuals have access to modify group membership. These groups should be considered Privileged, that way only AD Admins or your PIM/PAM tool can modify them. Secondly, create a new Group Policy Object (following your organization naming scheme). My example will be: Servers - Access Control - Administrators - Member I read this as follows, to help make sense of what the policy does: This is a Server Policy, provides Access Control , for the Administrators group, on Member servers. Another example (which you can leverage any Local group): Server - Access Control - Remote Desktop - Member What would that policy do? It should be self-explanatory. Group Policy names are important to humans, not computers. Now that we've laid the groundwork for the actual policies, let's decide how we want to create and manage the local Administrative groups for your member servers. **Note #2** You must design this implementation with consideration given to token bloat **End Note**

Option 1:

Create Initial Control GPO

1. Create a group for each computer object within Active Directory. Keep in mind the token bloat concern.
   Get-ADComputer -Server contoso.com -Filter {(Enabled -eq $true) -and (OperatingSystem -like '*Server*')} | Foreach{ New-ADGroup -Name "$($_.Name)_Administrators" -SamAccountName "$($_.Name)_Administrators" -Description "Administrator Access for $($_.Name)" -Path "OU=Groups -SVRAccess,OU=Role Based Access,OU=Groups,DC=contoso,DC=com" -GroupCategory Security -GroupScope DomainLocal }
2. Create the Administrative group (such as a Server Administrators group) that has access to all servers. Remember, you want to delegate access away from the default "Domain Admins" group.
3. Create your Group Policy object following your naming scheme, but ensure it is not linked anywhere.
4. Navigate to Computer Configuration\Preferences\Control Panel Settings within the GPO
5. Click Local Users and Groups.
6. Right click and select New --> Group
7. Create the group as follows:
   1. Action: Update (This will always be an update if you are modifying existing groups)
   2. Group Name: Administrators (built-in) - Select from the drop-down.
   3. Description: Administrators have complete and unrestricted access to the computer/domain
8. Place a checkmark in both Delete All Member Users and Delete All Member Groups.
   1. Warning, this is what makes this as powerful as this is. Selecting these options then accidentally linking will remove all users/groups for every machine which the policy is applied to.
9. Click <Add…> to add a local group member.
   
10. Click the <…> button on the Local Group Member box.
11. Search for your desired group (ex: Server Administrators ) and click Check Names. Click OK to close.
12. Click <OK> to save.

**Note #3** This policy will overwrite any existing users and groups. You cannot restore, so be very careful when applying this. Make use of security filtering and be mindful of risk mitigation within your environment. Your end result should look like the below:

Add Specific Permissions for Every Machine

1. With the same GPO still open, Right click and select New --> Group
2. Create the group as follows:
   1. Action: Update (This will always be an update if you are modifying existing groups)
   2. Group Name: Administrators (built-in) - Select from the drop-down.
   3. Description: Administrators have complete and unrestricted access to the computer/domain
3. Do *NOT* place a checkmark in the Delete all options.
   
4. Click <Add…> to add a local group member.
5. Type %DomainName%\%ComputerName%_Administrators (or whatever you picked as your group name)
6. Click <OK> to save.

Your end result for these steps should look like the below: All that is left is to test in an isolated environment.

Option 2

Add permissions per server "farm"

1. Open GPMC (if not already open)
2. Open the existing GPO created in the previous section
3. Navigate to Computer Configuration\Preferences\Control Panel Settings within the GPO
4. Click Local Users and Groups.
5. Right click and select New --> Group
   1. Action: Update (This will always be an update if you are modifying existing groups)
   2. Group Name: Administrators (built-in) - Select from the drop-down.
   3. Description: Administrators have complete and unrestricted access to the computer/domain
6. Do *NOT* place a checkmark in the Delete all options.
   
7. Click <Add…> to add a local group member.
8. Click the <…> button on the Local Group Member box.
9. Search for your desired user or group (ex: Domain\jdoe or Domain\WEB_Administrators) and click Check Names. Click OK to close

1. Click Common Tab
2. Place checkmark in Item-Level Targeting and click <Targeting…>

1. Click the New Item dropdown

Below are different examples of queries that can be performed to target specific machines for least privilege access.

Computer Name Example:

The Computer Name can be utilized in different ways. Individual machines can be targeted, or farms of machines (like a web farm). The first example shows an individual machine.

1. Within the Targeting Editor that is open from the first step, click the <…> button
2. Enter the desired computer name in the Select Computer window and click Check Names.
3. Click <OK> to close
4. Computer name will then be populated. If you know the exact name of the computer, you can type it in the box.
5. Click <OK> to close the Targeting Editor window.

This second example shows how to target a farm.

1. Within the Targeting Editor that is open from the previous step, type the System name, such as MDT0*. Star (*) is a wildcard and can be used anywhere within the query.
2. Examples include:
   1. *MDT0* (If a location prefix is at the beginning of system names)
   2. *MDT*01 (If you have a naming scheme such as LOC,Purpose,#01)
   3. MDT0* (If system names only end in a number)
3. This can be customized as needed. This should be tested thoroughly in your environment. PowerShell can be utilized for this testing
4. Get-ADComputer -Filter * | Where-Object Name -like MDT0*

This process can be used to manage not only the local Administrators group, but any number of groups (even custom groups created on the system. This includes (but is not limited to): Administrators; Remote Desktop Users; Event Log Readers; Remote Management Users. Group Policy Preferences allows you to leverage item level targeting without having to create multiple OU's, utilize Security Filtering, or perform some other trickery to implement that you would need to using Restricted Groups. Restricted Groups still provide a very valid use case, as the scenario described above is for granular management. If there is a desire to manage all machines (such as Desktops) with the same AD group, Restricted Groups provides an easier avenue towards implementation. In the end, the design aspect is the most important piece of the puzzle in this implementation. Decisions need to be made on flexibility versus group/token bloat. This scenario may not work in every environment, so as always, Your Mileage May Vary (YMMV). Thanks for reading everyone!