Group Policy Primer

Posted on August 31, 2016 by Mike

I wrote the following content in the Summer of 2013, right after a two-and-half year tour on the Windows Server 2012 Beta. This was originally the introduction to a larger document for learning how Group Policy Preferences Mapped Drives and Printers worked under the covers. It probably is the best summation of the Group Policy engine. I handed the content over to the publishing team and lost track of it. This may or may not be floating around on TechNet. That said, Microsoft seems to be deprecating and moving content… it may be gone, so I decided to post it.

Group Policy is a management technology included in Windows Server that enables you to secure computer and user settings. Securing these settings ensures a common computing environment for users and lowers the total cost of ownership by restricting accidental or deliberate configurations that adversely affect the operating system.

A Group Policy object (GPO) is a logical object composed of two components, a Group Policy container and a Group Policy template. Windows stores both of these objects on domain controllers in the domain. The Group Policy container object is stored in the domain partition of Active Directory. The Group Policy template is a collection of files and folders stored on the system volume (SYSVOL) of each domain controller in the domain. Windows copies the container and template to all domain controllers in a domain. Active Directory replication copies the Group Policy container while the File Replication Service (FRS) or the Distributed File System Replication (DFSR) service copies the data on SYSVOL.

The Group Policy container and template together; make the logical object called a Group Policy object. Each Group Policy object contains two classes of configuration: user and computer. Computer configuration settings affect the computer as whole, regardless of the logged on user. User configuration settings affect the currently logged on user, and may vary with each user. Some examples of computers settings are power management, user rights, and firewall settings. Examples of user settings include Internet Explorer, display settings, and Folder Redirection.

Group Policy objects and their settings apply to computers and user to which they are linked. You can link GPOs to an Active Directory site, domain, organizational unit, or nested organizational unit. Group Policy objects separate from the containers to which they are linked. This separation enables you to link a single GPO to multiple containers. Linking GPOs to many containers enables a single GPO to apply to users or computer within multiple container. This defines the scope of the GPO. Computer configurations apply to computers within the container or nested containers. User configurations apply to users in the same fashion.

Policy settings apply to computers at computer startup and to users during user logon. Windows Server 2012 and Windows 8 includes a Group Policy service. During computer startup, the Group Policy service queries Active Directory for the list of GPOs that are within scope (linked) of the computer object. Again, this includes:

The site in which the computer resides
The domain in which the computer is a member
The parent organizational unit to which the computer is a direct member and any other organizational units above the parent OU.

The Group Policy service decides which GPOs apply to computers (there are many ways to filer GPOs from applying, which is beyond the scope of this introduction) and applies those policy settings. Client-side extensions (CSEs) are responsible for applying policy settings contained in the GPOs. A Group Policy client-side extension is a separate component from the Group Policy service that is responsible for reading specific policy setting data from the GPO and applying it to the computer or user. For example, the Group Policy registry client-side extension reads registry policy setting data from each GPO and then applies that information into the registry. The security CSE reads and applies security policy settings. The Folder Redirection CSE reads and applies Folder Redirection policy settings.

Group Policy processing repeats when the user logs on the computer. The Group Policy service decides the GPOs that apply to the user and then applies user policy settings.

It’s important that you have a firm understanding of how to create, modify, and link Group Policy objects to containers in Active Directory. Group Policy Preferences use the same concepts as Group Policy. In fact, you manage Group Policy Preferences the same way that you manage Group Policy. This is a review of Group Policy; it’s not complete. If you are unfamiliar with how to manage Group Policy or you need a thorough refresher, then you can read the Windows Group Policy Resource Kit: Windows Server 2008 and Windows Vista (Microsoft Press 2008).

Client-side Extensions

A Group Policy client-side extensions is an isolated component that is responsible for processing specific policy settings delivered by the Group Policy infrastructure. The format in which each Group Policy client-side extension saves data can be unique to each extension. And, the Group Policy infrastructure is unaware of this format, nor does it care. Group Policy’s purpose is to deliver settings to the computer where each client-side extension applies their portion of the policy settings from multiple Group Policy objects.

To help understand the relationship between the Group Policy infrastructure and the Group Policy client-side extensions– consider a postal carrier. The postal carrier collects information from various sources and delivers that information to you. The postal carrier has no idea what information they are delivering. The information could be a letter, a DVD, or a CD with photos. The postal carrier only knows they are to deliver the information to a specific address.

In this analogy, the Group Policy service is the postal carrier– it delivers the information without out any knowledge about the information. The information delivered by the postal carrier represents the different policy settings. The Group Policy client-side extension represents the person receiving the information. Addresses can have many recipients. Each recipient receives their own mail in an expected format. The Group Policy client side extension reads its respective policy setting information and performs actions based on information contains in the policy settings.

Group Policy Processing

Group Policy application is the process of deciding which Group Policy objects that Windows applies to a user or computer and then applying those settings. Understanding Group Policy processing is key to planning and deploying Group Policy settings. Misunderstanding Group Policy processing is the most common cause of unwanted and unexplainable policy settings.

The key to understanding Group Policy processing is Scope. Scope is simply a collection of all Group Policy objects that should apply to a user or computer based on their object’s location in Active Directory. You create scope by linking Group Policy objects to specific locations within Active Directory.

Group Policy provides options that can change the scope of Group Policy object. Changing the scope of Group Policy objects affects which policy settings apply and those that do not. You change the scope of Group Policy using processing order, filtering, and link options.

Scope

Group Policy processing must identity the scope to which it is applying policy settings. Scope is simply states as where the user or computer object resides within the Active Directory hierarchy. The easiest way to discover the scope of a user or computer object is to lookup the respective user or computer’s distinguished name in Active Directory. An object’s distinguished name in a directory provides the objects identity and the objects location within the directory. Consider the following distinguished name.

CN=Kim Akers,OU=Human Resources, DC=corp,DC=contoso,DC=com

From this, the Group Policy service determines the name of the user object, the organizational unit that contains the user object, and the domain in which the user object resides.

CN=Jeff Low,OU=Managers,OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com

Linking

Understanding Group Policy scope requires knowing where to link Group Policy objects so they apply to users or computer. To enable a Group Policy object to apply to a user or computer, you associate it with a specific location within Active Directory. Associating a Group Policy object with an object in Active Directory is called linking.

Active Directory has rules that govern where you can link Group Policy objects. Active Directory objects to which you can link Group Policy objects include:

Site objects
Domain objects
Organizational Unit objects

Linking Group Policy objects to these Active Directory objects is strategic in deploying Group Policy. These are container objects. Container objects, as the name implies, means they can include other objects within them– they representing hierarchical grouping of objects in a directory. Site objects can contain computer objects from multiple domains. Domain objects can contain multiple Organizational Units, computers and user objects. Organizational Unit objects can contain other Organizational Unit objects, computers, and users. Let’s look at the distinguished name again.

CN=Jeff Low,OU=Managers,OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com

Close examination of the distinguished name reveals each container object that could potentially apply Group Policy settings to the user. The CN=Jeff Low is the user object name. You cannot link Group Policy directly to a user object. However, the remaining portion of the name shows the object’s location. Working left to right, you can discover each container object that is capable of apply Group Policy to the user.

OU=Managers,OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com
OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com
OU=RandD,DC=corp,DC=contoso,DC=com
DC=corp,DC=contoso,DC=com

Each of these locations represent the scope of Group Policy. The Group Policy service collects linked Group Policy objects from each of these locations in the directory. This represents the scope of Group Policy for the user or computer.

Notice the order in which Windows collects the list of Group Policy objects? It begins with the OU closest to the user and traverses up the directory to the object furthest away from the user, which is typically the domain object. Through linking, you have a list of Group Policy objects that are in scope with the user or computer. However, not every GPO in the list should apply to the user or computer.

00-gp

Security Filtering

Group Policy scope is the list of all Group Policy objects that may be applicable to the user or computer because of their object’s location within Active Directory. Security Filtering determines if the respective user or computer has the proper permissions to apply the Group Policy object. A user or computer must have the Read and Apply Group Policy permissions for the Group Policy service to consider the Group Policy object applicable to the user.

The Group Policy services iterates through the entire list of Group Policy objects determining if the user or computer has the proper permissions to the GPO. If the user or computer has the permissions to apply the GPO, then the Group Policy service moves that GPO into a filtered list of GPOs. It continues to filter each Group Policy object based on permissions until it reaches the end of the list. The filtered list of Group Policy objects contains all GPOs within scope of the user or computer and are applicable to the user or computer based on permissions.

01-gp

WMI Filtering

WMI filtering is the final phase of determining the scope of Group Policy objects that apply to a user or computer.

Windows Management Instrumentation (WMI) is the Microsoft implementation of Web-Based Enterprise Management (WBEM). WMI uses the Common Information Model (CIM) industry standard to represent systems, applications, networks, devices, and other managed components.

Group Policy provides more filters to control the scope of applicable Group Policy objects. WMI enables you to create queries to interrogate specific features of the computer, operating system, and other managed components. In the form of queries, you create criteria that behave like logical expressions– where the result equates to true or false. You associated, or link these criteria to a Group Policy object. If the criteria evaluates to true, the Group Policy object remains applicable to the user and is kept in the filtered list. If the criteria evaluates to false, the Group Policy service removes the Group Policy object from the filtered list.

Once WMI filtering completes, the Group Policy service has a list of filter Group Policy objects. This final list represents all applicable Group Policy objects for the user or computer. Internally, Security and WMI filtering occur in one cycle.

02-gp

Processing Order

Group Policy has a specific order in which it applies Group Policy objects. Understanding the order in which Group Policy objects apply is important because Group Policy uses the order of application to resolve conflicting policy settings among different Group Policy objects linked to different locations within Active Directory.

Local, Site, Domain, and OU

The Group Policy service applies the Local Group Policy first, then Group Policy objects from the Site, followed by Group Policy objects from the domain, and Group Policy objects from organization units. If the targeted user or computer to receive Group Policy settings, then the Group Policy service applies Group Policy objects from OUs furthest in lineage from the user to closest in lineage to the user. Consider the filtered list of applicable Group Policy objects.

DC=corp,DC=contoso,DC=com OU=RandD,DC=corp,DC=contoso,DC=com

OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com

OU=Managers,OU=Research,OU=RandD,DC=corp,DC=contoso,DC=com

02-gp

Notice the order of Group Policy objects has changed from the first list. This reordering of Group Policy occurs during the Security and WMI filter processing. The Group Policy service builds the first list of GPOs by finding the user or computer object and then collecting all linked GPOs as it walks up the directory tree. The GPOs are listed backwards from the order they apply because as the Group Policy service adds the newly discovered link location to the bottom of the list. This explains why the domain location is at the bottom of the list.

However, when filtering the list for security and WMI filters, the Group Policy service starts at the top of the list, which is the OU closest in lineage to the user or computer object. The service builds a new list (the filtered list) by placing the GPOs that pass through the filter into the filtered list. The service inverts the order of the original list, making the domain location at the top of the list. The location closest to the user is at the bottom of the list —the order Group Policy applies GPOs to users and computers.

Conflict Resolution

Each Group Policy object contains the same number of potential policy settings. Therefore, it is possible to have the same policy setting defined in multiple Group Policy objects. Conflicts occurs when the same policy setting is configured in multiple Group Policy objects. Like two cars competing for the same space on the road—one wins and the other loses. Group Policy handles conflicts by using a method known as last-writer-wins. Last-writer-wins resolves conflicts by declaring the prevailing setting as the setting that Group Policy writes last. Therefore, the Group Policy object containing the conflicting policy setting that applies last is the setting that wins over all other settings.

03-gp

The Processing Order section of this document describes that Group Policy objects apply in Local, Site, Domain, and Organizational Unit order. Based on this processing hierarchy:

Policy settings in Group Policy objects linked to the Active Directory site resolve policy setting conflicts between the Local Group Policy object and Group Policy objects linked to the Active Directory site.
Policy settings in GPOs linked to the domain resolve policy setting conflicts between Group Policy objects linked to the Active Directory site and GPOs linked to the Active Directory domain.
Policy settings in GPOs linked to an organizational unit resolve policy setting conflicts between Group Policy objects linked to the Active Directory domain and GPOs linked to an organizational Unit.
Policy settings in GPOs linked to a child organizational unit resolve policy settings conflicts between Group Policy objects linked to the child organizational unit and GPOs linked to the parent organizational unit.

Conflict Resolution among GPOs linked at the same Location

Group Policy enables you to link multiple Group Policy objects at each site, domain, and organization unit locations in the directory. Until now, conflict resolution only identified resolutions between conflicting policy settings linked at two different locations in Active Directory. What about conflicting policy settings in Group Policy objects that are linked at the same location?

Group Policy continues to use the last-writer-wins method for resolving policy setting conflicts among Group Policy objects linked as the same location in Active Directory. Understanding how the Group Policy Management Console (GPMC) links Group Policy objects to locations in Active Directory explains the processing order of Group Policy objects link at the same location in Active Directory.

GPLink Attribute

The locations that support Group Policy linking, Active Directory sites, domains, and organizational units, do so because each of these objects have a GPLink attribute. The GPLink attribute is a single-valued attribute that accepts a value of a string data type. While the Active Directory Schema enforces the single-valued nature of the GPLink attribute, Group Policy uses the attribute as a multivalued attribute. The GPMC writes the value of the GPLink attribute using the following format.

[distinguishedNameOfGroupPolicyContainer;linkOPtions][…][…]

The distingushedNameOfGroupPolicyContainer token represents the distinguished name of the Group Policy Container. A Group Policy object is a single logical object composed of two components of information. The component of information stored on the file system is the Group Policy template. The remaining component, the Group Policy Container is an object in Active Directory object that lives in the domain partition of Active Directory. As previously covered, the distinguished name of a directory object provides the object’s name and location in the directory.

The linkOptions token is an integer value that defines the link options associated with the Group Policy object. Currently, you can enable or disable linked of Group Policy objects. Also, you can configure the link as enforced. The linkOptions value is a bit value where combining values varies the configurations.

Enabled  0x0
Disabled 0x1
Enforced 0x2

Disabling the link of a Group Policy objects prevents the Group Policy service from including that GPO in the list of GPOs within scope of the targeted user or computer. The distinguishedNameOfGroupPolicyContainer and the linkOptions token are enclosed in square brackets ( [ ] ) and separated by a semicolon (;). This represents a singly linked Group Policy object. Linking another Group Policy object to the location inserts a new distingushedNameOfGroupPolicyContainer and linkOptions combination before the existing combination; it does not add the new combination to the end. The linking pattern continues to insert newly linked GPOs at the beginning of the value; by moving existing values to the right.

The Group Policy service reads this long string as a list of values from left to right. The first GPO link entry in the value is the first to apply at this location. The next entry in the value applies afterwards. The process continues until the last GPO in the value applies.

Group Policy inherently assigns each GPO precedence based on the order it reads the list—left to right. Therefore, the first GPO in the value has the lowest precedence in the list of linked Group Policy objects. The next GPO in the value has a higher precedence than the previous GPO because it applies its policy settings after the previous GPO; by winning any policy setting conflicts between the two GPOs. Each GPO that follows has a higher precedence than the Group Policy object before it in the link order. The last GPO in the value has the highest precedence because it is the last Group Policy object the Group Policy service applies.

The best way to understand this is to think of the long string as a list of GPOs. Take the first GPO (the left most GPO) in the value and place it the list. Take the next links GPO listed and place on top of the list (causing all others to move down in the list by one). Continue this process until the last GPO is on top of the list. This final GPO linked entries list is in precedence order, which means the list is processed from the bottom to the top.

05-gp

When viewed in a list in precedence order, it’s easy to discover that GPOs higher in the list have more precedence than GPOs lower in the list. As a result, GPOs lower in the list lose policy setting conflicts and GPOs higher in the list win policy setting conflicts.

Link Options

As previously stated, a Group Policy linked as options of enabled, disabled, and enforced. The enabled and disabled options are intuitive to understand. When an enabled link is considered in the scope of Group Policy for the targeted user or computer. A disabled linked behaves as if the Group Policy object was never linked.

Enforced

The Enforced link option is the exception to all rules. The Enforced option ensures the settings from the linked GPO always win conflicts regardless of any other Group Policy object that contains policy settings that may conflict with those of the linked GPO. The GPMC visually represents an enforced Group Policy link by adding a padlock to the existing linked policy icon. Group Policy settings from an enforced link always apply, even if the organizational unit has block policy inheritance enabled

Block Policy Inheritance

The last item about Group Policy processing order is Block Policy Inheritance, or simply known as Block Inheritance in the Group Policy Management Console. Each domain and organizational unit in Active Directory object contains a GPOptions attribute. This setting enables you to block Group Policy settings linked higher in the processing order from applying to users and computers that are typically in containers lower in the processing order.

For example, policy settings linked to the domain apply to computers and users within the entire domain, regardless of their parent organizational unit. However, you can use GPMC to block inheritance on the domain or an organizational unit to prevent normal Group Policy setting from applying to users and computers within that container. Blocking policy inheritance on the domain prevents Group Policy settings from GPOs linked to the Active Directory site from applying to the domain. Blocking policy inheritance on organizational units prevents normal Group Policy settings from GPOs linked to sites and domains from applying to the organizational units.

Block policy inheritance does not prevent Group Policy settings from enforced linked Group Policy objects from applying to users and computers. Group Policy settings from enforced links apply regardless of the block policy inheritance status on domain and organizational unit objects.

That wraps up the basics of how the Group Policy engine processes information.

–Mike Stephens

Group Policy Script Processing Behavior

Posted on March 23, 2010 by Mike

Today I am discussing the default processing behavior for Group Policy scripts. Microsoft changed the default behavior of Group Policy startup and logon scripts processing from synchronous to asynchronous starting with Windows Vista and Windows Server 2008. This behavior is the same in Windows 7 and Windows Server 2008 R2. I’ve recently read some confusion regarding this policy setting.

Computer Startup Scripts:

The default processing behavior for computer startup scripts is asynchronous. Asynchronous scripts processing is when computer startup scripts no longer wait for the previous script to complete before starting the next startup script. Versions of Windows prior to Windows Vista defaulted to synchronous processing. This behavior can be changed by reading from the following locations, in the following order.

Computer Preference

Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon 
ValueName: RunStartupScriptSync

Computer Policy

Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystem 
ValueName: RunStartupScriptSync

User Logon Scripts:

The default processing behavior for Group Policy logon scripts is asynchronous. However, this behavior can be changed by reading from the following locations, in order.

User Preference

Key: HKEY_CURRENT_USERSoftwareMicrosoftWindows NTCurrentVersionWinlogon 
ValueName: RunLogonScriptSync

Computer Preferences

Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindows NTCurrentVersionWinlogon 
ValueName: RunLogonScriptSync

User Policy

Key: HKEY_CURRENT_USERSoftwareMicrosoftWindowsCurrentVersionPoliciesSystem 
ValueName: RunLogonScriptSync

Computer Policy

Key: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionPoliciesSystem 
ValueName: RunLogonScriptSync

User Logoff/Computer Shutdown:

User Logoff and Computer Shutdown Group Policy Scripts always process synchronously.

Customers are noticing timing issues with their computer startup scripts when using Windows 7 and Windows Server 2008 R2. Yes, this is true because the default behavior changed to run these scripts asynchronously. If you relied on the previous behavior, then you need to configure computer startup scripts to run synchronously. Unfortunately, this is where some confusion surfaces.

You’ll soon notice that Windows does not include a policy setting to enable computer startup scripts to run synchronously, or does it? Yes, it does; however, not so intuitive. I’ve had some GP administrators break out the nice search feature in the Group Policy Management Editor and search for the keyword synchronous—this is not going to return the information you are seeking. The policy setting to enable this does not include the word synchronous in the explain text or in any other portion of the policy. You need to configure the Run startup scripts asynchronously policy setting to disabled to force computer startup scripts to process synchronously, which is the default behavior prior to Windows 7 and Windows Vista.

Hopefully, this will clear up any confusion with how Windows 7 process computer startup scripts and explain how to restore the older behavior.

– Mike Stephens

Background uploading of User Registry Settings

Posted on March 22, 2010 by Mike

This post discusses an interesting feature I learned about in Windows 7. Many Microsoft customers deploy Roaming User Profiles. In fact, many combine Roaming User profiles and Folder Redirection to get the best experience possible. However, one of the drawbacks with Roaming User profiles is the user must logoff before their settings are uploaded to the server. Folder redirection solves this problem for any of the known folders within the user profile namespace, such as Documents, Music, or Downloads—the data is highly available without requiring a user logoff. Now, if this could only occur with user’s registry settings.

Windows 7 solves this problem by allowing the User Profile service to upload the user’s registry settings of a Roaming User profile while the user remains logged on to the computer, or terminal services session (provided the session is hosted on Windows Server 2008 R2).

You enabled this feature using Group Policy. The policy setting Background upload of a roaming user profile’s registry file while user is logged on, is located under Computer Configuration\Policies\Administrative Templates\System\User Profiles. The policy setting offers two configuration settings: scheduled or interval. The scheduled method allows you to configure a time of day (represented on 24 hour time) at which to upload the user’s registry settings. The interval method allow you to choose a specific interval (represented in hours) at which to upload the user’s registry settings. This method accepts an interval range between 1 and 720 inclusively. Both settings include a random delay that does not exceed one hour.

00-bgProfileUpload Background uploading only occurs with Roaming User profile. Also, background uploading does not alter uploading the entire profile when the user logs off. It is important to remember that background uploading only uploads the user’s registry settings (ntuser.dat).

Now those subtle changes made in the registry can be uploaded to the server while the user remains logged on. Pretty cool.

–Mike Stephens

Control Extended Protection for Authentication using Security Policy

Posted on December 10, 2009 by Mike

Microsoft has introduced additional security measures for authentication known as Extended Protection for Authentication, also known as channel binding token (CBT). Extended protection can cause a variety of interoperability issues including but not limited to:

Windows clients that support channel binding fail to be authenticated by a non-Windows Kerberos server
NTLM authentication failures from Proxy servers
NTLM authentication failures from non-Windows NTLM servers
NTLM authentication failures when there is a time difference between the client and DC or workgroup server

Note: Read more about Extended Protection for Authentication in Microsoft Knowledge base article 968389 and MSDN.

Administrators may want to control the state of Extended Protection to multiple client computers. This can be accomplished using security policy. Security policy is the most appropriate solution to distribute the registry setting that controls Extended Protection for Authentication because the setting is stored under the LSA key in HKEY_LOCAL_MACHINE. Also, distributing the setting using security policy increases the chance of the desired settings winning all conflicts because, by default, security settings always apply during Group Policy Processing. Once the policy is applied, any user or application that changes the registry location will be reverted back to the desired configuration during the next application of security policy.

Add the policy setting to Security Policy settings

The Extended Protection for Authentication policy setting must be added to Security Policy editor to include the policy setting in Group Policy. To accomplish this:

==== Start copy after this line ====

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\SeCEdit\Reg Values\MACHINE/System/CurrentControlSet/Control/Lsa/SuppressExtendedProtection] 
“ValueType”=dword:00000004 
“DisplayType”=dword:00000003 
“DisplayName”=”Network Security: Extended Protection for Authentication” 
“DisplayChoices”=hex(7):30,00,7c,00,45,00,6e,00,61,00,62,00,6c,00,65,00,64,00,\ 
  00,00,33,00,7c,00,44,00,69,00,73,00,61,00,62,00,6c,00,65,00,64,00,00,00,00,\ 
  00

==== Stop copy before this line ====

Copy the above text.
Open Notepad and paste the text from step one into Notepad.
Click File and then Click Save As.
In the File name box, type secpoladd.reg.
In the Save as type list, click All Files. Remember the path to which the file is saved.
Click Save and close Notepad.
Locate the saved file from the path in step
Double-click the secpoladd.reg file. Click Yes to the Registry Editor dialog box.

It is only required to modify the security editor on the computer used to manage Group Policy. This allows the Extended Protection for Authentication policy setting to be included in a Group Policy object. Extending this security setting to other computers is not required for client computers to receive the security setting.

Include the Extended Protection for Authentication policy setting in Group Policy

00extendedProtection

With the security editor extended, you can now include the security setting within a Group Policy object. To do this:

Using GPMC, edit the Group Policy object that is to contain the security setting.
Navigate to Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options.
In the right pane of the MMC, scroll through the list of security settings to locate Network Security: Extended Protection for Authentication. Double-click the security setting.
Select Define this policy setting. Choose the desired configuration from the list and click OK.
Close the Group Policy object.
The Group Policy object now contains the security policy setting. Use GPMC to deploy the GPO to clients as needed.

Conclusion

Improving security always poses a risk with application compatibility. The long term solution is to determine why applications no longer work when security in heightened. A short-term solution during the investigation may be to reduce security to allow the application to work, pending the results of the investigation. Controlling this using Group Policy helps manage the setting for the enterprise.

— Mike Stephens

Windows 7, Windows Server 2008 R2 and the Group Policy Central Store

Posted on December 9, 2009 by Mike

Today, I want to bring clarity to something we are seeing with Windows Server 2008 R2 and existing Group Policy central store. Before that discussion, let us cover some background information.

ADMX Files and the Group Policy Central Store

Microsoft introduced the ADMX file format with Windows Vista and Windows Server 2008. This XML-based file format replaced the token-based ADM file format used by earlier versions of Windows to define administrative templates. Group Policy uses administrative templates to represent registry-based policy settings that appear when editing Group Policy. The content included in administrative templates describes the user interface used by Group Policy editors and registry locations where Windows stores policy settings. Windows Server 2008 R2 and Windows 7 provide a new set of administrative template files in the ADMX format.

Windows 7 ADMX files now include support for two registry types: REG_MULTI_SZ and REG_QWORD. The REG_MULTI_SZ registry data type represents multi strings entries within a single registry value. The REG_QWORD registry data type represents a 64-bit number, which is twice the size of the 32-bit number stored in REG_DWORD. These new aspects of the ADMX syntax are only viewable when using the GPMC and Group Policy editors from Windows Server 2008 R2 or Windows 7 Remote Server Administration Tools (RSAT). Group Policy editors and the GPMC from Windows Vista cannot read ADMX files containing this new syntax.

The Central Store

Earlier versions of Group Policy that used ADM files suffered from a symptom known as SYSVOL bloat. These versions of Windows copied the set of ADM files into each Group Policy object stored on SYSVOL. Each set of ADM files required approximately 4MB of disk space. A domain can realistically have 100 Group Policy objects. One hundred Group Policy objects multiplied by 4 megabytes of disk space equates to 400MB of redundant data—what a waste. Windows Server 2008 and Vista introduced the concept of the Group Policy Central Store to overcome SYSVOL bloat. The Group Policy Central Store is a single folder on each domain controllers SYSVOL that stores one set of ADMX files for the entire domain. The central store effectively relieves the symptoms of SYSVOL bloat and reduces the amount of data transferred during SYSVOL replication when new Group Policy objects are created. Some documentation refers to the Group Policy Central Store as an alternate location to store ADMX files (the other location is the local store found in %SYSTEMROOT%\PolicyDefinitions). A more accurate description of the Central Store is the preferred location.

So what’s the Problem?

The Group Policy Management Console and the Group Policy Management Editor always use the Group Policy Central store, when it is present. The pro here is that all instances of the GPMC and GPME use the same set of ADMX files. The con is that servicing ADMX files is difficult. Also, GPMC cannot use the local store as long as a Group Policy Central Store exists. So adding a single ADMX set for a single computer is not possible when using a central store. So, when we released Windows 7 and Windows Server 2008 R2, we also released a new set of ADMX files (within the operating system). These new ADMX files expose new Windows 7 and Windows 2008 R2 policy settings as well as policy settings for previous operating systems. Therefore, you need these files to configure Windows 7 Group Policies. Here’s where the dilemma continues.

A Central Store and Windows 7

If you have a central store (presumably hosted with Windows Server 2008 ADMX files), then you have two choices: upgrade the ADMX files or remove the central store.

Updating the Central Store

Updating the Central Store affects all users in the domain that use GPMC and its editor. It is important to understand this because newer ADMX files may not be compatible with older versions of Group Policy Tools, as in the case with Windows Server 2008 R2. The screen capture below occurs in Windows Vista and Windows Server 2008 computers attempting to read a Group Policy Central store hosted with Windows Server 2008 R2 ADMX files.

00gpCentralStore

Windows Server 2008 R2 ADMX file, in this example the TerminalServer-Server.adml, contains an unknown element named <multiTextBox>. This element represents the REG_MULTI_SZ implementation that is new with Windows 7 and Windows Server 2008 R2. Newer ADMX files can contain new features, which older Group Policy Tools may not understand. This is why it is always a best practice to use the latest Group Policy Tools to manage Group Policy. Backwards compatibility is an important aspect of Group Policy; however, forward compatibility is not.

Also, you may be using Windows 7, but do not see Windows 7 policy settings. Remember, GPMC prefers the Group Policy Central Store over the local store. The Windows 7 GPMC (actually RSAT) uses the Group Policy Central Store (hosted with Windows Vista or Windows Server 2008 ADMX files) over its local store that hosts the Windows 7 ADMX. If you want to see Windows 7 policy settings, then you’ll need to upgrade your central store or remove it.

NOTE:
I have successfully used Windows Vista RSAT with an upgraded Group Policy Central Store. However, the ADMX and ADML files were from a Windows 7 computer. Using Windows Server 2008 R2 ADMX files produces the error in the preceding image using GPMC from Windows Server 2008 or Windows Vista RSAT.

01gpCentralStore

Removing the Group Policy Central Store

Removing the Central Store targets all Group Policy tools to use their local store for ADMX file. This allows Windows 7 RSAT and Windows Server 2008 R2 computer to use their ADMX files. Windows Vista RSAT and Windows Server 2008 use their local ADMX files. Windows Vista computers cannot manage or report on Windows 7 policy settings.

An Alternative to the Central Store

There is way for us to “have our cake and eat it too”. The answer is Terminal Services. I often suggest to customers that have many people managing Group Policy to setup a GPMC Terminal Server. Dedicating a single server as the means to manage Group Policy provides:

The concept of a central store
A single point of Group Policy management
Easy to audit and maintain

A dedicate Group Policy Terminal Server can provide the look and feel of a Group Policy Central Store without implementing a Central Store. ADMX files are located in one location, the terminal server. GPMC does not load the ADMX files from a network location. Domain controllers do not need to replicate the additional content of a Central Store—all the benefits of a Central Store, without creating one.

Group Policy is a critical part of the enterprise and yet it seems little is done to reduce its exposure. A dedicated Terminal Server running GPMC provide a true single point of management for the entire Group Policy experience. Terminal Services security can be implemented to reduce the number of people having access to GPMC. Auditing interactive logons can further assist with identifying changes made to Group Policy. Combine this with using Group Policy to prevent other computers from opening GPMC and you’ve effectively lowered the surface and exposure to Group Policy to only the people that actually need it.

Hopefully, this helps with understanding the pros and cons of using a Group Policy Central Store. Also, it should help with answer some of the common questions that arise regarding updating the central store or managing the latest Group Policy settings with Windows 7. And lastly, perhaps consolidating Group Policy Management to a Terminal Server will help limit access to Group Policy management to only the people that actually need it.

— Mike Stephens

Group Policy Slow Link Detection using Windows Vista and later

Posted on October 23, 2009 by Mike

Many Group Policy features rely on a well connected network for their success. However, not every connection is perfect or ideal; some connections are slow. The Group Policy infrastructure has always provided functionality to detect slow links. However, the means by which Group Policy determines this are different between operating systems prior to Windows Server 2008 and Windows Vista.

Before Windows Server 2008 and Vista

Windows Server 2003, Windows XP, and Windows 2000 Group Policy uses the ICMP protocol to determine a slow link between the Group Policy client and the domain controller. This process is documented in Microsoft Knowledgebase article 227260: How a slow link is detected for processing user profiles and Group Policy (http://support.microsoft.com/default.aspx?scid=kb;EN-US;227260).

The Group Policy infrastructure performs a series of paired ICMP pings from the Group Policy client to the domain controller. The first ping contains a zero byte payload while the second ping contains a payload size of 2048 bytes. The results from both pings are computed and voila, we have the bandwidth estimation. However, using ICMP has some limitations.

Many “not-so-nice” applications use ICMP maliciously. This new found use increased ICMP’s popularity forced IT professional to take precautions. These precautions included blocking ICMP. The solution to block ICMP provided relief from the susceptibility of malicious ICMP packets, but broke Group Policy. Workarounds were created (Microsoft Knowledgebase article 816045 Group Policies may not apply because of network ICMP policies); But the update did not remove the ICMP dependency.

The Windows Server 2008 and Vista era

Windows 7 and Windows Vista to the rescue! These new operating systems implement a new slow link detection mechanism that DOES NOT use ICMP– but we already knew this. The question we will answer is how does the new Group Policy slow link detection work?

The easy answer to how the new slow link detection works is Network Location Awareness (NLA). This networking layer service and programming interface allows applications, like Group Policy, to solicit networking information from the network adapters in a computer, rather than implementing their own methods and algorithms. NLA accomplishes this by monitoring the existing traffic of a specific network interface. This provided two important benefits: 1) it does not require any additional network traffic to accomplish its bandwidth estimate– no network overhead, and 2) it does not use ICMP.

Group Policy using NLA

The question commonly asked is how does Group Policy slow link detection implement NLA. The actual algorithms used by NLA are not as important as what Group Policy does during its request to NLA for bandwidth estimation.

Locate a domain controller

A Group Policy client requires communication with a domain controller to successfully apply Group Policy. The Group Policy service must discover a domain controller. The service accomplishes this by using the DCLocator service. Windows clients typically have already discovered a domain controller prior to Group Policy application. DCLocator caches this information makes it available to other applications and services. The Group Policy service makes three attempts to contact a domain controller, with the first attempt using the domain controller information stored in the cache. The latter two attempts force DCLocator to rediscover domain controller information. Retrieving cached domain controller information does not traverse the network, but forceful rediscovery does. Domain controller information includes the IP address of the domain controller. The Group Policy service uses the IP address of the domain controller (received from DCLocator) to begin bandwidth estimation.

During bandwidth estimation

The Group Policy service begins bandwidth estimation after it successfully locates a domain controller. Domain controller location includes the IP address of the domain controller. The Group Policy service performs the following actions during bandwidth estimation.

NOTE:
All actions listed in this section generate network traffic from the client to the domain controller unless otherwise noted. I’ve included a few actions that do not generate network traffic because their results could be accomplished using methods that generate network traffic. These actions are added for clarity.

Authentication

The first action performed during bandwidth estimation is an authenticated LDAP connect and bind to the domain controller returned during the DCLocator process. This connection to the domain controller is done under the user’s security context and uses Kerberos for authentication. This connection does not support using NTLM. Therefore, this authentication sequence must succeed using Kerberos for Group Policy to continue to process. Once successful, the Group Policy service closes the LDAP connection.

NOTE:
The user’s security context is relative to the type of Group Policy processing. The security context for computer Group Policy processing is the computer. The security context for the user is the current user for the current session.

The Group Policy service makes an authenticated LDAP connection as the computer when user policy processing is configured in loopback-replace mode.

Determine network name

The Group Policy services then determines the network name. The service accomplishes this by using IPHelper APIs to determine the best network interface in which to communicate with the IP address of the domain controller. The action also uses Winsock APIs; however, this action does not create any network traffic. Additionally, the domain controller and network name are saved in the client computer’s registry for future use.

HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionGroup PolicyHistory is where the service stores these values. The value names are DCName and NetworkName.

NOTE:
The NetworkName registry value is used by the Windows firewall to determine if it should load the domain firewall profile.

Site query

Group Policy processing must know the site to which the computer belongs. To accomplish this, the Group Policy service uses the Netlogon service. Client site discovery is an RPC call from the client computer to a domain controller. The client netlogon service internally caches the computer’s site name. The time-to-live (TTL) for the site name cache is five minutes. However, TTL expiry is on demand. This means the client only checks the TTL during client discovery. This check is implemented by Netlogon (not the Group Policy service). If the cached name is older than five minutes from when the name was last retrieved from the domain controller, then the Netlogon service makes an RPC call to the domain controller to discover the computer site. This explains why you may not see the RPC call during Group Policy processing. However, the opportunity for network traffic exists.

Determine scope of management

The following Group Policy actions vary based on Group Policy processing mode. Computer Group Policy processing only uses normal Group Policy processing. However, user Group Policy processing can use normal, loopback-merge, and loopback-replace modes.

Normal mode

Normal Group Policy processing is the most common Group Policy processing actions. Conceptually these work the same regardless of user or computer. The most significant difference is the distinguished name used by the Group Policy service.

Building the OU and domain list

The Group Policy service uses the distinguished name of the computer or user to determine the list of OUs and the domain it must search for group policy objects. The Group Policy service builds this list by analyzing the distinguished name from left to right. The service scans the name looking for each instance of OU= in the name. The service then copies the distinguished name to a list, which it uses later. The Group Policy service continues to scan the distinguished name until for OUs until it encounters the first instance of DC=. At this point, the Group Policy service has found the domain name, which completes the list. This action does not generate any network traffic.

Example: Here is the list from a given distinguished name

Distinguished Name:
cn=user,OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
List:
OU=marketing,OU=hq,DC=na,DC=contoso,DC=com
OU=hq,DC=na,DC=contoso,DC=com
DC=na,DC=contoso,DC=com

Evaluate scope of management

The Group Policy service uses the list OUs to determine the Group Policy objects linked to each scope of management and the options associated with each link. The service determines linked Group Policy objects by using a single LDAP query to the domain controller discovered earlier.

LDAP requests have four main components: base, scope, filter, and attributes. The base is used to specify the location within the directory the search should begin, which is usually represented as a distinguished name. The scope determines how far the search should traverse into the directory; starting from the base. The options include base, one-level, and subtree. The base scope option limits the search to only return objects matching the filter that matches the base. The onelevel option return objects from one level below the base, but not including the base. The subtree option returns objects from the base and all levels below the base. The filter provides a way to control what objects the search should return (see MSDN for more information on LDAP search filter syntax). The attribute setting is a list of attributes the search should return for the objects discovered that match the filter.

The service builds the LDAP request with the following arguments:

BaseDN: domain
Scope: Sub Tree
Filter: (|(distinguishedname=OU=xxx)( more OUs)(ends domainNC DC=))
Attributes: gpLink, gpOptions, ntSecurityDescriptor

Example: Scope of management LDAP search
BaseDN: DC=na,DC=contoso,DC=com
Scope: SubTree
Filter: (|(distinguishedname= OU=marketing,OU=hq,DC=na,DC=contoso,DC=com)
(distinguishedname =OU=hq,DC=na,DC=contoso,DC=com)
(distinguishedname =DC=na,DC=contoso,DC=com))
Attributes:gPlink,gPoptions,nTSecurityDescriptor

Determining the scope of normal Group Policy processing mode occurs in the security context of the applying security principal. The computer performs the LDAP query computer processing and the user performs the LDAP query for user processing. Merge and Replace are user-only processing modes, which occur under the security context of the user.

Replace user-processing performs an LDAP query using the computer’s distinguished name. Each component of the distinguished name is inserted into the filter portion of the LDAP query. The LDAP query filter parameter ends with the distinguished name of the domain (which is assembled using the parts of the computer’s distinguished name.

Merge user-processing performs two LDAP queries. The first LDAP query uses the distinguished name of the user object. The second query uses the distinguished name of the computer object. The Group Policy links returned from both queries are merged into one list. The Group Policy service merges these lists together by adding the Group Policy links returned from the computer query to the end of the list of Group Policy links returned from the user query. Concatenating the computer list to the end of the user list results with the Group Policy links listed in the order they apply.

Determine the Link Status:

The Group Policy service is ready to determine the status of the link between the client computer and the domain controller. The service asks NLA to report the estimated bandwidth it measured while earlier Group Policy actions occurred. The Group Policy service compares the value returned by NLA to the GroupPolicyMinTransferRate named value stored in HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsNTCurrentVersionWinlogon, which is the preference key or, HKEY_LOCAL_MACHINESoftwarePoliciesMicrosoftWindowsSystem, which is the policy key. The default minimum transfer rate to measure Group Policy slow link is 500 (Kbps). The link between the domain controller and the client is slow if the estimated bandwidth returned by NLA is lower than the value stored in the registry. The policy value has precedence over the preference value if both values appear in the registry. After successfully determining the link state (fast or slow—no errors), then the Group Policy service writes the slow link status into the Group Policy history, which is stored in the registry. The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionGroup PolicyHistory. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equaling false and a zero value equaling true. If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status.

Conclusion

Group Policy slow link detection has matured since the days of using ICMP for slow link detection. Today, Windows 7 and Windows Vista’s Group Policy services use NLA to sample TCP communication between the client and the domain controller, without sending additional network traffic.

– Mike Stephens

What occurs when the Security Group Policy CSE encounters a null DACL

Posted on June 2, 2009 by Mike

The Group Policy security client side extension can distribute security descriptors on files and registry keys. This extension is difficult to troubleshoot because it is considerably durable when it comes to failures. In most situations, it completes processing, but not without leaving behind the ever popular SCECLI 1202 event.

Event Type: Warning
Event Source: SceCli
Event Category: None
Event ID: 1202
Date: 21/09/1999
Time: 18:15:14
User: N/A
Computer: MachineName
Description:
Security policies are propagated with warning. 0x4b8 : An extended error occurred. Please look for more details in TroubleShooting section in Security Help.

You can start your troubleshooting by following Microsoft Knowledge base article 324383 Troubleshooting SCECLI 1202 Events. Unfortunately, the return code 0x4b8 is ambiguous because it serves as generic alert of a nondeterministic problem– it means something happened; but what happened was not catastrophic. Therefore, the security extension keeps processing,

NOTE: The knowledge base article uses the command secedit /refreshpolicy machine_policy /enforce. For Windows XP and later use the command gpupdate /force.

Security extension processing has many facets. Using the previously mentioned knowledge base article should help you understand the general area within security processing that is failing. However, it’s not enough evidence to confirm Professor Plum, did it in the library with the candlestick. But you should be able to determine the misbehaving portion of security processing from the winlogon.log. Scan the log file for the Configure File Security… section. It may look like:

—-Configure File Security…
Configure c:\.
File Security configuration was completed with one or more errors.

If you suspect your file system security settings as the culprit, then you may want to use Process Monitor to help further determine where in the failure occurs. It’s difficult to provide prescriptive guidance when there are many reasons for the resulting error. However, one scenario where we see this problem is in the case of a nested file or folder containing a null discretionary access control list (DACL).

NOTE: You can read more about the differences between null and empty discretionary access control list by reading the Null and Empty DACLs ASKDS blog post.

The scenario we encounter usually involves using the security policy extension to assign file permissions to a particular folder. Files and folders residing beneath the targeted folder inherit the permissions that are assigned to the targeted folder, unless that file or folder specifically blocks inheritance. If one of the underlying files or folders beneath the targeted folder contains a null DACL, then the security extension halts processing the remainder of file system security. Furthermore, an entry appears in the winlogon.log stating the configuration completed with one or more errors and, an event with the event ID 1202 appears is recorded to the event log. The return code reported in the event log is 0x4b8. Lastly, the winlogon.log file does not contain information on the file or folder responsible for stopping the process. The parent folder is the only item listed in the log. This means that one or more files or folder beneath the folder listed in the log file is responsible for halting security processing. The problem now is how to identify those files or folders. But, let’s explain why security processing halts.

Why a null DACL halts file security Group Policy processing

I previously mentioned that permissions we assign to folders through security policy processing propagate to all files and folders hosted within the targeted folder. Propagating security is known as inheritance, where a file or folder beneath a folder receives subset of the permissions from the containing folder. Windows must calculate the subset of permissions to apply to files and folders beneath the targeted folder. Windows derives these permissions by combining permission from the targeted folder and the file or folder beneath the targeted folder. Permission from the targeted folder are known as inherited permissions. Permissions on the file or folder residing in the targeted folder are explicit permissions. The problem with security processing occurs when the file or folder residing in the targeted folder contains a null DACL. Explicitly, this file or folder does not have any permissions. So Windows cannot determine how to propagate inherited permissions to the object because the object itself does not actually have permissions ( see ASKDS blog post Null and Empty DACLs).

More on inheritance

The security extension must compute inheritance. Computing inheritance, is essentially asking the security extension to figure out how to add permissions from the parent object to the a child object that does not have room to store permissions. This would require the security extension to make arbitrary decision on intent. Is the null DACL on purpose? When does the extension observe the null DACL and when does it not? These are a few reasons why the security extension halts permission processing when it attempts to propagate inherited permissions after encountering a null DACL; it is not clear what the resulting permissions should be. Therefore, the security extension halts file security processing and moves forward with the next phase of Group Policy security processing. The recorded event is a warning, not an error. It is a warning because Group Policy security processing processed as a whole– meaning none of the events that occur were catastrophic to the entire processing phase. However, one or more subcomponents did experience errors.

What to do

Detecting a null DACL is challenging. The Windows ACL editor interpret a null DACL for you; so your unaware if the DACL is null, or Everyone has Full Control. Windows includes CACLS.EXE, which reports if permissions are not set. This is an effective way to determine a null DACL exists but, you must have an idea of the file or folder containing the null DACL.

00commandPrompt

Identifying the a nested file or folder with a null DACL within a deep folder structure is difficult. Manually investigating these files or folders is not practical. Fortunately, ADSI provides a security descriptor interface we can use through scripting to recursively search folders, sub-folders, and files that may have a null DACL. Below is a sample script that can be copied and pasted into a text document.

‘========================================================================== 
‘ 
‘ VBScript Source File 
‘ 
‘ NAME: CheckNullDacl.vbs 
‘ 
‘ AUTHOR: Mike Stephens , Microsoft Corporation 
‘ DATE  : 7/15/2003 
‘ 
‘ COMMENT: 
‘ 
‘========================================================================== 
‘  Microsoft provides programming examples for illustration only, without warranty either expressed or 
‘  implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a 
‘  particular purpose.  This sample assumes that you are familiar with the programming language being 
‘  demonstrated and the tools used to create and debug procedures. Microsoft support professionals 
‘  can help explain the functionality of a particular procedure, but they will not modify these examples 
‘  to provide added functionality or construct procedures to meet your specific needs. 
‘ =============================================================================

Option Explicit 
Const ADS_PATH_FILE     = 1 
Const ADS_SD_FORMAT_IID = 1 
Const SE_DACL_PRESENT = &h4 
Const Dbg = False 


Dim oArgs : Set oArgs = WScript.Arguments

If Not (oArgs.Count >= 1) Then  
        WScript.Quit(0) 
End If

WScript.Echo VbCrLf & “Recursivly searching “ & oArgs.Unnamed(0) & ” for NULL DACLs…” & vbCr

SearchSDsInFolder oArgs.Unnamed(0)

WScript.Echo VbCrLf & “-=[Complete]=-“ & VbCrLf

WScript.Quit(0)

Sub IsNullDacl(fileArg, bFolder) 
        Dim fso : Set fso = CreateObject(“Scripting.FileSystemObject”) 
        Dim sdUtil  : Set sdUtil = CreateObject(“ADsSecurityUtility”) 
        Dim sd :  Set sd = CreateObject(“SecurityDescriptor”) 
        Dim dacl        

        Dim sdControl, sdObject, DaclAceCount

        If(bFolder) = False Then  
                If(fso.FileExists(fileArg)) = False Then 
                        Exit Sub 
                Else 
                        Set sdObject = fso.GetFile(fileArg) 
                End If 
        Else 
                If(fso.FolderExists(fileArg)) = False Then 
                        Exit Sub 
                Else 
                        Set sdObject = fso.GetFolder(fileArg) 
                End If 
        End If 

        Set sd = sdUtil.GetSecurityDescriptor( sdObject.Path, ADS_PATH_FILE, ADS_SD_FORMAT_IID)       

        ‘  Get the SD Control 
        sdControl = sd.Control               

        ‘  Get the SD DACL  
        Set dacl = sd.DiscretionaryAcl 
        On Error Resume Next 
                DaclAceCount = dacl.AceCount 
                If Err.Number = 424 Then  
                        DaclAceCount = –1 
                        Err.Clear  
                End If  
        On Error GoTo 0

        If(sdControl And SE_DACL_PRESENT  SE_DACL_PRESENT) Then  
                WScript.Echo “- Null DACL detected on “ & cStr(sdObject.Path) & “.” 
                Exit Sub 
        ElseIf(DaclAceCount = -1) Then 
                WScript.Echo “- Null DACL detected on “ & cStr(sdObject.Path) & “.” 
                Exit Sub 
        Else 
                DebugPrint “Processed “ & cStr(sdObject.Path) 
        End If 
End Sub

Sub SearchSDsInFolder( folderArg) 
        Dim fso : Set fso = CreateObject(“Scripting.FileSystemObject”) 
        Dim flder, folder, folderCollection 
        Dim file, fileCollection

        Set flder = fso.GetFolder(folderArg)

        If(flder.SubFolders.Count > 0) Then  
                Set folderCollection = flder.SubFolders   
                For Each folder In folderCollection 
                        SearchSDsInFolder(folder) 
                Next 
        End If

        IsNullDacl flder.Path, true

        Set fileCollection = flder.Files 
        For Each file In fileCollection 
                Dim f : Set f = fso.GetFile(file) 
                IsNullDacl file.Path, False 
        Next
End Sub

Sub DebugPrint( text) 
        If( Dbg = True) Then  
                WScript.Echo text & vbCr 
        End If 
End Sub

Use cscript.exe to start the script. Provide a single argument when starting the script. This argument is the folder at which the search for null DACLs begins. The search is recursive; therefore, it searches all nested folders and files. Files or folders identified as having a null DACL are printed to the screen.

— Mike Stephens

AGPM Least Privilege Scenario

Posted on December 16, 2008 by Mike

A customer recently asked how they should configure their Advanced Group Policy Management (AGPM) server using the least amount of privileges. AGPM Program Manager, Michael Kleef, posted a quick task list on his TechNet blog(http://blogs.technet.com/mkleef/archive/2008/11/18/locking-down-agpm-fit-for-least-privilege.aspx) , but I thought I’d take the opportunity to go into more detail and provided some additional suggestions.

AGPM adds role-based administration, change control, workflow, and granular delegation to Group Policy Management. These features allow you to use AGPM to delegate Group Policy creation, review and deployment to non-administrative users. You can read more information about AGPM by downloading the Advance Group Policy Management Overview whitepaper (http://go.microsoft.com/fwlink/?LinkId=106067).

Least privilege requirements

AGPM least privilege configurations can vary slightly. The variance largely depends on how little of privileges you want to provide to the AGPM Server (actually the service account running the AGPM Service). Regardless, you need to achieve the following four requirements for the AGPM Service to work properly:

The AGPM Service account requires full access to the AGPM archive folder
The AGPM Service account requires full access to the local computer’s temp folder
(%systemroot%\temp)
Full access to GPOs created prior to using AGPM
The AGPM Service account must be a member of the Group Policy Creator Owners and Backup Operators Group

The AGPM Service account

There are two options when choosing the AGPM Service account: Local System or an actual domain user account used to run the service. Least privilege scenarios cannot use the Local System account. The AGPM service can only use the Local System account when the service is running on a domain controller. Yes, the AGPM service can run on a domain controller; however, it’s highly advisable not to install it on a domain controllers. Domain controllers have a specific purpose in the infrastructure just as Exchange or SQL servers– domain controllers authenticate users. The last thing you’ll want to do is restore a domain controller because your AGPM Server had a problem. I typically suggest naming the service account something intuitive– like AGPMService.

Archive folder

The AGPM Service requires Full Control of the archive folder. The archive folder is where the AGPM Server keeps a manifest and backups of controlled GPOs. The default archive for AGPM version 3.0 is %ProgramData%\Microsoft\AGPM

Temp folder

The AGPM Service uses GPMC application programming interfaces (APIs) to accomplish many GPO operations. Many of these APIs use the computer’s temp folder for temporary storage. You must grant the AGPM Service account Full Control to the computer’s temp folder, which is %systemroot%\temp.

Full Access to existing GPOs

AGPM ensures that it has proper ownership and permissions to all controlled GPOs. However, GPOs created before implementing AGPM will not provided adequate permissions to the AGPM Service. For this reason, you’ll want give the AGPM Service Full Control to all GPOs that exists prior to implementing AGPM.

Group memberships

The AGPM Service requires membership in two groups: Group Policy Creator Owners and Backup Operators.

Group Policy Creator Owners

By Default, Windows only allows Domain Administrators and Group Policy Creator Owners to create Group Policy objects. The least privilege configuration requires you to make the AGPM Service account a member of Group Policy Creator Owners. Membership in the Group Policy Creator Owners group allows the AGPM service to create Group Policy objects , makes the AGPM Service the owner of the new Group Policy object, and gives it the permissions required to manage the Group Policy object.

Backup Operators

Some of the operations that occur in AGPM mimic the functionality found in backup software. For example, the AGPM service may need to change the owner of a Group Policy object. Granting ownership to a security principal different from yourself is a privileged operations. Including the AGPM service account in the Backup Operators group provides it with the privilege to grant ownership. Backup Operators is a well-known security identifier found on each Windows Server. The AGPM Service attempts to change ownership on Group Policy objects, which are stored on the domain controller. The ownership change operation occurs at the domain controller, so you need to make sure the AGPM Service account is in the Backup Operators group on the domain controllers. Membership to the Backup Operators account on the AGPM Server is not required.

Troubleshooting

You can run across some configuration issue when attempting to configure the AGPM Server in a least privilege scenario. The following are the most common errors seen during an AGPM least privilege scenario.

[GPMC Error] Could not take ownership of the production GPO. Value does not fall within the expected range

00-agpm This error is discoverable when attempting to delete a controlled Group Policy object. The error occurs when choosing Delete GPO from archive only or Delete GPO from archive and production.

Solution

The AGPM Service is configured for least privileges and is not a member of Backup Operators on the domain controller. The AGPM service is attempting to grant ownership to a security principal in which it is not allowed. Add the AGPM service account to Backup Operators on the domain controller. Restarting the AGPM service is not a requirement.

[Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML.

01-agpm This error is discoverable when attempting to create a new controlled Group Policy object. There are two major causes of this error

Solution 1:

The AGPM service does not have permissions to the computer’s temp folder. Ensure the AGPM service has Full Control to the %systemroot%\temp folder of the computer running the AGPM Server service.

Solution 2:

First, check solution 1. Permissions on the computer’s temp folder is root cause of the problem and you’ll want to fix that first. If you are still receiving the error after following solution 1 (or temporarily making the AGPM service account a local admin of the computer running the AGPM Server service and restart the service), then the root cause of the problem occurred when you attempted to create your first controlled Group Policy object. The template created during the first controlled GPO creation failed (most likely with the this warning [GPMC Warning] A Report for this GPO could not be created. The backup will not contain any report of the settings Details: 0x80131509).

02-agpm Therefore, all subsequent controlled GPOs created from the template fail with [Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML. You need to Delete and Destroy all templates created before you followed solution 1 (permissions on the temp folder). Templates created before following solution 1 contain invalid XML. 03-agpm After deleting and destroying invalid templates (specifically the template), then create a new controlled Group Policy object. You’ll be prompted to create a new template. Agree to the create the new template. The operation takes longer than expected; however, it should return successful.
– Mike Stephens

Removable Storage, Group Policy and Windows Server 2008 and Windows Vista

Posted on August 25, 2008 by Mike

“I don’t want my users copying data to removable drives. How can I prevent this?”

Today I want to answer this common question asked to our team. Removable drives are widespread. Current mobile devices can now store up to 8 GB of data on a micro-SD card, which is no bigger than your thumb nail. Eight gigabytes is a huge amount of data and it could be your company’s Intellectual Property (IP) going out the door. There is a need to protect your company’s sensitive information from being transferred to removable storage devices; Group Policy in Windows Server 2008 and Windows Vista can help you.

You can control access to six removable storage categories (actually seven but the seventh category controls access to ALL removable storage devices). These categories include CD and DVD, Floppy Drives, Removable Disks, Tape Drives, and WPD devices. 00-storage Today’s computers usually do not included a floppy drives because the amount of data that fits on a floppy disk seems trivial in the age of one terabyte drives—regardless, you can restrict access to floppy drives, which includes USB floppy drives. Removable drives included classic USB thumb drives. WPD devices include media players, cell phones, CE devices, and some auxiliary displays. There is a custom category that allows you to identify the unique identifier of a device and control access of that device based on the unique ID.

Each device category provides two types of access control—deny read and deny write. These policy settings apply to Windows Vista or later (to included Windows Server 2008) and can co-exist in GPOs applying to clients earlier than Windows Vista; however these older operating systems ignore the policy settings.

You can find these policies under the Removable Storage Access category, under User or Computer Configuration\Policies\System\Removable Storage Access

These policy settings change the security descriptor on the removable objects. Changing the security descriptor requires a computer reboot. Window’s does not reboot the computer when the policy changes these security descriptors. However, Removable Storage provides a policy setting to which you can enable to force a reboot. Enable the Time (in seconds) to force reboot policy setting and provided value (in seconds) for which Windows waits before rebooting the computer to apply the new security descriptors for removal drives. 01-storage So, keep your Intellectual Property secure by controlling access to removable storage devices. Delegate write permissions to a limited user set, or limit removable storage write access to a single workstation. You can do your part to keep your company’s sensitive data where it belongs.

– Mike Stephens

Event Logging policy settings in Windows Server 2008 and Vista

Posted on August 12, 2008 by Mike

Today I’m focusing on policy settings for the Event Logging Service.

For clarity, these settings control the Event Logging service; the service responsible for capturing and writing events throughout Windows. These policy settings do not affect the Event Viewer application.

These are some powerful policy settings that allow you to configure five settings for Application, Security, Setup, and System event logs. These categories and their policy settings are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Event Log Service.

The Log File Path policy setting, when enabled, allows you to provide a specific location where the Event Log service writes its log file. You must provided path and filename when relocating where Windows writes the log file.

Next is the Maximum Log file size policy. When enabled, this policy allows you to specify the maximum size of the event log. It supports sizes between one megabyte and two terabytes and uses one-kilobyte increments. 00-eventLog The next two policy settings are related. The Event Logging service uses the Retain old events and Backup log automatically when fullpolicy settings when the event log reaches the maximum file size (defaults to 20 MB or the value specified in the Maximum Log size policy setting). With the Retain Old Events policy setting enabled, the Event Logging service stops writing new events to the event log when the log file reaches or exceeds the maximum value and you lose all new events. With this policy setting disabled, new events overwrite old events. When you enabling the Backup log automatically when full and the Retain old events policy settings, the Event Log service closes the current event log, renames it, and then creates a new log. The Backup log automatically when full policy setting works only when you enable Retain old events policy setting. 01-eventLog The last setting and one that I think is the most beneficial is the Log Access setting. Enabling this setting allows you to enter a security descriptor for the log file. The security descriptor controls who can read, write, or clear the event log. You enter the security descriptor using Security Definition Description Language (SDDL), which is document on MSDN(http://msdn.microsoft.com/library/en-us/secauthz/security/security_descriptor_string_format.asp). Also, my esteemed colleague Jim provides a two-part blog series about SDDL (http://blogs.technet.com/askds/archive/2008/04/18/the-security-descriptor-definition-language-of-love-part-1.aspx and http://blogs.technet.com/askds/archive/2008/05/07/the-security-descriptor-definition-language-of-love-part-2.aspx).

Finally, I should mention that these new policy settings have precedence over the older Windows Server 2003 and Windows XP security policy setting that manage Event Logs. Both settings can exist in the same Group Policy object and apply only to the respective operating systems for the policy setting. 02-eventLog These new policy settings for the Event Logging service provide more flexibility and control from earlier versions. Using Group Policy to control where event logs are written, how large they can grow, how they are preserved, and who can manage them are key to change control and security auditing. You can implement these policy settings in your existing Group Policy objects and they will not affect operating systems earlier than Windows Vista.
– Mike Stephens

Client-side Extensions

Group Policy Processing

Scope

Linking

Security Filtering

WMI Filtering

Processing Order

Local, Site, Domain, and OU

Conflict Resolution

Conflict Resolution among GPOs linked at the same Location

GPLink Attribute

Link Options

Enforced

Block Policy Inheritance

Share this:

Like this:

Computer Startup Scripts:

Computer Preference

Computer Policy

User Logon Scripts:

User Preference

Computer Preferences

User Policy

Computer Policy

User Logoff/Computer Shutdown:

Share this:

Like this:

Share this:

Like this:

Add the policy setting to Security Policy settings

Include the Extended Protection for Authentication policy setting in Group Policy

Conclusion

Share this:

Like this:

ADMX Files and the Group Policy Central Store

The Central Store

So what’s the Problem?

A Central Store and Windows 7

Updating the Central Store

Removing the Group Policy Central Store

An Alternative to the Central Store

Share this:

Like this:

Before Windows Server 2008 and Vista

The Windows Server 2008 and Vista era

Group Policy using NLA

Locate a domain controller

During bandwidth estimation

Authentication

Determine network name

Site query

Determine scope of management

Normal mode

Building the OU and domain list

Evaluate scope of management

Determine the Link Status:

Conclusion

Share this:

Like this:

Why a null DACL halts file security Group Policy processing

More on inheritance

What to do

Share this:

Like this:

Least privilege requirements

The AGPM Service account

Archive folder

Temp folder

Full Access to existing GPOs

Group memberships

Group Policy Creator Owners

Backup Operators

Troubleshooting

[GPMC Error] Could not take ownership of the production GPO. Value does not fall within the expected range

Solution

[Error] An XML file generated by GPMC cannot be read or may contain invalid or malformed XML.

Solution 1:

Solution 2:

Share this:

Like this: