Security Settings

Computer Configuration\Windows Settings\Security Settings

Description

Security settings are grouped into seven areas:

Administrators may define a security policy in Active Directory that contains specific security settings for any and all security areas. This is accomplished by defining security settings in a Group Policy object (GPO) that is associated with a domain or an organizational unit (OU). Security settings that are defined for a domain or OU apply to all machines that are contained in that domain or OU.

A security policy may also be established on the local machine. However, local machine policies can only contain security settings for the first two security areas (Account Policies and Local Policies). While all other security areas may be configured on a local machine through the use of various tools, a local security policy may only be established for Account Policies and Local Policies.

When there are conflicts, Security settings that are defined in Active Directory always override any security settings that are defined on the local machine. Security settings for an OU always override security settings defined in any parent OUs or on the domain itself. Thus, when determining the security settings that apply to a specific machine, the order of precedence may be represented as follows, from lowest to highest:

• Local security policy

• Domain policy

• OU policy

• ...

• OU policy (for the OU that the machine is contained in)

Windows 2000 Workstations and Servers

By default, a local security policy is defined on all Windows 2000 workstations and servers. This policy defines security settings for all Account Policies and Local Policies with the following exceptions:

• Kerberos Policy

• Disable CTRL+ALT+DEL requirement for logon

• Rename Administrator Account

• Rename Guest Account

• Driver and Non-Driver Signing Policy

• Nonexistent registry keys on upgrades

A Kerberos policy is not defined on local machines because Kerberos settings are domain-wide and cannot be configured on individual machines. The CTRL+ALT+DEL requirement is not defined because this setting differs depending on whether or not the machine is joined to a domain. The Administrator and Guest account names are not defined because these accounts are not "renamed" by default. A signing policy is not established because there are specific mechanisms for configuring these values during unattended setup. Finally, for upgraded machines, there may be several registry values that did not exist on the previous Windows NT4 configuration. No attempt is made to create these registry values during the upgrade process, so any policy associated with these registry values remains undefined.

Aside from these noted exceptions, the default local security policy for servers and workstations defines values for the 90 or so other Account and Local policy settings and is described below.

It is important to note that even though a policy may not be defined for a particular value, it does not mean the actual system setting is not defined. It just means that there is no policy regarding that particular setting. In these cases, the system always assumes some default value. For example, if a machine is joined to a domain, then CTRL+ALT+DEL will be required for logon. If the machine is a stand-alone workstation, then CTRL+ALT+DEL will not be required to logon. This is the behavior when the local security policy for this option is not defined. To change this default behavior, or to establish a policy regarding this behavior (even if it's the same as the default behavior), the setting for this security option should be defined.

Local security policy settings, if defined, may not be "undefined." Maintaining a defined state for all local policies ensures that a system is not "tattooed" with an Active Directory based setting that has since been undefined. For example, consider the security option Additional restrictions for anonymous connections . By default, there are no additional restrictions for anonymous connections, and this is reflected in the default local security policy. Now assume that an administrator decides to define additional restrictions for all machines in the domain. The administrator modifies the Default Domain GPO and configures this security option. Subsequently it is determined that certain applications no longer function properly with these restrictions so the administrator "undefines" the domain-level policy. If there were no local policy definition for this security option, then the domain-level policy would remain in effect even after it was "undefined". By having a local policy defined, that local policy setting becomes effective when the domain-level policy is not defined.

Windows 2000 Domain Controllers

By default, Account Policies (Password, Lockout, and Kerberos settings) are all defined in the Default Domain GPO. Since Domain Controllers are responsible for enforcing these domain-wide policies, Domain Controllers always receive these settings from the Default Domain GPO. Furthermore, since Password and Lockout Policies are defined in the Default Domain GPO, all Windows 2000 machines in that domain obtain the same password and lockout policies for their local Security Accounts Manager (SAM) database even though they have their own default local account policies defined. This happens because domain-level policies have precedence over local policies. Note that it is possible to specify a different local password policy on workstations or servers by including those workstations or servers in an OU which has its own account policy settings. This is because an OU policy has precedence over a domain policy.

Audit Policy and User Rights are defined by default in the Default Domain Controller GPO, which is associated with the Domain Controllers OU. As a result, all domain controllers have the same Audit and User Rights policy. Thus, for example, to grant an individual the interactive logon user right on a domain controller, the Default Domain Controller GPO should be modified. If the Default Domain GPO were modified instead, then all workstations in the domain would be affected (domain policy overrides local policy), but the target domain controllers would not be affected (OU policies have precedence over domain policies). With the exception of one security option ( Digitally sign server communication when possible ), the Security Options subcategory of local policies is not defined in the Default Domain Controller GPO. These security options are not defined on the default domain controller GPO because it is possible, and may be desirable, to have different values defined for individual domain controllers. These different options may be configured on individual domain controllers, for example, by using the Security Configuration and Analysis and Security Templates MMC Snap-ins.

Policies for Event Log Settings, Restricted Groups, System Services, Registry access control lists (ACLs), and File System ACLs may all be defined on Domains or OUs in Active Directory. This allows administrators, for example, to ensure that all Windows 2000 system directories are protected in a certain way or that members of the local Administrators group on all machines only contain a certain set of individuals. Since these security areas are not considered part of local security policy, any changes made by means of an Active Directory based policy will remain intact even if the administrator decides to "undefine" the policy. The reason for this is that no local security policy is maintained for these security areas. No local security policy is maintained for these areas because these settings are primarily managed with other tools such as the access control list editor in Windows 2000 Explorer. If a local policy were maintained for file ACLs, for example, administrators would have to define access permissions by means of the local policy editor (rather than Windows 2000 Explorer) to avoid having any changes overwritten by the policy.