• Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN
info@firstattribute.com
by FirstAttribute
Active Directory FAQActive Directory FAQ
  • Active Directory
    • AD Consulting
    • AD Design
      • Domain Name festlegen
      • Domain Struktur einrichten
      • Forest Struktur definieren
    • AD Management
    • AD Automation
      • Dynamic Access Control (DAC)
    • AD Federation Services
      • ADFS Betrieb
      • ADFS und Office365
      • ADFS und Cisco Unified Communications Manager
      • SAML und ADFS 2.0
  • Azure / M365
    • Azure AD
    • Microsoft 365 (O365)
  • Migration
    • Active Directory Migration
    • Exchange Migration
    • File Server Migration
    • Lotus Notes Migration
    • Novell Migration
  • Wissen
    • Alle Beiträge
    • Administration
    • PowerShell
    • Migration
    • Exchange
    • Tools
  • Kontakt
    • Wir über uns
    • Kontakt
  • EN

Gemappte Laufwerke werden nicht im Explorer angezeigt

Okt 19, 2020 (Letztes Update) | Posted by Hannes Hayashi Administration, KnowHow, Konfiguration |

 

Gemappte Laufwerke werden nicht im Explorer angezeigt

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.

Inhaltsverzeichnis

  • 1 Laufwerksmapping im Login-Script
  • 2 Hintergrund: normaler und privilegierter Kontext
    • 2.1  Mitglieder der lokalen Administrator Gruppe einsehen
  • 3 Analyse
  • 4 Lösung: Gemappte Laufwerke sichtbar machen

Laufwerksmapping im Login-Script

Sehen wir uns zunächst einmal ein Beispiel eines Login-Scriptes an:

<login-script.ps1>

net-use X: \\server\share\folder /persistent:no

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:

User Account Control (UAC)

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:

Local-User-Manager-lusrmgr.exe

Windows 7 Lusrmgr.exe – Unter Windows 8.x geht dies über die Modern-UI Oberfläche

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:

local-admins-group

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:

net-use-user

Ein Blick auf unseren Explorer zeigt, dass das Laufwerk erfolgreich verbunden ist:

explorer

Wenn wir jetzt eine Kommandozeile als Administrator ausführen und versuchen auf unser frisch verbundenes Laufwerk zuzugreifen scheint es aber ein Problem zu geben:

explorer-cmd-admin

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:

net-use-vergleich

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.

 

net-use-vergleich-admin

 

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:

regedit

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!


 

Artikel weiterempfehlen:
  • teilen
  • tweeten
  • sharen
  • xingen
  • mailen
Artikel erstellt am: 20.11.2014
Tags: Laufwerksmappingprivilegierter Kontext
3

3 Comments

Leave your reply.
  • Nikolaizik
    · Antworten

    8. März 2017 at 2:43 PM

    Hallo,
    leider funktioniert bei uns das Prozedere auf einem Windows Server2012R2 nicht. Die Anzeigen zwischen Explorer und CMD(Admin) nicht trotz Reg-Eintrag und /persistent:yes nicht identisch.

    Muss bei diesem Betriebssystem noch etwas beachtet werden?

    VG Nikolaizik

  • ramses
    · Antworten

    21. April 2016 at 1:22 PM

    Hi,

    vielen Dank für deine Hilfe.
    Ich habe etwas länger gebraucht bis ich feststellen konnte, dass es nicht am Computer liegt und auch „nicht am User“.
    Denn bei vielen Anwendern hat es ja funktioniert ;-).
    Jedoch bin ich auch zum Entschluss gekommen, dass es an den Adminrechten liegt.
    Vielen Dank nochmal und weiter so.

    lg ramses

Leave a Reply

<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>
Cancel Reply

FirstWare IDM-Portal im Test: IT-Administrator 08-2022

 

ADFAQ-FirstAttribute

Wer schreibt ?

Team der FirstAttribute AG

Consultants und Entwickler der FirstAttribute arbeiten seit mehr als 20 Jahren in IAM- und Cloud-Transition-Projekten.
Zusammen verfügen Sie über einen wertvollen Erfahrungsschatz im Bereich Active Directory und Azure AD und teilen diesen auf Active Directory FAQ.

Neueste Artikel

  • 8 Tipps für mehr Sicherheit in Active Directory und Backups von AD
  • Azure AD Custom Security Attributes ermöglichen flexible Berechtigungsstrukturen
  • Dateiberechtigungen in MS Teams und SharePoint Online verwalten – So funktioniert es
  • AD-Gruppen in Microsoft Teams verwenden – Dynamische Gruppen in der Praxis
  • Verbindung zwischen Microsoft 365 und SharePoint Online zu Azure AD

Unsere IAM-Lösungen

Ihre IAM-Lösung: FirstWare IDM-Portal

 

my-IAM für Cloud Identity Management in Microsoft Teams

Kontakt aufnehmen

Sie haben eine Frage oder Anmerkung? Schicken Sie uns schnell eine Nachricht.

Nachricht senden
Jetzt AD Tasks vereinfachen und delegieren: FirstWare IDM-Portal

Folgen Sie uns

Kontakt

  • FirstAttribute AG
  • Am Büchele 18, 86928 Hofstetten, Germany
  • +49 89 215 442 400
  • https://www.firstattribute.com

Schlagwörter

.Net ACL Active Directory AD LDS AD Objekt Azure AD Berechtigung Cloud cmdlets Delegation Domain Controller dynamicgroup dynamische Gruppen Exchange Exchange-Ordner Exchange-Postfach Exchange Migration Federation FirstWare Get-Mailbox Global Catalog Group Policy Gruppen Gruppenmitgliedschaft IDM-Portal LDAP m365 Microsoft Azure Migration New-ADUser Novell NTFS Office 365 PowerShell QMM QMM AD QMM Exchange Quest Migration Manager Schema Set-ADUser SID SID History Update Windows 10 Windows Server 2012 R2

Neueste Kommentare

  • activedirectoryfaq.com sharepoint login - infoslist bei Windows 365 und Azure AD verstehen in Theorie und Praxis
  • Domäne Letzte Anmeldung - ObenGesichert.com bei LastLogon vs. LastLogonTimestamp
  • Teams Code Zur Anmeldung - ObenGesichert.com bei Authentifizierung für MS Teams in hybriden Netzwerken
Login
Impressum
Datenschutzerklärung

© 2023 · Active-Directory-FAQ by firstattribute.com

Prev Next