If you would like to read the other parts in this article series please go to:
- Top 10 Reasons Why Group Policy Fails to Apply (Part 1)
- Top 10 Reasons Why Group Policy Fails to Apply (Part 3)
Introduction
In our first installment of this topic we looked at 5 reasons why Group Policy might not be working properly in your environment. Looking back at those 5 reasons exposed some key factors about Group Policy. First, Group Policy relies on proper authentication through DNS to the domain controllers, using Kerberos for the authentication protocol. We also looked at the concept of scope of management, which can easily break Group Policy if not configured properly. Finally, making sure that the correct object type setting (user or computer) is set to match the object type you are controlling is invaluable. Now, we are going to move on to discuss more reasons why Group Policy might not be working properly in your environment.
6. GPO Setting Is Being Controlled by GPO with Higher Precedence
Group Policy is complicated and can be exacerbated by adding a multitude of GPOs at different levels within AD. I am not saying it is not common to have GPOs at different levels in AD, just stating the fact that it can be complicated. There is a precedence of GPOs within AD, including the local GPO. Considering there can be a GPO linked to the site, the domain, and organizational units in AD, the precedence is summarized by LSDOU. Local GPO has the weakest precedence, site linked GPOs are next, domain linked GPOs are next, with OU linked GPOs having the highest precedence.
So, assume there is a GPO linked to the domain which sets the Run command off of the Start Menu to disabled, where another GPO linked to the OU level setting the same Run command to Enabled…. The GPO linked to the OU will “win” and the user in the OU where the GPO is linked will have the Run command policy set to Enabled. (The setting I am referring to is “Remove the Run command…” so the Run option off of the Start Menu will be removed.
This precedence must be evaluated for every GPO setting, as there can only be one setting take place when all GPOs and the settings are evaluated. The RSOP.msc (Resultant Set of Policies) command on the target computer will indicate which setting “won” and from which GPO it came from, which can be seen in Figure 1.
Figure 1: RSoP.msc indicates the resulting GPO settings and from which GPO the setting came from.
Note:
When setting up “lists” in a GPO setting, such as User Rights, Restricted Groups, etc., these lists will not accumulate, but rather are looked at as a complete list at each level. So, if the GPO at the domain lists two entries for the setting and the GPO at the OU lists one entry for the setting, only one entry will end up for the setting, not three.
7. Security Filtering is Not Configured Correctly on GPO
As a Group Policy MVP I find that certain aspects of GPOs are more complicated than others. One of the most complicated aspects of GPOs is the concept of security filtering. Security filtering is really nothing more than the access control list (ACL) on the GPO. However, it seems more complicated due to the evolution of the setting interface, the complexity of what is listed and what a GPO can apply to, as well as the minimum requirements for the ACL to receive the settings.
First, the interface for this setting in the GPMC masks what the minimum ACL settings need to be. You can see the interface for security filtering in Figure 2. You can see it states that only the users, computers, and groups in the list can receive the GPO settings.
Figure 2: Security Filtering interface and configuration for a GPO using the GPMC.
When you add a user, computer, or group to this you are in essence adding that object to the ACL for the GPO and granting the object Read and Apply Group Policy permissions, which can be seen in Figure 3.
Figure 3: Detailed security filtering for a GPO.
In order to get to the graphic shown in Figure 3, you will need to be within the GPMC, ensuring the GPO that you want to see the details for is selected. Instead of selecting the Scope tab, which is what you see in Figure 3, select the Delegation tab. The Delegation tab lists the capabilities of object defined by GPMC. You should see the Authenticated Users group on a default GPO. Now that you see the Authenticated Users group on the Delegation tab, select the Advanced button in the lower right corner. This will display the Security Settings for the GPO. Ensure you select the Authenticated Users group, which will display the same result you see in Figure 3.
Second, notice what the detail security filtering is for a GPO. That is right, it is Authenticated Users. I often get feedback from administrators that Authenticated Users ONLY includes user accounts. That is not correct. Authenticated Users includes every authenticated object to Active Directory, which would include all domain users, groups (defined and part of AD), and computers that have been joined to the domain.
Third, although the security filtering pane says that it applies to users, computers, and groups that are listed, that is not entirely true. Remember from our first article that GPOs can only apply to users and computers. When a group is listed, it is simply grouping users and/or groups instead of listing them individually. The user and/or computer must still be under scope of management in order to get the setting defined in the GPO. This means that the user and/or computer must be in the group listed on the security filtering list, plus be in the OU (if the GPO is linked to the OU), in order to get the setting defined in the GPO.
Summary
From this article, you can see that precedence and permissions (security filtering) can cause dramatic issues with the results of the GPO settings that you are trying to impart on the users and computers. Never forget the basics of Group Policy, which is essential for troubleshooting what is going wrong with Group Policy. For precedence, you will need to be able to determine if any settings are set in multiple GPOs, and then determine which GPO has higher precedence. For security filtering, just make sure that the correct user, computer, or group (group is preferred) is listed on the security filtering pane. Then, also ensure that the user and/or computer is under scope of management, which will ensure the object will receive the setting in the GPO linked to that AD node.
If you would like to read the other parts in this article series please go to:
Want to understand the effect of application of Computer settings from a GPO by removing authenticated users from the list.