Group Policy Processing and MS16-072
Today I'll talk about a change in the group policy processing design that troubled me today.
I created a new GPO, configured the settings and the security filtering in order to restrict it to a test users group and then linked in to the domain. The policy however did not apply to all of the users in security group. I started by running gpresult in order to get the status of the GPO for the users on their computers. The GPO was inaccessible. I then double checked the permissions on the GPO just to make sure that the filtering has applied the correct permissions and that there were no deny permissions. Everything was good so far. I fired up the event viewer on the client computer in order to check the events regarding the group policy processing but there were not events regarding my GPO. After a quick check on the SYSVOL and ADSIEdit, I decided to focus on the client side since the GPO applied to some of the users in the security group and discovered the following.
Recently, the following change was applied to the way GPOs are being retrieved from the domain controllers with the MS16-072 update. The user GPOs are now retrieved using the computer context instead of the user context. What does this mead? It's very simple. Instead of using the user's account to read the policies from the domain controller, the computer account is used instead.
How does this affect your Group Policy design? If you have GPOs that contain user settings, assigning read and apply permissions for the users on the GPO is not enough. Computers must also have read permissions in order to fetch the GPO.
The solution? Add the "Authenticated Users" group with read permissions. If you do not want to allow all these account to read the GPO, use my preferred solution: add the "Domain Computers" group with read permissions.
So, next time a GPO status in gpresult is inaccessible although you have assigned read and apply permissions to the users, check if that update is installed!
You can read more about the security update here and the vulnerability here.
I created a new GPO, configured the settings and the security filtering in order to restrict it to a test users group and then linked in to the domain. The policy however did not apply to all of the users in security group. I started by running gpresult in order to get the status of the GPO for the users on their computers. The GPO was inaccessible. I then double checked the permissions on the GPO just to make sure that the filtering has applied the correct permissions and that there were no deny permissions. Everything was good so far. I fired up the event viewer on the client computer in order to check the events regarding the group policy processing but there were not events regarding my GPO. After a quick check on the SYSVOL and ADSIEdit, I decided to focus on the client side since the GPO applied to some of the users in the security group and discovered the following.
Recently, the following change was applied to the way GPOs are being retrieved from the domain controllers with the MS16-072 update. The user GPOs are now retrieved using the computer context instead of the user context. What does this mead? It's very simple. Instead of using the user's account to read the policies from the domain controller, the computer account is used instead.
How does this affect your Group Policy design? If you have GPOs that contain user settings, assigning read and apply permissions for the users on the GPO is not enough. Computers must also have read permissions in order to fetch the GPO.
The solution? Add the "Authenticated Users" group with read permissions. If you do not want to allow all these account to read the GPO, use my preferred solution: add the "Domain Computers" group with read permissions.
So, next time a GPO status in gpresult is inaccessible although you have assigned read and apply permissions to the users, check if that update is installed!
You can read more about the security update here and the vulnerability here.
