User policies voor client worden toegepast op DC

[Eagle Creek]

Hi!

Ik begin met een aantal screenshots om het ontwerp van het (test)netwerkje te tonen.








1 x Server
- DC
- DHCP/DNS

3 testclients.
- Win 7

1 testuser
- Deze user is domain admin.

----------------------------

Wat ik dacht:
Ik heb de computers die policies moeten krijgen in de OU "desktops" geplaatst, en de users in de OU "Users".

Testuser1 meld zich aan op een testclient, ontvangt z'n policies en alles hobbelt prima zoals het moet.

Echter: testuser1 is een domain admin, en kan zich derhalve aanmelden op de server. Testuser deed dit, en ontving zijn policies: en werd software geïnstalleerd op de server, en diverse instellingen op het profiel toegepast. Dit verraste mij. De server waarop de user zich aanmeldde staat namelijk helemaal niet in een OU om instellingen te ontvangen.

Betekent dit dat een policy toegepast op een user ALTIJD voor die user geldt, ongeacht welke pc (server of client) hij zich aanmeldt?

[Appel]

Eagle Creek schreef op zondag 27 december 2009 @ 22:39:
Betekent dit dat een policy toegepast op een user ALTIJD voor die user geldt, ongeacht welke pc (server of client) hij zich aanmeldt?

Ja.

Daarom gebruikt ik ook voor het inloggen op servers andere accounts, gewoon een simpel account aanmaken waar geen policies op toe worden gepast die voor normale gebruikers bedoelt zijn. Zo krijg je geen vervuiling van de servers.

[ Voor 31% gewijzigd door Appel op 27-12-2009 22:52 ]

[alt-92]

..of je filtert het uit met een WMI filter bijvoorbeeld op OS.
Maar het makkelijkste is inderdaad om je useraccounts netjes in te zetten, en niet teveel met de builtin users te hannesen.
Dus laat je de builtin Administrator lekker in de standaard Users container staan waar normaal geen GPO's aan vast te hangen zijn buiten de standaard overerving van de Default Domain(wide) Policy en maak je een admin useraccount aan die alleen de benodigde rollen/rechten krijgt.

[Eagle Creek]

Aha. Dit dacht ik ook alwel, maar iemand anders zei tegen mij dat dit niet zo werkte, vandaar mijn twijfel.

Dit betekent dan dus ook dat wanneer ik op een server ander gedrag wil hebben dan op een cliënt, dit niet kan doen (lees: zonder WMI-filter). Ik dacht eigenlijk dat dit per GPO geregeld was.

Zo krijg je geen vervuiling van de servers.

Inderdaad, want dat is de bedoeling niet. Sowieso wil ik op een Terminal Server een heel andere set voorkeuren dan op een laptop, bijvoorbeeld.

Sowieso is het niet mijn bedoeling om uiteindelijk met domain admins op een client te gaan werken, maar voor een testsituatie is het goed dat het bovenkomt.

Builtin accounts laat ik sowieso altijd links liggen. Zo heb je ook iets om op terug te vallen mocht een andere admin (om welke reden dan ook) niet meer bruikbaar blijken .

Thanks heren .

[Mike2k]

Uhh...hoe is het screenshot verduidelijkend als je alles zwart maakt (ondanks dat dat absoluut geen nut heeft)

Verder: je gebruikt, zoals LzpAppel al lichtjes aanstiptte, NOOIT gewone user accounts als domain admins.
Domain admins en users gooi je in een aparte OU zodat je op de OU een policy toe kan passen.

Domain admins heb je altijd nodig voor als je je users een restricted account geeft die bijv geen software mag installeren.

Domain admin accounts krijgen meestal een prefix om aan te geven dat het domain accounts zijn.
Bijv: adm_user of admuser of verzin zelf wat...

Met gewone users als domain admins ben je ook niet SOX compliant...
Wikipedia: Information technology controls

[Eagle Creek]

[b][message=33173126,noline]Domain admins heb je altijd nodig voor als je je users een restricted account geeft die bijv geen software mag installeren.

Domain admin accounts krijgen meestal een prefix om aan te geven dat het domain accounts zijn.
Bijv: adm_user of admuser of verzin zelf wat...

Met gewone users als domain admins ben je ook niet SOX compliant...
Wikipedia: Information technology controls

Zoals ik zei (en ook zichtbaar is in de screenshot) eindigen administratieve accounts met de suffix "adm". Het is zeker niet mijn bedoeling om adm-accounts in te zetten voor dagelijks gebruik.
Evenwel is dat wel in de huidige test set-up het geval, en daarbij kwam mijn vraag aan het licht. Dezelfde vraag had er geweest wanneer een niet-adm account zich aangemeld had op een client, en daarna op een server. Toevallig kwam deze situatie nog niet eerder aan bod.

Wat betreft het "uitvlakken": die naamgevingen heeft niemand wat mee van doen, en het is op deze manier nog duidelijk genoeg denk ik. Enkel sommige OU-toepassingen mogelijk niet, maar gezien de antwoorden hoefde ik dat verder niet toe te lichten .

[Eagle Creek]

Over WMI-filters gesproken: in de situatie dat adm-accounts sowieso gescheiden zijn (en dat zijn ze in het uiteindelijke ontwerp, don't worry ), dan kan ik ook met behulp van de Security Filtering van de group policy zelf de adm-groep eruit filteren lijkt me (i.p.v. authenticated) .

[ Voor 4% gewijzigd door Eagle Creek op 28-12-2009 01:45 ]

[Oogje]

Mike2k schreef op maandag 28 december 2009 @ 01:33:
Met gewone users als domain admins ben je ook niet SOX compliant...
Wikipedia: Information technology controls

SOX zou echt het laatste zijn waar ik me druk over zou maken, been there done that. Common sense zouden ze eens moeten invoeren

[alt-92]

CS 2.0 heeft een LUA bug