Anmeldescript oder GPO mit zu hohen Rechten?

thetoxic
Goto Top
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.

  • 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

Content-Key: 3542122385

Url: https://administrator.de/contentid/3542122385

Ausgedruckt am: 18.08.2022 um 23:08 Uhr

Mitglied: Hubert.N
Hubert.N 04.08.2022 um 13:28:55 Uhr
Goto Top
Moin

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?

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ß
Mitglied: erikro
erikro 04.08.2022 um 13:37:03 Uhr
Goto Top
Moin,

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.

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
Mitglied: TheToxic
TheToxic 04.08.2022 um 13:54:59 Uhr
Goto Top
@Hubert.N
Hatte ich bereits getan. Das Anmelde-Script wird laut Log unter dem angemeldeten User ausgeführt. -> so auch i.O.
Ich vermute dass das Script jedoch mit erhöhten Rechten ("Als Administrator") oder in ähnlicher Form ausgeführt wird.

@erikro
Es ist ein Anmeldescript.

Gruß,
TheToxic
Mitglied: TheToxic
TheToxic 04.08.2022 um 14:03:17 Uhr
Goto Top
Ich glaube ich habe mit dem Problem wie im Bild zu sehen ist zu kämpfen.

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.
netuse
Mitglied: Hubert.N
Hubert.N 04.08.2022 um 14:17:45 Uhr
Goto Top
... 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:

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.

All diese Dinge würdest Du sehen, wenn Du die Ausgaben Deiner Befehle in eine Datei schreiben würdest...

Gruß
Mitglied: Hubert.N
Hubert.N 04.08.2022 aktualisiert um 14:24:43 Uhr
Goto Top
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.
Mitglied: TheToxic
TheToxic 04.08.2022 um 14:53:07 Uhr
Goto Top
@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.

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.

Zitat von @Hubert.N:
nun sind wir also von einer Druckerverbindung zu einem Laufwerk gekommen?!

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.
Mitglied: Hubert.N
Hubert.N 04.08.2022 aktualisiert um 15:18:27 Uhr
Goto Top
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.
Mitglied: TheToxic
Lösung TheToxic 05.08.2022 um 07:01:09 Uhr
Goto Top
@Hubert.N
Exakt so ist es. Nun sprechen wir die gleiche Sprache face-wink
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.
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.

Mitglied: TheToxic
TheToxic 05.08.2022 um 07:15:44 Uhr
Goto Top
Korrektur... leider ist dies doch nicht des Rätsels Lösung...
Am Test-PC/Tesut-User ja... im Echtsystem... Nein face-sad
Aber es hat etwas mit erhöhten Rechten zu tun... Ich berichte erneut wenn ich das Problem gefunden habe...
Mitglied: TheToxic
Lösung TheToxic 08.08.2022 um 12:15:50 Uhr
Goto Top
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