Benutzer mit den meisten Antworten
Server kann auf Shares (eigene und fremde) nicht zugreifen

Frage
-
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)
Auf dem Server erhalten wir immer wieder die Event-Id 1058, aber kein 1030.
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 ...
Antworten
-
So .. Problem nun gelöst. Es war nicht das SMB Signing.
Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage und Routing standen alte Netzwerkkarten. Ich habe die Einträge mit LanmanServer verglichen (von außen ging ja alles) und abgeändert.
Nach dem Booten ging wieder alles!
Trotzdem Danke für die Bemühungen!- Als Antwort markiert Jörg Schnettker Samstag, 28. November 2009 11:54
Alle Antworten
-
Hmm.... scheint doch ein anderes Problem zu sein. Ich habe alles mögliche in der Registry getestet und es geht nicht.
Wenn ich per Wireshark den Traffic des Servers analysiere, dann sehe ich keine Anfrage des SMB Protokolls (oder gibt es intern keine Anfrage?) auf den Karten.
Hat vielleicht jemand einen Tip, wie ich den Fehler analysieren kann? -
Das entwickelt sich zwar zu einem "Selbstgespräch", aber ich wäre über jede Hilfe dankbar!
Habe nun auch den Holzhammer mit dcgpofix angewandt. Dies wird als Tipp gegeben bei reinen 1058 Fehlern. Geholfen hat das nichts - nur dass auch nun die Clients keine Gruppenrichtlinien jetzt mehr haben bzw. lesen können (Clients kamen ja noch auf /Server/sysvol).
Wie kann es sein, dass der Server auf seine eigene Shares nicht zugreifen kann? Auf fremde Shares ist mir das ja egal, aber die eigenen braucht er für die Gruppenrichtlinien
Bis auf dem 1058 finde ich nichts in den Logs.
"Fehler bei der Verarbeitung der Gruppenrichtlinie. Der Versuch, die Datei "\\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini" von einem Domänencontroller zu lesen, war nicht erfolgreich. Die Gruppenrichtlinieneinstellungen dürfen nicht angewendet werden, bis dieses Ereignis behoben ist. Dies ist möglicherweise ein vorübergehendes Problem, das mindestens eine der folgenden Ursachen haben kann:a) Namensauflösung/Netzwerkverbindung mit dem aktuellen Domänencontroller.
b) Wartezeit des Dateireplikationsdienstes (eine auf einem anderen Domänencontroller erstellte Datei hat nicht auf dem aktuellen Domänencontroller repliziert).
c) Der DFS-Client (Distributed File System) wurde deaktiviert.
+ System - Provider [ Name ] Microsoft-Windows-GroupPolicy [ Guid ] {aea1b4fa-97d1-45f2-a64c-4d69fffd92c9} EventID 1058 Version 0 Level 2 Task 0 Opcode 1 Keywords 0x8000000000000000 - TimeCreated [ SystemTime ] 2009-11-22T16:28:50.386Z EventRecordID 605886 - Correlation [ ActivityID ] {9F162B15-C181-4C52-A263-8C39B760CB3C} - Execution [ ProcessID ] 508 [ ThreadID ] 4900 Channel System Computer server.klaas.local - Security [ UserID ] S-1-5-18 - EventData SupportInfo1 4 SupportInfo2 840 ProcessingMode 0 ProcessingTimeInMilliseconds 2043 ErrorCode 2 ErrorDescription Das System kann die angegebene Datei nicht finden. DCName \\server.klaas.local GPOCNName CN={6AC1786C-016F-11D2-945F-00C04fB984F9},CN=Policies,CN=System,DC=klaas,DC=local FilePath \\klaas.local\sysvol\klaas.local\Policies\{6AC1786C-016F-11D2-945F-00C04FB984F9}\gpt.ini "
ein Net use in der Shell bringt ein
"Systemfehler 1231 aufgetreten.Das Netzlaufwerk ist nicht erreichbar. Weitere Informationen über die Behebung von Netzwerkproblemen finden Sie in der Windows-Hilfe."
(egal ob sysvol oder irgendein anderer share auf dem Server)
Lege ich auf dem Server ein neuen Share an und versuche über \\server\sharename zuzugreifen, dann kann ich den auch nicht vom Server aus erreichen - aus dem Netzwerk ist die FReigabe sofort zu erreichen
-
Hallo,
gehe bitte mal auf in die Registrierung unter:
HKLM\SYSTEM\CCS\SERVICES\LanManServer\Parameters und HKLM\SYSTEM\CCS\SERVICES\LanManWorkstation\Parameters
Dort gibt es jeweils die Werte enablesecuritysignature und requiresecuritysignature. Was stehen dort für Werte?
Grüße
Frank -
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters]
"ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
00,74,00,25,00,5c,00,53,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\
77,00,6b,00,73,00,73,00,76,00,63,00,2e,00,64,00,6c,00,6c,00,00,00
"ServiceDllUnloadOnStop"=dword:00000001
"EnablePlainTextPassword"=dword:00000001
"OtherDomains"=hex(7):00,00
"AllowedGuestAuthWhenSigning"=dword:00000001
"enablesecuritysignature"=dword:00000001
"requiresecuritysignature"=dword:00000000[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters]
"ServiceDll"=hex(2):25,00,53,00,79,00,73,00,74,00,65,00,6d,00,52,00,6f,00,6f,\
00,74,00,25,00,5c,00,73,00,79,00,73,00,74,00,65,00,6d,00,33,00,32,00,5c,00,\
73,00,72,00,76,00,73,00,76,00,63,00,2e,00,64,00,6c,00,6c,00,00,00
"ServiceDllUnloadOnStop"=dword:00000001
"NullSessionPipes"=hex(7):62,00,72,00,6f,00,77,00,73,00,65,00,72,00,00,00,6e,\
00,65,00,74,00,6c,00,6f,00,67,00,6f,00,6e,00,00,00,73,00,61,00,6d,00,72,00,\
00,00,6c,00,73,00,61,00,72,00,70,00,63,00,00,00,00,00
"autodisconnect"=dword:0000000f
"enableforcedlogoff"=dword:00000001
"restrictnullsessaccess"=dword:00000001
"Lmannounce"=dword:00000000
"Size"=dword:00000003
"AdjustedNullSessionPipes"=dword:00000002
"OptionalNames"=hex(7):00,00
"requiresecuritysignature"=dword:00000001
"enablesecuritysignature"=dword:00000001
"Guid"=hex:13,ed,de,97,7f,8f,b1,40,82,30,bf,08,8d,98,fe,fd
Beim Lanman Server hatte ich auch schon mal requiresecuritysignature=0 versucht. Ebenfalls ohne Erfolg.
Sind die Werte, die ich dort finde, auch die, die gezogen werden? -
Beim Lanman Server hatte ich auch schon mal requiresecuritysignature=0 versucht. Ebenfalls ohne Erfolg.
Sind die Werte, die ich dort finde, auch die, die gezogen werden?
Hast Du danach auch den Serverdienst neu gestartet? Setze das mal wieder auf 0 und starte dann den Serverdienst neu. Dann sollte das passen. Die Werte, sind die, die auch gezogen werden.
Viele Grüße
Frank -
Hi, das habe ich gerade gemacht und es hat nichts daran geändert. Würde das überhaupt erklären, warum ich auf fremde Shares nicht zugreifen kann? Zudem können ja alle Clients auf die Shares des Servers zugreifen. Würde das zurücksetzen aller Sciherheitseinstellung was bringen?
-
So .. Problem nun gelöst. Es war nicht das SMB Signing.
Unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Linkage und Routing standen alte Netzwerkkarten. Ich habe die Einträge mit LanmanServer verglichen (von außen ging ja alles) und abgeändert.
Nach dem Booten ging wieder alles!
Trotzdem Danke für die Bemühungen!- Als Antwort markiert Jörg Schnettker Samstag, 28. November 2009 11:54