[Powershell] Script werkt prima, echter niet bij andere user

[Urk]

Ik heb het onderstaande PS scriptje geschreven. Dit scriptje dient ervoor om bij redirected profiles extra rechten toe te kennen aan de owner van de profielmap. Dit om als iemand anders (bijv een manager) een bestand toevoegd dat de user dan nog steeds rechten heeft aangezien hij niet de owner is van het nieuwe bestand wat door de manager bijv op zijn desktop is geplaatst.

Het script werkt echter prima, het draait op de fileserver zelf. Echter wanneer iemand op een RDS server voor het eerst inlogt en dus een profielmap voor hem wordt aangemaakt met de gebruiker als owner gebeurd er niets. Op de fileserver zelf zie ik in de console wel dat de map is gemaakt en zie ik step 2 t/m 5 gewoon netjes gelogd. Echter er worden geen rechten toegevoegd.

Eerst dacht ik dat het iets met te weinig rechten te maken zou kunnen hebben maar volgens mij kan dit niet aangezien het PS script zelf op de server draait met admin rechten.

Iemand wellicht een idee wat ik fout doe of wat ik over het hoofd zie? Ik zit een beetje vast..
Alvast

PowerShell:

$watcher = New-Object System.IO.FileSystemWatcher
$watcher.Path = "F:\Profiles" ##Change this to the profile root folder
$watcher.IncludeSubdirectories = $false
$watcher.EnableRaisingEvents = $true

$created = Register-ObjectEvent $watcher "Created" -Action {
    write-host "Created: $($eventArgs.FullPath)"
    
    Start-Sleep -Milliseconds 2000
    
    $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::ContainerInherit -bor [System.Security.AccessControl.InheritanceFlags]::ObjectInherit
    $PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None
    
    Try
    {
        ##$currentowner = Get-Acl "F:\Profiles\Joanna" | select Owner
        $acl = Get-Acl $($eventArgs.FullPath)
        $currentowner = $acl.Owner
        $permission = $currentowner,"FullControl",$InheritanceFlag,$PropagationFlag,"Allow"
        write-host "Stap 2 $currentowner"
        $accessRule = new-object System.Security.AccessControl.FileSystemAccessRule $permission
        write-host "Stap 3"
        $acl.SetAccessRule($accessRule)
        write-host "Stap 4"
        $acl | Set-Acl $($eventArgs.FullPath)
        write-host "Stap 5"
    }
    Catch
    {
        $ErrorMessage = $_.Exception.Message
        write-host $ErrorMessage
        Break
    }
}

[Creepy]

Ff een tikje door naar Serversoftware en Windows Servers waar Powershell thuis hoort.

[Dennism]

Heb je wel de policy aanstaan dat een administrator automatisch rechten krijgt op een roaming profile? Anders zou je inderdaad tegen een rechten issue aan kunnen lopen daar bij default alleen de gebruiker rechten krijgt op zijn eigen profiel folder en dan kan zelfs een administrator er niets mee zonder eerst zelf ownership te nemen.

Computer Configuration > Policies > Administrative Templates > System > User Profiles > Add the Administrator security group to roaming users profiles

Over de handigheid van een systeem als dit valt natuurlijk ook te discussiëren. Het lijkt mij in ieder geval geen best practise oplossing dat bedrijfsdata waar meedere personen bij moeten kunnen in individuele user profielen staat. Is het niet handiger om bijv. afdelingsmappen te hebben waar zowel de manager als de gebruikers die bij een bepaald bestand moeten kunnen er allemaal bijkunnen. Al is dat natuurlijk een andere discussie.

[Urk]

Dennism schreef op dinsdag 26 september 2017 @ 11:47:
Heb je wel de policy aanstaan dat een administrator automatisch rechten krijgt op een roaming profile? Anders zou je inderdaad tegen een rechten issue aan kunnen lopen daar bij default alleen de gebruiker rechten krijgt op zijn eigen profiel folder en dan kan zelfs een administrator er niets mee zonder eerst zelf ownership te nemen.

Computer Configuration > Policies > Administrative Templates > System > User Profiles > Add the Administrator security group to roaming users profiles

Over de handigheid van een systeem als dit valt natuurlijk ook te discussiëren. Het lijkt mij in ieder geval geen best practise oplossing dat bedrijfsdata waar meedere personen bij moeten kunnen in individuele user profielen staat. Is het niet handiger om bijv. afdelingsmappen te hebben waar zowel de manager als de gebruikers die bij een bepaald bestand moeten kunnen er allemaal bijkunnen. Al is dat natuurlijk een andere discussie.

Dank voor je feedback! Ik gebruik geen roaming profiles, alleen redirected profiles. En ja, in GPO's staat aan dat de user niet exclusief toegang heeft tot zijn redirected profile map, bovendien staan de rechten zo ingesteld dat Administrators en een andere groep (Sec-Management) rechten heeft op alle profielmappen. Ik kan als admin er dus ook prima bij.
Dat vergat ik te melden en kan het dus niet zijn.
Toch lijkt het iets met rechten te zijn, als ik op de RDS server inlog als Administrator worden de rechten op de fileserver via het PS script wel automatisch goed gezet, als ik inlog als normale user niet....

Wat betreft je 2e opmerking: nee dit is absoluut bewust zo gedaan, en sterker nog: ik heb meedere klanten waarbij bijv een directeur of manager toegang wil tot bijv de desktop van een andere user.
In dit geval is het belangrijk dat alleen de user zelf en de general manager erbij kan. Een afdelingsmap is dus niet handig want zou je per user map alleen de user en manager exclusieve toegang moeten geven. Ook zou je die steeds handmatig moeten aanmaken, nu gaat alles automatisch.

[Dennism]

Urk schreef op woensdag 27 september 2017 @ 02:38:


Wat betreft je 2e opmerking: nee dit is absoluut bewust zo gedaan, en sterker nog: ik heb meedere klanten waarbij bijv een directeur of manager toegang wil tot bijv de desktop van een andere user.
In dit geval is het belangrijk dat alleen de user zelf en de general manager erbij kan. Een afdelingsmap is dus niet handig want zou je per user map alleen de user en manager exclusieve toegang moeten geven. Ook zou je die steeds handmatig moeten aanmaken, nu gaat alles automatisch.

Hou er dan wel rekening mee dat dit goed vooraf zeer duidelijk bekend gemaakt moet zijn in bijv. een IT reglement. Zelf in een bedrijfsomgeving mag een directeur of manager (Of ITer) niet zomaar rond neuzen in een map waar het niet onlogisch is dat er ook privé zaken kunnen staan van de betreffende gebruiker, denk hierbij aan mappen in het profiel of bijv. de E-mailbox. Dit mag zelfs bij melding vooraf slechts onder bepaalde criteria en in de regel zeker niet met een permanent verkregen toegang, ook al is dit van te voren gemeld.

Paar voorbeelden: https://www.security.nl/p...ke+bestanden+_+mappen+%3F en bijv. https://www.sprengersadvo...ilbox-van-een-medewerker/ pas hier dus als ITer goed mee op.

[ Voor 7% gewijzigd door Dennism op 27-09-2017 08:32 ]

[Question Mark]

Ik heb onderstaande zin nu een paar keeer gelezen, maar begrijp er weinig van...

Urk schreef op maandag 25 september 2017 @ 18:00:
Dit om als iemand anders (bijv een manager) een bestand toevoegd dat de user dan nog steeds rechten heeft aangezien hij niet de owner is van het nieuwe bestand wat door de manager bijv op zijn desktop is geplaatst.

Een persoon plaatst rechtstreeks een bestand op de desktop van user, en het probleem is dat de user dan rechten krijgt omdat hij géén owner is?

Je hoeft geen owner te zijn van een bestand om daar rechten op te hebben.... Wat is nu precies je probleem?

Kan het niet zo zijn dat gebruikers vanaf je RDS servers bestanden verplaatsen op dezelfde partitie, waardoor de bronrechten behouden blijven? Als dat het geval is moet je de gebruikers gewoon even instrueren om deze bestanden te copy/pasten.

https://support.microsoft...nd-move-files-and-folders

By default, an object inherits permissions from its parent object, either at the time of creation or when it is copied or moved to its parent folder. The only exception to this rule occurs when you move an object to a different folder on the same volume. In this case, the original permissions are retained.

Verder eens met bovenstaande opmerkingen over de inrichting.. het is een bijzonder vreemde inrichting. Ik heb nog nooit meegemaakt dat managers toegang moeten hebben tot profieldata van een gebruiker.

[Urk]

Ja, ik weet reeds dat dit bekend moet zijn vanwege juridische gronden, net zoals dat wanneer iemand toegang moet hebben tot iemand anders zijn mailbox. Dit is voor een bedrijf in Spanje en daar heb ik verteld hoe dit juridisch in nederland werkt, hoe dit juridisch daar geregeld is mogen ze zelf uitzoeken, dat is niet mijn taak, ik zorg alleen voor het technische verhaal.
Daarbij: waar in de wet staat dat er verschil is tussen data op een netwerkshare of in zijn/haar profiel? Wie zegt dat dat niet gewoon algemene bedrijfsinformatie kan zijn? En wie zegt dat die data in zijn/haar profiel prive data is? En waar staat dat dat je dat niet zou mogen inzien? In mijn optiek kan dat idem zijn maar ik ben geen jurist. Ik weet absoluut dat het bij mailboxen stenger is.

Maargoed dit is voer voor een hele andere discussie dan mijn technische vraag.

Een persoon plaatst rechtstreeks een bestand op de desktop van user, en het probleem is dat de user dan rechten krijgt omdat hij géén owner is?

Klopt, een persoon plaatst een bestand op de desktop van de user, tot zover correct, echter krijgt de user zelf geen rechten omdat degene die het bestand geplaatst heeft de owner van het bestand kan zijn (afhankelijk van move/copy actie). Een oplossing daarvoor is om additionele (non inheritable) rechten nogmaals te geven voor de user zelf op zijn eigen profielmap. De rechten op de redirected profiles root map zijn zo ingdedeeld zoals Microsoft in dit artikel heeft voorgeschreven: https://support.microsoft...ess-to-redirected-folders

Ik heb nog steeds geen idee wanner het PS script onder het Admin account op de fileserver draait waarom dit dan niet werkt
Ook PowerShell ISE uitvoeren nog als Administrator maakt geen verschil tussen normaal uitvoeren als admin.

[Zethiel]

Hoe staat bij jullie allebei de execution policy?

[Killah_Priest]

Zethiel schreef op woensdag 27 september 2017 @ 17:23:
Hoe staat bij jullie allebei de execution policy?

Dit lijkt mij niet relevant in dit verhaal aangezien het script op een server draait met een FileSystemWatcher (alleen de executionpolicy van de server waarop dit script draait is dus relevant en aangezien het script verder wel draait kan het onmogelijk met de executionpolicy te maken hebben).

[Question Mark]

Urk schreef op woensdag 27 september 2017 @ 17:14:
Klopt, een persoon plaatst een bestand op de desktop van de user, tot zover correct, echter krijgt de user zelf geen rechten omdat degene die het bestand geplaatst heeft de owner van het bestand kan zijn (afhankelijk van move/copy actie).

Nogmaals, ownership staat compleet los van rechten die een user krijgt. Je krijgt prima "Full Control" op een bestand hebben of krijgen, waar je niet de owner van bent.

Wat gebeurt er nu als een manager een bestand copy/paste? Volgens het technet artikel erft het bestand dan de rechten van de profile folder, waardoor de user keurig de juiste rechten krijgt.

Dit probleem moet je niet oplossen met IO-intensieve scripts, maar bij de basis.

[Urk]

Question Mark schreef op donderdag 28 september 2017 @ 10:06:
[...]

Nogmaals, ownership staat compleet los van rechten die een user krijgt. Je krijgt prima "Full Control" op een bestand hebben of krijgen, waar je niet de owner van bent.

Wat gebeurt er nu als een manager een bestand copy/paste? Volgens het technet artikel erft het bestand dan de rechten van de profile folder, waardoor de user keurig de juiste rechten krijgt.

Dit probleem moet je niet oplossen met IO-intensieve scripts, maar bij de basis.

Sorry Mark hele late reactie maar dit probleem speelt nog steeds.
Wat betreft je opmerking, nee als de manager een bestand in het profiel van een user opslaat dan kan de user dat bestand niet open (access denied). Alleen het opnieuw resetten van de huidige owner (replace owner) en het resetten van de rechten lost dat probleem op.
Doordat het redirected profile verhaal werkt met "owner rechten" om het maar even zo te noemen. De CREATOR OWNER heeft bepaalde rechten en kent die toe aan onderliggende items. Als een andere user iets plaatst is die de CREATOR OWNER en daardoor krijgt de eigenaar van het profiel geen rechten. Wat wellicht logisch is en daarom mijn script die nogmaals de rechten op de hoofdmap zet voor de gebruiker van het profiel.

Het is mijns inziens absoluut geen IO intesive script. Hij monitort slechts 1 folder, en niets een subfolders op de creatie van nieuwe mappen, that's it. Tuurlijk zal het een kleine beetje resources gebruiken maar resources genoeg.

Hierbij dus een kickje om dit topic nieuw leven in te blazen want ik begrijp nog steeds niet (zelfs na mijn hersens meerdere malen logisch te laten kraken ) waarom dit niet werkt...

[ Voor 13% gewijzigd door Urk op 30-11-2017 04:25 ]

[Killah_Priest]

Om te beginnen : hoe draai je het script? Scheduled task? Handmatig gestart?