Partager via

Applying security settings

  • Article

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

Applying security settings through Group Policy

When policy is applied

Once you have edited the security settings, the settings are refreshed on the computers in the organizational unit linked to your Group Policy object:

  • When a computer is restarted the settings on that computer will be refreshed.

  • The security settings are refreshed every 90 minutes on a workstation or server and every 5 minutes on a domain controller. The settings are also refreshed every 16 hours, whether or not there are any changes.

  • To force a computer to refresh its security settings as well as all Group Policy settings, see the Gpupdate command line tool.

Precedence of policy when more than one policy is applied to a computer

For security settings which are defined by more than one policy, the following order of precedence, from highest to lowest, is observed:

  • Organizational Unit Policy

  • Domain Policy

  • Site Policy

  • Local computer Policy

For example, a workstation that is joined to a domain will have its local security settings overridden by the domain policy wherever there is a conflict. Likewise, if the same workstation is a member of an Organizational Unit, the settings applied from the Organizational Unit's policy will override both the domain and local settings. If the workstation is a member of more than one Organizational Unit, then the Organizational Unit that immediately contains the workstation has the highest order of precedence.

Notes

  • Use Resultant Set of Policies tool to find out what policies are applied and in what order to a computer. For more information , see Resultant Set of Policy.

  • For domain accounts, there can be only one account policy which includes password policies, account lockout policies, and kerberos policies. For more information, see Account and local policies.

Persistence in security settings

Security settings may still persist even if a setting is no longer defined in the policy that originally applied it.

Persistence in security settings occurs when:

  • The setting has not been previously defined for the computer.

  • The setting is for a registry object.

  • The settings is for a file system object.

All settings applied through local policy or a Group Policy object are stored in a local database on your computer. Whenever a security settings is modified, the computer saves the security setting value to the local database which retains a history of all the settings that have been applied to the computer. If a policy first defines a security setting and then no longer defines that setting, then the setting takes on the previous value in the database. If a previous value does not exist in the database then the setting does not revert to anything and remains defined as is. This behavior is sometimes called "tattooing."

Registry and file settings will maintain the values applied through policy until that setting is set to other values.

Filtering security settings based on group membership

You can also decide what users or groups will or will not have a Group Policy object applied to them regardless of what computer they have logged onto by denying them either the Apply Group Policy or Read permission on that Group Policy object. Both of these permissions are needed to apply Group Policy. For more information, see Group Policy (pre-GPMC).