[Active Directory] Template users

[BlakHawk]

We willen sneller en efficienter werken, tja wie niet?
Maar voor systeembeheerders zijn dit toch wel "keywords".

Het gaat hier namelijk om een wat grotere complexere omgeving. Dan is er denk ik redelijk wat tijdswinst te behalen uit het aanmaken van users door middel van template users. Het zaql er ook beheerbaarder van worden denk ik.

Maar goed we deden hier nog niets mee in het verleden en willen het nu gaan toe passen.
Dan lopen we wel tegen een aantal vragen op. In principe is het idee vrij simpel... Je maakt een template user voor verschillende groepen en vervolgens copy je die user en klaar is kees.
Maar hoe ga je om met een groot aantal afdelingen en per afdeling wel weer dezelfde type users?
Is hier een bepaalde standaard voor?

Eigenlijk willen we een aantal users als template en dan volgens de afdelings ou andere afdelingsafhankelijke zaken regelen. Is dit slim?

Heeft iemand tips of zaken waar we zeker rekening mee moeten houden?

[Tags NL]

Het werken met templates heeft bepaalde voordelen, maar het is niet perfect. Je kunt een groot aantal dingen regelen door groepen en instellingen in het template te stoppen, bijvoorbeeld:

- Groepen voor afdelingsdirectory's
- Groepen voor applicties
- Distributiegroepen
- Home en Profilepath met %username% in het template
- Locatie en telefoonnummer

Maar je kunt het template bijvoorbeeld niet gebruiken om automatisch Terminal Services profilepaden in te stellen, dat kun je dan beter via een Group Policy doen.

Je zou dan per afdeling een aantal standaard templates kunnen aanmaken, een normale gebruiker en een senior gebruiker ofzo. Een template maken voor een manager heeft niet zoveel nut denk ik, er zal maar een manage per afdeling zijn.

Nadelen vindt ik van templates is dat je altijd uitzonderingen hebt, een nieuwe medewerker die bijna helemaal in het standaard profiel valt en d.m.v een template kan worden aangemaakt en daarna alsnog van een paar groepen extra lid moet worden. (Terwijl de andere gebruikers die ook door dat template zijn aangemaakt die juist niet mogen hebben.)

Al met al kan het in je voordeel werken, maar voorkom wildgroei anders verliest het concept zijn kracht gelijk...

[BlakHawk]

-={Fred_Perry}=- schreef op maandag 05 januari 2009 @ 11:29:
Al met al kan het in je voordeel werken, maar voorkom wildgroei anders verliest het concept zijn kracht gelijk...

Ja inderdaad, om deze reden willen we eigenlijk per type gebruiker een template maken, omdat hier zo veel afdelingen zijn.

Het gaat om een ziekenhuis.
Je hebt dus erg veel afdelingen, en iedere afdeling heeft wel een arts.

Denk zelf dat het een beter idee om één user template arts te maken en deze niet per afdeling aan te maken, maar gewoon een algemeen account. Verdere afdelingsettings vervolgens via ou/gpo te laten verlopen.

[Tags NL]

dfrenner schreef op maandag 05 januari 2009 @ 11:38:
[...]


Ja inderdaad, om deze reden willen we eigenlijk per type gebruiker een template maken, omdat hier zo veel afdelingen zijn.

Het gaat om een ziekenhuis.
Je hebt dus erg veel afdelingen, en iedere afdeling heeft wel een arts.

Denk zelf dat het een beter idee om één user template arts te maken en deze niet per afdeling aan te maken, maar gewoon een algemeen account. Verdere afdelingsettings vervolgens via ou/gpo te laten verlopen.

Ik zou een template per afdelings-arts maken, ik neem aan dat elke afdelings-arts specifieke rechten nodig heeft om bestanden te kunnen delen met de rest van zijn afdeling?

Via een GPO kun je een hoop dingen regelen qua instellingen, maar rechten kun je niet via een OU laten lopen. Ik bedoel daarmee dat als je een gebruiker in OU Balie medewerkers ofzo stopt, dat die medewerker dan niet ineens rechten heeft op de afdelingsdirectory Balie medewerkers op de Fileserver en niet automatisch rechten heeft op een bepaalde mailbox in Exchange. Je zal toch met groepen moeten blijven werken en zoveel mogelijk van die standaardgroepen in een Template stoppen om het jezelf makkelijk te maken...

Misschien snap ik niet helemaal hoe het in een ziekenhuis werkt qua autorisatie en rollen?

[ Voor 3% gewijzigd door Tags NL op 05-01-2009 11:49 ]

[pennenlikker]

Ik zou het zeker doen, heb zelf stage gelopen bij een netwerk met ongeveer +-3000 gebruikers en deze wilde net met zo'n script gaan beginnen.
Het spaart je helpdesk/systeembeheer een hele hoop tijd uit, en nog belangrijker het haalt een heleboel menselijke fouten eruit.
Ik heb hier met nog twee man toen een plan van aanpak voor geschreven, en er komt echt erg veel bij kijken als je veel verschillende afdelingen hebt met rechten en toegewezen scripts en email adressen en noem het maar op.

Wat ik wel zou doen is het door iemand laten doen die of erg goed kan scripten, of van een externe partij zo'n soort product kopen, echt waar dat spaart je geld
De systeembeheerder daar dacht ook even een script te typen, maar er komt erg veel bij kijken en gaat erg veel tijd in zitten als je niet dagelijks script.
Hij is er meer als een maand mee bezig geweest om voor alle afdelingen en alle variabelen een goed script te maken.

En het belangrijkste goed plannen, goed documenteren, en goed testen voor je het in productie zet.

[To_Tall]

Ik werk voornamelijk meet aa_ICT aa_verkoop aa_afdelingsnaam enz.

Deze user zit standaard in de juiste OU, met de juiste GPO's ook bepaalde standaard rechten zijn hierin al verwerkt.

Maar vaak wordt verteld graag een nieuwe gebruiker instellen met dezelfde als gebruiker B.
Dan is het heel simple om zo'n account te kopieeren. Alleen Naam en NAW gegevens invullen. Aantal rechten nog controleren. en zorgen dat het default corp user profile geladen wordt.

[Anoniem: 57365]

een template user(s) is een goede manier om rechten uit te delen. Maar beter is omRBAC (role based access; term doet het goed bij managers ) geimplementeerd te hebben. Hier zal je goed over na moeten denken. Als je dit geimplementeerd hebt, dan kan je template users gebruiken of nog mooier via een website (producten als netiq of quest zijn hier goed in) gebruikers aanmaken. En zover bent kan je nog een stap verder gaan. Een hr medewerker voert een nieuwe gebruiker op in SAP oid en van daaruit wordt de gebruiker in AD gemaakt op basis van zijn naam en functie, locatie etc.

Voor specifieke rechten, bijv. een share voor een project, kan je de projectleider aanstellen als beheerder. Hij kan rechten uitdelen/afnemen via een website (hij heeft dus alleen rechten via de applicatie/website). Dit is een win-win voor het beheer en het bedrijf. Rechten worden snel gezet (ze moeten het immers zelf doen) en de verantwoordelijkheden voor een share/resource liggen bij iemand die daadwerkelijk verantwoordelijk is, waardoor wildgroei in rechten minder voorkomt of tenminste bij verantwoordelijken voor de data ligt.

eerste stap is in ieder geval een goed RBAC plan (definieer functies en hun rechten. kijk daarna hoe dat het slimste is om om te zetten in een OU structuur en groepen) maken.

vb. citrix farm voor gebruikers.
3 functies (roles):
- admins
- console gebruikers
- specifieke applicatie gebruikers.

applicaties:
- console
- ms-office
- applicatieX
- algemene share voor applicatieX
- share voor console gebruikers

maak een groep voor elke applicatie een groep met daarin zoveel mogelijk rechten.
console_groep met rechten op: "share voor console gebruikers", "console"
ms-office_groep met rechten op de office applicaties
applicatieX_groep met daarin: applicatieX rechten en de share

vervolgens profielen voor de verschillende gebruikers
admins_profile (ook een groep): local admins citrix servers/domain admins, console_groep, ms-office_groep, groep_applicatieX
console_profile: console_groep, ms-office_groep, applicatieX_groep
applicatieX_profile: applicatieX_groep (dit lijkt onzinnig, maar voor de eenduidigheid zou ik dit zeker doen).

En tot slot de gebruikers koppelen aan de juiste profielen. Elke gebruiker heeft dus 1 profiel (zit in 1 groep + users). En aan dit profiel hangen direct de juiste rechten. (door dat het behoorlijk simpel is, kan je aan een functie van iemand een profiel koppelen en dus dat verder automatischer, zodat vanuit een hr tool de gebruiker aangemaakt kan worden).

Wat verder erg belangrijk is, om slechts een paar mensen admin te maken die de profielen mogen beheren. Zij moeten het concept dan ook goed snappen. Hoe meer mensen dit beheren hoe onoverzichtelijker het wordt.

btw, ik heb hier geen OU gebruikt, maar het wel handig om profiel groepen en "applicatie" groepen in aparte OU's te zetten. Gebruikers per functie/afdeling/locaties in groepen zetten (zodat ook andere policies mogelijk zijn). Oftewel je kan het zo gek maken als jezelf wilt, maar probeer het zo simpel mogelijk te maken voor beheer.
OU structuur hoeft ook helemaal niet te lijken op de organisatie, het is bedoeld voor beheer, niet om de organisatie structuur na te bouwen. Dus als 5 afdelingen/locaties exact dezelfde policies hebben, dan hoef je ook geen aparte OU's daarvoor te maken.

[ Voor 45% gewijzigd door Anoniem: 57365 op 05-01-2009 14:57 ]

[BlakHawk]

Denk inderdaad toch dat het dan makkelijker is om het helemaal per afdeling te gaan indelen.
Is er ook een manier om andere users aan te maken met een soort wizard?

Ik wil een dergelijke user en dan vraagt hij gewoon een aantal gegevens?
Bestaat hier software voor?

[Anoniem: 57365]

dfrenner schreef op maandag 05 januari 2009 @ 14:34:
Denk inderdaad toch dat het dan makkelijker is om het helemaal per afdeling te gaan indelen.
Is er ook een manier om andere users aan te maken met een soort wizard?

Ik wil een dergelijke user en dan vraagt hij gewoon een aantal gegevens?
Bestaat hier software voor?

netiq en quest noemde ik hierboven al. Vergis je echter niet, dit werkt via een website, maar op de achtergrond draaien scripts om de gebruikers aan te maken. Die scripts zal je wel zelf moeten maken. Het voordeel is echter dat je verder kan gaan met delegatie, zonder dat men daadwerkelijk rechten heeft op je AD (de quest/netiq applicatie heeft die rechten en alleen in die applicatie delegeer je).