Problem solve Get help with specific problems with your technologies, process and projects.

Where does your client's security policy actually come from?

Your clients could be getting different domain-enforced security settings than what you defined in your domain policy.

Did you know that it is possible for your clients to get domain-enforced security settings that are completely different from what you have defined in your domain policy?

The application of Group Policy is, for the most part, pretty straight forward. Computer settings apply to computers, and user settings apply to users, right? Well, actually, clients do not get their account security policy directly from the domain policy; it comes from the domain controller's local policy. I've found few administrators who understand this principle, yet it is crucial in the design of a company's security policy and for troubleshooting security issues such as password requirements and account lockout.

Let's see how it works.

There are a few basic principles we need to remember.

  1. Account security settings are only applied from policy at the domain level. Microsoft recommends you put these security settings in the default domain policy. It is possible to put account security settings in multiple policies at the domain level, and they will be processed according to normal Group Policy Object (GPO) priority using the "last writer wins" rule. However, having conflicting settings in multiple policies doesn't make sense and creates problems when troubleshooting. It is therefore a good idea to apply security just to a single GPO whether that is the default domain policy or a special purpose GPO, called something like "Domain Security Policy."
  2. It is possible to define security in GPOs applied to organizational units (OUs), but they will only apply to the local security policy of clients that are members of the domain. When a user logs in to the domain, he or she will get the security settings from the domain policy -- not the local policy (see #3).
  3. Domain controllers provide security settings to domain users at logon time. This is a critical (and confusing) concept. The user's machine doesn't pull the security settings from the GPO at startup as it does for other machine settings. The client gets the security settings when the user is validated.
  4. The security settings that domain controllers apply to clients upon a successful user logon are those that are stored in the DC's local secedit.sdb security database.
  5. The DC gets the Account Security settings from the domain policy and applies them to its local .sdb. Note that this applies only to the account security settings, not to any other policy setting.
  6. DCs replicate their local .sdb with each other. (Honest!)
What does all this mean?

The easiest way to demonstrate this is to point out what happens if you choose to block inheritance at the Domain Controllers OU, which some organizations do. If you block inheritance, your Account Policy settings will not get to the DC's secedit.sdb (see #1 and #5 above) and, thus, will not be applied to the client (see #3 above).

For example, suppose you had defined a password length of 8 characters in the default domain policy prior to blocking inheritance -- so the DCs have that value defined in their local secedit.sdb. Then you set the Block Inheritance option at the Domain Controllers OU. Later you have a corporate mandate to change the password minimum length to 10.

Here's what will happen if you set the Block Inheritance option on the Domain Controllers OU as just described:

First, log on to a client with a domain account and reset the password to an 8-character password. It works, but it shouldn't because the policy says 10 -- right? Run GPresult/v (assuming the client is XP) and the password length will be 10. Table 1 shows this graphically, assuming the user logged on with a domain account, along with other Account Policy settings.

Setting Domain policy value DC secedit.sdb value Local policy setting Effective setting for the user
Password length 10 8 10 8
Password history 24 5 24 5
Table 1. These are the effective settings when users log on with a domain account when Block Inheritance has been enabled on the Domain Controllers OU.

Note: In Windows 2000 Pro, the local security policy GUI had a column called "Effective Settings." This is not shown in XP. The term "Effective Settings" used here refers to the actual settings that will affect the user, depending on whether the person logs in as a local user or a domain user.

From this table, you can see that if the user logs on with a domain account, he or she will get the policy from the DC that is stored in the DC's secedit.sdb.

Table 2 shows what users experience if they log on to a local account.

Setting Domain policy value DC secedit.sdb value Local policy setting Effective setting for the user
Password length 10 8 10 10
Password history 24 5 24 24
Table 2. These are the effective settings when users log on with a local account when Block Inheritance has been enabled on the Domain Controllers OU.

You can see that this is very confusing. For all intents and purposes it appears that the client gets the domain policy values but the effective setting is different. When logged into a local user account, the user gets the local security policy, which is populated with the domain policy settings imposed on the client. However, when logged into the domain account, the user gets the settings that the DC has in its secedit.sdb. The DC's secedit.sdb has the last settings it received from the domain policy before the Block Inheritance option was enabled. When Block Inheritance is enabled, the new settings -- defined in the domain policy -- cannot be populated to the DCs. Thus, when the client contacts the DC, it gets the settings the DC knows about, which are different from what the actual policy specifies.

Why do it?
So, if blocking inheritance at the Domain Controllers OU causes such mayhem, why do it? Many companies deploy a number of GPOs at the domain level for such things as desktop lockdown. Obviously, you don't' want to apply lockdown policies to DCs. Enabling Block Inheritance at the Domain Controllers OU prevents miscellaneous settings from applying to domain controllers. There are better designs that would prevent this, such as putting the lockdown policies in OUs but, in some cases, Block Inheritance is a good option.

How to make it work
You have to block inheritance on the Domain Controllers OU, but that messes up the security policy. So, how do we make it all work together? Here are your options:

  • Set the No Override option on the GPO where the security settings are defined. This will force the account settings to the Domain Controllers OU in spite of the Block Inheritance setting.
  • On a DC, define the local security settings so the account policies are what you want for the domain. It seems that the DCs will replicate this among themselves. I don't know if it is safe to assume this always happens, so I always check the other DC's secedit.sdb to make sure the change is made.
  • Use security filtering so lockdown policies don't apply to DCs.
For my money, setting the No Override option is easiest, but remember that it will also enforce other policy settings defined in that GPO. Therefore, I would recommend the following:
  • Define a single-purpose GPO called Account Security Policy.
  • Configure the Account Security settings (Password, Account Lockout, Kerberos) as desired.
  • Enable the No Override option on the Account Security Policy GPO.

What about Kerberos settings?
Just as the password length was set (from an actual client case I worked on), the same principle applies to all Account Policy settings -- Password, Account Lockout and Kerberos. For instance, in another case the administrator had somehow set the Kerberos "Maximum Tolerance for Computer Clock Synchronization" setting to "Not Defined" (default is 5 minutes), which applied it to the DC. Then they blocked inheritance on the Domain Controllers OU. That setting defines the time skew allowed between clients for Kerberos to successfully authenticate (the default being 5 minutes). I don't know why they set it to "Not Defined." When set to Not Defined, the skew is zero (0), thus authentication would always fail because the clocks between the client and DC would never perfectly match. In addition to failed client logons, replication failed as well. The company chose to modify the DC's secedit.sdb and set the time skew to five minutes rather than setting No Override on the domain security policy, and it fixed the problem.

Note that Kerberos settings can only be defined at the domain level. Look in the Default Domain Controller Policy, and you won't see the settings.

If you never block inheritance on the Domain Controllers OU, you won't ever see this problem. Nevertheless, it is good to understand this situation so you'll know how the security policy gets applied and are ready for such a situation. If you are ever presented with an edict from "up above" to block inheritance on this OU, you will be prepared to explain the ramifications rather than calling support when users complain that they can't log on.

Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers.

Dig Deeper on Windows systems and network management