Warning! Groepsbeleid wordt niet meer toegepast sinds 14 juni 2016 door security-update

Door RRX op woensdag 22 juni 2016 17:22 - Reacties (16)
CategorieŽn: Software, Windows, Views: 6.183

Ik wil even wat kwijt, misschien heb je er wat aan.

het kan goed zijn dat bepaalde groepsbeleid objecten die je in werking hebt sinds 14 juni 2016 niet meer toegepast worden.

De meeste Windows systeembeheerders die werken met Windows kennen het (hoop ik) wel, groepsbeleidobjecten.

Eťn van de leuke dingen van groepsbeleidobjecten is dat je er voor kan zorgen dat ze alleen van toepassing zijn op bepaalde users en/of groepen.

Stel je dus voor je hebt een groep "studenten" die je qua rechten op de Windows machine helemaal wilt inperken, dan kan je een groepsbeleid aanmaken die je op de groep "studenten" toepast zodat ze alleen nog kunnen doen waarvan jij wilt dat ze dat kunnen. De boel lekker dichtgetimmerd.

Een ander voorbeeld, een bepaalde groep in het bedrijf moet bepaalde schijfletters krijgen, dus pas je een groepsbeleid toe op die groep medewerkers en die krijgen een bepaalde schijfletter toegewezen.

Nu hadden wij van de week een klant waar ineens de schijfletters niet meer tevoorschijn kwamen op een Windows 10 machine. Ook hadden wij dat hier op kantoor bij een bepaalde schijfletter.

Diezelfde middag moest ik bij een klant een groepsbeleid maken die voor een bepaalde groep users van toepassing moest zijn, dus een mooie policy gemaakt en gefilterd op die specifieke groep users, maar wat ik ook probeerde de instellingen werden niet toegepast :( .

Op de server heb je een tool RSoP (Resultant Set of Policy) waarmee je kan nabootsen welke groepsbeleiden op een bepaalde user op een bepaalde computer worden toegepast.

Deze gaf aan dat alles correct stond, echter op de Windows 10 client nog steeds geen resultaat :(.

Dan ga je verder zoeken. Op de client
code:
1
Gpresult /h report.html /f

in de usercontext uitgevoerd. Wat blijkt, volgens het rapport heeft de user schijnbaar geen rechten op het zojuist aangemaakte groepsbeleid.

De rest van de zaken die ik heb geprobeerd laat ik ivm tijdgebrek achterwege en zal tot de conclusie van mijn verhaal komen:

Microsoft Security Bulletin MS16-072

Op 14 juni heeft Microsoft een beveiligingspatch uitgebracht voor Windows zie hier:
https://support.microsoft.com/en-us/kb/3163622

Nadat deze update is geÔnstalleerd worden groepsbeleidobjecten alleen nog maar toegepast wanneer;
A. De Authenticated Users groep leesrechten heeft op de policy (wat standaard zo is, maar er voor zorgt dat de policy op iedereen wordt toegepast.
B. Naast een specifiek gedefinieerde groep (Via security filtering) ook de "Domain Computers" groep leesrechten krijgt op de policy (via Delegation).


Wanneer je dit dus niet doorhebt, veroorzaakt MS16-072 mijn inziens ook weer een security-issue omdat een groepsbeleid waarmee je een bepaalde groep users qua rechten had ingeperkt ineens veel meer rechten kunnen hebben in het netwerk.

Wat vinden jullie daarvan?

De oplossing is dus te vinden onderaan dit artikel;
https://support.microsoft.com/en-us/kb/3163622
To resolve this issue, use the Group Policy Management Console (GPMC.MSC) and follow one of the following steps:
Add the Authenticated Users group with Read Permissions on the Group Policy Object (GPO).
If you are using security filtering, add the Domain Computers group with read permission.
Met credits voor
http://serverfault.com/qu...sabled-server-2012-r2-and

Waar ik de oplossing heb gevonden.

Raymond.

Edit: Titel aangepast gezien het niet alleen Windows 10 betreft

Volgende: Logmein & Teamviewer Alternatief: Screenconnect 12-'14 Logmein & Teamviewer Alternatief: Screenconnect

Reacties


Door Tweakers user Robe90, woensdag 22 juni 2016 17:30

Weer mooi opgelost Raymond! :)

Door Tweakers user itlee, woensdag 22 juni 2016 21:50

Betreft dit alle type domain controllers? w2k12r2? of w2k8?

thnx voor het delen van je blog in ieder geval, per definitie ben ik geen voorstander van (flinke) policies, brengt alleen maar narigheid, en als mensen willen klooien doen ze het toch wel.

evengoed inhoudelijk op je artikel, betekent dat er maar 1 oplossing is en dat is meerdere OU's aanmaken en daar je users in stoppen om vervolgens de policy op los te laten.

nadeel is weer, als je meerdere policies actief hebt voor 1 user die in verschillende OU's moeten zitten. (daarvoor waren de groepen zo'n mooie oplossing)

maar, de hamvraag, blijft dit nu zo? of is dit een tijdelijke fout van MS?

Door Tweakers user Tyson, woensdag 22 juni 2016 21:58

itlee schreef op woensdag 22 juni 2016 @ 21:50:
maar, de hamvraag, blijft dit nu zo? of is dit een tijdelijke fout van MS?
Dit blijft zo:
This by-design behavior change protects customers’ computers from a security vulnerability.

Door Tweakers user RRX, woensdag 22 juni 2016 22:15

@itlee

Het betreft de clients die de polities niet meer accepteren. Ik kwam er achter bij een Windows 10 client en een server 2012 RDS maar ik ga er vanuit dat deze patch op alle OS'en die nog door MS ondersteund worden in werking treden

Ik heb nooit narigheid met policies en bedrijfsmatig is het een must. Niet alleen om dichttimmeren naar ook voor bijv. Software, snelkoppelingen, standaard sjabloonlocaties etc.etc.

De oplossing is vrij simpel zoals genoemd in het artikel, als je een policy ipv de authenticated users wil filteren op een andere user of groep moet je ook de domain computers groep rechten geven op die policy, dan werkt het gewoon weer.

Het discutabele aan dit hele verhaal vind ik dat door een client update ongemerkt bepaalde policies onklaar worden gemaakt.

Zoals Tyson aangaf. Dit blijft zo.

Ik weet even niet hoe MS dit op een andere manier had kunnen doorvoeren naar ik vond het vrij onverwacht

[Reactie gewijzigd op woensdag 22 juni 2016 22:16]


Door Tweakers user Sh1fty88, woensdag 22 juni 2016 23:09

Toevallig van de week ook last van gehad op een RDS 2016 TP4 test server, netwerkshares werden plots niet meer toegewezen. Na lang zoeken uiteindelijk de policy werkend gekregen door authenticated users toe te voegen.

Hierna deze weer verwijderd en de security group en het server account toegevoegd en magisch verschenen de netwerkshares weer. ik dacht dat ik gek werd totdat ik dit las, mijn dank is groot voor de opheldering _/-\o_

[Reactie gewijzigd op woensdag 22 juni 2016 23:12]


Door Tweakers user MAX3400, donderdag 23 juni 2016 07:35

Sh1fty88 schreef op woensdag 22 juni 2016 @ 23:09:
Toevallig van de week ook last van gehad op een RDS 2016 TP4 test server, netwerkshares werden plots niet meer toegewezen.
Het is inderdaad wel heel toevallig; vergeet even niet dat 2016 absoluut unsupported is en dat TP4 helemaal niet meer genoemd staat als applicable product.

In het algemeen; best kwalijk dat mensen/admins dus blijkbaar klakkeloos WindowsUpdates doorvoeren zonder te lezen wat ze nou daadwerkelijk doen.

Door Tweakers user @r!k, donderdag 23 juni 2016 07:46

Authenticated users read rechten toekennen is NIET hetzelfde als Apply policy. Als authenticated users read rechten krijgen kan iedereen de settings van die GPO bekijken. Pas als je authenticated users echt toewijst via security filtering zal de GPO worden toegepast. Echter als je dit via delegation doet is dat niet het geval.

Door Tweakers user RRX, donderdag 23 juni 2016 09:33

@MAX3400
Doe jij het wel, van iedere update de +/- een A4 aan teksten doorlezen en bepalen of het mogelijk van invloed is bepaalde zaken die jij gebruikt?

Ik denk dat dit alleen is voorbehouden aan grotere bedrijven waarbij er dedicated mensen op een functie als patch management zijn toegewezen. Dit is namelijk een nogal tijdrovende klus!

[Reactie gewijzigd op donderdag 23 juni 2016 09:33]


Door Tweakers user Monkeybrains, donderdag 23 juni 2016 11:26

Ik heb dit vorige week, kort na het uitrollen van deze updates dus, aan de hand gehad. Gek genoeg was het alleen een probleem als de client onze oude DC als logonserver had die nog W2008R2 draait. Als de client de nieuwe DC (W2012R2) als logonserver had was het geen probleem.

Het leuke was dat de default domain policy wel goed uitgevoerd werd |:(

Uiteindelijk een post op het forum van Microsoft gevonden van een aantal mensen die hetzelfde hadden, met de oplossing die hier ook genoemd wordt (authenticated users read rights).

Door Tweakers user RRX, donderdag 23 juni 2016 11:33

@Monkeybrains

Dat kan dan overigens ook nog wellicht dit probleem zijn geweest https://adsecurity.org/?p=1405 ook een extra security-fix die onlangs is doorgevoerd.

[Reactie gewijzigd op donderdag 23 juni 2016 11:34]


Door Tweakers user JerX, vrijdag 24 juni 2016 09:21

Dit probleem is al vrij oud.. sinds Windows Server 2008 geven wij authenticated users read rechten op een GPO.

Door Tweakers user RRX, vrijdag 24 juni 2016 10:46

@JerX hoe bedoel jij dat dan, bij delegation?

Ik heb er namelijk nog nooit problemen mee gehad en het staat ook als specifieke oplossing genoemd in https://support.microsoft.com/en-us/kb/3163622.

Sinds de update van vorige week ineens overal deze problemen.

Door Tweakers user JerX, vrijdag 24 juni 2016 15:38

RRX schreef op vrijdag 24 juni 2016 @ 10:46:
@JerX hoe bedoel jij dat dan, bij delegation?

Ik heb er namelijk nog nooit problemen mee gehad en het staat ook als specifieke oplossing genoemd in https://support.microsoft.com/en-us/kb/3163622.

Sinds de update van vorige week ineens overal deze problemen.
Yup bij Delegation.

Door Tweakers user Ethirty, zaterdag 25 juni 2016 12:05

Er is nog een tweede patch die problemen met GPO's geeft hebben wij gemerkt.
https://support.microsoft.com/en-us/kb/3159398

Wij hebben in ieder geval na patch tuesday deze maand een hoop ellende voor onze kiezen gekregen.

Door Tweakers user Lunacy, maandag 27 juni 2016 19:55

Blij dat ik je post gisteren toevallig even had gelezen. Vandaag was het raak bij ťťn van m'n klanten en wist dus al snel waar te zoeken. Tnx voor het sharen!

Door Tweakers user Fore!, woensdag 29 juni 2016 13:36

Thnx voor de oplossing! Ik heb het probleem ook ondervonden en ook opgemerkt vanuit logfiles dat dit in eens "geweigerd" werd.

Fijn dat je dit deelt :)

Reageren is niet meer mogelijk