none
Check ob User Get-ADQuery nutzen darf RRS feed

  • Frage

  • Hallo,

    ich habe ein Script geschrieben welches überprüft ob AD Benutzer vorhanden sind oder Deaktiviert wurden. Sollte ein User nicht vorhanden bzw. deaktiviert worden sein. So wird sein Home Verzeichnis automatisch gelöscht.

    Nun habe ich aber mit dem Gedanken gespielt, was wohl passiert wenn der User, der dieses Script ausführt, kein Recht hat die AD abzufragen. Nach diesem Schema würde das Script davon ausgehen, das es den Benutzer nicht gibt und den Ordner löschen.

    Meine "Idee" wäre nun einen vorgeschalteten Check hinzuzufügen, welcher überprüft ob der User in der Lage ist die AD abzufragen. Diesen Check wollte ich aber so allgemein wie möglich halten. Sprich ich wollte nicht einfach einen mir bekannten Benutzer abfragen. So welche Konstanten können Sich ja immer Ändern und würden in der Zukunft zu Problemen führen.

    Gibt es hier irgendetwas?

    MfG

    Donnerstag, 2. Februar 2017 12:17

Antworten

  • Hi,

    vielleicht dann ganz einfach am Anfang des Scriptes was "festes" im AD abfragen. z.B.: eine OU. Ist es der lokale Admin wird der die Abfrage scheitern ...

    Du könnest auch prüfen, ob der User der das Script ausführt im AD vorhanden ist. $env:Username z.B.:

    Beste Gruesse
    brima 

    • Als Antwort markiert MarcelWie Donnerstag, 2. Februar 2017 14:08
    Donnerstag, 2. Februar 2017 14:04

Alle Antworten

  • Hallo,

    wir sehen von deinem Script nicht all zu viel, aber so wie du das Verhalten interpretierst solltest Du nochmal intensiver darüber nachdenken.

    Beste Gruesse
    brima

    Donnerstag, 2. Februar 2017 13:31
  • Hallo,

    hier ist das Script. Aber ich wüsste nicht wie ich prüfen kann ob ein User nicht vorhanden ist und dabei zu unterscheiden ob er einfach nicht die AD Abfragen darf, oder es den User einfach nicht gibt:

    # Source is the directory that the script should check for folders which doesn't resemble an user account
    $source="F:\TS-Profiles\"
    
    # Destination is the directory where the script moves the orphan folders
    $destination="F:\Archive\TS-Profiles\"
    
    If (Test-Path $source) {
        $folders=Get-ChildItem -Path $source | Select-Object name
        $date = Get-Date -format "yyyyMMdd"
        foreach ($folder in $folders){
            try {
                $user=Get-ADUser ($folder.name -replace ".XXX.V2")
            }
            catch {
                Clear-Variable user
            }
            $useracc=$user.Enabled
            $userid=$user.SamAccountName
            $fullpath=$source + $folder.name
            $newid=$date + "_" + $folder.name
            if ($userid -eq $null -or $useracc -eq $False) {
                if ($userid -eq $null) {
                    Write-Host $fullpath "- No owner found, orphan folder moved to" ($destination + $newid) -ForegroundColor Red
                    Move-Item $fullpath ($destination + $newid)
                }
                if ($useracc -eq $False) {
                    Write-Host $fullpath "- User account" $user.SamAccountName "disabled, orphan folder moved to" ($destination + $newid) -ForegroundColor Red
                    Move-Item $fullpath ($destination + $newid)
                }        
            }
        }
    }


    Donnerstag, 2. Februar 2017 13:38
  • Hi,

    das Script arbeitet ja schon mal anderes wie es aus deiner Beschreibung ohne es zu sehen hervor ging, es wird nicht gelöscht sondern erst mal nur verschoben, gut so.

    Zudem ist nicht der User die Quelle sondern die Verzeichnisse.

    User die mit dem AD verbunden sind sollten im Normal auch einen lesenden Zugriff haben.

    User die nicht mit dem AD verbunden sind sollten ehre nicht das Recht haben, Homeshares zu verscheieben, löschen usw.

    Beste Gruesse
    brima


    • Bearbeitet brima Donnerstag, 2. Februar 2017 13:52
    Donnerstag, 2. Februar 2017 13:52
  • Moin,

    das genannte Script wird auf dem Fileserver ausgeführt. Meine Worst Case Situation wäre, das jemand mit lokalen Admin Rechten sich auf dem Server anmeldet und das Script ausführt. Der lokale Admin User hätte halt keinen AD Zugriff und es würde theoretisch zum Verschieben der Verzeichnisse kommen.

    MfG

    Donnerstag, 2. Februar 2017 13:57
  • Hi,

    vielleicht dann ganz einfach am Anfang des Scriptes was "festes" im AD abfragen. z.B.: eine OU. Ist es der lokale Admin wird der die Abfrage scheitern ...

    Du könnest auch prüfen, ob der User der das Script ausführt im AD vorhanden ist. $env:Username z.B.:

    Beste Gruesse
    brima 

    • Als Antwort markiert MarcelWie Donnerstag, 2. Februar 2017 14:08
    Donnerstag, 2. Februar 2017 14:04
  • Moin,

    die Idee mit dem Prüfen des eigenen Benutzers ist die beste Idee. Es macht es Dynamisch und vermindert Fehler. Vielen Dank für den Tipp! 

    Donnerstag, 2. Februar 2017 14:08
  • > das genannte Script wird auf dem Fileserver ausgeführt.
     
    Da ist der Fehler... Das Skript sollte auf einem Domain Controller laufen (am besten im SYSTEM Kontext), dann darf es garantiert alles lesen. Daraus erstellst Du ein Ergebnis, das Du lokal auf dem Domain Controller ablegst. Mit Hilfe eines zweiten Task (mit anderem User, entsprechend berechtigt) transferierst Du es dann auf den Fileserver. Dort wird es von einem dritten Task weiter verarbeitet.
     
    PS: Wenn sich jemand mit Adminrechten auf einem Server anmelden kann, dann sollte er diese Adminrechte auch verdienen :-)
     
    Donnerstag, 2. Februar 2017 16:34
  • > die Idee mit dem Prüfen des eigenen Benutzers ist die beste Idee.
     
    Hilft leider nichts, wenn im AD viel mit ACLs gearbeitet wird... Wenn List Object Mode aktiviert ist, finde ich keine Objekte, auf die ich keine Leserechte habe. Ist dann, als wenn sie nicht existieren würden.
     
    Donnerstag, 2. Februar 2017 16:36