Aren’t Restricted Groups great?  I love how they keep our groups safe.  Now, what are Primary Groups again?  Oh, that’s the Domain Users group, right?  What do Primary Groups have to do with Restricted Groups?  Here’s a scenario…

You’re the domain admin for your organization and management just informed you that you need to grant temporary domain admin rights to an application owner to do his install.  You’re not thrilled with the idea but you console yourself with the thought that it’s temporary.  As a progressive admin, you protect your domain groups with Restricted Groups so you crack open the policy and add the application owner’s admin account to the Domain Admins group.  The application owner completes his install and then let’s you know that he’s done.  You modify your Restricted Groups policy to remove the application owner from Domain Admins and you feel better.

As part of your annual audit, the Security Team inventories your Domain Admins membership and much to your surprise, there’ the application owner’s admin account.  You open Active Directory Users and Computers and look at the Members tab on the Domain Admins group and there’s the account.  You check out the Restricted Groups policy for Domain Admins and the application owner’s admin account isn’t in there. What happened?

By default, a user’s primary group is the Domain Users group but it’s membership is not stored in the memberOf attribute on the user or in the member attribute of the group (which are linked anyhow).  In fact, Domain Users typically has no values in the member attribute even though every user in the domain is generally a member.  That’s because a user’s primary group is stored in the primaryGroupID attribute on the user account itself.

Restricted Groups sets the member attribute on the group that it manages (if you’re making the policy restrictive).  If we’re protecting the Domain Admins group then it’s going to restrict the member attribute on this group to whatever security principals we’ve configured.  Since Primary Groups doesn’t affect the member attribute, Restricted Groups has no power over it.

When you made your application owner a temporary member of Domain Admins, he made the Domain Admins group his primary group.  He didn’t mean anything by it but when he did the Domain Admins group was removed from his memberOf attribute and set in his primaryGroupID attribute.  When you edited the policy to remove the application owner’s security principal, it didn’t do anything because there wasn’t anything to do.  The account was already removed from the member attribute of the Domain Admins group.

Now don’t worry about users with full permissions to their own accounts being able to edit the primaryGroupID attribute and make themselves members of Domain Admins or any other group.  They have to already be a member of the group before it can be set as the Primary Group.  However, while Restricted Groups are great, you do have to remember to keep an eye on your important groups.