Laufwerkmappings und die lokale Administratoren-Gruppe. Oder:
Was muss man tun, damit gemappte Laufwerke als Admin zur Verfügung stehen?
Trotz Einbindung in das Logon Script, sind eingebundene Laufwerke nicht sichtbar.
Der Grund liegt in der unterschiedlichen Behandlung von „normalem Kontext“ und „privilegiertem Kontext“.
Aber ganz von vorn. Ich hatte neulich bei einem Kunden die Aufgabe ein Login-Script zu erstellen. Dabei bin ich auf eine bekannte Tatsache gestoßen, die ich in diesem Artikel einmal näher erläutern möchte: Gemappte Laufwerke werden nicht im Explorer angezeigt, obwohl diese korrekt eingebunden sind.
Zunächst möchte ich einmal die Umstände schildern, wie ich auf das Problem gestoßen bin.
Anschließend werde ich die technischen Hintergründe und die Lösung schildern.
Index
Laufwerksmapping im Login-Script
Sehen wir uns zunächst einmal ein Beispiel eines Login-Scriptes an:
<login-script.ps1>
Die Zeile bewirkt, dass eine Verbindung zu dem Share “share” und dem Unterordner “folder” auf dem Server “server” mit dem Laufwerksbuchstaben “X:” hergestellt wird. Dies ist natürlich nur ein Beispiel.
Zu beachten ist hierbei das “/persistent:no”:
Der Parameter „/persistent:no“ bewirkt, dass Verbindungen nur für die aktuelle Sitzung gültig sind.
Sie werden bei einem Abmelden des Benutzers nicht „gemerkt“. Meldet sich der Benutzer ab und anschließend ohne Netzverbindung (bzw. ohne das Login-Script) wieder an, ist das Laufwerk nicht mehr verbunden.
Ohne den Parameter wäre die Verbindung auch ohne Netzwerk / Login-Script beim nächsten Anmelden noch verbunden.
Aus diesem Grund wird es von den meisten als “Best-Practice” angesehen „/persistent:no“ bei Laufwerksverbindungen zu setzen.
Normalerweise stellt dies auch kein Problem dar, allerdings schien das Skript bei einigen Anwendern nicht zu funktionieren. Nach kurzer Analyse stellte sich schnell heraus, dass diese Anwender auf ihrem PC in der lokalen Administrator-Gruppe waren.
Hinweis: Es ist grundsätzlich nicht ratsam seine Anwender zu lokalen Administratoren zu machen!
Hintergrund: normaler und privilegierter Kontext
Seit Windows Vista gibt es bei Microsoft die User Account Control (UAC). Die UAC bewirkt z.B. folgendes:
Meldet sich ein Nutzer, der lokaler Administrator ist, an einem PC an, werden zwei Kontexte erstellt:
- Ein “normaler” Kontext und
- ein “privilegierter” Kontext
Der Nutzer arbeitet die meiste Zeit in dem normalen Kontext. Sobald der Benutzer seine administrativen Privilegien verwenden will, fordert ihn das System auf dies zu bestätigen:
Dies resultiert darin, dass die Anwendung (hier: die Kommandozeile cmd.exe) in diesem privilegierten Kontext gestartet wird.
Eine weitere Besonderheit ist, dass Login-Skripte immer im “Admin-Kontext” ausgeführt werden, wenn der Benutzer Mitglied der lokalen Administrator-Gruppe ist.
Mitglieder der lokalen Administrator Gruppe einsehen
Sie können die Mitglieder der lokalen Administrator-Gruppe einsehen, indem Sie den “Local User Manager” starten.
Am einfachsten geht dies indem Sie auf das Start-Menü klicken und “lusrmgr.msc” eingeben:
Die Anwendung in unserem konkreten Fall ist “net use”.
Mit anderen Worten: Das Laufwerks-Mapping wird im “Admin-Kontext” ausgeführt.
Aus Sicherheitsgründen teilen sich die beiden Kontexte nicht alle Informationen. Unter Anderem werden Laufwerks-Mappings nicht zwischen „Admin-Kontext“ und “User-Kontext” geteilt.
Analyse
Wir können dieses Verhalten sehr einfach nachstellen und beweisen.
Zunächst werfen wir einen Blick auf unsere lokale Administrator-Gruppe:
Wie wir sehen, ist der User SANCTUARY\tuser1 in der lokalen Administrator-Gruppe. Diesen User werden wir für unsere Tests verwenden.
Öffnen wir nun eine Kommandozeile (cmd) und führen den Befehl aus unserem Login-Skript einmal mit richtigen Daten aus:
Ein Blick auf unseren Explorer zeigt, dass das Laufwerk erfolgreich verbunden ist:
Wenn wir jetzt eine Kommandozeile als Administrator ausführen und versuchen auf unser frisch verbundenes Laufwerk zuzugreifen scheint es aber ein Problem zu geben:
TIP: Mit dem Kommandozeilenbefehl “whoami” kann man auf Windows 7 und neueren PCs schnell sehen wie der angemeldete User heißt und gegen welche Domäne dieser authentifiziert ist!
Mit “net use” können wir uns gemappte Laufwerke in den zwei Kommandozeilen anzeigen lassen und vergleichen:
Unten ist die “privilegierte” DOS-Box und oben die “normale”.
Wie wir sehen ist also unsere Laufwerksverbindung nur im “normalen” Kontext aktiv.
Bei unserem Login-Script passiert dieser Effekt nun genau anders herum. Das Login-Script wird im Admin-Kontext ausgeführt. Daher läuft auch das “net use” in diesem privilegierten Kontext und die Verbindung ist nur dort sichtbar.
Lösung: Gemappte Laufwerke sichtbar machen
Die Lösung ist denkbar einfach und von Microsoft unterstützt (siehe Technet).
Über den Registry-Key
HKLM:\Software\Microsoft\Windows\CurrentVersion\Policies\System\EnableLinkedConnections
lässt sich erzwingen, dass Laufwerksverbindungen, die in einem der beiden Kontexte hergestellt werden, automatisch in den anderen “kopiert” werden.
Mit anderen Worten: Laufwerk-Mappings sind dann automatisch sowohl im Admin-Kontext als auch im User-Kontext vorhanden.
Der Key ist standardmäßig nicht vorhanden und muss als REG_DWORD angelegt und auf den Wert “1” gesetzt werden.
Das Ganze sieht dann so aus:
Alternativ kann man auch das /persistent:no in ein /persistent:yes ändern. Dies bewirkt ebenfalls, dass die Laufwerksverbindung im User-Kontext sichtbar ist. Allerdings mit dem Nebeneffekt, dass die Verbindung solange bleibt bis sie manuell getrennt wird.
Hinweis: Wenn man bei einer Installation von einem Netzlaufwerk den Fehler “0x8007003” (“Das System kann den angegeben Pfad nicht finden.“ / “The system cannot find the path specified.”) erhält, liegt dies mit hoher Wahrscheinlichkeit an demselbem Phänomen. Beim Aufruf des Installations-Programmes wird der Anwender aufgefordert in den privilegierten Kontext zu wechseln (UAC), hierbei “vergisst” das System aber die Laufwerksverbindung zu der Installations-Datei selbst! Der Fehler 0x8007003 ist daher auch mit dem Registry-Key EnableLinkedConnections zu lösen!
3 Comments
Leave your reply.