Active directory group policy

[Yarisken]

Beste,

In onze AD zitten wij met een OU structuur voor users gebaseerd op regio. Dus alles users van 1 regio zitten samen in 1 OU.
Nu is er een externe firma gekomen voor een windows 10 deployment project en die hebben onze baas ingefluisterd dat we beter werken met een OU structuur gebaseerd op functie. Dus bv alle sales mensen in 1 OU etc... .
Wij hebben hier maandag meeting over.
Ik kan niet echt een nuttig argument verzinnen waarom we dit zouden omschakelen. Enkel voor hun windows 10 deployment policy's dat deze sneller worden ingevoerd op de laptop / desktops omdat er geen query dient te gebeuren in een OU op bv het functieveld.

Volgens deze firma is het de best practice van MS om dit zo te doen en werken de meeste firma's zo.
Is dit werkelijk zo bij jullie ook ? Zijn er nog meer voordelen die ik nu niet zie ?

[Meekoh]

It depends
Er zijn meerdere wegen naar Rome.
Het maakt niet zo denderend veel uit wat je kiest, als je maar goed kunt beargumenteren waarom je daarvoor kiest. Even een voorbeeldje van een retailer waar ik mee te maken heb gehad.
Daar hadden we OU's op basis van het soort locatie waar men werkte. Dit had meer te maken met het feit dat we bepaalde dingen anders geregeld wilden hebben voor bijv. Hoofdkantoor computers en computers in het distributiecentrum of de winkels. Dit zou je ook kunnen scheiden met WMI query's, maar dat is iets trager.

Draai de vraag dus eens om? Waarom heb je een structuur op basis van Regio? Is er daadwerkelijk een verschil in beleid per Regio?

edit: Ik ben trouwens niet vaak een structuur tegen gekomen met Functies van users als OU. Dat zit meestal verwerkt in groepen. Want op basis van de functie wil je ook bijv. een user toegang geven tot een bepaalde applicatie. Dat werkt niet als je alleen scheid op OU, ACL's werken niet op basis van in welke OU je zit. Wel je groepslidmaatschappen.

[ Voor 25% gewijzigd door Meekoh op 22-04-2016 11:43 ]

[Jazzy]

Volgens deze firma is het de best practice van MS om dit zo te doen en werken de meeste firma's zo.

Dit is absolute onzin en diskwalificeert degene die deze uitspraak gedaan heeft als deskundige op dit gebied.

Er zijn grofweg drie redenen om voor een bepaalde structuur te kiezen:
- Toepassen van een GPO op OU basis (OU voor werkstations, OU voor gebruikers, aparte OU voor terminal servers, etc.)
- Gebruik van Delegation of Control (helpdesk van een bepaalde afdeling alleen rechten geven op de gebruikers van hun eigen afdeling)
- Overzicht (snel een object kunnen vinden doordat je een OU per locatie, object type, etc. hebt)

Er is geen bepaalde standaard om dit in te richten. Sterker nog, er zijn hele grote organisaties die alle user accounts gewoon in de default Users container hebben staan. Dus als de huidige manier voor jullie werkt dan is dat prima, dit is simpelweg niet iets wat je goed of fout kunt doen.

Deze firma moet wel met ijzersterke argumenten kunnen komen als ze jullie willen bewegen om je structuur te veranderen zodat zei één of ander filter niet hoeven te gebruiken.

[Yarisken]

Jazzy schreef op vrijdag 22 april 2016 @ 11:37:
[...]

Dit is absolute onzin en diskwalificeert degene die deze uitspraak gedaan heeft als deskundige op dit gebied.

Er zijn grofweg drie redenen om voor een bepaalde structuur te kiezen:
- Toepassen van een GPO op OU basis (OU voor werkstations, OU voor gebruikers, aparte OU voor terminal servers, etc.)
- Gebruik van Delegation of Control (helpdesk van een bepaalde afdeling alleen rechten geven op de gebruikers van hun eigen afdeling)
- Overzicht (snel een object kunnen vinden doordat je een OU per locatie, object type, etc. hebt)

Er is geen bepaalde standaard om dit in te richten. Sterker nog, er zijn hele grote organisaties die alle user accounts gewoon in de default Users container hebben staan. Dus als de huidige manier voor jullie werkt dan is dat prima, dit is simpelweg niet iets wat je goed of fout kunt doen.

Deze firma moet wel met ijzersterke argumenten kunnen komen als ze jullie willen bewegen om je structuur te veranderen zodat zei één of ander filter niet hoeven te gebruiken.

Thx voor de reply's. Wel de voornaamste reden waarom we deze structuur gebruiken is dat we zo makkelijk de gebruikers terugvinden ( gewoon zien welke regio iemand zit en niet extra navragen welke functie bv ).
Ook algemene aanpassingen zoals wijziging adres / telefoon etc... kan makkelijk in de AD console gedaan worden en dat moeten we dan niet scripten. Als we op functie zouden nemen dan hebben we ook x3 het aantal ou's.
Thx voor de munitie, het gaat leuk worden maandag.

[Jazzy]

Mag ik aanschuiven?

Maar serieus, ik zou de discussie snel van tafel vegen als ik jullie was. En zorg dat je heel scherp bent in de rest van het traject. Als ze uitspraken over AD doen die niet helemaal blijken te kloppen dan is de kans groot dat ze op andere gebieden ook niet al te sterk zijn. Schroom in ieder geval niet om ze te blijven challengen, de discussies die daaruit volgen zijn altijd zinvol, ongeacht of de uitkomst er door veranderd.

Edit: Nog even inhoudelijk trouwens, maar er zijn natuurlijk allerlei alternatieven om te filteren of te selecteren en die zijn nog veel flexibeler ook. Denk bijvoorbeeld aan groepslidmaatschap, een object kan wel lid van meerdere groepen zijn maar niet in meerdere OU's geplaatst worden. Een andere optie is het gebruik van custom atributes, ook heel flexibel.

[ Voor 28% gewijzigd door Jazzy op 22-04-2016 11:51 ]

[Yarisken]

Jazzy schreef op vrijdag 22 april 2016 @ 11:49:
Mag ik aanschuiven?

Maar serieus, ik zou de discussie snel van tafel vegen als ik jullie was. En zorg dat je heel scherp bent in de rest van het traject. Als ze uitspraken over AD doen die niet helemaal blijken te kloppen dan is de kans groot dat ze op andere gebieden ook niet al te sterk zijn. Schroom in ieder geval niet om ze te blijven challengen, de discussies die daaruit volgen zijn altijd zinvol, ongeacht of de uitkomst er door veranderd.

Probleem is dat onze baas meer de mening van een externe consultant vertrouwd dan die van mij en mijn collega. Da's interne keuken maar dat is een zwaar gevecht van tijd tot tijd en niet enkel met AD group policies.

[eheijnen]

Wat geven zij aan welke voordelen eraan verbonden zijn aan een omschakeling ?
Wat gaat het kosten ?
Hoevel users hebben jullie in totaal ?

[Meekoh]

En wat leesvoer van MS: https://technet.microsoft...ine/2008.05.oudesign.aspx
Wel een beetje oud, maar nog best relevant.

Edit: Zoals Jazzy ook al aangaf, scheiden op basis van Functie is niet perse een MS best practice.
Het is best practice om een wel overwogen ontwerp te maken op basis van je requirements.

[ Voor 41% gewijzigd door Meekoh op 22-04-2016 11:59 ]

[Jazzy]

Yarisken schreef op vrijdag 22 april 2016 @ 11:52:
Probleem is dat onze baas meer de mening van een externe consultant vertrouwd dan die van mij en mijn collega. Da's interne keuken maar dat is een zwaar gevecht van tijd tot tijd en niet enkel met AD group policies.

Dat begrijp ik en in theorie heeft een consultant natuurlijk meer kennis en ervaring doordat hij gespecialiseerd is. Maar de praktijk is helaas dat niet alle consultants van een even zwaar caliber zijn, maakt daarbij niet uit hoe bekend het bedrijf van naam is of hoeveel Microsoft competenties ze ook hebben.

Maar ook de betere consultants hebben hun valkuilen, doordat ze hun werk eigenlijk elke keer op dezelfde (volgens hun de beste) manier doen zijn ze soms star en gaan niet meer onbevangen aan een project van start.

Het is dus altijd goed om scherp te zijn als je met externen werkt en zeker niet blind op alles afgaan wat er gedeeld wordt. En discussies worden altijd gevoerd op basis van argumenten, als iemand volhoudt dat het 'zo hoort' of best practice is zonder de achterliggende argumenten te kunnen geven dan weet diegene er gewoon niet genoeg van af.

[Yarisken]

eheijnen schreef op vrijdag 22 april 2016 @ 11:53:
Wat geven zij aan welke voordelen eraan verbonden zijn aan een omschakeling ?
Wat gaat het kosten ?
Hoevel users hebben jullie in totaal ?

Wij hebben 800 users. Omzetten zal wel enkele uren duren.
Geen idee wat het kost.

Voordelen zijn voor de persoon intern hier , met heel beperkte kennis van group policy's, gewoon de group policy's op OU moet toepassen voor zijn windows 10 project. Als ik zeg van per policy een query in te stellen op een OU dan hoor ik het in Keulen donderen ... . Die doet helpdesk bij ons en heeft beperkte AD en GPO kennis. Nog een jong gastje :-). Samen met de externe consultant naar de baas gestapt om onze structuur te wijzigen. Die gaat bloeden maandag ....

[eheijnen]

Ik zou me nog even laten voorrekenen door hun wat jullie dat gaat besparen c.q. hoeveel onderhoud en de W10 implementatie daardoor goedkoper wordt. Kan best zijn dat ze dit voorstellen om meer omzet te draaien. Dat zou ik zeker controleren zodat je niet met een uit de hand gelopen implementatie komt te zitten.

Dan speelt nog de vraag of ze voldoende kennis van scripten hebben. Zo niet dan berust hun voorstel waarschijnlijk op het gebrek hieraan.

Daarnaast zou ik de boot nog even afhouden en offerte vragen / info inwinnen bij een of twee andere firma('s) om te kijken wat zij adviseren.

[Yarisken]

eheijnen schreef op vrijdag 22 april 2016 @ 12:18:
Ik zou me nog even laten voorrekenen door hun wat jullie dat gaat besparen c.q. hoeveel onderhoud en de W10 implementatie daardoor goedkoper wordt. Kan best zijn dat ze dit voorstellen om meer omzet te draaien. Dat zou ik zeker controleren zodat je niet met een uit de hand gelopen implementatie komt te zitten.

Dan speelt nog de vraag of ze voldoende kennis van scripten hebben. Zo niet dan berust hun voorstel waarschijnlijk op het gebrek hieraan.

Daarnaast zou ik de boot nog even afhouden en offerte vragen / info inwinnen bij een of twee andere firma('s) om te kijken wat zij adviseren.

We hebben hier een tijd geleden al een externe consultant gehad ( andere firma ) die onze AD structuur onder de loep had genomen en die had geen enkele opmerking. Enkel dat we security groepen en distributie groepen best apart lieten. Baas vond het omslachtig dat we met 2 aparte groepen zouden zitten voor mail en fileserver ..... kreeg hem niet overtuigd .... . Gelukkig is dit er wel doorgekomen.

[Verwijderd]

Jazzy schreef op vrijdag 22 april 2016 @ 11:37:
Dit is absolute onzin en diskwalificeert degene die deze uitspraak gedaan heeft als deskundige op dit gebied.

RBAC wordt is wel een erg bekende standard practice. Hoewel niet altijd even goed doorgevoerd, kan het wel degelijk een voordeel bieden. Dat het geen oplossing voor alle situaties is mag duidelijk zijn.

Dat mensen bij voorbaat al roepen dat het onzin zou vind ik dan ook wat sterk.

[Question Mark]

Yarisken schreef op vrijdag 22 april 2016 @ 11:31:
Volgens deze firma is het de best practice van MS om dit zo te doen en werken de meeste firma's zo.
Is dit werkelijk zo bij jullie ook ? Zijn er nog meer voordelen die ik nu niet zie ?

OU's gebruik je om je beheer goed te kunnen doen, denk dan aan zaken als Delegation of Control eenvoudig kunnen regelen, of om GPO's goed te kunnen targetten.

Er is geen vuistregel die voorschrijft hoe het moet, net zo min als dat er best practices voor zijn.

De enige regel die ik zelf hanteer is: "Keep it simple"....

Verder ontopic:

Het lijkt erop dat men user policy's op bepaalde werkplekken snel willen kunnen gaan targeten. Daar heeft MS loopback policy processing voor uitgevonden.

[eheijnen]

Yarisken schreef op vrijdag 22 april 2016 @ 12:23:
[...]


We hebben hier een tijd geleden al een externe consultant gehad ( andere firma ) die onze AD structuur onder de loep had genomen en die had geen enkele opmerking. Enkel dat we security groepen en distributie groepen best apart lieten. Baas vond het omslachtig dat we met 2 aparte groepen zouden zitten voor mail en fileserver ..... kreeg hem niet overtuigd .... . Gelukkig is dit er wel doorgekomen.

En anders haal je die (eerdere) externe consultant er nog even bij in die gesprekken met hun.
Ik zou ze nog eens goed aan de tand voelen hierover.

En nog een artikel over distribution-groups:
https://technet.microsoft...c781446%28v=ws.10%29.aspx

Als je met deze zaken wat moeite hebt zou ik me wat meer inlezen of een self-paced training doen over AD die aansluit bij jullie server-platform

[ Voor 16% gewijzigd door eheijnen op 22-04-2016 12:39 ]

[Meekoh]

Verwijderd schreef op vrijdag 22 april 2016 @ 12:24:
[...]

RBAC wordt is wel een erg bekende standard practice. Hoewel niet altijd even goed doorgevoerd, kan het wel degelijk een voordeel bieden. Dat het geen oplossing voor alle situaties is mag duidelijk zijn.

Dat mensen bij voorbaat al roepen dat het onzin zou vind ik dan ook wat sterk.

Dat word ook niet beweerd
Echter een OU structuur op basis van functies heb je niet perse nodig om RBAC te implementeren.
RBAC prima, maar stellen dat een OU structuur op basis van Functie groepen een MS best practice is vind ik op zijn minst twijfelachtig.

[Jazzy]

Verwijderd schreef op vrijdag 22 april 2016 @ 12:24:
[...]

RBAC wordt is wel een erg bekende standard practice. Hoewel niet altijd even goed doorgevoerd, kan het wel degelijk een voordeel bieden. Dat het geen oplossing voor alle situaties is mag duidelijk zijn.

Dat mensen bij voorbaat al roepen dat het onzin zou vind ik dan ook wat sterk.

RBAC is een prima reden om voor een bepaalde OU-structuur te kiezen. Wat onzin is is om te stellen dat het best practice is om je OU-structuur in te delen op basis van functie en dat de meeste bedrijven het zo doen.

[Verwijderd]

Meekoh schreef op vrijdag 22 april 2016 @ 12:28:
Dat word ook niet beweerd
Echter een OU structuur op basis van functies heb je niet perse nodig om RBAC te implementeren.
RBAC prima, maar stellen dat een OU structuur op basis van Functie groepen een MS best practice is vind ik op zijn minst twijfelachtig.

Laat ik het zo zeggen: het klinkt alsof men het over RBAC heeft zonder dat die term expliciet genoemd is en misschien ook omdat mensen er eerder nog niet van gehoord hebben. Dan weet ik niet of de interpretatie zoals die hier staat het gevolg is van het niet goed kennen en interpreteren van RBAC, of omdat het externe bedrijf dat daadwerkelijk zo voorgesteld heeft

Het gaat over wat iemand anders weer iemand anders verteld zou hebben. Daar is nogal wat ruimte voor fouten in de interpretatie. Tel dat op bij dat verandering altijd eng is en ik weet niet zeker of dat waar we het hier over hebben ook is waar het over gaat.

[Jazzy]

Volgens mij heeft helemaal niemand het over RBAC, behalve jij.

[Verwijderd]

Jazzy schreef op vrijdag 22 april 2016 @ 12:41:
Volgens mij heeft helemaal niemand het over RBAC, behalve jij.

Het klinkt echter wel behoorlijk als RBAC, zeker als erbij verteld wordt dat het standard practice zou zijn en bij veel bedrijven gebruikt wordt. Dat hoeft uiteraard niet op basis van OU te gebeuren, maar omdat het hier mogelijk om een interpretatie van een interpretatie gaat, is niet helemaal duidelijk of dat ook het oorspronkelijke verhaal is. Nog even los van dat veel mensen OU's en groepen moeilijk weten te onderscheiden en dat verwarring tussen die twee niet ondenkbaar is.

Als de externe firma het inderdaad over RBAC heeft, dan zijn hun claims eigenlijk gewoon waar. Dan blijft de vraag over of men het nou daadwerkelijk over OU's heeft gehad.

[ Voor 3% gewijzigd door Verwijderd op 22-04-2016 12:49 ]

[Jazzy]

Laten we voor het gemak eens aannemen dat de TS zich niet vergist als hij het over de OU-structuur heeft. Zelfs als het achterliggende doel RBAC is (wel vreemd dat dit binnen de scope van een Windows 10 migratie valt) dan nog is het te kort door de bocht om te stellen dat het best practice is om OU's in te delen op functie. Want dan krijg je te maken met een collega die op Sales werkt maar eigenlijk ook voor Service, of de salesmanager die wel in Sales werkt maar wel toegang moet hebben tot die managementrapportagesoftware in tegenstelling tot de gewone stervelingen.

Anyway, conclusie is in ieder geval dat er niet één enkele best practice is en dat er dus eerst duidelijkheid over de argumenten moet zijn.

[Verwijderd]

Jazzy schreef op vrijdag 22 april 2016 @ 12:53:
dan nog is het te kort door de bocht om te stellen dat het best practice is om OU's in te delen op functie.

Ik heb hierboven al aangegeven dat het niet zaligmakend is en dat je bijvoorbeeld ook op groepsbasis kunt werken. Een beetje RBAC kan echter een aantal dingen wel een stuk makkelijker maken. Een hybride vorm kan namelijk ook gewoon.

Net zoals bij alle andere practices, termen en acroniemen (LEAN, AGILE, SCRUM) is het vooral een middel en geen doel. Zolang je dat maar in het oog houdt kan het je goed helpen zaken te stroomlijnen.

Jazzy schreef op vrijdag 22 april 2016 @ 12:53:
Want dan krijg je te maken met een collega die op Sales werkt maar eigenlijk ook voor Service, of de salesmanager

Dan stop je die persoon in beide groepen en werkt het zoals het hoort Het idee is dan ook dat je niet met losse rechten werkt, maar met grotere blokken.

[ Voor 22% gewijzigd door Verwijderd op 22-04-2016 13:00 ]

[Yarisken]

Het gaat hier puur over de OU structuur. RBAC staat hier helemaal los van :-).
Scope van windows 10 heeft hier niks mee te maken.

[ Voor 25% gewijzigd door Yarisken op 22-04-2016 13:21 ]

[Oogje]

Verwijderd schreef op vrijdag 22 april 2016 @ 12:58:
[...]

Dan stop je die persoon in beide groepen en werkt het zoals het hoort Het idee is dan ook dat je niet met losse rechten werkt, maar met grotere blokken.

Dat lukt je dus niet in je voorgestelde OU structuur op basis van RBAC, dat is juist t hele punt

[Verwijderd]

Oogje schreef op vrijdag 22 april 2016 @ 17:48:
Dat lukt je dus niet in je voorgestelde OU structuur op basis van RBAC, dat is juist t hele punt

Dat had ik hierboven al erkend, maar we raken een beetje off-topic

[sneep]

Je kunt overal een business case van maken. Ik zou niet alleen met kosten voor implementatie rekening houden maar ook met kosten voor beheer. Samengevat, als je bespaart op implementatiekosten door je te conformeren aan hoe je leverancier gewend is te werken en die besparing raak je vervolgens kwijt door hogere beheerskosten in de eerstvolgende jaren dan heb je het niet goed gedaan.
Sterker nog, focus je op beheersgemak en neem de eenmalige implementatiekosten voor lief ook al zijn die wat hoger. Je wilt als beheerder niet (dagelijks?) met een AD bezig zijn die niet past bij je organisatie.

[Jazzy]

Weet niet of de discussie overzichtelijker wordt als je er een businesscase van gaat maken op basis van kosten. Helemaal al niet als blijkt dat de onderliggende argumentatie zwak blijkt te zijn, en daar lijkt het tot nu toe wel op.

[Dennism]

Jazzy schreef op vrijdag 22 april 2016 @ 20:51:
Weet niet of de discussie overzichtelijker wordt als je er een businesscase van gaat maken op basis van kosten. Helemaal al niet als blijkt dat de onderliggende argumentatie zwak blijkt te zijn, en daar lijkt het tot nu toe wel op.

Overzichtelijker misschien niet, echter management overtuigen op puur technische gronden wanneer de personen op management management functies geen inhoudelijke kennis hebben wil nog wel eens lastig zijn, het kan dan erg handig zijn als je ook een kostenplaatje hebt dat voor jouw argument gunstiger uitpakt, die taal spreken ze namelijk allemaal vaak wel