none
Wieso wird die per GPO geplante Aufgabe nicht in der Aufgabenplanung angezeigt?

    Frage

  • Hallo.

    Vielleicht kann mir hier jemand mit einem Gruppenrichtlinien Problem helfen, auf das wir gestoßen sind.

    Das Problem ist, dass bei uns in der Domäne keine Aufgaben über GPOs geplant werden können. Zum testen habe ich mir ein PowerShell Skript geschrieben, welches als Aufgabe gestartet werden soll und eine einfache Textausgabe in der Konsole ausgiebt. Jedoch wird diese Aufgabe garnicht in der Aufgabenplanung auf dem Zielsystem angezeigt. Folgende Punkte konnten wir bereits überprüfen/feststellen.

    1. Ein gpresult /r , bzw. gpresult /h ergaben, dass die Gruppenrichtlinie mit dem GPO auf dem System angewendet wird.

    2. Im Eventlog konnten wir lediglich den folgenden Fehler feststellen.

    "Das Benutzer "TestGeplanterTask"-Einstellungselement im Gruppenrichtlinienobjekt "test_geplanter_task{5B87FD85-B53A-4802-89D1-C26AC140F7AA}" wurde nicht übernommen, da ein Fehler mit Fehlercode "0x80070005 Zugriff verweiger" Dieser Fehler wurde unterdrückt. aufgetreten ist."

    3. In den folgenden Verzeichnissen werden keine Dateien zu dieser Aufgabe angelgt:
                   - C:\Windows\System32\Tasks
                   - HKLM\Software\Windows NT\CurrentVersion\Schedule\Taskcache\Tasks
                   - HKLM\Software\Windows NT\CurrentVersion\Schedule\Taskcache\Tree

    4. Zurzeit wird die Aufgabe mit dem Benutzerkonto NT-AUTORITÄT\System ausgeführt. Zudem wird Sie unabhängig von der Benutzeranmeldung und mit den höchsten Berechtigungen ausgeführt.

    5. Uns ist aufgefallen, dass in den Einstellungen des GPO der Punkt "Aufgabe erst nach folgender Leerlaufdauer starten" erscheint, obwohl der entsprechende Haken nicht durch uns gesetzt wurde. Ich habe noch keinen Weg gefunden diesen Eintrag aus den Einstellungen zu entfernen

    Ich freue mich schon auf die Antworten.

    Mit freundlichen Grüßen
    Jonas


    • Bearbeitet J0n4s Donnerstag, 24. Januar 2019 13:46
    Donnerstag, 24. Januar 2019 13:10

Antworten

  • Ich habe einen neuen Stand. Die Aufgabe wird nun endlich über ein GPO bereitgestellt und geplant. Das ganze funktioniert nun auch in einer Computerkonfiguration. Allerdings nur mit dem Benutzerkonto NT-AUTORITÄT\System.

    Für alle Leute die vielleicht hierrauf stoßen und dasselbe Problem haben:
    Wie wir feststellen mussten, ist das Eingeben einer Administratorkennung zum Beispiel nur teilweise möglich. Aufgrund einer Sicherheitslücke können in GPOs keine Passwörter mehr gespeichert werden.

    https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati

    Daher ist das nutzen einer Benutzerkennung nur möglich, wenn diese am Zielsystem angemeldet ist. Dazu muss man sagen, dass dies jedoch bei uns selbst in diesem, nicht wirklich praktischen, Fall noch nicht funktioniert. Im Computer.log des Debugging Logs steht allerdings, dass die GPO erfolgreich angewendet wurde. Wir werden aber wohl oder übel das System-Konto für unsere geplanten Aufgaben verwenden müssen. Sollte jemand einen Workaround kennen um Aufgaben per GPO zu planen und mit sicher verwarten Credentials auszuführen, darf er sich gerne melden. :D

    Vielen Dank und Grüße
    Jonas


    • Als Antwort markiert J0n4s Montag, 28. Januar 2019 14:16
    • Bearbeitet J0n4s Montag, 28. Januar 2019 14:17
    Montag, 28. Januar 2019 13:57

Alle Antworten

  • Dann aktiviere mal das Debug Logging für GPP Scheduled Tasks - https://blogs.technet.microsoft.com/askds/2008/07/18/enabling-group-policy-preferences-debug-logging-using-the-rsat/

    BTW, nachdem da "Benutzer" im Event steht - ist das eine User-GPO? Und ist "Im Kontext des angemeldeten Benutzers" aktiv?


    Greetings/Grüße, Martin - https://mvp.microsoft.com/en-us/PublicProfile/5000017 Mal ein gutes Buch über GPOs lesen? - http://www.amazon.de/Windows-Server-2012--8-Gruppenrichtlinien/dp/3866456956 Good or bad GPOs? My blog - http://evilgpo.blogspot.com And if IT bothers me? Coke bottle design refreshment - http://sdrv.ms/14t35cq

    Donnerstag, 24. Januar 2019 14:42
    Beantworter
  • Ich muss mich korigieren. Den oben genannten Fehler haben wir "behoben" indem wir eine Computerrichtlinie erstellt und den Haken für "Im Kontext des angemeldeten Benutzers" somit deaktiviert haben. Sitzen schon etwas länger an dem Problem und hatten es, da es nicht ganz so dringend ist, erstmal nach hinten geschoben. Habe da etwas in meinen Notizen durcheinander gebracht.

    Zusammenfassend:
          - Es ist nun eine Computerrichtlinie
          - folglich ist der Haken "Im Kontext des angemeldeten Benutzers" nicht gesetzt
          - das ursprüngliche Problem besteht immer noch.

    Das Debug Logging werde ich trotzdem nochmal aktivieren.

    Gruß
    Jonas

    Donnerstag, 24. Januar 2019 15:17
  • Ich habe einen neuen Stand. Die Aufgabe wird nun endlich über ein GPO bereitgestellt und geplant. Das ganze funktioniert nun auch in einer Computerkonfiguration. Allerdings nur mit dem Benutzerkonto NT-AUTORITÄT\System.

    Für alle Leute die vielleicht hierrauf stoßen und dasselbe Problem haben:
    Wie wir feststellen mussten, ist das Eingeben einer Administratorkennung zum Beispiel nur teilweise möglich. Aufgrund einer Sicherheitslücke können in GPOs keine Passwörter mehr gespeichert werden.

    https://support.microsoft.com/en-us/help/2962486/ms14-025-vulnerability-in-group-policy-preferences-could-allow-elevati

    Daher ist das nutzen einer Benutzerkennung nur möglich, wenn diese am Zielsystem angemeldet ist. Dazu muss man sagen, dass dies jedoch bei uns selbst in diesem, nicht wirklich praktischen, Fall noch nicht funktioniert. Im Computer.log des Debugging Logs steht allerdings, dass die GPO erfolgreich angewendet wurde. Wir werden aber wohl oder übel das System-Konto für unsere geplanten Aufgaben verwenden müssen. Sollte jemand einen Workaround kennen um Aufgaben per GPO zu planen und mit sicher verwarten Credentials auszuführen, darf er sich gerne melden. :D

    Vielen Dank und Grüße
    Jonas


    • Als Antwort markiert J0n4s Montag, 28. Januar 2019 14:16
    • Bearbeitet J0n4s Montag, 28. Januar 2019 14:17
    Montag, 28. Januar 2019 13:57
  • Hi,
     
    Am 28.01.2019 um 14:57 schrieb J0n4s:
    > *Für alle Leute die vielleicht hierrauf stoßen und dasselbe Problem haben:*
     
    ... wir reden von MS14-025, das ist 5 Jahre alt. Seit dem ist das
    cpassword Feld im Editor ausgegraut. Es ist aber weiterhin functional,
    wenn es im XML eingetragen ist.
     
    Bei Benutzerkonfiguration geht auch "%Logonuser%". Dann wird es als der
    CurrentUser ausgeführt, vorausgesetzt es ist ein Job, den der User
    ausführen darf. Den weg nutze ich zB bei Proxy an/aus.
     
    Tschö
    Mark
     
    --
    Mark Heitbrink
     
    Homepage:  http://www.gruppenrichtlinien.de - deutsch
     
    GET Privacy and DISABLE Telemetry on Windows 10
     
    Montag, 28. Januar 2019 20:19
  • Ich nutze bei solchen Szenarien immer ein Skript, das die geplante Aufgabe einfügt. Der CMD Befehlt Schtasks kennt die Möglichkeit Credentials mit zu geben. Der PowerShell befehlt sollte die auch kennen, dann muss nur der Zugriff auf die Scripte abgesichert werden, da dort das Password auch im Klartext steht.

    Es komplizierter, aber sicherer, schreibt ein Script auf einem Server das nach die Maschinen den Task haben überprüft und ihn ggf. einrichtet. Führt dieses Skript als geplante Aufgabe auf einem eurer Server aus.


    Viele Grüße
    Fabian Niesen
    ---
    Infrastrukturhelden.de
    LinkedIn - Xing - Twitter
    #Iwork4Dell - Opinions are my own

    Montag, 18. März 2019 05:19