Change in GPO Processing

  • 343 Views
  • Last Post 28 June 2016
a-ko posted this 16 June 2016

 https://support.microsoft.com/en-us/kb/3163622 MS16-072 changes the way user policy objects are accessed. They are now accessed via the machine’s security context, not the user context. Which means if you’ve been using security filters for user policies, these policies will no longer be applied to the system unless you perform the included fixes. This is a pretty big change. Goes back to why I recommended against using GPO Security Filters unless absolutely necessary…. -Mike C

Order By: Standard | Newest | Votes
gduke posted this 28 June 2016

Brian,



 

Thank you for mentioning this. We’re seeing strange GP processing behavior from our Windows 10 clients, specifically not processing many Group Policy objects

that should be applied (and have applied in the past).

 

I remembered you had mentioned that an update made some unexpected changes, which led me to the documentation for

KB3163017, which mentions the following:

 

MS16-072 changes the security context with which user group policies are retrieved. This by-design behavior

change protects customers’ computers from a security vulnerability. Before MS16-072 is installed, user group policies were retrieved by using the user’s security context. After MS16-072 is installed, user group policies are retrieved by using the computer's

security context. […]


 

Symptoms

 

All user Group Policy,

including those that have been security filtered on user accounts or security groups, or both,

may fail to apply on domain joined computers.

 

I’m surprised more things haven’t broken (yet). I haven’t attempted to apply fixes, yet, but this will be first order

of business tomorrow.

 

--Geoff

 

Geoffrey Duke

802.656.1172 |

Sr

Systems Administrator
|

Enterprise

Technology Services
|

University

of Vermont


 

 

 

 

show

Alix posted this 23 June 2016

Hi all,
since the application of the security patches last week, it seems that the communication between clients and Domain Controller is bizarre : the number of computers returned  by "dsquery computer -inactive 1" is *5 more than "dsquery computer -inactive i" , with i=2 or i>2.
If I test the secure channel of an "alive but inactive computer" (and I propose to name this computer "mypc") with this command :
nltest /server:mypc /sc_query:mydomain
there is no error with the connection status
More the "inactive PC" (which can be a server) seems to be all right : no problem to access remote share etc
Let's say that I am worry : what kind of test can I do ? What about the command "dsquery inactive" and "nltest" : which one is correct ?
Thanks for your advice,
A.
2016-06-21 17:05 GMT+02:00 Brian Arkills <barkills@xxxxxxxxxxxxxxxx>:
















MS16-077: “WPAD Update” which includes SMB hardening that by default restricts Netbios over TCP to the local subnet. My senior engineer thinks this might have been the worst named update he’s ever seen from Microsoft,

especially when you combine it with other updates that do mention SMB.

 

We had a major incident last week due to this poorly named Microsoft update, where our Samba servers were rendered dead in the water due to applying this patch to the domain controllers of the domain those Samba

servers were joined.

 

We had “newer” samba servers staged which were not affected and ended up swinging all our client shares to the new samba servers sooner than planned as a workaround.

 

We eventually heard someone else mention a similar problem, and realized that the name of this update was extremely misleading, and we had overlooked it as a possible cause of our incident. Configuring the settings

mentioned in the KB on our DCs did “fix” our older samba servers, but definitely too late to do our customers any good.

 

Not sure how this would relate to the problem mentioned involving GPOs, unless we are talking about domain clients which are pretty old capable of only doing netbios over tcp.

 

 

show

barkills posted this 21 June 2016

MS16-077: “WPAD Update” which includes SMB hardening that by default restricts Netbios over TCP to the local subnet. My senior engineer thinks this might have been the worst named update he’s ever seen from Microsoft,

especially when you combine it with other updates that do mention SMB.

 

We had a major incident last week due to this poorly named Microsoft update, where our Samba servers were rendered dead in the water due to applying this patch to the domain controllers of the domain those Samba

servers were joined.

 

We had “newer” samba servers staged which were not affected and ended up swinging all our client shares to the new samba servers sooner than planned as a workaround.

 

We eventually heard someone else mention a similar problem, and realized that the name of this update was extremely misleading, and we had overlooked it as a possible cause of our incident. Configuring the settings

mentioned in the KB on our DCs did “fix” our older samba servers, but definitely too late to do our customers any good.

 

Not sure how this would relate to the problem mentioned involving GPOs, unless we are talking about domain clients which are pretty old capable of only doing netbios over tcp.

 

 

show

patrickg posted this 21 June 2016

Ran the script to show which GPO’s had the issue, only three did and none were being using by our users. It did warn about the Direct Access policies on the plus we are not in prod yet

with DA.

 

https://blogs.technet.microsoft.com/poshchap/2016/06/16/ms16-072-known-issue-use-powershell-to-check-gpos/

 

http://www.gpanswers.com/never-a-dull-moment-with-group-policy-or-what-to-do-about-ms16-072/

 


~Patrick

 

 

show

SmitaCarneiro posted this 21 June 2016

I’ve noticed issues too. My test environment that is Server 2012 r2 based , now has problems applying GPOs. I cannot edit any GPOs either, even though I can link

and unlink them. It seems to be related to the UNC hardening that MS recommended last February to require authentication and Integrity checking for the SYSVOL and NETLOGON shares. Am still working on it.

 

I also heard from a colleague in a different environment that there are issues with Samba servers no longer being able to handle authentication after Microsoft

changed the default behavior of NetBIOS to be more secure

 

This discussion covers it.

https://social.technet.microsoft.com/Forums/en-US/5b32fb1c-bb5d-4be0-8a61-5adcb6ea4eb7/kb3161949-june-2016-update-causes-network-file-shares-to-become-unavailable?forum=w7itpronetworking.

 

Smita

 

 

show

Alix posted this 21 June 2016

Hi everyone,
Since the application of the security updates of last week, I have GPO problem which has not disapeared with adding the configuration described in MS16-072.Event ID 1085 :
Windows failed to apply the Group Policy Registry settings. Group Policy Registry settings might have its own log file.
Error Description : parametre incorrect.
I have to say that on one of the Domain controllers, I had to uninstall all the security updates of last week (replication error 1753) and I think that it is correlated => uninstalling the update on all the DC ? Any idea ? (by the way, the DC are 2008R2 and I m trying to activate the GPO logging) 
Alix
2016-06-16 7:15 GMT+02:00 Mike Cramer <mike.cramer@xxxxxxxxxxxxxxxx>:
 https://support.microsoft.com/en-us/kb/3163622 MS16-072 changes the way user policy objects are accessed. They are now accessed via the machine’s security context, not the user context. Which means if you’ve been using security filters for user policies, these policies will no longer be applied to the system unless you perform the included fixes. This is a pretty big change. Goes back to why I recommended against using GPO Security Filters unless absolutely necessary…. -Mike C

darren posted this 17 June 2016

Jeremy-
Now that I'm reading that, I had it backwards. It was per-computer security group ILTs that were "fixed", as noted below. Per-user security group ILTs never did a round trip. I'm looking for references to that but it's mostly internal stuff I have based on conversations from about 3 years ago with the product team, related to some slow boot/slow logon reporting we did around GP. I'll see if I can find a more definitive reference. I think my timing was wrong--it was probably Windows 8 when that came out, though I could swear it was later. Apparently I've been doing this too long...

Thanks,

Darren

show

jheaton posted this 17 June 2016

We're all Windows 7 at the moment. Also, we do have separate sites for each of our server sites, so downtown Sac, and 14 other sites. Things are working fine as-is, so I don't think I'll be changing how we are doing the GPs, I'll just have to add what needs to be done to make them work.

show

jeremyts posted this 16 June 2016

I didn't know that Darren. Do you have a reference for that as I can't find anything? I only thought they addressed the round-trip on computer groups a few years ago now: https://blogs.technet.microsoft.com/askds/2011/08/18/improved-group-policy-preference-targeting-by-computer-group-membership/

Cheers,
Jeremy

show

kennedyjim posted this 16 June 2016

Read permissions for everyone will not apply it to everyone. It will allow the machine to read the gpo. Then the users with Apply will get it.





















show

jkolenda posted this 16 June 2016

All,
I have been following this thread for awhile.  not sure if this has been 100% answered or not.  Apologize if that has been.
Just curious if I currently use security filtering with AD groups to open up something for certain users say like regedit, and if I add authenticated users back to the GPO will read permissions not apply group policy permissions will that apply that GPO to all users?
I am thinking and hoping that will not be the case.  But then thinking if the machine policy is the one pulling the GPO not it might.


show

darren posted this 16 June 2016

GP Preferences with Item-Level Targeting is the common way to handle this. I've seen customers put literally 1000s of drive mappings, each with ILTs, in a single GPO. Obviously depends a bit on your topology however. In Windows 8.1+, MS got rid of the round-trip required to evaluate user security group filtering in ILT, so if your clients are newer, they can take advantage of this.

Darren

show

jheaton posted this 16 June 2016

We've got so many OUs already that I don't want to separate them further. I think I'll just stick to the way it is for now, and wait for DFS to eliminate all these mapped drives.

show

SamErde posted this 16 June 2016

My short answer would also be a single GPO with preferences for each site. I'm also curious if the op has different AD sites set up for each physical site that he is trying to achieve this at.


show

SmitaCarneiro posted this 16 June 2016

If you're referring to item-level targeting, that is querying AD, would that not add a delay in processing?

Smita

show

kennedyjim posted this 16 June 2016

Or a Northern California OU with a sub OU for each office under that. The drive mappings just hit those office OU's, the common ones hit the N CA OU. Or keep doing it the way you are, it is perfectly acceptable and is referred to as a best practice and/or suggested by MS in lots of places. Here are a couple.

https://technet.microsoft.com/en-us/library/cc779168(v=ws.10).aspx

https://blogs.technet.microsoft.com/grouppolicy/2009/07/30/security-filtering-wmi-filtering-and-item-level-targeting-in-group-policy-preferences/

show

dddugan posted this 16 June 2016

Single GPO with group policy preferences?

show

jheaton posted this 16 June 2016

Ok, so let me pose this, and have you tell me how I "should" be doing it.

I have login policies done through GPO. I have an OU, that covers Northern California, which has multiple offices. Each office has its own server, and I want the users in that office to map to their local server. We've done this by creating separate GPOs, and applying them to security groups of people in the different offices, through Security Filtering.

How would you accomplish this? And don't say DFS, because we are actually going down that road, just not there yet.

show

a-ko posted this 16 June 2016

OUs were kind of designed for this, though.

I think there's a general recommendation against deep OU nesting but I'm not sure what the technical reasons for that are...

show

kurtbuff posted this 16 June 2016

Following your advice on using OUs instead of security filtering would
make our OU structure much more complicated.

For instance, within a single department, I have staff with laptops,
and those machines must have bitlocker and directaccess policies
applied, but I don't want those GPOs applied to the desktops.
Additionally, some machines in each department are nominated as test
candidates for patches via WSUS - the test candidates get patches
immediately after release, and the others get them a week later,
assuming no problems arise.

But, that means, with the conditions I've outlined, going from one OU
for each department's computers to, at a minimum, 4 OUs, and that
doesn't include other circumstances.

I think the explosion of OUs for taking into account each of those
(sometimes overlapping) cases would make things harder to manage.

Kurt

show

Show More Posts
Close