[Active Directory] Beheren van Security Groups

[b00ster]

Beste Tweakers,

Ik ben al een tijdje opzoek naar de beste oplossing voor het inrichten en beheren van Security Groups binnen Active Directory op een Windows Server 2008 R2 netwerk.

Ik zou proberen de situatie zo goed mogelijk te schetsen zoals het beheer bij ons nu is ingericht. Wat de knelpunten en problemen zijn, en waar we heen willen.

We hebben een simpele fileserver (Windows Server 2003) die gebruikt wordt voor het opslaan van (afdeling) bestanden, profielen en persoonlijke mappen (homedrives).
We draaien een Windows Server 2008 R2 netwerk met Active Directory (één domein).
Binnen Active Directory Users & Computers worden rechten d.m.v. Security Groups vrij gegeven op de fileserver. Dit gebeurd met behulp van Domain Local Groups die op Share/NTFS niveau met rechten worden gedefinieerd.

Al groepsnamen hebben we een naamconventie die we aanhouden. Een voorbeeld hiervan is: “SG Afdeling ICT RW”. Dat simpelweg betekend een Securty Group (SG), die recht geeft op map “Afdeling ICT” met de rechten RW (Read+Write). Tevens wordt in de descriptie van de Security Groups het complete pad weer gegeven. Dat zou dus kunnen zijn: “Geeft RW recht op \\fileserver1\data\Afdeling ICT”.

We merken echter heel vaak dat medewerkers rechten nodig hebben voor hun werkzaamheden op sub, sub, submappen. Een voorbeeld hiervan is:
“H:\PZ\Map1\Sub1\Sub2\Sub3”
Waarbij de medewerker alleen mag lezen (R) of lezen en schrijven (RW) op map “Sub3”
En de overige mappen alleen maar listen (zien, “This folder only”).
Op zich werkt deze manier prima maar het zorgt voor extreem veel Security Groups in de Active Directory en op mapniveau (NTFS permissions).

We willen eigenlijk ernaar toe dat we Global Groups aanmaken per afdeling en Local Groups lid maken van de desbetreffende Global Groups en hiermee rechten verlenen. Per afdeling willen we dan een standaard opstellen van rechten die iedereen op die afdeling krijgt.
Echter blijven er altijd uitzonderingen komen en ik vroeg me af hoe andere mensen deze problemen oplossen. We zoeken dus een manier om duidelijk beheer in te richten voor Security Groups.

Gr b00ster!

[Question Mark]

b00ster schreef op woensdag 27 juli 2011 @ 10:10:
We willen eigenlijk ernaar toe dat we Global Groups aanmaken per afdeling en Local Groups lid maken van de desbetreffende Global Groups en hiermee rechten verlenen. Per afdeling willen we dan een standaard opstellen van rechten die iedereen op die afdeling krijgt.

Echter blijven er altijd uitzonderingen komen en ik vroeg me af hoe andere mensen deze problemen oplossen. We zoeken dus een manier om duidelijk beheer in te richten voor Security Groups.

De oplossing die je hier schetst heet RBAC (role based access control). Ik herken ook direct je probleem met uitzonderingen.

RBAC is een erg mooi principe, maar heeft als nadeel voor de gebruiker(s) dat het redelijk star is. Wat wij vaak proberen overeen te komen is om per afdeling twee rollen te defineren:

• "admin" afdeling X
• "user" afdeling X

Waarbij de "admin" rol wat meer kan en mag dan een reguliere user. Groot probleem blijft vaak dat medewerkers zeggen dat ze vaak niet uit de voeten kunnen met een generieke rechtenset.

Mijn conclusie is dan ook dat RBAC goed kan werken in een organisatie waar medewekers vaak dezelfde taken hebben, maar dat het minder geschikt is voor dynamische organisaties waar medewerkers verschillende taken en verantwoordelijkeheden hebben.

[b00ster]

Klopt en daarom wil ik een soort van combinatie gaan toepassen, een verdeling van RBAC kan wel werken om afdelingen in ieder geval een standaard te geven. De uitzonderingen zijn dan een bijzaak, maar wel belangrijk omdat deze altijd zullen blijven. De organisatie is vrij dynamisch en dat zal ook wel zo blijven, daarom is het soms moeilijk om het systeem perfect in te delen voor simpel beheer...

[Red Cell]

Zeer herkenbaar inderdaad. De grap is dat dit bijna niet met techniek is op te lossen.

Ik geef vaak aan dat uitzonderingen (wat dit feitelijk zijn) een zeer slecht idee zijn.
Uitzonderingen worden vergeten, maken een chaos van je beveiligings structuur en nodigen alleen maar uit tot meer uitzonderingen. Vroeger of later heb je geen inzicht (hoe hard je ook probeerd) meer in waar mensen wel en geen toegang tot hebben. Als ik dit laatste vertel zijn mensen sneller geneigd om van uitzonderingen af te zien. Dan word vaak gekozen van ok geef hem dan maar "normale" toegang.
In andere woorden ik raad mijn klanten dringend af om uitzonderingen te gebruiken.

Het enigste wat je technisch kan doen is de shares fijnmaziger maken.
Als mensen op submappen van PZ aparte rechten moet hebben splits deze op in nieuwe shares. Op die manier blijf je vanaf je rootmap 2 security groups houden (R en RW)

Ja ik besef dat je maar zoveel shares kan hebben maar ik heb geen bedrijf gehad waar mensen meer dan 10 shares nodig hadden.

[b00ster]

Red Cell schreef op woensdag 27 juli 2011 @ 11:08:

Ik geef vaak aan dat uitzonderingen (wat dit feitelijk zijn) een zeer slecht idee zijn.
Uitzonderingen worden vergeten, maken een chaos van je beveiligings structuur en nodigen alleen maar uit tot meer uitzonderingen. Vroeger of later heb je geen inzicht (hoe hard je ook probeerd) meer in waar mensen wel en geen toegang tot hebben. Als ik dit laatste vertel zijn mensen sneller geneigd om van uitzonderingen af te zien. Dan word vaak gekozen van ok geef hem dan maar "normale" toegang.
In andere woorden ik raad mijn klanten dringend af om uitzonderingen te gebruiken.

Precies en een gedeelte van dat inzicht zijn een aantal collega's nu al kwijt. Daarom ben ik ook van mening dat de structuur en de rechtenopzet anders moet. Het beste is gewoon een nieuwe fileserver opzetten, maar dit is makkelijker gezegd dan gedaan...

Ik hoor trouwens graag van mensen hun ervaring van bedrijven, en hoe deze bedrijven tewerk gaan...

Gr b00ster

[Remco]

Wat ik vaak doe is groepen maken die terugslaan op de datastructuur.
Dus bijvoorbeeld de afdeling PZ heeft als groepsdata folder d:\data\pz
Dan worden zij lid van de groep NTFS-DATA-PZ. En deze groep geef ik dan rechten op d:\data\pz

Dan komt het natuurlijk voor dat binnen PZ niet iedereen op een bepaalde folder rechten mag hebben. De afspraak is dan dat men tot op 1 niveau diep uitzonderingen mag maken. Dus b.v. de afdeling salarisadministratie mag alleen in de folder d:\data\pz\salaris, en de andere leden van PZ niet.
Dan maak ik een groep NTFS-DATA-PZ-SALARIS en geef de betreffende leden de rechten.
Dieper dan dit niveau ga ik niet.

Dan heb je nog de uitzondering dat er samenwerkingsverbanden zijn tussen afdelingen. Bijv. financien en pz voor de uitbetaling van de lonen.
Voor dit soort verbanden, en ook andere projectmatige zaken maak ik bijvoorbeeld dit aan.
d:\data\projecten.
Onder deze map ga ik mappen maken met bijbehorende rechten. Bijvoorbeeld de samenwerking van financien en pz voor de lonen.
De folder wordt dan d:\data\projecten\pz_fin_lonen
En de bijbehorende groep NTFS-DATA-PROJECTEN-PZ_FIN_LONEN.
Dieper dan dat niveau worden er geen rechten verleend.

Eventueel zou je de groepen nog kunnen uitbreiden met een -WR of -RX mocht het zo zijn dat je veel read only users hebt op bepaalde folders.