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**
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 }
**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:
Your end result for these steps should look like the below: All that is left is to test in an isolated environment.
Below are different examples of queries that can be performed to target specific machines for least privilege access.
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.
This second example shows how to target a farm.
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!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.