[SBS 2008] Mapmachtigingen - Geverifieerde gebruikers?

[Anoniem: 296710]

Ik moet hier op het werk een server beheren en kan er wel een beetje mee overweg voor wat we nodig hebben. Tot voor kort had iedereen volledige machtigingen over de data share als ze de regels zouden respecteren. Aangezien we een klein kantoor zijn en dit mij werk zou besparen vond ik dit een goede keuze op dat moment. Nu blijkt dat niet alle regels gerespecteerd worden en nu wil ik de toegang tot bepaalde mappen beperken zodat ieder alleen kan wat hij eigenlijk maar zou mogen kunnen. (Had ik van in het begin moeten doen.) Alleen weet ik niet goed wat nu een goede manier is om te doen.

Wat ik al probeerde:

Op de server kan ik voor de data share alleen voor de aparte gebruikers de machtigingen instellen, en dit blijkt dus voor de gehele share te gelden, ongeacht extra machtigingen die ik instel op de mapjes apart. Dit lukt dus niet.

Als ik groepen aanmaak en iedereen toevoeg die tot een bepaalde groep behoor, dan kan ik de machtigingen instellen voor de verschillende groepen, alleen lukt het dan niet als iemand in 2 groepen zit en een van de groepen mag niet schrijven in een bepaalde map omdat de weigering voorang geeft. Ik moet deze weigering gebruiken omdat iedereen die inlogt blijkbaar geverifieerde gebruiker is en ik deze machtigingen blijkbaar niet kan wijzigen voor de share. Ik zou dus groepen moeten maken zoals niet-it maneger, maar dit lijkt me echt niet goed.

Ik denk dat als de geverifieerde gebruikers standaard alleen kunnen lezen, ik die groepen wel goed kan gebruiken door daar extra aan te duiden of ze mogen schrijven, maar ik weet echt niet of het een goed idee is om deze te wijzigen en waar ik dit dan moet doen.

Graag zou ik dus willen weten wat de aangeraden manier is om de mapmachtigingen in te stellen/beheren op een sbs 2008 server.

Alvast bedankt voor de hulp.

[barry457]

Zou beginnen om de default user rechten weg te halen.
2x groep aanmaken per afdeling. 1x read rechten en 1x write rechten.
Dit voor elke afdeling doen. en de personen in de correcte groep plaatsen.

[CMD-Snake]

barry457 schreef op maandag 17 december 2012 @ 10:30:
Zou beginnen om de default user rechten weg te halen.
2x groep aanmaken per afdeling. 1x read rechten en 1x write rechten.
Dit voor elke afdeling doen. en de personen in de correcte groep plaatsen.

Let wel dat als je de default read and write doet dat dit meteen vererft naar alle onderliggende mappen. Soms kan dat niet wenselijk zijn. Ik zou de permissies geavanceerd zetten zodat ze niet automatisch op alle onderliggende mappen komen te staan.

Vergeet niet om als je de groepen goed hebt er template users mee te maken in de SBS Console. Mocht er ooit iemand bij komen op een afdeling dan kan je snel een account laten aanmaken op basis van de template.

[Anoniem: 296710]

Wat word bedoeld met de default rechten? Deze die in te stellen zijn via de sbs console? Als ik deze wegdoe dan kan je helemaal niet meer op de data share. Het lijkt me dat de instellingen van de machtigingen die gemaakt worden via de sbs console altijd voorrang hebben en deze beslissend zijn, ongeacht wat ingesteld word in de mapeigenschappen? Alleen bij het aanduiden van weigeren van machtigingen in de mapeigenschappen kan ik de toegang beperken, maar dan moet ik rare groepen maken (zoals niet-it manager etc...) en kan ik personen niet in meerdere groepen gaan zetten.

[CMD-Snake]

Anoniem: 296710 schreef op maandag 17 december 2012 @ 15:07:
Wat word bedoeld met de default rechten? Deze die in te stellen zijn via de sbs console? Als ik deze wegdoe dan kan je helemaal niet meer op de data share. Het lijkt me dat de instellingen van de machtigingen die gemaakt worden via de sbs console altijd voorrang hebben en deze beslissend zijn, ongeacht wat ingesteld word in de mapeigenschappen? Alleen bij het aanduiden van weigeren van machtigingen in de mapeigenschappen kan ik de toegang beperken, maar dan moet ik rare groepen maken (zoals niet-it manager etc...) en kan ik personen niet in meerdere groepen gaan zetten.

Om te beginnen, ik merk uit je post dat je er weinig kennis van hebt. Dingen als rechten zetten zijn echt basis activiteiten voor beheerders. Mijn advies is om een bedrijf te vinden dat beheer doet voor het MKB bij jou in de buurt. Dat lijkt me veiliger en prettiger voor je. Blijf verder maar van de dingen af, voordat je onbedoeld iets om laat vallen.

Om je vraag toch enigzins te behandelen. Je haalt Share rechten en NTFS rechten door elkaar. Share rechten bepalen welke gebruikers de share kunnen benaderen en wat ze in de share kunnen doen. NTFS rechten bepalen wat je wel en niet kan doen in de onderliggende mappen. Deze rechten ken je doorgaans toe aan AD groepen.

Maar om terug te gaan naar de eerste alinea, zoek een professional die je kan helpen hierbij. Dat lijkt me veel beter.

[Killah_Priest]

CMD-Snake schreef op maandag 17 december 2012 @ 15:46:
[...]


Om te beginnen, ik merk uit je post dat je er weinig kennis van hebt. Dingen als rechten zetten zijn echt basis activiteiten voor beheerders. Mijn advies is om een bedrijf te vinden dat beheer doet voor het MKB bij jou in de buurt. Dat lijkt me veiliger en prettiger voor je. Blijf verder maar van de dingen af, voordat je onbedoeld iets om laat vallen.

Om je vraag toch enigzins te behandelen. Je haalt Share rechten en NTFS rechten door elkaar. Share rechten bepalen welke gebruikers de share kunnen benaderen en wat ze in de share kunnen doen. NTFS rechten bepalen wat je wel en niet kan doen in de onderliggende mappen. Deze rechten ken je doorgaans toe aan AD groepen.

Maar om terug te gaan naar de eerste alinea, zoek een professional die je kan helpen hierbij. Dat lijkt me veel beter.

Inderdaad, NTFS rechten zijn wel de basis voor beheer (hoewel ik soms nog wel beheerders tegenkom die het na jaren nog steeds niet snappen en uren aan het klooien zijn met een enkele share).

Sowieso is de grootste fout die gemaakt word door velen werken met share permissies ipv NTFS permissies gebruiken.
Meestal kan je de share permissies gewoon op everyone/full controll zetten aangezien je de rechten via de NTFS permissies beheert (most restrictieve gaat immers altijd voor).

[CMD-Snake]

Killah_Priest schreef op maandag 17 december 2012 @ 19:07:
[...]
Sowieso is de grootste fout die gemaakt word door velen werken met share permissies ipv NTFS permissies gebruiken.
Meestal kan je de share permissies gewoon op everyone/full controll zetten aangezien je de rechten via de NTFS permissies beheert (most restrictieve gaat immers altijd voor).

In SBS zal je alleen via Share permissie werken als je via de console gaat. Daar wordt je overigen toe gedwongen door het systeem. De console is ook een beetje een alles of niets geval.

NTFS rechten kan je dan achteraf aanmaken op de gebruikelijke manier. Een standaard user kan nog erg veel veranderen aan een map met zijn default rechten. Het is aan te bevelen om die NTFS permissies aan te passen.

[Anoniem: 296710]

De NTFS permissies kan ik maken, maar wat ik niet versta is dat het niet werkt wat ik overal lees. Normaal zou altijd de meest restrictieve permissies genomen worden. Dus op de share staat dat alle personen volledige toegang hebben tot alles in de share. Bij de NTFS permissies van een testmapje zet ik dan voor een gebruiker alleen lees en uitvoeren toegang, maar toch kan deze nog bestanden aanmaken. Waarom neemt hij niet de meest restrictieve?

[CMD-Snake]

Anoniem: 296710 schreef op dinsdag 18 december 2012 @ 14:28:
De NTFS permissies kan ik maken, maar wat ik niet versta is dat het niet werkt wat ik overal lees. Normaal zou altijd de meest restrictieve permissies genomen worden. Dus op de share staat dat alle personen volledige toegang hebben tot alles in de share. Bij de NTFS permissies van een testmapje zet ik dan voor een gebruiker alleen lees en uitvoeren toegang, maar toch kan deze nog bestanden aanmaken. Waarom neemt hij niet de meest restrictieve?

Is die test user dan nog lid van andere groepen? Standaard is iedereen lid bij SBS van de groep Domein\Users. Deze groep wordt op vrijwel elke map toegevoegd en heeft aardig veel rechten.

Als jouw test user lid is van die groep, naast de beperkte groep, dan kan hij toch veel meer.

Tevens kan je op een map een wizzard draaien dat je kan bepalen wat elke groep effectief kan doen. Heel handig als je moet expirimenteren met rechten.

[Anoniem: 296710]

Dus de groep Domein\Users heeft voorrang op al de andere permissies en dan geld de regel van de meest restrictieve niet?

Ik zie hier dat de groep Domein\Users alleen lees en uitvoer rechten hebben. Er is wel een andere groep aanwezig die wel schrijfrechten heeft: Geverifieerde gebruikers. Deze groep kan ik alleen weizigen op het niveau van de harde schijf. Dus ik vermoed dat deze groep op alles voorrang heeft?

Ik zal de wizard eens opzoeken en mee experimenteren.

[ Voor 6% gewijzigd door Anoniem: 296710 op 18-12-2012 16:57 ]

[CMD-Snake]

Anoniem: 296710 schreef op dinsdag 18 december 2012 @ 16:56:
Dus de groep Domein\Users heeft voorrang op al de andere permissies en dan geld de regel van de meest restrictieve niet?

Ik zie hier dat de groep Domein\Users alleen lees en uitvoer rechten hebben. Er is wel een andere groep aanwezig die wel schrijfrechten heeft: Geverifieerde gebruikers. Deze groep kan ik alleen weizigen op het niveau van de harde schijf. Dus ik vermoed dat deze groep op alles voorrang heeft?

Ik zal de wizard eens opzoeken en mee experimenteren.

De regel dat het meest restrictieve voorrang heeft is ook van toepassing in SBS, het is immers Windows Server 2008 die je hebt. Maar als een user lid is van meerdere groepen dan komt het complexer te liggen. Zeker als die groepen overlappende permissies bevatten.

Het beste is om een user dan zoveel mogelijk groepen te ontnemen en kijken wanneer iets niet meer lukt.

Let wel op dat je niet zomaar iets veranderd aan bepaalde systeem groepen, zoals die verifieerde gebruikers groep.

[Killah_Priest]

Als je zowel share als NTFS permissies (lees dit als conflicterende permissies)ergens op hebt staan dan werken de meest beperkende rechten.
Bij groeps lidmaatschap gaat dit niet echt op, een user kan immers lid zijn van meerdere groepen waarbij er geen conflict is qua permissies (tenzij je een deny op 1 van de groepen gooit terwijl een andere groep wel rechten heeft).

Hou er ook rekening mee dat als je een user lid maakt van een andere groep dat de user opnieuw in zal moeten loggen).

Controleer je overigens de rechten na een wijziging wel dmv het tabblad "Active permissions"?

[alt-92]

Most restrictive gaat alleen op voor overlap bij NTFS en Share permissies.
(omdat je SMB/Share de 'voordeur' is qua toegang).
Dus Share Read-only & NTFS Modify = effectief Read-only.

Als je alleen op NTFS Modify permissies én Read permissies aan dezelfde groep/user toekent dan zul je zien dat je effectieve permissieset de Modify set is.

Tenzij je weer met een expliciete Deny gaat werken, maar dat is een mijnenveld voor onervaren beheerders. Niet doen dus

De basisregel blijft echter: geef alleen die permissies die nodig zijn aan de groepen die nodig zijn.
Begin dus met de standaard Read & Execute set, en werk dan naar ruimer indien dat nodig is.

Ik kan je trouwens wel aanraden om ergens de Windows Server 2008 Resource Kit boek & CD te bemachtigen, want daar in wordt heel goed uitgelegd hoe dit spul allemaal werkt.

[Anoniem: 296710]

Bedankt allen voor de reacties. Ik heb alles gekregen zoals nodig was.

De share permissies heb ik gelaten op full control.
De NTFS permissies heb ik dan op de share map op de minimum vereisten gezet en dan per submap(pen) uitgebreid indien nodig. Dit met groepen om makkelijk later users toe te kunnen voegen, uitgezonderd de echte persoonlijke mappen die speciaal voor die gebruiker is.

Ik ben zeker geen expert op netwerkbeheer gebied, ben dan ook programmeur. Ik krijg dan ook hulp indien nodig van onze leverancier van de server. Maar de machtigingen is iets wat ik zeker goed zelf moet kunnen instellen aangezien er wel eens wat kan veranderen aan de structuur enzo. Vandaar dat ik dit zeker zelf goed diende te krijgen. Ik vind alleen dat er weinig goed leesbare info is over het instellen van machtigingen en wat elke instelling ervan nu precies inhoud. Dit zou me het experimenteren bespaard hebben.

[Widow]

Ik weet niet hoe je googelt maar er is echt tonnen informatie te vinden over NTFS share en security rechten. Of heb je een Nederlandse server installatie? Als je Engelse zoektermen gebruikt kom je genoeg info tegen iig

http://www.windowsecurity...ows-ntfs-permissions.html

Als ik je één klein stukje advies mag geven over full control sharing permissions. Let wel dat gebruikers op dat moment NTFS permissies kunnen instellen, en ownership kunnen pakken van een bestand. Oftewel, een gebruiker kan ownership pakken van een bestand en kan er dan voor zorgen dat niemand anders nog bij dat bestand kan. Kan jij als admin er wel weer vanaf halen, maar beter geef je geen full control aan gebruikers.

[alt-92]

Widow schreef op vrijdag 21 december 2012 @ 13:35:
I
Als ik je één klein stukje advies mag geven over full control sharing permissions. Let wel dat gebruikers op dat moment NTFS permissies kunnen instellen, en ownership kunnen pakken van een bestand.

Nee, dat kan niet met Share permissions.
Everyone FC op share level betekent: "ik handel al mijn file security met NTFS af".

Everyone FC op NTFS nivo is inderdaad wel makkelijk, maar risicovol.
Overigens: als je Modify rechten geeft én je laat Creator Owner staan heb je alsnog als gebruiker volledige rechten op de map & bestanden die je aanmaakt en kun je die ACLs wijzigen.

Creator Owner weghalen voorkomt ook dat issue (gaat ten koste van traceability, maar ja, je kan niet alles hebben).