First published on TechNet on Aug 14, 2017
Hi everyone! My name is Tim Medina, Premier Field Engineer, and today we are going to take a brief look at GPOs with a focus on restricted groups. More importantly, we will discuss how, if used in an unsupported manner, you can cause your very own replication hurricane. But, before we get into that let's take a moment and point back to the official use guidance for Restricted Groups in Group Policy: https://support.microsoft.com/en-us/help/279301/description-of-group-policy-restricted-groups Read that over then come back, no worries I will be right here. All done? Let's get moving then storm's coming in… First let's hit the ground running with the basics, where this works best. The use of Restricted Groups in GPOs is often used as a managed security set to ensure tampering of rights does not occur on a domain member specifically with rights allocation to local groups. As seen below we go into the Windows Settings and can add a Global Group to the Restricted Group target Local Group. When applied to target systems you see that it is now functional under the GPO control and local control. This will allow you to step forward with distributing rights to specific accounts if you chose to give rights and access. From here normal distribution and application of this GPO takes place, the system updates in the background and then new settings apply and the group targets are updated. So you look up and see the blue sky world of distributed rights that are GPO controlled and say to yourself "I CAN DO THIS ANYWHERE!!! RIGHTS FOR YOU AND YOU AND EVERYBODY!". Which you can do to a point and that is when things can go sideways as you build your own hurricane. It should be noted here that the following is done only in a lab and to show by example. This is a non-supported function and will cause direct harm to your environment. If you did not read the article at the top, take a second and do so now. So we dig into the policies and some colleague says, "Why not do this with Domain Admins!" *cue storm clouds moving in* So we start a new target GPO and link it to your Domain Controller (or anywhere) OU since that is your control target system set. From there we add a user or group to the global group similar to what is seen above and off we go with the addition that this group is also part of Domain Admins. Everything seems fine until you start looking at the effects of what we are doing. See below: The GPO refresh triggers an update that then triggers an update that then triggers an update and so on. This cascade effect will cause your very own replication storm until the system fully accepts the change made or backs it out. So let's say you then attempt to make a change (for illustration we will say we have 50 DCs) to a different applicable GPO for a setting update where this GPO is applied. So you propagate said change that will then trigger a refresh check, which will in turn trigger your RG GPO to fire once more. Again, resulting in a storm which can also back out your new GPO change if other systems replicate back the change first which is the expected call. One update causes another which triggers the restricted group update to precede the target change and thus reversion occurs. In the end you have a nice hurricane in a bottle and is also why it is not supported because, it can cause direct harm to your environment. If you have questions on this leave me a comment and we can talk more about it. If you or anyone else you know has other questions, why not submit them to us to cover here! Just send us a message at AskPFEPlat@microsoft.com Thanks for reading! Tim "I can make a replication hurricane" Medina
Microsoft