Share permissies vloeien niet naar beneden.

[Verwijderd]

Voor een basisschool heb ik een Windows 2K3 Std. Server opgezet. Er is één domein. De kinderen maken gebruik van school software die op shares moet worden geinstaleerd en vanaf daar gewoon opgestart kan worden.

Nu loop ik echter tegen een probleem aan. Veel van de school software roept bestanden aan in submappen aan maar daar krijg ik geen toegang tot. Echter kan ik daar wel komen als ik er heen klik vanuit de expliciet gesharede map.

Om het duidelijk te maken. De share \\Server01\Software\Rekenen is expliciet geshared, via de share folder optie. De security rechten zijn naar beneden gevloeid en in orde. Ik kan nu als user direct naar \\Server01\Software\Rekenen browsen. Ik kan vanuit \\Server01\Software\Rekenen naar de submap Rekensoftware browsen. Als ik echter direct naar \\Server01\Software\Rekenen\Rekensoftware\ wil browsen krijg ik een 'access denied'.

Het lijkt er dus op dat share permissies niet naar beneden vloeien. Weet iemand een alternatief of iets wat ik mis doe?

Alvast bedankt.

[Question Mark]

Waarschijnlijk staat dan op die "probleemmappen" het vinkje uit dat rechten van bovenaf mogen doorvloeien (inherit folder permissions).

Controleer dat eens

[Workaholic]

Zoals question mark al aangeeft, controleer de advanced permissions en zet desnoods de permissies opnieuw op de mappen met behulp van --> remove permissions.

[Verwijderd]

Het "inherit folder permissions" vinkje staat aan. Er is ook zichtbaar dat er rechter zijn geeerfd van hogere mappen.

Als ik een testshare maak, met zo min mogelijk instellingen (grote shares kunnen wat rommelig worden) houd ik het zelfde probleem.

Zelfs tot een punt waar ik Everyone full permissions geef en Everyone full control geef. Enkel de domain admin lijkt geen problemen te hebben met shares.

[ Voor 8% gewijzigd door Verwijderd op 04-12-2009 10:27 ]

[racoon]

Wat gebeurd er als je het vinkje van inherit folder permissions uit zet?

[Verwijderd]

Niets,

Echter vind ik wel uit dat als ik een nieuwe UO maak en een nieuwe user daar in dat het wel werkt. Policy probleem? En welke zou het dan kunnen zijn?

[Question Mark]

"Bypass traverse Checking" zou je even kunnen controleren (en evt. nog het "traverse folder right").

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Zie ook:

Bypass traverse checking
How to set, view, change, or remove special permissions for files and folders in Windows XP

[Verwijderd]

Question Mark schreef op vrijdag 04 december 2009 @ 11:53:
"Bypass traverse Checking" zou je even kunnen controleren (en evt. nog het "traverse folder right").

Computer Configuration\Windows Settings\Security Settings\Local Policies\User Rights Assignment

Zie ook:

Bypass traverse checking
How to set, view, change, or remove special permissions for files and folders in Windows XP

Alles daar staat op not defined. Lijkt me dus dat het daar niet ligt. Ik zal de docu's even doornemen maar ik heb helaas al een hele hoop gedaan en gelezen.

Grappig detail is trouwens dat als ik een subfolder waar ik normaal dus "access denied" op krijg laat mounten met net use in een startup script dat wel gewoon werkt.

[ Voor 10% gewijzigd door Verwijderd op 04-12-2009 12:05 ]

[Ethirty]

Share rechten zelf voor user$ op full control ipv read-only? Wat gebeurt er als je user$ full control/change ntfs-rechten geeft op de mapstructuur?

[Verwijderd]

Ethirty schreef op vrijdag 04 december 2009 @ 12:17:
Share rechten zelf voor user$ op full control ipv read-only? Wat gebeurt er als je user$ full control/change ntfs-rechten geeft op de mapstructuur?

User$? Die kwam ik bij mijn XP machines altijd wel tegen maar hier niet. Is dat niet gewoon Everyone of Users? Beide hebben op de testmap full control.

Detail is als ik als client inlog en in de command prompt: net use z: \\Server\Testmap doe ik er gewoon in kom. Erg raar.

[Ethirty]

niet user$ als in letterlijk, meer om te vragen of specieke users voldoende rechten heeft. Ja dus.

[Question Mark]

Verwijderd schreef op vrijdag 04 december 2009 @ 12:04:
[...]


Alles daar staat op not defined. Lijkt me dus dat het daar niet ligt.

"Not defined" wil zeggen dat dit niet ingesteld staat via Group Policy's. Het kan echter nog wel lokaal op de werkplekken ingesteld staat. Controleer dus even de daadwerkelijke instelling op de werkplek/server.

[Verwijderd]

Question Mark schreef op vrijdag 04 december 2009 @ 13:31:
[...]

"Not defined" wil zeggen dat dit niet ingesteld staat via Group Policy's. Het kan echter nog wel lokaal op de werkplekken ingesteld staat. Controleer dus even de daadwerkelijke instelling op de werkplek/server.

In windows XP ben ik nooit de optie traversing tegen gekomen. Of andere opties in die zin. Traversing heb ik overigens geprobeerd, zonder resultaat.

[Question Mark]

Verwijderd schreef op vrijdag 04 december 2009 @ 13:45:
[...]
In windows XP ben ik nooit de optie traversing tegen gekomen.

Traverse folder rights staat uitgelegd in het tweede linkje wat ik postte. Het is notabene nog een artikel speciaal voor XP.

[Verwijderd]

Question Mark schreef op vrijdag 04 december 2009 @ 13:47:
[...]
Traverse folder rights staat uitgelegd in het tweede linkje wat ik postte. Het is notabene nog een artikel speciaal voor XP.

Maar de traversing opties kan ik aannemelijk enkel op de shares van de XP machines instellen. Daar staan de shares niet, die staan op de server. Overigens worden deze rechten al toebedeeld via Everyone.

[didi79]

Misschien is het allemaal zo ingewikkeld niet... Soms kan client afmelden en terug aanmelden dergelijke probleempjes direct oplossen.

[Verwijderd]

didi79 schreef op vrijdag 04 december 2009 @ 16:54:
Misschien is het allemaal zo ingewikkeld niet... Soms kan client afmelden en terug aanmelden dergelijke probleempjes direct oplossen.

Hoe bedoel je dit?

[alt-92]

Titel klopt sowieso niet helemaal, share permissies kennen maar één nivo in tegenstelling tot NTFS permissies (waar je het eigenlijk over hebt).

Afmelden en aanmelden forceert een renewal van je Kerberos ticket op basis waarvan je je toegang krijgt tot de resource.
Vanaf dat moment neem je ook de (gewijzigde) groupmemberships en diens permissies mee, tot die tijd werk je met de 'oude' set gecachte permissies.

[MEN-O]

Wat is het OS van je clients ?

[Verwijderd]

Het gaat uitsluitend om XP SP3 machines.

[didi79]

Zijn al je PC's en users lid van het domein ?
Kan je cached logons uitsluiten (waardoor group membership er misschien niet doorkomt) ?

[Verwijderd]

Ze zijn allemaal lid van het domein, hoe sluit ik die caches uit precies?

[didi79]

Is in te stellen via registry of local policies.http://www.howtonetworking.com/server/disabledomaincache.htm
Misschien ook via group policy, maar dat vereist net dat je pc met de AD communiceert.

[alt-92]

Dat soort dingen stel je juist via GPO's in (om de heel simpele reden dat je dat beter kunt troubleshooten en beheren).

Besef je alleen wel dat dat ook andere gevolgen kan hebben, afhankelijk van je clientPC's .
Laptops bijvoorbeeld kun je zonder cached logons niet meer buiten de deur laten gebruiken zonder VPN met je corpnet.

Overigens heb je nog een redelijk eenvoudige manier van troubleshooten door klist te gebruiken.
Zit in de resource kit.

c:\Program Files\nttools>klist
Usage: klist <tickets | tgt | purge>

[Verwijderd]

Maar wat ik niet helemaal begrijp is dat ik nu halsbrekende toeren moet uithalen om iets simpels als shares werkend te krijgen.

Is er hier iets fundamenteels fout gegaan, of is het een bug? Is wat ik wil echt werkelijk zo vreemd? En zou ik dit probleem bij server 2008 ook tegen komen? Het loopt nu al enkele weken zo en het moet eens gaan werken, dan gooi ik liever alles over de kop.

[Verwijderd]

Een hele stap verder, na het toevoegen van "Authenticated users" aan de share permissies lijkt het allemaal aardig te lopen. Echter kan nog steeds niemand naar de server zelf browsen.

[Grolsch]

volgens mij is er iets fundamenteels aan je netwerk niet lekker.
Je werkt dus met een AD
Zit je DNS goed in elkaar

[alt-92]

Verwijderd schreef op dinsdag 15 december 2009 @ 11:39:
Maar wat ik niet helemaal begrijp is dat ik nu halsbrekende toeren moet uithalen om iets simpels als shares werkend te krijgen.

Is er hier iets fundamenteels fout gegaan, of is het een bug?

User error.

Share permissies zijn NIET hetzelfde als NTFS file permissies.

Zorg dat je die twee zaken goed uit elkaar haalt, want uit alles wat je zegt komt naar voren dat je daar geen verschil in ziet.