Domain Controller kann auf Shares (eigene und fremde) nicht zugreifen
Von außen kommt man auf die Shares des Servers. Auf dem Server geht es nicht. Dadurch kann der Domain-Controller nicht auf die Richtlinien zugreifen und auch nicht abändern
Hallo,
ich bin mittlerweise mit dem oben genannten Problem absolut am verzweifeln.
Wir nutzen Windows Server 2008 als DC. Alle Clients können auf die Shares des Servers zugreifen (SYSVOL und diverse Daten Shares), aber der Server selbst kann auf keinem Share zugreifen. Auf den Laufwerken (also ohne \\ ) kann der Server zurgreifen. Es klingt für mich selbst wie SMB Signing Probleme (besonders weil der Server auch der einzige ist, der nicht auf einem Samba Share im Netz zugreifen kann - er kann aber auch nicht auf einen lokalen Share eines Rechners (x-beliebig) und auf einen Share eines alten Windows 2000 File-Servers zugreifen), aber dahingehend habe ich eigentlich alles getestet (dachte ich zumindest).
Die Registry habe ich wie folgt testweise geändert:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature 1
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature 1
(wie auf http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_signing.htm vorgeschlagen). Ein Rechner-Neustart brachte keine Änderungen - der Neustart der Dienste Server und Arbeitsstation brachten auch keine Änderung
Schau ich auf dem Server mit rsop.msc nach, dann sind
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)
beide aktiviert (ist es normal, das bei dem Programm ein rotes X durch die Computzerkonfiguration ist?)
Auf dem Server erhalten wir immer wieder die Event-Id 1058, aber kein 1030.
Folgendes habe ich im Explorer getestet
\\server.firma.local -> sehe die Shares, bei einem Zugriff kommt die Fehlermeldung
\\firma.local -> sofort Fehler
\\192.168.0.1 -> sofort Fehler
Das ganze hatte mal funktioniert, leider kann man aber nicht mehr zurückverfolgen, was genau geändert wurde (oder gibt es eine Art Verlauf?)
Wie könnte ich feststellen, ob es wirklich am SMB Signing liegt und noch viel wichtiger: wie könnte ich das Beheben?! Kann man das Signing vorrübergehend komplett abschalten? Wie kann man die Richtlinien ändern, wenn man nicht auf sysvol zugreifen kann (und wie kann der Server die dann für sich selbst anwenden?). Ich befürchte, dass die "fehlerhafte" Einstellung sich in den "Default Domain Controllers Policy" befinden (anhand der letzten Dateiänderung), aber wie könnte ich die a) ändern und b) anwenden ohne sysvol Zugriff?
Ich hoffe mir kann jemand helfen und meinen schlaflosen Nächten ein Ende bereiten ...
Hallo,
ich bin mittlerweise mit dem oben genannten Problem absolut am verzweifeln.
Wir nutzen Windows Server 2008 als DC. Alle Clients können auf die Shares des Servers zugreifen (SYSVOL und diverse Daten Shares), aber der Server selbst kann auf keinem Share zugreifen. Auf den Laufwerken (also ohne \\ ) kann der Server zurgreifen. Es klingt für mich selbst wie SMB Signing Probleme (besonders weil der Server auch der einzige ist, der nicht auf einem Samba Share im Netz zugreifen kann - er kann aber auch nicht auf einen lokalen Share eines Rechners (x-beliebig) und auf einen Share eines alten Windows 2000 File-Servers zugreifen), aber dahingehend habe ich eigentlich alles getestet (dachte ich zumindest).
Die Registry habe ich wie folgt testweise geändert:
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanmanWorkstation\Parameters\EnableSecuritySignature 1
Microsoft-Netzwerk (Server): Kommunikation digital signieren (immer) Deaktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature 0
Microsoft-Netzwerk (Server): Kommunikation digital signieren (wenn Client zustimmt) Aktiviert
HKLM\System\CurrentControlSet\Services\LanManServer\Parameters\EnableSecuritySignature 1
(wie auf http://www.gruppenrichtlinien.de/index.html?/HowTo/SMB_signing.htm vorgeschlagen). Ein Rechner-Neustart brachte keine Änderungen - der Neustart der Dienste Server und Arbeitsstation brachten auch keine Änderung
Schau ich auf dem Server mit rsop.msc nach, dann sind
Microsoft-Netzwerk (Client): Kommunikation digital signieren (immer)
Microsoft-Netzwerk (Client): Kommunikation digital signieren (wenn Server zustimmt)
beide aktiviert (ist es normal, das bei dem Programm ein rotes X durch die Computzerkonfiguration ist?)
Auf dem Server erhalten wir immer wieder die Event-Id 1058, aber kein 1030.
Folgendes habe ich im Explorer getestet
\\server.firma.local -> sehe die Shares, bei einem Zugriff kommt die Fehlermeldung
\\firma.local -> sofort Fehler
\\192.168.0.1 -> sofort Fehler
Das ganze hatte mal funktioniert, leider kann man aber nicht mehr zurückverfolgen, was genau geändert wurde (oder gibt es eine Art Verlauf?)
Wie könnte ich feststellen, ob es wirklich am SMB Signing liegt und noch viel wichtiger: wie könnte ich das Beheben?! Kann man das Signing vorrübergehend komplett abschalten? Wie kann man die Richtlinien ändern, wenn man nicht auf sysvol zugreifen kann (und wie kann der Server die dann für sich selbst anwenden?). Ich befürchte, dass die "fehlerhafte" Einstellung sich in den "Default Domain Controllers Policy" befinden (anhand der letzten Dateiänderung), aber wie könnte ich die a) ändern und b) anwenden ohne sysvol Zugriff?
Ich hoffe mir kann jemand helfen und meinen schlaflosen Nächten ein Ende bereiten ...
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 129924
Url: https://administrator.de/forum/domain-controller-kann-auf-shares-eigene-und-fremde-nicht-zugreifen-129924.html
Ausgedruckt am: 23.12.2024 um 10:12 Uhr
6 Kommentare
Neuester Kommentar
Hi,
Hast schonmal folgendes ausgprobiert? Auch wenn du keine 1030er Event-ID hast.
http://support.microsoft.com/kb/842804/de
Hast schonmal folgendes ausgprobiert? Auch wenn du keine 1030er Event-ID hast.
http://support.microsoft.com/kb/842804/de
Falls auf dem Server eine Firewall oder AV-"Lösung" mit Netzwerkschutzfunktionen läuft - schmeiß die testhalber runter und starte neu.
Falls es das nicht ist, hast Du ein ernstes Problem. Evtl. ist ein Restore vom Backup oder eine Reparaturinstallation dann der beste Weg. Auch ein Wiedereinspielen des letzten Servicepacks könnte man als "Reparatur-light" versuchen.
Falls es das nicht ist, hast Du ein ernstes Problem. Evtl. ist ein Restore vom Backup oder eine Reparaturinstallation dann der beste Weg. Auch ein Wiedereinspielen des letzten Servicepacks könnte man als "Reparatur-light" versuchen.