IMPORTANT ANNOUNCEMENT FOR OUR READERS!
AskPFEPlat is in the process of a transformation to the new Core Infrastructure and Security TechCommunity, and will be moving by the end of March 2019 to our new home at https://aka.ms/CISTechComm (hosted at https://techcommunity.microsoft.com). Please bear with us while we are still under construction!
We will continue bringing you the same great content, from the same great contributors, on our new platform. Until then, you can access our new content on either https://aka.ms/askpfeplat as you do today, or at our new site https://aka.ms/CISTechComm. Please feel free to update your bookmarks accordingly!
Why are we doing this? Simple really; we are looking to expand our team internally in order to provide you even more great content, as well as take on a more proactive role in the future with our readers (more to come on that later)! Since our team encompasses many more roles than Premier Field Engineers these days, we felt it was also time we reflected that initial expansion.
If you have never visited the TechCommunity site, it can be found at https://techcommunity.microsoft.com. On the TechCommunity site, you will find numerous technical communities across many topics, which include discussion areas, along with blog content.
NOTE: In addition to the AskPFEPlat-to-Core Infrastructure and Security transformation, Premier Field Engineers from all technology areas will be working together to expand the TechCommunity site even further, joining together in the technology agnostic Premier Field Engineering TechCommunity (along with Core Infrastructure and Security), which can be found at https://aka.ms/PFETechComm!
As always, thank you for continuing to read the Core Infrastructure and Security (AskPFEPlat) blog, and we look forward to providing you more great content well into the future!
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