Nutzer zur Ausführung von fremden Tasks berechtigen - Windows 10 kann es offenbar nicht
Hi.
Mir scheint, ich bin auf einen weiteren Bug gestoßen:
Ich arbeite in der Administration sehr häufig mit Tasks. Unter anderem berechtige ich Nutzer, definierte Skripte mit Systemrechten auszuführen, indem ich einen Task deploye, den Nutzer lesen und ausführen, aber nicht verändern dürfen. Seit dem Umstieg auf Windows 10 läuft der Task nicht mehr, der Nutzer erhält "Zugriff verweigert".
Auf 7 und 8.1 läuft das und ich habe keine Idee, was der Grund sein soll - außer einem Bug.
Vielleicht hat hier jemand eine Idee.
Zum Nachstellen:
Taskname: test
Ausführendes Konto: system (oder auch gerne ein anderer)
Trigger: einmalig (jetzt)
Aktion: notepad
Zum Berechtigen des Nutzers: Lese- und Ausführrecht vergeben auf c:\windows\system32\tasks\test
--
Führt der Nutzer nun aus
schtasks /run /tn test
läuft das auf 7/8.1 während auf 10 "Zugriff verweigert" kommt.
--
Edit: kleiner Fortschritt: ich habe festgestellt, dass der User auf Win10 (und nur dort) die Tasks nicht einmal listen kann, weder in der GUI, noch über die Kommandozeile. NIcht einmal dann, wenn wir ihn zum Besitzer der Datei samt Vollzugriff machen.
Edit2: wenn ich den User selbst einen Task manuell anlegen lasse, kann er ihn natürlich sehen und starten. Editiere ich dann den Task als Admin und trage "System" als ausführendes Konto ein, kann der User den Task danach noch starten, ihn aber nicht modifizieren - prima. Will ich das aber deployen, zum Beispiel über ein Startskript und mache genau das, was ich über die GUI mache, nämlich
schtasks /change /tn test /ru ""
dann wird die Änderung angenommen, das Resultat sieht auch gleich aus, dennoch kann der Nutzer den Task nicht starten "Konto hat nicht das Recht , den Task zu starten".
Super. Win10 bug-approved.
Mir scheint, ich bin auf einen weiteren Bug gestoßen:
Ich arbeite in der Administration sehr häufig mit Tasks. Unter anderem berechtige ich Nutzer, definierte Skripte mit Systemrechten auszuführen, indem ich einen Task deploye, den Nutzer lesen und ausführen, aber nicht verändern dürfen. Seit dem Umstieg auf Windows 10 läuft der Task nicht mehr, der Nutzer erhält "Zugriff verweigert".
Auf 7 und 8.1 läuft das und ich habe keine Idee, was der Grund sein soll - außer einem Bug.
Vielleicht hat hier jemand eine Idee.
Zum Nachstellen:
Taskname: test
Ausführendes Konto: system (oder auch gerne ein anderer)
Trigger: einmalig (jetzt)
Aktion: notepad
Zum Berechtigen des Nutzers: Lese- und Ausführrecht vergeben auf c:\windows\system32\tasks\test
--
Führt der Nutzer nun aus
schtasks /run /tn test
läuft das auf 7/8.1 während auf 10 "Zugriff verweigert" kommt.
--
Edit: kleiner Fortschritt: ich habe festgestellt, dass der User auf Win10 (und nur dort) die Tasks nicht einmal listen kann, weder in der GUI, noch über die Kommandozeile. NIcht einmal dann, wenn wir ihn zum Besitzer der Datei samt Vollzugriff machen.
Edit2: wenn ich den User selbst einen Task manuell anlegen lasse, kann er ihn natürlich sehen und starten. Editiere ich dann den Task als Admin und trage "System" als ausführendes Konto ein, kann der User den Task danach noch starten, ihn aber nicht modifizieren - prima. Will ich das aber deployen, zum Beispiel über ein Startskript und mache genau das, was ich über die GUI mache, nämlich
schtasks /change /tn test /ru ""
dann wird die Änderung angenommen, das Resultat sieht auch gleich aus, dennoch kann der Nutzer den Task nicht starten "Konto hat nicht das Recht , den Task zu starten".
Super. Win10 bug-approved.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 296026
Url: https://administrator.de/contentid/296026
Ausgedruckt am: 24.11.2024 um 03:11 Uhr
21 Kommentare
Neuester Kommentar
DWW, wenn Du schon mal dabei bist ...
Mach mal die Gegenprobe. Editiere als Admin und trag alles wieder so ein, wie es war, als der User es erstellt hat. Kann der User den Task dann noch starten?
Das Ergebnis könnte Aufschluss darüber geben, ob die Ursache allein daran liegt, dass der (ein) Admin den Task bearbeitet hat, oder ob es möglicherweise daran liegt, dass der Task dann unter Local System laufen soll. Überhaupt: Wennn Du den Task dann als Adimin editierst und einen anderen Benutzer statt Local System einträgst - geht es dann?
Mach mal die Gegenprobe. Editiere als Admin und trag alles wieder so ein, wie es war, als der User es erstellt hat. Kann der User den Task dann noch starten?
Das Ergebnis könnte Aufschluss darüber geben, ob die Ursache allein daran liegt, dass der (ein) Admin den Task bearbeitet hat, oder ob es möglicherweise daran liegt, dass der Task dann unter Local System laufen soll. Überhaupt: Wennn Du den Task dann als Adimin editierst und einen anderen Benutzer statt Local System einträgst - geht es dann?
Ja, leicht überlesen.
Und so: ?
User Loginscript erstellt Task.
Computer-Startupscript prüft ob Task mit bestimmten Namen (kann man auch mit Pfad spezifizieren) da, und wenn ja, dann modifizieren.
Somit ist dieser Task zwar erst nach 2x Booten in der gewünschten Fassung da. Aber wenn der Task einmal existiert, dann kannst Du ihn doch jederzeit mit dem Computer Startup-Script anpassen.
Trotzdem doof und umständlich, ja.
Und so: ?
User Loginscript erstellt Task.
Computer-Startupscript prüft ob Task mit bestimmten Namen (kann man auch mit Pfad spezifizieren) da, und wenn ja, dann modifizieren.
Somit ist dieser Task zwar erst nach 2x Booten in der gewünschten Fassung da. Aber wenn der Task einmal existiert, dann kannst Du ihn doch jederzeit mit dem Computer Startup-Script anpassen.
Trotzdem doof und umständlich, ja.
Moin DWW.
Hast du nicht mal in Erwägung gezogen das MS hier eventuell aus Sicherheitsgründen Hand angelegt hat, wäre für mich eine logische Erklärung.
Du bist doch immer so besessen von den ganzen Lockdown-Features.
Weitere Infos zu den Tasks wie Hashes, werden in der Registry abgelegt:
Aber wer weiß. Melde es einfach mal im Technet, oder übers Feedback.
Grüße Uwe
Hast du nicht mal in Erwägung gezogen das MS hier eventuell aus Sicherheitsgründen Hand angelegt hat, wäre für mich eine logische Erklärung.
Du bist doch immer so besessen von den ganzen Lockdown-Features.
Weitere Infos zu den Tasks wie Hashes, werden in der Registry abgelegt:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Schedule\TaskCache
Aber wer weiß. Melde es einfach mal im Technet, oder übers Feedback.
Grüße Uwe
Edit: kleiner Fortschritt: ich habe festgestellt, dass der User auf Win10 (und nur dort) die Tasks nicht einmal listen kann, weder in der GUI, noch über die Kommandozeile. NIcht einmal dann, wenn wir ihn zum Besitzer der Datei samt Vollzugriff machen.
Macht es einen Unterschied, wenn Du den Task als V1 erstellst? Bzw. gibt es das bei Win10 überhaupt noch? (Komme hier gerade an kein Win10 ran)Zitat von @DerWoWusste:
Wenn ich mittels evencreate.exe ins Eventlog schreibe, brauche ich Adminrechte für alle Logs (access denied). Mittels powershell cmdlet Write-EventLog kann ich das selbe ohne Adminrechte machen (außer Securitylog). Warum? Richtig, buggiger MM.
Den Zugriff kannst du per GPO mit SDDL Einträgen einschränken:Wenn ich mittels evencreate.exe ins Eventlog schreibe, brauche ich Adminrechte für alle Logs (access denied). Mittels powershell cmdlet Write-EventLog kann ich das selbe ohne Adminrechte machen (außer Securitylog). Warum? Richtig, buggiger MM.
Administrative Vorlagen > Windows Komponenten > Ereignisprotokolldienst > (System/Anwendung/Sicherheit) > (Protokollzugriff konfigurieren)
Diese Richtlinieneinstellung gibt den für das Protokoll zu verwendenden Sicherheitsdeskriptor mithilfe der SDDL (Security Descriptor Definition Language)-Zeichenfolge an.
Wenn Sie diese Richtlinieneinstellung aktivieren, können nur Benutzer, die dem Sicherheitsdeskriptor entsprechen, auf das Protokoll zugreifen.
Wenn Sie diese Richtlinieneinstellung deaktivieren oder nicht konfigurieren, haben alle authentifizierten Benutzer und Systemdienste Schreib-, Lese- oder Löschzugriff auf dieses Protokoll.
Hinweis: Wenn Sie diese Richtlinieneinstellung aktivieren, kann sie von einigen Tools und APIs ignoriert werden. Die gleiche Änderung sollte an der Richtlinieneinstellung "Protokollzugriff konfigurieren (Legacy)" vorgenommen werden, um diese Änderung für alle Tools und APIs zu erzwingen.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\EventLog
Zitat von @emeriks:
Kann der normale User dann nicht auch das System-Log leeren? Würde ich nicht machen.
Via Powershell geht das Löschen der Logs hier mit einem normalen User nicht (Zugriff verweigert), Glück gehabt .Kann der normale User dann nicht auch das System-Log leeren? Würde ich nicht machen.
Zitat von @emeriks:
OK. Ich fragte weil:
Den Text hatte ich nur aus der GPO zitiert, ist also nicht auf meinem Mist gewachsen .OK. Ich fragte weil:
haben alle authentifizierten Benutzer und Systemdienste Schreib-, Lese- oder Löschzugriff auf dieses Protokoll.
Zitat von @DerWoWusste:
Ich weiß. Die Frage war aber: Man kann mit dem einen Weg als Nutzer schreiben, mit dem anderen nicht - warum?
Das wird vermutlich der Verwendung der unterschiedlichen APIs geschuldet sein, oder sie haben den Überblick ganz einfach verloren, so kann ich es mir nur erklären.Ich weiß. Die Frage war aber: Man kann mit dem einen Weg als Nutzer schreiben, mit dem anderen nicht - warum?
es ist einfach Schlamperei.
Wundert mich nicht mehr. Da hängt bestimmt noch zu viel alte Sch... aus NT-Zeiten mit drin. Damals hat doch ein Programmierer der MS verlassen hat, und welcher mit an Änderungen des Windows-Kernels gearbeitet hat gesagt, dass bei MS kaum noch einer den alten Spaghetti-Code versteht bzw die Wartung so aufwendig ist. Das sagt wohl alles ...