21
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.
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 296026
Url: https://administrator.de/contentid/296026
Printed on: April 19, 2024 at 12:04 o'clock
21 Comments
Latest comment
Hi DWW,
schon mal statt SYSTEM einen anderen Benutzer getestet?
Ich könnte mir vorstellen, dass da ein ebesondere Sperre bzgl. Local System eingebaut ist.
E.
schon mal statt SYSTEM einen anderen Benutzer getestet?
Ich könnte mir vorstellen, dass da ein ebesondere Sperre bzgl. Local System eingebaut ist.
E.
Hi.
Das macht keinen Unterschied, welcher Nutzer im Task als ausführend eingetragen ist.
Siehe auch mein Edit oben als neue Erkenntnis.
Das macht keinen Unterschied, welcher Nutzer im Task als ausführend eingetragen ist.
Siehe auch mein Edit oben als neue Erkenntnis.
Es wird noch wilder, siehe mein Edit2.
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?
Hi.
Hast Du mein Edit2 gelesen? Dann hast Du es nicht verstanden, denn ich erreiche ja schon, was ich will, wenn ich den User den Task erstellen lasse und dann als Admin den ausführenden Nutzer auf System setze. Der User kann ihn noch starten und es wird mit Systemrechten gehandelt. Leider kann man das (wie beschrieben) nur manuell setzen, und somit nicht deployen.
Ich habe auch einen Workaround für mein Ansinnen, denn ich kann Tasks ja auch über Events triggern und den schwachen Nutzer einfach zuvor ein Event schreiben lassen. Ich wüsste nur gerne, warum Win10 da etwas geändert hat - bisher sieht alles nach Bug aus.
Hast Du mein Edit2 gelesen? Dann hast Du es nicht verstanden, denn ich erreiche ja schon, was ich will, wenn ich den User den Task erstellen lasse und dann als Admin den ausführenden Nutzer auf System setze. Der User kann ihn noch starten und es wird mit Systemrechten gehandelt. Leider kann man das (wie beschrieben) nur manuell setzen, und somit nicht deployen.
Ich habe auch einen Workaround für mein Ansinnen, denn ich kann Tasks ja auch über Events triggern und den schwachen Nutzer einfach zuvor ein Event schreiben lassen. Ich wüsste nur gerne, warum Win10 da etwas geändert hat - bisher sieht alles nach Bug aus.
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.
Habe ja geschrieben, dass das nicht geht - genau das hatte ich versucht. Von Hand geht es, per Skript nicht. Alles buggiger Mistmüll.
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\TaskCacheAber 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)
Hi Uwe.
Logisch ist das nicht. Zunächst einmal ist die Notwendigkeit, User auf gesicherte Weise zu ermächtigen, Dinge mit hohen Rechten zu tun (non-interactive), weiterhin gegeben. Auch schrieb ich ja, wie man das Ziel erreichen kann. Nur deployen kann man das nicht, weil aus irgendeinem Grund die GUI anders arbeitet als ein Skript. Auf die gesamten Registryzweige habe ich schon berechtigt, alles schon erfolglos getestet.
Technet ist schon angelaufen, aber da kommt bei technisch anspruchsvollen Dingen fast nie etwas heraus. Feedback-App werde ich auch nutzen.
Logisch ist das nicht. Zunächst einmal ist die Notwendigkeit, User auf gesicherte Weise zu ermächtigen, Dinge mit hohen Rechten zu tun (non-interactive), weiterhin gegeben. Auch schrieb ich ja, wie man das Ziel erreichen kann. Nur deployen kann man das nicht, weil aus irgendeinem Grund die GUI anders arbeitet als ein Skript. Auf die gesamten Registryzweige habe ich schon berechtigt, alles schon erfolglos getestet.
Technet ist schon angelaufen, aber da kommt bei technisch anspruchsvollen Dingen fast nie etwas heraus. Feedback-App werde ich auch nutzen.
@emeriks - nö, V1 verhält sich gleich.
OK, dann halte ich jetzt mal die Klappe.
Nebenbei: Der von Dir beschriebene Workaround ist aber sehr clever! Hat der jetzt irgendeinen Nachteil, oder wie jetzt?
Nebenbei: Der von Dir beschriebene Workaround ist aber sehr clever! Hat der jetzt irgendeinen Nachteil, oder wie jetzt?
Ach, Zusatzfrage an den Powershell-Gott 
:
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.
@emeriks: nö, keine Nachteile. Ich muss lediglich Trigger anpassen.
: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.
@emeriks: nö, keine Nachteile. Ich muss lediglich Trigger anpassen.
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
Kann der normale User dann nicht auch das System-Log leeren? Würde ich nicht machen.
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.
.
OK. Ich fragte weil:
haben alle authentifizierten Benutzer und Systemdienste Schreib-, Lese- oder Löschzugriff auf dieses Protokoll.
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.
.
Ich weiß. Die Frage war aber: Man kann mit dem einen Weg als Nutzer schreiben, mit dem anderen nicht - warum? Es ist doch sinnlos, einem Benutzer etwas auf einem Weg zu verbieten, wenn er es auf anderem Wege eh erreichen kann. Und davon gibt es nun einige Beispiele. Schau Dir AD-Gruppen an - Du kannst als Nutzer, wenn die ACL der Gruppe es erlaubt, dich selbst per Powershell (Add-ADGroupMember) zu einer Gruppe hinzufügen. per net group /domain geht das nicht: "access denied". Das habe ich schon x-Mal irgendwo gesehen und es hat mit ACL-Prüfung herzlich wenig zu tun, fürchte ich, es ist einfach Schlamperei.
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 ...
Ja, sehe ich auch so.
Nun denn, danke für Eure Anregungen!
Nun denn, danke für Eure Anregungen!
