Restricted Groups policy and AD groups--not a good idea
A while back there was a thread on ActiveDir about Restricted Group policy--the security policy feature in GP that lets you manage group membership. Someone had suggested using Restricted Groups to manage AD group membership and I mentioned that it was a bad idea.
Here's why.
First, let's think about how Group Policy is processed. A given client machine--be it a server or workstation--will process GP in both the foreground and background. Foreground processing happens at machine startup or user logon, while background processing happens on a periodic basis--every 5 minutes for DCs and every 90 minutes (plus a 30 minute randomizer) for workstations and member servers. Further, a client processes GP by first locating a DC in its own site (using the normal DC locator process) and then reading the various parts of each GPO that apply to it from both AD and the portion of the GPOs that reside in SYSVOL on that DC.
Ok, now that we've laid that groundwork, let's think about applying restricted groups policy to AD groups, rather than its natural and intended use--which is for managing local group membership on workstations' and member servers' local SAMs. So, in order to manage AD group membership, which resides in AD, we would need to apply a restricted groups policy to an AD domain controller, because that is where AD group membership is held. Now, as we know, AD is a "loosely consistent" multi-master replicated database. GPO changes occur, by default, on the PDC emulator and replicate out from there. In addition, because AD replication happens at a different pace than SYSVOL replication, on a given domain controller, at any given time, there may be a version of a GPO in AD that is different from the SYSVOL version. So now lets imagine that you make a change to an AD group's membership using Restricted Groups policy. You make the change at the PDC emulator, and then that change starts to replicate to all other DCs. However, because a DC processes policy in the background every 5 minutes, you might have some DCs that have gotten the AD replication change of the new restricted groups policy but not the SYSVOL part. Therefore, when those DCs process the new policy, they will still have the old group membership information. Meanwhile, you have DCs that have gotten the new policy and they are each making group membership changes in AD, even though they all have the same group membership information. So, each DC that makes such a change will think that its changes are new, and will communicate that information to its partner on the next AD replication cycle. Additionally, you have some of these DCs that don't yet have up-to-date information from the SYSVOL portion of the GPO but are receiving new group membership information from AD replication from those DCs that did have the GPO up-to-date. As you can see, this can quickly get out of hand, with perceived group membership changes bouncing around from one DC to the next. In a large environment or an environment without Link-Value Replication enabled (e.g. Win2K), this could cause a lot of excess AD replication traffic, at the very least--not to mention inconsistent group membership state.
So the bottom line is, avoid using Group Policy Restricted Groups Policy for AD membership control. You're much better using a single-master system for updating group membership than relying on a mechanism such as Group Policy to perform this change.