There are numerous security settings that can be configured in a single Group Policy Object. These settings range from controlling the Administrator account to controlling the LDAP client signing requirements. With so many security settings, it is important to understand how the function and where there might be a behavior that is not as obvious as you would imagine. In December 2004 I wrote an article on “Enforcing Group Policy Security Settings” which will give you some detailed insight on how security settings can be enforced in a standard environment. In this article, I will expand on this concept (with some in-depth Registry “hacks”), as well as go into some of the most common scenarios where security settings do not behave as they appear.
Enforcing Group Policy Security Settings, Updated!
Back in the stone age using computing years, which is December 2004 in this context, I wrote an article on how you can ensure that your security settings were being applied. The article went into some dramatic detail on how you can verify which settings are “policies” and which settings were “preferences” giving you a clear understanding of how each setting was applied to the computer. With each type of setting you can enforce these settings at the standard Group Policy refresh interval, which is approximately every 90 minutes.
All of those details are still in play and the techniques that I illustrated to you are still possible and valid. However, there is another “built-in” technology that you should be fully aware of. This technology allows you to control how often the security settings in a GPO are refreshed, without ANY changes to the GPO itself. Yes, this is true! You can have all security settings apply automatically after X minutes even if there has not been a change to the GPO. The Registry value that you will need to alter is MaxNoGPOListChangesInterval, as shown in Figure 1.
Figure 1: You can modify how often the security settings in a GPO refresh
You can find this setting in the Registry under:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions\{827D319E-6EAC-11D2-A4EA-00C04F79F83A}
The default value for this setting is 960 minutes (or 0x3c0 in hex. (For those that are conversion inept, this is 16 hours))
This setting is very important as it allows administrators to ensure that security settings are being forced down and enforced on the users, without having this occur at every refresh interval. Users will now have a secure desktop, without having to see the negative impact of security settings being refreshed every 90 minutes or so.
Note:
There are some negative impacts on setting this value too low, especially if you are using this setting in conjunction with Sysprep images. Please be sure to test all settings before implementing into production.
Security Settings for Domain Controllers
I have written many articles over the years describing how the Account Policies in a Group Policy Object affect domain controllers and the local Security Accounts Manager (SAM) on servers and desktops throughout the domain. These settings are unique for domain controllers due to the nature of all domain controllers needing to be in synch with some settings that are domain wide.
The Account Policies are not the only settings that affect domain controllers in this way. There are other security settings that can only be applied to the domain root node in order to take effect on domain controllers. Again, these settings need to function like this in order for all domain controllers in the domain to have a unified and synchronized front when representing the domain. If one desktop were to go to domain controller A and get X setting and a different desktop were to go to domain controller B and get Y setting, that could cause significant and dramatic negative effects throughout the enterprise.
The settings that apply to all domain controllers through a GPO linked to the domain only, include:
- Account Policy
- Network Security: Force logoff when logon hours expire
- Accounts: Administrator account status
- Accounts: Guest account status
- Accounts: Rename Administrator account
- Accounts: Rename guest account
The Grim Reaper of Security Settings
Some questions and technologies go in cycles. Most recently there has been a lot of activity surrounding the File System and Registry settings in a Group Policy Object. These settings are located under the Computer Configuration node, as shown in Figure 2.
Figure 2: Registry and File System nodes in a GPO can control Permissions for almost any Registry Key or File
These settings in a Group Policy Object control the permissions for a Registry Key, file, or folder. The settings are very simple to configure and do the job quite nicely. However, the reason for the negative implication is that they can take a long time to apply. When a computer boots up these settings can take numerous extra cycles to apply, causing significant delays in the user getting to their desktop.
It is suggested that these settings be used sparingly. Instead of using these settings, it is best to configure these security permissions in the desktop image. Only use these policy settings when you cannot put the permissions in the original image or you have a very unique situation where there will only be a few settings being distributed via Group Policy.
Security Descriptors During Migration
Using the GPMC, you can migrate Group Policy Objects from one domain to another. This is a very useful capability and one that is often done when moving objects from a test domain to production, or even between two production domains. In almost all instances, the settings that are contained in the Group Policy Object are “neutral,” meaning that the settings are just a toggle that either turns a feature on or off. However, when it comes to security settings, not all settings are so simple. There are numerous security settings that rely on user and/or group accounts to channel where they apply. These settings require special attention when being migrated from one domain to another. The reason is that each domain has unique user and group accounts that must be translated between them. The settings that are affected include:
- User rights assignment
- Restricted groups
- Services
- File system
- Registry
- The GPO DACL, if you choose to preserve it during a copy operation
The solution to this is to use Migration Tables in the GPMC, as shown in Figure 3.
Figure 3: Translation tables allow for cross domain GPO migrations
Summary
Not all Group Policy Object settings are created equal. When it comes to security settings, this is certainly the case. Be sure to look closely and test all security settings before pushing them into production. The good thing is that security settings now apply every 16 hours, even with no changes to the policy settings. This ensures reliable and stable security on your desktops and servers. For domain controllers, be sure to be clear where settings can be and are applied, domain controllers act different than most computers. Finally, when establishing user and group accounts in settings, these must be translated from one domain to the other using Migration tables. Once you get a handle on the unique security settings, your network will be more secure and stable!
