Let op: Tweakers stopt per 2023 met Tweakblogs. In
dit artikel
leggen we uit waarom we hiervoor hebben gekozen.
Warning! Groepsbeleid wordt niet meer toegepast sinds 14 juni 2016 door security-update
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
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
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
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:
in de usercontext uitgevoerd. Wat blijkt, volgens het rapport heeft de user schijnbaar geen rechten op het zojuist aangemaakte groepsbeleid.1
| Gpresult /h report.html /f |
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
Met credits voorTo 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.
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
12-'14 Logmein & Teamviewer Alternatief: Screenconnect
Reacties
Weer mooi opgelost Raymond! 
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?
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?
Dit blijft zo:itlee schreef op woensdag 22 juni 2016 @ 21:50:
maar, de hamvraag, blijft dit nu zo? of is dit een tijdelijke fout van MS?
This by-design behavior change protects customers’ computers from a security vulnerability.
@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
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]
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
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
[Reactie gewijzigd op woensdag 22 juni 2016 23:12]
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.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.
In het algemeen; best kwalijk dat mensen/admins dus blijkbaar klakkeloos WindowsUpdates doorvoeren zonder te lezen wat ze nou daadwerkelijk doen.
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.
@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!
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]
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).
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).
@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.
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]
Dit probleem is al vrij oud.. sinds Windows Server 2008 geven wij authenticated users read rechten op een GPO.
@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.
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.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.
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.
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.
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!
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
Fijn dat je dit deelt
Reageren is niet meer mogelijk