When security policy is processed, Windows uses the secedit security configuration engine to process Group Policy-based security policy. Part of this processing relies on using a local security database, found on each Windows system, called secedit.sdb. This file is found, by default, in c:\windows\security\database. Occasionally this database can get corrupted and prevent security policy from applying on that machine. You can check for this by running the following command:

esentutl /g c:\windows\security\database\secedit.sdb

If the command finds errors you can use the esentutl utility's /p option to attempt to repair the file.

Yes, in fact security policy is one of those anomalies with respect to the "Don't process if the GPO hasn't changed" rules. By default, security policy (which is defined as policy found in Computer Configuration|Windows Settings|Security Settings) will process every 16 hours in the background, even if the GPO hasn't changed. This ensures that, for a critical area like security configuration, if the user has made a change on the local system that contravenes policy, that change will be undone on a periodic basis. You can actually modify this background refresh interval by editing the following registry value:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}\MaxNoGPOListChangesInterval

This value is stored as a hexadecimal number that represents the number of minutes between background refreshes.

There is a known issue in XP, SP1 and Win2K earlier than SP4 where using this feature in Restricted Group Policy won't work. Check out http://support.microsoft.com/default.aspx?scid=kb;en-us;Q810076 for information on a hotfix for XP. Note that there are two modes of operation for Restricted Groups policy. There's the "Members" policy in the top box, which mandates that, for a given group, only those users/groups listed in this dialog may be members. Use this policy with caution because any members of the target group that aren't in the list get removed the next time the GPO is processed. And administrative groups are excluded from this, meaning that you can very easily lock yourself out of a bunch of machine if you're not careful. The second part of Restricted Groups is the "Members of". This is where you can optionally ensure that the selected group is made of a member of a list of other groups. This membership in the local Administrators group is what was fixed by the hotfix noted above. Note also that if you use Restricted Groups policy on a GPO that is targeted by a Domain Controller, then the groups whose membership you are effecting reside in AD and thus this policy has an impact on AD replication and group membership (esp. in pre-Win2K3 environments where group membership is replicated as a single attribute).