none
NTFS-Berechtigung von mehreren Laufwerken entfernen RRS feed

  • Frage

  • Hallo an alle,

    ich habe eine Funktion geschrieben, um bestimmten Gruppen die NTFS-Berechtigung von Laufwerken zu entziehen.
    Die Funktion wird von einem Hauptskript aufgerufen, was als Tasksequenz-Schritt bei einer Serverinstallation über SCCM ausgeführt wird.
    Rufe ich die Funktion manuell auf dem Server aus, werden die Berechtigungen sauber entfernt. Vom Hauptskript aufgerufen bekomme ich Fehlermeldungen, allerdings erst nach dem zweiten Laufwerk, dass es keinen Laufwerksbuchstaben mit dem Namen gibt. Anbei die Funktion:

    function Remove-GroupfromDrivesACL
    {
    #Define and validate parameters
    [CmdletBinding()]
    Param(
          #Group
          [parameter(Mandatory=$True,ValueFromPipeline=$False)]
          [String]$Group,
         
          [parameter(Mandatory=$True,ValueFromPipeline=$True)]
          [String]$DrivePath
          )
      Process
       {
        try
         {  
         $objUser = New-Object System.Security.Principal.NTAccount("$Group")
         $colRights = [System.Security.AccessControl.FileSystemRights]'ReadAndExecute'
         $InheritanceFlag = [System.Security.AccessControl.InheritanceFlags]::None
         $PropagationFlag = [System.Security.AccessControl.PropagationFlags]::None
         $objType =[System.Security.AccessControl.AccessControlType]::Allow
         $objACE = New-Object System.Security.AccessControl.FileSystemAccessRule ($objUser, $colRights, $InheritanceFlag, $PropagationFlag, $objType)
         $objACL = (Get-Item $DrivePath -ErrorAction Stop).GetAccessControl('Access')
         $objACL.RemoveAccessRuleAll($objACE)
         Set-ACL -Path $DrivePath -AclObject $objACL -ErrorAction Stop
         Write-Log -LogPath $Global:LogPath -LogString ('Remove NTFS rights for group ' + $Group + ' on path ' + $DrivePath) -Severity Success -Host $Host -EventLog
         }
        catch [Exception]
         {
         Write-Log -LogPath $Global:LogPath -LogString ('Remove NTFS rights for group ' + $Group + ' on path ' + $DrivePath + ' ' + $_.Exception.Message) -Severity Success -Host $Host -EventLog
         exit}
       }
    }

    Der Aufruf erfolgt vom Hauptskript so:
    $DrivePathes = @((Get-WmiObject Win32_Volume | Where-Object {(($_.DriveLetter -ne 'C:') -and ($_.DriveType -eq '3'))}).DriveLetter | ForEach-Object {$_ + '\'})
    $GroupstoRemove = @('Everyone','Creator Owner','Users')
     ForEach ($DrivePath in $DrivePathes)
      {
       ForEach ($Group in $GroupstoRemove)
        {
        Remove-PwCGroupfromDrivesACL -Group $Group -DrivePath $DrivePath -ErrorAction Stop
        }
      }
    Die Fehlermeldung im Log sieht so aus:
    Remove NTFS rights for group Everyone on path D:\
    Remove NTFS rights for group Everyone on path E:\ Cannot find drive. A drive with the name 'E' does not exist.

    Hat jemand eine Idee? Vielen Dank im Voraus.

    Freitag, 27. Februar 2015 16:40

Antworten

  • Wenn es aber wirklich so ist, das das Script bei direktem Start läuft, aber mit dem SCCM-Account nicht, muß es einen Unterschied geben, zwischen der Umgebung die der SCCM-Account sieht und der die du (bzw. der Account des direkten Starts) siehst. Den gilt es herauszufinden. (Rechte sind hier natürlich immer der erste Checkpoint.)

    Du könntest ausserdem z.b. mal prüfen, ob der Output von

    Get-WmiObject -Class Win32_LogicalDisk

    in beiden Fällen (beide Scriptlauf-Szenarios) gleich ist (mal testweise ausgeben).
     
    Ein weiterer Ansatz wäre, mal herauszufinden, welcher Befehl eigentlich genau die Fehlermeldung ausspuckt.  Hierfür solltest du deinen Logstring um folgendes erweitern:

    $($error[0].InvocationInfo.PositionMessage)
    damit wird dir auch die Position des fehlererzeugenden Befehls ausgegeben.
     

    Grüße, Denniver


    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Snippet Manager v3: Link
    (Schneller, besser + einfacher scripten.)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.


    Dienstag, 3. März 2015 13:12
    Moderator

Alle Antworten

  • Ist E:\ ein normales Laufwerk? Ansonsten tippe ich das E:\  mit dem ServiceAccount von SCCM nicht verfügbar ist, aber mit deinem (Admin?)Account schon.

    Unabhängig davon, versuch mal

    Win32_LogicalDisk 

    statt "Win32_Volume". Und schau mal was er dir dann für Laufwerke auflistet.

    $DrivePathes = Get-WmiObject -Class Win32_LogicalDisk | ? { $_.Drivetype -eq 3 -and $_.deviceid -ne 'C:' } | Select -ExpandProperty DeviceID | ForEach-Object {$_ + '\'}

     
    Grüße, Denniver


    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Snippet Manager v3: Link
    (Schneller, besser + einfacher scripten.)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.


    Freitag, 27. Februar 2015 18:05
    Moderator
  • Hallo Denniver,

    vielen Dank für deine Antwort. Alle Laufwerke sind zusätzliche Festplatten einer virtuellen Maschine mit GPT-Partition. Das Skript läuft mit System-Rechten und beim ersten Laufwerk werden auch die Rechte sauber entfernt. Habe die WMI-Abfrage umgestellt und getestet, leider mit dem gleichen Resultat.

    Samstag, 28. Februar 2015 16:14
  • Wenn es aber wirklich so ist, das das Script bei direktem Start läuft, aber mit dem SCCM-Account nicht, muß es einen Unterschied geben, zwischen der Umgebung die der SCCM-Account sieht und der die du (bzw. der Account des direkten Starts) siehst. Den gilt es herauszufinden. (Rechte sind hier natürlich immer der erste Checkpoint.)

    Du könntest ausserdem z.b. mal prüfen, ob der Output von

    Get-WmiObject -Class Win32_LogicalDisk

    in beiden Fällen (beide Scriptlauf-Szenarios) gleich ist (mal testweise ausgeben).
     
    Ein weiterer Ansatz wäre, mal herauszufinden, welcher Befehl eigentlich genau die Fehlermeldung ausspuckt.  Hierfür solltest du deinen Logstring um folgendes erweitern:

    $($error[0].InvocationInfo.PositionMessage)
    damit wird dir auch die Position des fehlererzeugenden Befehls ausgegeben.
     

    Grüße, Denniver


    Blog: http://bytecookie.wordpress.com

    Kostenloser Powershell Snippet Manager v3: Link
    (Schneller, besser + einfacher scripten.)

    Hilf mit und markiere hilfreiche Beiträge mit dem "Abstimmen"-Button (links) und Beiträge die eine Frage von dir beantwortet haben, als "Antwort" (unten).
    Warum das Ganze? Hier gibts die Antwort.


    Dienstag, 3. März 2015 13:12
    Moderator
  • Hallo Denniver,

    ich habe jetzt auch den Test gemacht, dass ich die Funktion aus dem Hauptskript auskommentiert, die Tasksequenz angehalten und dann die Funktion manuell (aus dem Powershell ISE) aufgerufen habe. Das hat funktioniert. Ich habe danach das Powershell Modul NTFSSecurity zum Entfernen der Gruppen eingebunden, jedoch mit dem gleichen Ergebnis. Die Fehlermeldung kommt immer nach dem zweiten Laufwerk beim Einlesen (Get-Item E:\). Es scheint mir, dass die Übergabe des zweiten (!) Laufwerksbuchstaben irgendwie nicht 100% prozentig funktioniert, was aber so nicht ersichtlich ist, weil eine Ausgabe den richtigen Laufwerksbuchstaben bzw. Pfad anzeigt.

    Als Workaround habe ich die Funktion direkt in das Hauptskript integriert und so funktioniert es. Vielen Dank für deine Unterstützung.

    Gruß Robert

    Mittwoch, 4. März 2015 07:40