Group Policy allows you to add and remove users to an Active Directory (AD) group. Using this feature improves security because you can ensure that high-risk security groups only contain the users that you specify via Group Policy.
Profile gravatar of Josh Rickard

Josh Rickard

Josh's primary focus is in Windows security and PowerShell automation. He is a GIAC Certified Windows Security Administrator (GCWN) and GIAC Certified Forensic Analyst (GCFA). You can reach Josh at MSAdministrator.com or on Twitter at @MS_dministrator.
Profile gravatar of Josh Rickard

In this example, I am going to use the built-in Domain Admins group created when you first set up your domain. You can use this same process for any group you want to manage via Group Policy. But you should manage this group (and others like Domain Controller Admins etc.) this way since they are high-risk groups (this group has the keys to the kingdom).

To manage the Domain Admins group, you will need Remote Server Administration Tools (RSAT) installed. After installing that, open up the Group Policy Management Console (GPMC) and navigate to the root of your AD forest. Next, right-click and select Create a GPO in this domain, and Link it here… When prompted, assign a descriptive name to this GPO (I'm using Manage Domain Admins, but you can use whatever your standards are in your organization).

Create a GPO and link it to the root of your AD forest

Create a GPO and link it to the root of your AD forest

Once you have your GPO created and linked to the appropriate location, you will then need to right-click and select Edit to modify your new Group Policy Object. In the new GPO window, we should navigate to the following location:

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Restricted Groups

Once in the Restricted Groups section, either right-click in the empty space on the right-hand side or right-click on the Restricted Groups item in the navigation tree. Then select Add Group, and the Add Group dialogue box will display. We select the desired group we want to manage here. In my example, I am using Domain Admins.

Adding the group you want to manage with Group Policy

Adding the group you want to manage with Group Policy

We now select OK and then OK again in the Add Group dialogue box. Once you do this, a new dialogue box will open that allows you to add members to this group. There are two options available in this new dialogue box: Members of this group and This group is a member of.

We are going to be using Members of this group. By using this, we are ensuring that specific individuals or accounts are part of the Domain Admins group. This ensures that if someone accidently or maliciously has added an account to the Domain Admins group, the next time Group Policy refreshes (every 90 minutes, with a random offset of 0 to 30 minutes) it will remove those members (unless they have added them via this GPO).

For this example, I have two user accounts I will use. The first is an MSAdministrator and Administrator account I want to be in the Domain Admins group. I will not add the second account named Malicious User here, but I will add it to this group in Active Directory to show the removal process.

For added protection, go to your Manage Domain Admins GPO in the GPMC and navigate to the Delegation tab to restrict who can edit this specific Group Policy Object.

Add users you want to be part of the Domain Admins group

Add users you want to be part of the Domain Admins group

Press OK and close out of all open windows in the Group Policy Management Console. Next, we will add our Malicious User to the Domain Admins group in Active Directory.

Adding a test Malicious User to the Domain Admins group

Adding a test Malicious User to the Domain Admins group

Now that we have created our Group Policy in the root of our domain, the next time that Group Policy refreshes, it will remove the Malicious User from the Domain Admins group. This is because we have overwritten or trumped the group membership in Active Directory with our own group members. This ensures that if someone accidently added a user or a malicious actor wanted to gain control of your domain, that user would now need to modify the permissions of our Group Policy Object as well as the group in Active Directory. This adds another layer of protection by making it more difficult for a potential takeover in our environment.

After updating Group Policy (run gpupdate /force if you do not want to wait for the refresh interval), you can view the Domain Admins group in Active Directory. You will see that the system has updated our group members appropriately.

Group Policy has overwritten our Domain Admins group members

Group Policy has overwritten our Domain Admins group members

Managing our security and distribution groups via Group Policy adds a level of assurance against accidently adding or removing members from our groups. This allows for better management of these groups, as well as protection against both accidents and malicious attackers that may infiltrate your network.

Win the monthly 4sysops member prize for IT pros

Share
1+

Users who have LIKED this post:

  • avatar

Related Posts

9 Comments
  1. Profile gravatar of Luc Fullenwarth
    Luc Fullenwarth 2 months ago

    Hello Josh,

    I use this technique for the local Administrators group on desktops, but not the local Administrators group on servers because members of this group are often different from one server to another.

    But, in this case each computer is checking his own groups, like you said, every 90 minutes plus the random offset.

    However, when you set a GPO to check domain groups, all concerned servers by this GPO will all check the same domain group.

    For example, if you link the GPO to the Domain Controllers OU, and you have 10 domain controllers, the group will be checked on an average rate of a little more than 9 minutes.

    And if you link it to an OU containing 100 servers, the same domain group will be checked about every minute.

    Thus, I wonder what you propose for "linked to the appropriate location" when you are talking about a Domain Admins group.

    1+

    • Profile gravatar of Leos Marek
      Leos Marek 2 months ago

      Hi Luc. The same group appliance is not completely correct. You can set system variable on the servers (via script based on hostname, ou presence, or whatever you like) and then you can define a single GPO which says to assign %variable%-group to admins.

      This works perfectly, you just have to maintain the sysvar..

      Leos

      0

      • Profile gravatar of Luc Fullenwarth
        Luc Fullenwarth 2 months ago

        Hi Leos,

        How would you exactly apply this to the tutorial above?
        Could you please provide the list of all your steps in detail?

        0

        • Profile gravatar of Leos Marek
          Leos Marek 2 months ago

          Hi Luc, sorry it was a mistake, I didnt read properly... not really related to the above story..

          0

    • Profile gravatar of Josh Rickard Author
      Josh Rickard 2 months ago

      Hey Luc, sorry for the late reply.  I was away on vacation for a bit. 🙂  You can apply a GPO to manage the Domain Admin group in any location.  It really depends on if you have alerting or any automation to notify if your Domain Admin group gets changed.  If you do not, then you can apply it at the root of your domain.  This will ensure that it is applied anytime that Group Policy is updated.  If you do, then I would still apply it at the root of your domain and adjust my alerting (but that's me).

      If you are using Domain Admins on your systems (workstations & servers) then you will want to make sure that any changes made to the Domain Admin group is applied and reflected across your systems as quick as possible.  You may not want to wait 90 minutes for permissions to update on a server/workstation.

      Thanks and sorry again for the late reply.

      0

      • Profile gravatar of Luc Fullenwarth
        Luc Fullenwarth 2 months ago

        Yes I agree with you that being able to fix a group without having to wait up to 2 hours is very good.

        While that's sounds perfectly ok for environment with few servers, I wonder about the consequences when a group is accessed for writing several times by second by different computers.

        I never faced such a situation. Thus it's an open question for which I don't have the answer for the moment.

        However, instinctively I would just apply this GPO to an OU containing less than 100 computers instead of applying it at the root of the domain.

        0

  2. avatar
    VINICIUS DELLAGLIO 2 months ago

    I have a different approach for adding users to groups using GPOs: with restricted groups, instead of managing the MEMBERS list, I manage the MEMBER OF. How that works: you create a group and using the GPO you set that this group will be member of a specific group (ie local administrators). This is another way to go, but it won't keep the specific members as explained on your tutorial. I personally like both approaches.

    3+

    Users who have LIKED this comment:

    • avatar
    • avatar
    • Profile gravatar of Josh Rickard Author
      Josh Rickard 2 months ago

      Hey Vinicius, you are correct!  I have definitely done both, but adding the members explicitly to restricted groups ensures that no one is "injected" into a group without first having a layer of approval to that GPO to edit said group.  By adding to the member of, all the permissions I technically need is OU Admin rights (which, we can compromise by phishing another IT member 🙂 ).

      You are correct though, adding by group definitely has it's place and benefit!

      Thanks!

      0

  3. avatar
    Willem Kasdorp [MSFT] 2 months ago

    Hi,

    This trick has a couple of potential problems, especially in large forests with significant replication latency. For this reason, managing "members" using restricted groups for domain groups is formally unsupported: https://support.microsoft.com/en-us/help/279301/description-of-group-policy-restricted-groups. This says:

    "Microsoft does not support using Restricted Groups in this scenario. Restricted Groups is a client configuration means and cannot be used with Domain Groups. Restricted Groups is designed specifically to work with Local Groups. Domain objects have to be managed within traditional AD tools. Therefore, we do not plan currently to add or support using Restricted Groups as a way to manage Domain Groups."

    0

Leave a reply

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

*

CONTACT US

Please ask IT administration questions in the forum. Any other messages are welcome.

Sending
© 4sysops 2006 - 2017

Log in with your credentials

or    

Forgot your details?

Create Account