none
Server kann auf Shares (eigene und fremde) nicht zugreifen RRS feed

  • 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)
    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.

    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 ...
    Mittwoch, 18. November 2009 06:25

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!
    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?
    Freitag, 20. November 2009 13:52
  • 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

     


    Sonntag, 22. November 2009 16:36
  • 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
    Donnerstag, 26. November 2009 10:24
  • [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?

    Freitag, 27. November 2009 17:38

  • 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
    Freitag, 27. November 2009 17:43
  • 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?
    Freitag, 27. November 2009 18:13
  • 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!
    Samstag, 28. November 2009 11:54