best practice OU admins

[simple.]

We hebben 3 locaties, en ieder had altijd zijn eigen server en admin.
nu zijn alle servers (win server 2012 r2) in hetzelfde domein geplaatst en staat op elke locatie een domain controller.
ik wil de domain admin blijven en alle policies bepalen ect.
wel wil ik op de 2 locaties waar ik niet kom een admingroep maken.
deze admingroep moet computers in het domein kunnen toevoegen, maar enkel in zijn eigen OU.
het moet niet zo zijn dat de admin van locatie 2 een computer toevoegt aan het domein, en de admin van locatie 3 die pc uit de folder "computers" haalt en deze in de OU van locatie 3 plaatst.

wat is de best practice om de computers die admin van locatie 3 toevoegt enkel in de OU van locatie 3 terecht te laten komen?

met een child domain zou ieder child domain zijn eigen admin hebben maar de best practice voor 1 bedrijf met meerdere locaties is juist 1 domein houden met verschillende OU's voor elke locatie.
maar hoe bereik ik toch een soortgelijk resultaat voor de OU?

[Oogje]

Google eens op Delegate OU Control

[Question Mark]

simple. schreef op vrijdag 2 maart 2018 @ 10:32:
met een child domain zou ieder child domain zijn eigen admin hebben maar de best practice voor 1 bedrijf met meerdere locaties is juist 1 domein houden met verschillende OU's voor elke locatie.

Waarom?

Wat is de exacte reden dat je scheiding van beheer wilt? Wat is er mis met meerdere beheerders met een gelijke rechtenset?

[Verwijderd]

Hij vertrouwt waarschijnlijk zijn eigen admins niet

[simple.]

Oogje schreef op vrijdag 2 maart 2018 @ 10:33:
Google eens op Delegate OU Control

natuurlijk al gedaan, deze post beschreef het heel mooi denk ik.

deze post benoemd echter mijn probleem, ik wil geen prestaged computer objects moeten aanmaken want dan kan ik het net zo goed zelf doen.

het zou wel fijn zijn als ze na het joinen door een delegated user ook meteen in de juiste OU terecht komen of alleen rechten hebben op die objecten om in hun OU te zetten. ik niet wil dat ze zomaar alle computers kunnen husselen tussen de verschillende OU's.

Question Mark schreef op vrijdag 2 maart 2018 @ 13:14:
[...]

Waarom?

Wat is de exacte reden dat je scheiding van beheer wilt? Wat is er mis met meerdere beheerders met een gelijke rechtenset?

de andere admins zijn "gewone gebruikers" (met IT kennis weliswaar) die uberhaubt niet meer rechten willen/nodig hebben.
zij willen alleen nog verantwoordelijk zijn voor alledaags beheer.

[Question Mark]

Wat is er mis met de default computers OU?

Een GPO kun je targetten aan een site, daar heb je geen OU's voor nodig. Standaard gebruikers hebben al rechten om computers aan het domein toe te voegen. Waar denk je tegenaan te lopen bij het gebruik van de default computers OU?

Maak het niet moeilijjker dan het hoeft te zijn. Met jouw randvoorwaarden (geen pre-staged objecten, en kennelijjk geen deploymenttooling) is dit de meest simpele oplossing.

[simple.]

ik organiseer computers in sub OU's voor deployment per functie van werknemers.
de default computers folder is daarom niet voldoende.
anders had het inderdaad niet nodig geweest.

[Killah_Priest]

Wat je anders zou kunnen doen : maak een OU aan voor nieuwe computers waarop je in ieder geval een basisset met je belangrijkste (niet afdeling specifieke) settings loslaat en stel met redircmp.exe dit in als standaard OU voor nieuwe computers.

Dan ben je er uiteraard nog niet helemaal, maar het zorgt in ieder geval wel voor wat meer controle.

Enne, je hoeft geen admin te zijn om een machine aan het domein te joinen, een user mag 10x een machine aan het domein joinen (dit is overigens te wijzigen). Wel moet je uiteraard local admin rechten op de machine hebben.

[ Voor 24% gewijzigd door Killah_Priest op 02-03-2018 19:47 ]

[Question Mark]

simple. schreef op vrijdag 2 maart 2018 @ 15:04:
ik organiseer computers in sub OU's voor deployment per functie van werknemers.

Kun je die userspecifieke instellingen dan niet beter kwijt in GPO's die applied worden op users?

Het lijkt mij sowieso handiger om computers in een organisatie zo algemeen mogelijk te houden. Dat maakt het roamen van medewerkers ook wat eenvoudiger.

[simple.]

Question Mark schreef op zaterdag 3 maart 2018 @ 19:45:
[...]

Kun je die userspecifieke instellingen dan niet beter kwijt in GPO's die applied worden op users?

Het lijkt mij sowieso handiger om computers in een organisatie zo algemeen mogelijk te houden. Dat maakt het roamen van medewerkers ook wat eenvoudiger.

Als het via GPO wel kan doe ik dat net zo graag.
Ik ben het met je eens dat de computers algemeen moeten zijn, maar ik moet echter wel 3 groepen houden vanwege software installer GPO's.
voor het roamen is het geen probleem want de functies en werkplekken verschillen dus die roamen niet tussen elkaar.

wat ik eigenlijk zou willen is dat ik per OU admin kan aanwijzen in welke folder, de door hem gejoinde computers heen gaan in de AD.

[Question Mark]

simple. schreef op maandag 5 maart 2018 @ 09:30:
[...]
wat ik eigenlijk zou willen is dat ik per OU admin kan aanwijzen in welke folder, de door hem gejoinde computers heen gaan in de AD.

Het enige wat kan is met delegation of control een medewerker rechten geven om dit te mogen in de juiste OU. Als de medewerker dan een computer domainjoined met de commandprompt (ipv de gui) kan een OU opgegeven worden.

https://technet.microsoft...ry/cc776879(v=ws.10).aspx

code:

netdom add/d:devgroup.example.com mywksta /OU:OU=Dsys,OU=Workstations,DC=microsoft,DC=com

Da's de enige optie die je hebt.

Persoonlijk zou ik overigens nog steeds alle pc's in één OU gooien, en met GPO targetting gaan werken...

[simple.]

Question Mark schreef op maandag 5 maart 2018 @ 09:59:
Persoonlijk zou ik overigens nog steeds alle pc's in één OU gooien, en met GPO targetting gaan werken...

Wat is het voordeel hier van?
Mijn idee is juist dat ik, en de admins op locatie nu meer overzicht houden.

[Question Mark]

Het voordeel is dat je geen rekening meer hoeft te houden welke pc in welke OU geplaatst moet gaan worden.

GPO's voor een werkplek kun je koppelen aan een site. PC's op lokatie A krijgen dan de GPO's voor site A, PC's op lokatie B krijgen dan automatisch de GPO's voor site B.

Dat werkt dan allemaal automatisch, zonder dat je er over na hoeft te denken. Hou het zo simpel mogelijk.

Dat is ook de best practice vanuit Microsoft:

https://technet.microsoft...ary/2008.05.oudesign.aspx

There are three key principles regarding Group Policy, delegation, and object administration that can help guide your design decision. These principles can be summed up with three questions you should ask yourself that will help to ensure the OU structure you are creating will stand the tests of time and organizational change:

• Does this OU need to be created so a unique Group Policy Object (GPO) can be applied to it?
• Does a particular group of administrators need to have permissions to the objects in this OU?
• Will this new OU make it easier to administer the objects within it?

If the answer to any of these questions is "yes," then you should probably create the OU. If the answer to all three questions is "no," then you should rethink the layout and determine whether a different design might create a better fit.

OU's moet je alleen maar aan gaan maken als ze je helpen. Gelet op jouw case, wil je onderscheid kunnen maken op lokatie voor het kunnen toekennen van een GPO. Daar kun je ook je sites voor gebruiken, en heb je dus geen OU's voor nodig.

[Verwijderd]

Kan je niet instellen bij een OU, managed by en dan vervolgens iemand selecteren die alleen in die OU computers mag wijzigen?

Ik vind je indeling en principe maar omslachtig. ik geef je het advies om te targetten met GPO(meer beheerwerk), scripten(is op begin veel werk, maar dan zijn de pc's een stuk sneller met opstarten) en werken volgens AGDLP principe.