4
Zuordnung von Netzlaufwerken mit Hilfe von Batch-Dateien
Hallo,
ich habe hier als DC einen Windows Server 2003 Standard. Ich weiss, daß das System inzwischen antik ist, aber das kleine Inselnetz mit ca. 11 Clients hat keine Internet-Anbindung und der Server muss eigentlich nur als Fileserver dienen, damit zentral abgelegte Programme an mehreren Clients aufgerufen werden können.
Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net use Befehlen Laufwerksbuchstaben zugeordnet hat.
Diesen Namen der Batchdatei habe ich in der 'AD-Benutzer- und Computer-Verwaltung' bei den entsprechenden Usern unter Profil > Anmeldeskript angegeben.
Inzwischen haben die Clients alle Win10pro64 - und das Zuweisen der Laufwerke mit HIlfe des Skripts funktioniert nicht mehr
Egal, ob ich die Datei als anmeldeskript.bat oder als anmeldeskript.cmd benenne, scheinen die Befehle nicht abgearbeitet zu werden.
Dabei ist mir auch aufgefallen, daß ich beim Aufruf des netlogon-Verzeichnisses im Explorer mit \\Servername\netlogon eine Abfrage nach Zugangsdaten erhalte, obwohl das Verzeichnis für den angemeldeten Benutzer freigegeben ist.
Hmmmm... - woran kann das liegen? Wahrscheinlich kann es mit den verhinderten Zugriffen auf die Netlogon-Freigabe zusammenhängen, denn wenn die Clients hier nicht zugreifen können, dann kann wohl auch das Skript nicht abgearbeitet werden... - aber warum?
Alle anderen Serverfreigaben können normal aufgerufen werden. Nur die Freigaben Sysvol und Netlogon nicht
Gibt es hier grundsätzliche Probleme im Zugriff von Windows10-Clients aus auf die Standardfreigabepfade der Netzwerk-Anmeldeskripte?
Ich hoffe, Ihr könnt mir helfen. Entweder hat sich hier ein Fehler in die Berechtigungen der Freigabe eingeschlichen oder ich stehe nur auf der Leitung und sehe den Wald vor lauter Bäumen nicht.
André
ich habe hier als DC einen Windows Server 2003 Standard. Ich weiss, daß das System inzwischen antik ist, aber das kleine Inselnetz mit ca. 11 Clients hat keine Internet-Anbindung und der Server muss eigentlich nur als Fileserver dienen, damit zentral abgelegte Programme an mehreren Clients aufgerufen werden können.
Als die Clients noch mit 1x WindowsXPpro und sonst Win7pro64bit ausgestattet waren, hatte ich unter \\Servername\NETLOGON eine Batchdatei angelegt, die freigegebenen Netzlaufwerken mit Hilfe von Net use Befehlen Laufwerksbuchstaben zugeordnet hat.
Diesen Namen der Batchdatei habe ich in der 'AD-Benutzer- und Computer-Verwaltung' bei den entsprechenden Usern unter Profil > Anmeldeskript angegeben.
Inzwischen haben die Clients alle Win10pro64 - und das Zuweisen der Laufwerke mit HIlfe des Skripts funktioniert nicht mehr
Egal, ob ich die Datei als anmeldeskript.bat oder als anmeldeskript.cmd benenne, scheinen die Befehle nicht abgearbeitet zu werden.
Dabei ist mir auch aufgefallen, daß ich beim Aufruf des netlogon-Verzeichnisses im Explorer mit \\Servername\netlogon eine Abfrage nach Zugangsdaten erhalte, obwohl das Verzeichnis für den angemeldeten Benutzer freigegeben ist.
Hmmmm... - woran kann das liegen? Wahrscheinlich kann es mit den verhinderten Zugriffen auf die Netlogon-Freigabe zusammenhängen, denn wenn die Clients hier nicht zugreifen können, dann kann wohl auch das Skript nicht abgearbeitet werden... - aber warum?
Alle anderen Serverfreigaben können normal aufgerufen werden. Nur die Freigaben Sysvol und Netlogon nicht
Gibt es hier grundsätzliche Probleme im Zugriff von Windows10-Clients aus auf die Standardfreigabepfade der Netzwerk-Anmeldeskripte?
Ich hoffe, Ihr könnt mir helfen. Entweder hat sich hier ein Fehler in die Berechtigungen der Freigabe eingeschlichen oder ich stehe nur auf der Leitung und sehe den Wald vor lauter Bäumen nicht.
André
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: 316287
Url: https://administrator.de/contentid/316287
Ausgedruckt am: 22.11.2024 um 02:11 Uhr
4 Kommentare
Neuester Kommentar
Hi
das "Problem" gab es bei WIndows 8 schon, die Lösung sollte bei Win10 die selbe sein
If your Server is running Windows 2003 or below, please modify the following registry on Windows 8.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa and set LmCompatibilityLevel to 2.
LG
das "Problem" gab es bei WIndows 8 schon, die Lösung sollte bei Win10 die selbe sein
If your Server is running Windows 2003 or below, please modify the following registry on Windows 8.
HKLM\SYSTEM\CurrentControlSet\Control\Lsa and set LmCompatibilityLevel to 2.
LG
Bevor ich in der Registry etwas zerschieße, lieber nochmal eine Rückfrage:
Der Schlüssel LmCompatibilityLevel ist bei den Windows10-Rechnern nicht vorhanden und muss dann sicher erst angelegt werden - oder?
Was für eine 2 soll dann eingetragen werden? Hex? Dez.? Dword?
André
Der Schlüssel LmCompatibilityLevel ist bei den Windows10-Rechnern nicht vorhanden und muss dann sicher erst angelegt werden - oder?
Was für eine 2 soll dann eingetragen werden? Hex? Dez.? Dword?
André
Ich habe das vorhin mal ausprobiert, aber eine Veränderung im Zugriffsverhalten auf die Netzfreigaben Netlogon und Sysvol hat es leider nicht gegeben. Immer noch Zugriff verweigert - egal welche Benutzercredentials ich eingebe.
Ich habe jetzt aber noch einen Hinweis auf 'gehärtete UNC-Pfade' gefunden. Wenn man in den lokalen Gruppenrichtlinien unter Computerkonfiguration > administrative Vorlagen > Netzwerk > Netzwerkanbieter den Schlüssel 'gehärtete UNC-Pfade' aktiviert und unter 'Anzeigen' dann die folgenden Daten eingibt, dann funktioniert der Zugriff.
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
Auch wenn hier steht:
Windows Server 2003 SP2
We determined that implementing these changes in Windows Server 2003 SP2 would require such comprehensive architecture changes that it would destabilize the system and result in application compatibility problems. We continue to recommend that customers who are security-conscious upgrade to our latest operating systems to keep pace with security threats and benefit from robust, modern operating system protection.
Leider kann man diese Gruppenrichtlinien-Einstellungen nicht über den Server verteilen, da die Clients im jetzigen Zustand ja keine Gruppenrichtlinien finden...
So muss man alles an jedem Client einzeln einstellen.
Etwas besser ging es dann, wenn man diese Einstellungen nicht in den lokalen Richtlinien, sondern wie hier beschrieben in der Registry durchführt.
Einfach in HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths die Zeichenfolgen \\*\SYSVOL und \\*\NETLOGON jeweils mit dem Wert RequireMutualAuthentication=0 hinzufügen.
Und dafür kann man sich eine kleine Batch-Datei mit folgendem Inhalt schreiben, die man dann einfach nur mit 'als admin ausführen' starten muss:
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t
REG_SZ
Aber ob da so wirklich im Sinne des Erfinders ist, wage ich zu bezweifeln. Aber da es für Win2K3 ja keinen Support mehr gibt, wird sich daran wohl auch nichts mehr ändern.
André
Ich habe jetzt aber noch einen Hinweis auf 'gehärtete UNC-Pfade' gefunden. Wenn man in den lokalen Gruppenrichtlinien unter Computerkonfiguration > administrative Vorlagen > Netzwerk > Netzwerkanbieter den Schlüssel 'gehärtete UNC-Pfade' aktiviert und unter 'Anzeigen' dann die folgenden Daten eingibt, dann funktioniert der Zugriff.
\\*\SYSVOL RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
\\*\NETLOGON RequireMutualAuthentication=0,RequireIntegrity=0,RequirePrivacy=0
Auch wenn hier steht:
Windows Server 2003 SP2
We determined that implementing these changes in Windows Server 2003 SP2 would require such comprehensive architecture changes that it would destabilize the system and result in application compatibility problems. We continue to recommend that customers who are security-conscious upgrade to our latest operating systems to keep pace with security threats and benefit from robust, modern operating system protection.
Leider kann man diese Gruppenrichtlinien-Einstellungen nicht über den Server verteilen, da die Clients im jetzigen Zustand ja keine Gruppenrichtlinien finden...
So muss man alles an jedem Client einzeln einstellen.
Etwas besser ging es dann, wenn man diese Einstellungen nicht in den lokalen Richtlinien, sondern wie hier beschrieben in der Registry durchführt.
Einfach in HKLM\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths die Zeichenfolgen \\*\SYSVOL und \\*\NETLOGON jeweils mit dem Wert RequireMutualAuthentication=0 hinzufügen.
Und dafür kann man sich eine kleine Batch-Datei mit folgendem Inhalt schreiben, die man dann einfach nur mit 'als admin ausführen' starten muss:
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\SYSVOL" /d "RequireMutualAuthentication=0" /t REG_SZ
%COMSPEC% /C reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\NetworkProvider\HardenedPaths /v "\\*\NETLOGON" /d "RequireMutualAuthentication=0" /t
REG_SZ
Aber ob da so wirklich im Sinne des Erfinders ist, wage ich zu bezweifeln. Aber da es für Win2K3 ja keinen Support mehr gibt, wird sich daran wohl auch nichts mehr ändern.
André
