11
Anmeldescript oder GPO mit zu hohen Rechten?
Hallo zusammen,
ich habe ein Problem mit der Verarbeitung eines Powershell-Anmeldescripts. Das Script ist per GPO als Anmeldescript deklariert.
Das Anmeldescript enthällt einen Aufruf auf ein externes KIX-Script.
Die Verarbeitung des Scripts funktioniert tadellos. Der Benutzer meldet sich an, das Script tut was es soll... aber mit den falschen Berechtigungen.
Client: Windows 10 Pro
Das Script verbindet einen LPT-Port mit einer Printshare, ähnlich dem Net Use Befehl. Dies funktioniert erfolgreich
in Kix:
Das Anmeldescript wird aber scheinbar unter anderen Benutzerberechtigungen ODER dem Systemaccount ausgeführt.
Mein Fazit:
Das Anmeldescript wird mit erhöhten Berechtigungen einem anderen Userkontext ausgeführt. Dieser erhält die LPT-Verbindung, aber nicht der User im normalen Kontext/Berechtigung. Der Benutzer erhält keine Druckerverbindung (von LPT zu Printshare)
Als Alternative sehe ich zur Zeit nur, das Script als geplanten Task bei Anmeldung auszuführe ... (ungetestet)
Kann jemand das Problem nachvollziehen?
Kann man GPOs oder Powershellscripte in der Ausführung auf Benutzerebene herabsetzen?
Hat jemand noch eine Idee?
Gruß, TheToxic
ich habe ein Problem mit der Verarbeitung eines Powershell-Anmeldescripts. Das Script ist per GPO als Anmeldescript deklariert.
Das Anmeldescript enthällt einen Aufruf auf ein externes KIX-Script.
Die Verarbeitung des Scripts funktioniert tadellos. Der Benutzer meldet sich an, das Script tut was es soll... aber mit den falschen Berechtigungen.
Client: Windows 10 Pro
Das Script verbindet einen LPT-Port mit einer Printshare, ähnlich dem Net Use Befehl. Dies funktioniert erfolgreich
net use LPT2 \\server\printshareuse LPT2: \\server\printshareDas Anmeldescript wird aber scheinbar unter anderen Benutzerberechtigungen ODER dem Systemaccount ausgeführt.
- Wenn ich im Script eine Auswertung zur Verbindung (net use; von LPT zur Printshare) protokolliere, so wird die Verbindung korrekt angezeigt
- Wenn ich unter dem angemeldeten User mithilfe des gleichen Befehls (net use) die Verbindung prüfe, so wird ist die Verbindung nicht hergestellt
- Wenn ich unter dem angemeldeten User das Script per Hand ausführe, so wird die Verbindung korrekt hergestellt.
Mein Fazit:
Das Anmeldescript wird mit erhöhten Berechtigungen einem anderen Userkontext ausgeführt. Dieser erhält die LPT-Verbindung, aber nicht der User im normalen Kontext/Berechtigung. Der Benutzer erhält keine Druckerverbindung (von LPT zu Printshare)
Als Alternative sehe ich zur Zeit nur, das Script als geplanten Task bei Anmeldung auszuführe ... (ungetestet)
Kann jemand das Problem nachvollziehen?
Kann man GPOs oder Powershellscripte in der Ausführung auf Benutzerebene herabsetzen?
Hat jemand noch eine Idee?
Gruß, TheToxic
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 3542122385
Url: https://administrator.de/contentid/3542122385
Ausgedruckt am: 22.11.2024 um 00:11 Uhr
11 Kommentare
Neuester Kommentar
Moin
Anmeldeskripte im Benutzerteil der GPO werden immer unter dem angemeldeten Benutzer ausgeführt. Alles andere würde ja definitiv fast immer ins Chaos führen.
Um Dein Problem einzugrenzen, fängst Du einfach an, in dem Skript die Schritte zu protokollieren. Bei deiner Annahme, es würde unter einem anderen Account ausgeführt, ermittelst Du den Benutzernamen und schreibst ihn in eine Datei. Und schon bist Du schlauer. Zumindest was diese Annahme betrifft.
Und gleichermaßen verfährst Du mit dem dann folgenden Anweisungen. Ausgabe in Datei protokollieren lassen und schon wirst Du schlauer sein.
Gruß
Zitat von @TheToxic:
Kann jemand das Problem nachvollziehen?
Kann man GPOs oder Powershellscripte in der Ausführung auf Benutzerebene herabsetzen?
Hat jemand noch eine Idee?
Kann jemand das Problem nachvollziehen?
Kann man GPOs oder Powershellscripte in der Ausführung auf Benutzerebene herabsetzen?
Hat jemand noch eine Idee?
Anmeldeskripte im Benutzerteil der GPO werden immer unter dem angemeldeten Benutzer ausgeführt. Alles andere würde ja definitiv fast immer ins Chaos führen.
Um Dein Problem einzugrenzen, fängst Du einfach an, in dem Skript die Schritte zu protokollieren. Bei deiner Annahme, es würde unter einem anderen Account ausgeführt, ermittelst Du den Benutzernamen und schreibst ihn in eine Datei. Und schon bist Du schlauer. Zumindest was diese Annahme betrifft.
Und gleichermaßen verfährst Du mit dem dann folgenden Anweisungen. Ausgabe in Datei protokollieren lassen und schon wirst Du schlauer sein.
Gruß
Moin,
So ist es, was mich zu der Frage führt: Ist es wirklich ein Anmeldeskript oder vielleicht doch ein Start-Skript?
Liebe Grüße
Erik
Zitat von @Hubert.N:
Anmeldeskripte im Benutzerteil der GPO werden immer unter dem angemeldeten Benutzer ausgeführt. Alles andere würde ja definitiv fast immer ins Chaos führen.
Anmeldeskripte im Benutzerteil der GPO werden immer unter dem angemeldeten Benutzer ausgeführt. Alles andere würde ja definitiv fast immer ins Chaos führen.
So ist es, was mich zu der Frage führt: Ist es wirklich ein Anmeldeskript oder vielleicht doch ein Start-Skript?
Liebe Grüße
Erik
Ich glaube ich habe mit dem Problem wie im Bild zu sehen ist zu kämpfen.
Das Bild sind zwei CMD nebeneinander.
In dieser Reihenfolge abgearbeitet:
1. net use als Administrator um Laufwerk zu verbinden
2. Laufwerk wird unter dem User "als Adminstrator" verbunden
3. Laufwerk ist für den User mit normalen Rechten nicht aufrufbar.
Das Bild sind zwei CMD nebeneinander.
- Rechts "als Administrator" Laufwerk verbunden und angezeigt
- Links mit normalen Berechtigungen die Verbindung angezeigt
In dieser Reihenfolge abgearbeitet:
1. net use als Administrator um Laufwerk zu verbinden
2. Laufwerk wird unter dem User "als Adminstrator" verbunden
3. Laufwerk ist für den User mit normalen Rechten nicht aufrufbar.
... wobei die Frage bleibt, was die tatsächlichen Anweisungen als Ausgabe haben.
und nein. Es ist per default nicht möglich, ein Anmeldeskript als Benutzer mit erhöhten Rechten zu starten. Wenn man das will, muss man dafür extra in die Trickkiste greifen.
Ich tippe eher auf etwas ganz banales, wie "ich verwende eine Variable, die zu dem Zeitpunkt nicht zur Verfügung steht" o.ä. Das sollte aber eine Protokollierung der Befehle zeigen.
Du kannst auch mal versuchen, das Skript in der GPO unter Benutzer\Administrative Vorlagen\System\Anmelden\Diese Programme bei... zu definieren. Dann wird die Ausführung etwas später gestartet.
Oder unter Computer\Administrative Vorlagen\System\Gruppenrichtlinie\Anmeldeskriptverzögerung konfigurieren die Verzögerung global einstellen.
Ist bei dir konfiguriert, dass bei der Anmeldung auf das Netzwerk gewartet wird? Vlt. ist sonst es ja auch so unglaublich einfach, dass Du Befehle zum Verbinden einer Netzwerkressource ausführst, diese aber zu dem Zeitpunkt noch nicht zur Verfügung steht, weil das Netzwerk noch nicht zur Verfügung steht.
Womit ich aber wieder bei mir selbst bin denn ich schrieb:
All diese Dinge würdest Du sehen, wenn Du die Ausgaben Deiner Befehle in eine Datei schreiben würdest...
Gruß
und nein. Es ist per default nicht möglich, ein Anmeldeskript als Benutzer mit erhöhten Rechten zu starten. Wenn man das will, muss man dafür extra in die Trickkiste greifen.
Ich tippe eher auf etwas ganz banales, wie "ich verwende eine Variable, die zu dem Zeitpunkt nicht zur Verfügung steht" o.ä. Das sollte aber eine Protokollierung der Befehle zeigen.
Du kannst auch mal versuchen, das Skript in der GPO unter Benutzer\Administrative Vorlagen\System\Anmelden\Diese Programme bei... zu definieren. Dann wird die Ausführung etwas später gestartet.
Oder unter Computer\Administrative Vorlagen\System\Gruppenrichtlinie\Anmeldeskriptverzögerung konfigurieren die Verzögerung global einstellen.
Ist bei dir konfiguriert, dass bei der Anmeldung auf das Netzwerk gewartet wird? Vlt. ist sonst es ja auch so unglaublich einfach, dass Du Befehle zum Verbinden einer Netzwerkressource ausführst, diese aber zu dem Zeitpunkt noch nicht zur Verfügung steht, weil das Netzwerk noch nicht zur Verfügung steht.
Womit ich aber wieder bei mir selbst bin denn ich schrieb:
Zitat von @Hubert.N:
Um Dein Problem einzugrenzen, fängst Du einfach an, in dem Skript die Schritte zu protokollieren. (...)
Und gleichermaßen verfährst Du mit dem dann folgenden Anweisungen. Ausgabe in Datei protokollieren lassen und schon wirst Du schlauer sein.
Um Dein Problem einzugrenzen, fängst Du einfach an, in dem Skript die Schritte zu protokollieren. (...)
Und gleichermaßen verfährst Du mit dem dann folgenden Anweisungen. Ausgabe in Datei protokollieren lassen und schon wirst Du schlauer sein.
All diese Dinge würdest Du sehen, wenn Du die Ausgaben Deiner Befehle in eine Datei schreiben würdest...
Gruß
Ich glaube ich habe mit dem Problem wie im Bild zu sehen ist zu kämpfen.
nun sind wir also von einer Druckerverbindung zu einem Laufwerk gekommen?!
Noch mal:
- teste es erst einmal als Benutzer manuell
- schreibe in das Skript am Ende des Befehls ein >> <lokaler Speicherort mit Zugriff für alle>\logon.txt
- schaue in die logon.txt, was da steht.
@Hubert.N
Wie ich bereits geschrieben habe wird das Script erfolgreich ausgeführt. Die LPT-Verbindung wird korrekt hergestellt. Hier ist keine Variable falsch, das Netzwerk steht zur Verfügung. Es wurde alles ausführlich unter dem User manuell getestet -> alles schick
Nur eben per GPO-Anmeldescript habe ich diesen merkwürdigen Effekt wie im Screenshot dargestellt.
Das Script verbindet die LPT zur Printshare, (auch im Log, auch mit dem gleichen User), nur sieht man im "normalen" Kontext des Benutzers nichts davon.
Ist das dein Ernst? Net use ist es egal ob es Laufwerk oder eine LPT umleitung ist! Dies war ein Beispiel um das Fehlerbild darzustellen.
Wie ich bereits geschrieben habe wird das Script erfolgreich ausgeführt. Die LPT-Verbindung wird korrekt hergestellt. Hier ist keine Variable falsch, das Netzwerk steht zur Verfügung. Es wurde alles ausführlich unter dem User manuell getestet -> alles schick
Nur eben per GPO-Anmeldescript habe ich diesen merkwürdigen Effekt wie im Screenshot dargestellt.
Das Script verbindet die LPT zur Printshare, (auch im Log, auch mit dem gleichen User), nur sieht man im "normalen" Kontext des Benutzers nichts davon.
Zitat von @Hubert.N:
Du kannst auch mal versuchen, das Skript in der GPO unter Benutzer\Administrative Vorlagen\System\Anmelden\Diese Programme bei... zu definieren.
Das werde ich probieren.Du kannst auch mal versuchen, das Skript in der GPO unter Benutzer\Administrative Vorlagen\System\Anmelden\Diese Programme bei... zu definieren.
Ist das dein Ernst? Net use ist es egal ob es Laufwerk oder eine LPT umleitung ist! Dies war ein Beispiel um das Fehlerbild darzustellen.
o.k. ... Skript wird also erfolgreich ausgeführt.
Wenn das so ist und (also z.B. mit der Verbindung des Netzlaufwerkes) im Protokoll dann steht, dass der Vorgang erfolgreich war und Anmeldeskripte immer im Kontext des Benutzer ohne erhöhte Rechte ausgeführt werden (das ist so "by Design"), dann bleibt für mich nur als logische Erklärung, dass Du anschließend den Explorer oder was auch immer in einem andern Kontext startest.
Wenn das so ist und (also z.B. mit der Verbindung des Netzlaufwerkes) im Protokoll dann steht, dass der Vorgang erfolgreich war und Anmeldeskripte immer im Kontext des Benutzer ohne erhöhte Rechte ausgeführt werden (das ist so "by Design"), dann bleibt für mich nur als logische Erklärung, dass Du anschließend den Explorer oder was auch immer in einem andern Kontext startest.
@Hubert.N
Exakt so ist es. Nun sprechen wir die gleiche Sprache
Nur dass ein Anmelde-Script mit erhöhten Rechten ausgeführt wird und nicht mit normalen Rechten im Kontext des Benutzers. Das merkt man scheinbar nur mit aktiver UAC.
Nach einiger Suche habe ich eine Lösung dafür gefunden.
https://docs.microsoft.com/de-de/troubleshoot/windows-client/networking/ ...
http://woshub.com/how-to-access-mapped-network-drives-from-the-elevated ...
Unglaublich aber wahr, man muss einen Reg-Key setzten damit die Abarbeitung erfolgreich funktioniert...
Im zweiten Link wird genau das Verhalten beschrieben.
Exakt so ist es. Nun sprechen wir die gleiche Sprache
Nur dass ein Anmelde-Script mit erhöhten Rechten ausgeführt wird und nicht mit normalen Rechten im Kontext des Benutzers. Das merkt man scheinbar nur mit aktiver UAC.
Nach einiger Suche habe ich eine Lösung dafür gefunden.
https://docs.microsoft.com/de-de/troubleshoot/windows-client/networking/ ...
http://woshub.com/how-to-access-mapped-network-drives-from-the-elevated ...
Unglaublich aber wahr, man muss einen Reg-Key setzten damit die Abarbeitung erfolgreich funktioniert...
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
Typ: DWORD(32-Bit)-Wert
Name: EnableLinkedConnections
Value: 1Im zweiten Link wird genau das Verhalten beschrieben.
EnableLinkedConnections registry parameter, LanmanWorkstation and LSA (lsass.exe) will check for a second access token associated to the session of the current user. If this token is found, the list of the mapped network drives will be copied from one token to another. Thus, the network drives mapped in the privileged mode will be visible in the normal mode, and vice versa.
Korrektur... leider ist dies doch nicht des Rätsels Lösung...
Am Test-PC/Tesut-User ja... im Echtsystem... Nein
Aber es hat etwas mit erhöhten Rechten zu tun... Ich berichte erneut wenn ich das Problem gefunden habe...
Am Test-PC/Tesut-User ja... im Echtsystem... Nein
Aber es hat etwas mit erhöhten Rechten zu tun... Ich berichte erneut wenn ich das Problem gefunden habe...
Tatsächlich ist es doch die oben beschriebene Lösung.
Jedoch hatte ich vergessen einen Parameter per GPO zu verteilen:
Erst mit der Kombination aus Richtlinie und Reg-Key klappt die Verbindung.
Manche PCs haben den Registry-Key bereits gesetzt... das hängt offenbar von dem verwendeten OS-Version mit ab.
@Hubert.N
Danke für deine Unterstützung
Jedoch hatte ich vergessen einen Parameter per GPO zu verteilen:
Suchen Sie im Editor für lokale Gruppenrichtlinien den folgenden Gruppenrichtlinienpfad:
Richtlinie für lokale Computer\Windows Einstellungen\Sicherheit Einstellungen\Lokale Richtlinien\Sicherheitsoptionen
Konfigurieren Sie die folgende Richtlinie, um die Zustimmung einzufordern: Benutzerkontensteuerung: Verhalten der Eingabeaufforderung für Erhöhte Rechte für Administratoren im AdministratorgenehmigungsmodusErst mit der Kombination aus Richtlinie und Reg-Key klappt die Verbindung.
Manche PCs haben den Registry-Key bereits gesetzt... das hängt offenbar von dem verwendeten OS-Version mit ab.
@Hubert.N
Danke für deine Unterstützung
