Understanding Local and Effective Security Permissions

The whole point of Group Policy is that when you make a wish from upon high, your client machines will embrace your wish. I've already discussed that Group Policy can be set, if you like, on the local machine. However, GPOs from Active Directory that contain policy settings that conflict with those on the local machine will "win" and override those set at the local machine.

If a local security policy is set on a machine and then a GPO in the domain "wins" you'll want to know, at a glance, which changes are coming from upon high within Active Directory Group Policy. This is the difference between "local" policies and "effective" policies.

Note 

With Windows 2000 clients , it was sometimes difficult to tell that your security wishes were being embraced. Windows 2000 local policy has a Local Setting and Effective Setting column to assist; but it wasn't always accurate. An older KB article (Q257922) described this as "Local Security Policy May Not Accurately Reflect Actual System Settings." However, that KB article is no longer available.

The user interface in Windows XP and Windows 2003 member servers has changed a bit since Windows 2000. Specifically, it now clearly distinguishes between security policies that can be changed locally versus security policies that are coming from upon high.

Figure 6.5 shows the local machine policy via GPEDIT.MSC. Many Security Option settings are not being enforced from an Active Directory GPO (say, at the domain level or in an OU that contains the client machine). However, in Figure 6.5, I set up one policy setting, the Devices: Restrict CD-ROM access to locally logged in user , set to Enabled within a GPO linked to the OU that contains the computer. Because Active Directory GPOs trump local computer policy, this security policy setting therefore cannot be adjusted locally.

Figure 6.5: Active Directory GPOs restrict the modification of local computer policy. Windows XP has a better way than Windows 2000 to display effective permissions. The icon within the local computer policy has changed from "1/0" icons to a scroll and computer icon.

Trying set this security policy setting locally (once it's set from a GPO linked to the OU) is not permitted. Indeed, the icon changes within GPEDIT.MSC to show you that the security policy is set within Active Directory:

• The security policies that are being dictated from a GPO in Active Directory have a little scroll icon flanked with two computers.

• The security policies that can still be set locally have "1/0" icons.

This same "effective setting" icon theme is valid throughout other security settings categories: Account Policy (including Password policy), Audit Policy, User Rights Assignment, and Security options.

The Strange Life of Password Policy

If you create a new GPO, link it to any OU, and then edit your new GPO, it certainly appears as if you could set the Password policy and Account Lockout policy.

For example, I have a Sales OU in which I recently placed XPPRO2. As you can see in Figure 6.6, I created and linked a GPO, called "Sales Password policy," to the Sales OU. I am setting the Password policy such that the minimum password length is 10 characters .

Figure 6.6: It might seem counterproductive to set the Password policy at any level but the domain.

At first glance this would seem to be counterproductive, because, as already stated, these policy settings only take hold of the accounts in the domain via the "Default Domain Policy" GPO. But administrators might actually want to perform this seemingly contradictory action. That is, when the user logs on locally to the Windows 2000 or Windows XP workstation, the account policy settings contained in the GPO linked to the OU will have been magically planted on their machine to take effect for local accounts. In Figure 6.7, I have logged in as the local administrator account on the workstation.

Figure 6.7: Setting a Password policy in the domain (other than at the domain level) will affect passwords used for local accounts upon member machines.

Again, this won't affect users' accounts when users are logging on to the domain; rather, it affects only the local accounts on the targeted computers. This could be helpful if you grant local administrator rights to users upon their workstations or laptops and want to set a baseline.

Tip 

If you are still using Windows 2000 machines, the contents in Figure 6.7 would should show both "Local" and "Effective" settings for Windows 2000 Professional machines. However, because of the behavior described here, the effective settings might not be accurate. Again, this is noted in the old (and seemingly disappeared) KB 257922: "Local Security Policy May Not Accurately Reflect Actual System Settings."