[Rechten] Moved & copied files owner van parent krijgen?

[Urk]

Ik heb een probleempje waar ik bij meerdere klanten tegenaan loop. Het komt voornamelijk voor icm Redirected Folders en Work Folders (in 2012 R2).
Een profielmap in een redirected folder worden zoals jullie aamgemaakt bij de eerste login op de server via de gebruiker (automatisch), de map heeft dan bijv Jan als owner, alles wat Jan in die map doet houd Jan als owner en dus kan hij overal bij.

Het probleem gaat mis zodra ik als Administrator of een manager binnen het bedrijf een bestand moet platsen het het profiel of de work folder van gebruiker Jan.
De Admin of Manager is dan owner van het bestand maar Jan niet meer waardoor Jan geen rechten meer heeft op dit bestand.

Hier loop ik vaker tegen aan. Uiteraard wil ik niet voor iedere user extra erbovenop excplicit die user rechten geven op die map want dan zou ik dat handmatig moeten doen voor alle gebruikers.
Is er dus een mogelijkheid via bijv een registry key/value om nieuwe bestanden die door wie dan ook geplaatst worden in de profielmap van de gebruiker de owner krijgen van de parent? Zodat Jan de owner blijft en dus bij die bestanden kan, ook al zijn de bestanden gekopieerd of verplaatst door de Admin of een Manager?

Ik hoop dat jullie snappen wat ik bedoel want is wellicht beetje lastig uit te leggen maar wellicht komt het jullie ook bekend voor.
Server OS in dit geval: Windows Server 2012 R2.

[Wom]

Je specifieke situatie is iets waar ik geen ervaring mee heb, maar in het verleden heb ik problemen gehad met ownership en kon dat met deze tips verhelpen: http://www.experts-exchan...blems-and-resolution.html

Denk dat het Creator Owner stuk van toepassing hier is.

[MAX3400]

Er is een essentieel verschil tussen copy of move als we over NTFS praten. Daarnaast is er ook nog invloed op waarvandaan het bronbestand komt en waar het heengaat zoals van marketing.bedrijf.local naar managers.bedrijf.local

Gezien de permissies op elke homedirectory, vermoed ik dat je iets meer troubleshooting moet posten zodat door middel van deductie de situatie voor ons iets duidelijker wordt.

[Urk]

MAX3400 schreef op woensdag 19 augustus 2015 @ 15:14:
Er is een essentieel verschil tussen copy of move als we over NTFS praten. Daarnaast is er ook nog invloed op waarvandaan het bronbestand komt en waar het heengaat zoals van marketing.bedrijf.local naar managers.bedrijf.local

Gezien de permissies op elke homedirectory, vermoed ik dat je iets meer troubleshooting moet posten zodat door middel van deductie de situatie voor ons iets duidelijker wordt.

OK, laat ik het even houden op de redirected profile map op een Win2k12 R2 server, buiten de overige rechten heeft de CREATOR OWNER daar de volgende rechten op:

Full control op subfolders & files only
Voor alle gebruikers geen inheritable permissies.

Zodra een nieuwe user voor het eerst inlogt wordt er netjes in D:\Profiles een mapje gemaakt met de naam van de gebruiker, dus bijv D:\Profiles\Jan via GPO Redirected Profile settings.
Alles werkt prima voor de gebruiker zelf, behalve wanneer een admin of een manager die ook Read/Write rechten heeft op de gehele D:\Profiles map een bestand (bijv Test.doc) plaatst in bijv. D:\Profiles\Jan\Desktop.
D:\Profiles\Jan\Desktop\Test.doc heeft dan als owner Manager waardoor de gebruiker dit bestand niet meer kan openen. Wanneer ik als Admin zelf de rechten reset en de owner terugezet naar de gebruiker en deze rechten toepas op deze map en onderliggen mappen kan hij er weer bij.

Ik wil dat dus niet steeds handmatig moeten resetten.

Ik heb geen idee hoe deze ingewikkelde kwestie op te lopen en loop er eigenlijk bij al m'n klanten tegenaan. Dank voor jullie feedback dus
Hoop dat ik nu iets duidelijker ben.

[ Voor 3% gewijzigd door Urk op 19-08-2015 15:34 ]

[Tijntje]

Dat hangt er dus vanaf waar het bestand vandaan komt en of er wordt verplaatst of gekopieerd.

• Als een bestand vanuit een folder naar een andere folder wordt gekopieerd op dezelfde partitie dan worden de rechten geërfd van de bovenliggende folder.
• Als een bestand vanuit een folder naar een andere folder wordt verplaatst op dezelfde partitie dan worden de originele rechten behouden.
• Als een bestand vanuit een folder naar een andere folder wordt gekopieerd op een andere partitie dan worden de rechten geërfd van de bovenliggende folder.
• Als een bestand vanuit een folder naar een andere folder wordt verplaatst op een andere partitie dan worden de rechten geërfd van de bovenliggende folder.

Het is eigenlijk te belachelijk voor woorden dat NTFS nog steeds zo werkt maar het is niet anders.

[ Voor 3% gewijzigd door Tijntje op 19-08-2015 15:40 ]

[Urk]

Tijntje schreef op woensdag 19 augustus 2015 @ 15:39:
Dat hangt er dus vanaf waar het bestand vandaan komt en of er wordt verplaatst of gekopieerd.

• Als een bestand vanuit een folder naar een andere folder wordt gekopieerd op dezelfde partitie dan worden de rechten geërfd van de bovenliggende folder.
• Als een bestand vanuit een folder naar een andere folder wordt verplaatst op dezelfde partitie dan worden de originele rechten behouden.
• Als een bestand vanuit een folder naar een andere folder wordt gekopieerd op een andere partitie dan worden de rechten geërfd van de bovenliggende folder.
• Als een bestand vanuit een folder naar een andere folder wordt verplaatst op een andere partitie dan worden de rechten geërfd van de bovenliggende folder.

Het is eigenlijk te belachelijk voor woorden dat NTFS nog steeds zo werkt maar het is niet anders.

Ja, thanks. Dat wist ik wel deels maar daar zijn registry keys voor zoals MoveSecurityAttributes volgens mij. Die lossen echter niet het probleem van de owner op volgens mij.
De vraag is alleen of die werken onder Windows Server 2012 R2 (kan ik online niet zo snel vinden) en wanneer dat actief wordt? Na een reboot? En werkt neem ik aan ook wanneer iemand van een werkstation een move of copy actie op de betreffende fileserver uitvoert, toch?

Edit: volgens mij is het inderdaad zo dat als je een map kopieerd naar iemand zijn profiel het dan wel goed gaat met de rechten.... hoewel ik dan twijfel of de owner klopt. Kan ik zo nog even nakijken.

Edit2: Ik heb dit zojuist getest en zowel move als copy van zowel zelfde als andere partitie op de server heeft het bestand na move/copy de rechten geërfd van de bovenliggende folder. Probleem is echter dat de owner de user is die de actie heeft gedaan waardoor de user toch niet het bestand kan openen omdat hij geen rechten heeft. Pas zodra ik de owner van het bestand zet op de user van de profielmap kan hij er bij....

[ Voor 19% gewijzigd door Urk op 19-08-2015 15:57 ]

[Tijntje]

Urk schreef op woensdag 19 augustus 2015 @ 15:47:
[...]


Ja, thanks. Dat wist ik wel deels maar daar zijn registry keys voor zoals MoveSecurityAttributes volgens mij. Die lossen echter niet het probleem van de owner op volgens mij.
De vraag is alleen of die werken onder Windows Server 2012 R2 (kan ik online niet zo snel vinden) en wanneer dat actief wordt? Na een reboot? En werkt neem ik aan ook wanneer iemand van een werkstation een move of copy actie op de betreffende fileserver uitvoert, toch?

Edit: volgens mij is het inderdaad zo dat als je een map kopieerd naar iemand zijn profiel het dan wel goed gaat met de rechten.... hoewel ik dan twijfel of de owner klopt. Kan ik zo nog even nakijken.

Edit2: Ik heb dit zojuist getest en zowel move als copy van zowel zelfde als andere partitie op de server heeft het bestand na move/copy de rechten geërfd van de bovenliggende folder. Probleem is echter dat de owner de user is die de actie heeft gedaan waardoor de user toch niet het bestand kan openen omdat hij geen rechten heeft. Pas zodra ik de owner van het bestand zet op de user van de profielmap kan hij er bij....

Die registry key geeft niet het resultaat wat je er van verwacht en ik zou die dan ook zeker niet gebuiken.

Dat de owner het zelfde blijft klopt natuurlijk ook gewoon. De persoon die een bestand aanmaakt is de owner en zal dat normaal gesproken ook blijven. Dit hoeft echter een ander gebruiker niet in de weg te staan om dat bestand ook te kunnen gebruiken.

[Urk]

Tijntje schreef op woensdag 19 augustus 2015 @ 16:10:
[...]

Die registry key geeft niet het resultaat wat je er van verwacht en ik zou die dan ook zeker niet gebuiken.

Dat de owner het zelfde blijft klopt natuurlijk ook gewoon. De persoon die een bestand aanmaakt is de owner en zal dat normaal gesproken ook blijven. Dit hoeft echter een ander gebruiker niet in de weg te staan om dat bestand ook te kunnen gebruiken.

Dank voor je reactie!
Klopt zeker wat je zegt dat dat behavior by design is. In het geval van Redirected Profiles staat dat dus wel in de weg. GPO Redirected Profiles maakt de map namelijk aan dus die is de owner. Zodra die user een bestand dus niet aanmaakt maar een andere user heeft hij er geen rechten meer op.

Is er een manier om dit op te lossen of op een andere manier af te vangen wellicht?

[Tijntje]

Urk schreef op woensdag 19 augustus 2015 @ 16:15:
[...]

Dank voor je reactie!
Klopt zeker wat je zegt dat dat behavior by design is. In het geval van Redirected Profiles staat dat dus wel in de weg. GPO Redirected Profiles maakt de map namelijk aan dus die is de owner. Zodra die user een bestand dus niet aanmaakt maar een andere user heeft hij er geen rechten meer op.

Is er een manier om dit op te lossen of op een andere manier af te vangen wellicht?

Nee
Je zal er voor moeten zorgen dat de folder rechten juist staan en dat gebruikers kopiëren in plaats van verplaatsten.

[Killah_Priest]

Urk schreef op woensdag 19 augustus 2015 @ 16:15:
[...]

Dank voor je reactie!
Klopt zeker wat je zegt dat dat behavior by design is. In het geval van Redirected Profiles staat dat dus wel in de weg. GPO Redirected Profiles maakt de map namelijk aan dus die is de owner. Zodra die user een bestand dus niet aanmaakt maar een andere user heeft hij er geen rechten meer op.

Is er een manier om dit op te lossen of op een andere manier af te vangen wellicht?

Nee, de GPO maakt geen map aan (een GPO zelf kan dit ook niet) : de user doet dit (of dit via een GPO gaat of handmatig, de user is degene die de folder aanmaakt en ook owner zal zijn van de map zelf).
Er zijn overigens wel "oplossingen" voor dit probleem te bedenken ; bv een PS script welke voor iedere redirected folder hard een ACL toekent met het useraccount van de persoon waar de folder bij hoort fullaccess rechten te geven ; files en folders zullen dan - ongeacht wie er ownership heeft op de file - toegankelijk zijn voor de user.

[MAX3400]

MSDN: Security Recommendations for Roaming User Profiles Shared Folders: Group Policy -> Goed lezen in tabel 7.7 t/m7 7.9. https://technet.microsoft.com/library/jj649074.aspx helpt misschien ook extra. Ook http://www.grouppolicy.bi...-k-a-user-virtualization/ geeft een mooie uitleg. Vergeet ook niet of & hoe NTFS & SHARE permissions worden toegepast; een mooi artikel is http://www.techrepublic.c...ermissions-in-windows-xp/

En dat is waarschijnlijk wat ik (niet goed) lees in dit topic; je moet je bij dit soort zaken niet focussen op \\server\share-name\%username% maar op \\server\share-name en eerst daar alles afvangen voordat %username% wordt aangemaakt en de inheritance krijgt van de share-name-directory.

/edit: ik krijg helaas wel de bibbers van dit soort topics waarin termen niet goed worden toegepast. Rechten/rights hebben zeer weinig met file-level access te maken.

Killah_Priest schreef op woensdag 19 augustus 2015 @ 16:30:
[...]
bv een PS script welke voor iedere redirected folder hard een ACL toekent met het useraccount van de persoon waar de folder bij hoort fullaccess rechten te geven ; files en folders zullen dan - ongeacht wie er ownership heeft op de file - toegankelijk zijn voor de user.

Alhoewel ik het volledig met je eens ben dat er omwegen zijn om de permissies recht te trekken, weet ik niet of een Powershell/Robocopy-scriptje de beste oplossing is. Ja, het is zeker een oplossing. Ja, het is een low-overhead verhaal. Ja, je hebt het script in 2 minuten in elkaar. Alleen de scheduling t.o.v. file-access (creation date of modification date) kan nog wel eens lastig zijn; zeker als je 5000 users hebt waarvan je gewoon weet dat er minstens elke seconde 10 files ergens in die 5000 redirected profiles veranderen.

[ Voor 41% gewijzigd door MAX3400 op 19-08-2015 17:50 ]

[Killah_Priest]

MAX3400 schreef op woensdag 19 augustus 2015 @ 17:43:
MSDN: Security Recommendations for Roaming User Profiles Shared Folders: Group Policy -> Goed lezen in tabel 7.7 t/m7 7.9. https://technet.microsoft.com/library/jj649074.aspx helpt misschien ook extra. Ook http://www.grouppolicy.bi...-k-a-user-virtualization/ geeft een mooie uitleg. Vergeet ook niet of & hoe NTFS & SHARE permissions worden toegepast; een mooi artikel is http://www.techrepublic.c...ermissions-in-windows-xp/

En dat is waarschijnlijk wat ik (niet goed) lees in dit topic; je moet je bij dit soort zaken niet focussen op \\server\share-name\%username% maar op \\server\share-name en eerst daar alles afvangen voordat %username% wordt aangemaakt en de inheritance krijgt van de share-name-directory.

/edit: ik krijg helaas wel de bibbers van dit soort topics waarin termen niet goed worden toegepast. Rechten/rights hebben zeer weinig met file-level access te maken.


[...]

Alhoewel ik het volledig met je eens ben dat er omwegen zijn om de permissies recht te trekken, weet ik niet of een Powershell/Robocopy-scriptje de beste oplossing is. Ja, het is zeker een oplossing. Ja, het is een low-overhead verhaal. Ja, je hebt het script in 2 minuten in elkaar. Alleen de scheduling t.o.v. file-access (creation date of modification date) kan nog wel eens lastig zijn; zeker als je 5000 users hebt waarvan je gewoon weet dat er minstens elke seconde 10 files ergens in die 5000 redirected profiles veranderen.

Ik zie het ook absoluut niet als een oplossing.
De oplossing is echter heel simpel (en ik zie dit heel vaak) : het proces klopt niet.
Waarom zou een manager een file in een redirected (persoonlijke) folder moeten plaatsen? Er zijn betere oplossingen voor het plaatsen van files (een gewone share bv) wat dat betreft.

Laatst kreeg ik bij een klant ook een verzoek om een bepaalde folder te replicaten naar een bepaalde locatie (een subfolder van een share welke al in een dfs replica zit dus dfs is uitgesloten). Mogelijke oplossingen even nagelopen met hun interne IT team en wij kwamen allemaal tot dezelfde conclusie : de betreffende afdeling die de files plaatst kan ze ook gewoon op locatie B neerzetten ipv A, dan hoeven wij ook geen omslachtige oplossingen te bedenken.

[Razwer]

Urk schreef op woensdag 19 augustus 2015 @ 14:52:
Het probleem gaat mis zodra ik als Administrator of een manager binnen het bedrijf een bestand moet platsen het het profiel of de work folder van gebruiker Jan.
De Admin of Manager is dan owner van het bestand maar Jan niet meer waardoor Jan geen rechten meer heeft op dit bestand.

EEN bestand? of een hele rits?
Smerige oplossing (beter voor bulk files): logon scripts draaien in principe altijd in de user space, dus het zo oplossen is een oplossing. Batch, VBS, Powershell etc kan allemaal.
Betere oplossing: GPO Preferences "configure a file item" https://technet.microsoft.com/en-us/library/cc772536.aspx
anyhow, zorg dat het in de userspace draait. Op remote users na, zullen users altijd eerst moeten inloggen om bij de files te kunnen.

Ik verbaas mij een beetje dat niemand dit eerder genoemd heeft...

[MAX3400]

Razwer schreef op woensdag 19 augustus 2015 @ 22:53:
[...]

EEN bestand? of een hele rits?
Smerige oplossing (beter voor bulk files): logon scripts...

Of we lezen allebei niet goed of jouw oplossing gaat niet werken. Er staat nergens in de startpost dat het om logon-issues gaat en om 1 bestand (of meerdere bestanden). Ik zie niet in hoe jouw oplossing, alhoewel een mogelijkheid voor logon, gaat werken als een user 8 uur achter elkaar is ingelogd en, volgens de summiere startpost, 90 verschillende files in 14 directories gaat ontvangen in zijn Redir. Profile.

[Razwer]

Het probleem gaat mis zodra ik als Administrator of een manager binnen het bedrijf een bestand moet platsen het het profiel of de work folder van gebruiker Jan.
De Admin of Manager is dan owner van het bestand maar Jan niet meer waardoor Jan geen rechten meer heeft op dit bestand.

Daar uit maak ik op dat hij sporadisch bestanden wil plaatsen in de user folders voor user X (of meerdere). Snelkoppeling naar iets bijvoorbeeld? of normal.dot oid? mapje met standaard brieven? verzin iets geks..

Dat kan (zoals de TS zegt) problematisch zijn wanneer ownership dan op de admin staat ipv de user, wat default behavior is wanneer je een bestand plaatst in een home folder.

Als dat de case is los je dat het makkelijkst op via een logon based "iets" (GPO pref of logon script).

Maar misschien heb je gelijk en lees/begrijp ik de startpost verkeerd.

[ Voor 6% gewijzigd door Razwer op 20-08-2015 09:51 ]

[Urk]

Killah_Priest schreef op woensdag 19 augustus 2015 @ 16:30:
[...]


Nee, de GPO maakt geen map aan (een GPO zelf kan dit ook niet) : de user doet dit (of dit via een GPO gaat of handmatig, de user is degene die de folder aanmaakt en ook owner zal zijn van de map zelf).
Er zijn overigens wel "oplossingen" voor dit probleem te bedenken ; bv een PS script welke voor iedere redirected folder hard een ACL toekent met het useraccount van de persoon waar de folder bij hoort fullaccess rechten te geven ; files en folders zullen dan - ongeacht wie er ownership heeft op de file - toegankelijk zijn voor de user.

Uiteraard, sorry voor de verwarring, dit was mj wel bekend, het wordt door de GPO getriggerd maar het wordt uitgevoerd in de security context van de user of machine.

Jouw voorstel om gebruik te maken van een PS script klinkt heel goed, ik denk inderdaad dat dat de beste oplossing is en dus dat wanneer er voor een user een redirected profile folder wordt aangemaakt dat een PowerShell script dit detecteert en automatisch additionele full control rechten geeft aan de owner van de root map (de user waar het om gaat dus).
Ik kan wel een beetje PS scripten maar wellicht is soortgelijk PS script al ergens beschikbaar? Anyone....?

P.S. Sorry voor de late reactie....

[Urk]

MAX3400 schreef op woensdag 19 augustus 2015 @ 17:43:

Alhoewel ik het volledig met je eens ben dat er omwegen zijn om de permissies recht te trekken, weet ik niet of een Powershell/Robocopy-scriptje de beste oplossing is. Ja, het is zeker een oplossing. Ja, het is een low-overhead verhaal. Ja, je hebt het script in 2 minuten in elkaar. Alleen de scheduling t.o.v. file-access (creation date of modification date) kan nog wel eens lastig zijn; zeker als je 5000 users hebt waarvan je gewoon weet dat er minstens elke seconde 10 files ergens in die 5000 redirected profiles veranderen.

OK Echter is dat toch niet ter sprake? Het PS script hoeft maar 1 keer rechten aan te passen zodra de root folder voor het eerst wordt gemaakt, daarna is het niet meer nodig en pakken de onderliggende mappen automatisch de inheritable permissions over van de root folder.
Of bedoel je iets anders?

In mijn omgevingen gaat het meestal om < 100 users.

[ Voor 4% gewijzigd door Urk op 30-08-2015 02:10 ]

[Urk]

Razwer schreef op woensdag 19 augustus 2015 @ 22:53:
[...]

EEN bestand? of een hele rits?
Smerige oplossing (beter voor bulk files): logon scripts draaien in principe altijd in de user space, dus het zo oplossen is een oplossing. Batch, VBS, Powershell etc kan allemaal.
Betere oplossing: GPO Preferences "configure a file item" https://technet.microsoft.com/en-us/library/cc772536.aspx
anyhow, zorg dat het in de userspace draait. Op remote users na, zullen users altijd eerst moeten inloggen om bij de files te kunnen.

Ik verbaas mij een beetje dat niemand dit eerder genoemd heeft...

Deze vat ik even helemaal niet.
Wat betreft je eerste vraag: zo nu en dan een aantal bestanden of enkele mappen.

GPO File Item's is naar mijn idee niet mogeijk en niet hiervoor geschikt. Het ideale is juist dat de redirected profile folder voor iedere nieuwe user ook automatisch wordt aangemaakt.

[Urk]

Razwer schreef op donderdag 20 augustus 2015 @ 09:49:
Dat kan (zoals de TS zegt) problematisch zijn wanneer ownership dan op de admin staat ipv de user, wat default behavior is wanneer je een bestand plaatst in een home folder.

Als dat de case is los je dat het makkelijkst op via een logon based "iets" (GPO pref of logon script).

Maar misschien heb je gelijk en lees/begrijp ik de startpost verkeerd.

Klopt inderdaad, ik denk inderdaad dat de rechten goed zetten via een script de beste oplossing is. Iemand misschien een zetje in de goede richting of een voorbeeld voor zo'n script die doet wat ik hierboven noem?