☰

Windows 7 Samba-Problem

tag-icon • tag-icon linux windows-7 redhat samba
Windows 7 Samba-Problem

Wir haben ein seltsames Samba-Problem, das nur einen Benutzer betrifft. Unser Samba-Setup ist wie folgt:

Red Hat Enterprise Linux Server Version 5.4 (Tikanga) - Samba-Server

Samba-Version 3.0.33-3.14.el5 - Samba-Version

Domänencontroller WIN2008R2 Standard - Windows DC

Windows 7 64 Bit - Client-PCs

Der Benutzer erwähnte, dass er vor einigen Wochen auf dieses Problem gestoßen ist, nachdem er seinen PC zwangsweise heruntergefahren hat. Wenn wir \\sambaservernamein Windows auf alle Benutzer zugreifen, werden alle Freigaben auf dem Samba-Server angezeigt, aber dieser Benutzer kann nach dem Starten seines PCs nicht mehr darauf zugreifen \\sambaservername. Fehlermeldung

Windows kann nicht darauf zugreifen\\sambaservername

Aktueller Workaround zur Lösung des Problems:

\\sambaservernameVersuchen Sie beispielsweise, auf eine Freigabe in zuzugreifen \\sambaservername\sharedfolder1. Aber selbst wenn Sie dies tun, wird zunächst ein Fehler angezeigt. Die Fehlermeldung lautet wie folgt

Anmeldefehler: unbekannter Benutzername oder falsches Kennwort.

Der Benutzer muss die Anmeldeinformationen erneut eingeben und kann auf die Freigabe zugreifen. Danach kann er \\sambaservernameproblemlos darauf zugreifen. Aber wenn er seinen Computer neu startet, bleibt das Problem bestehen.

Bisher durchgeführte Fehlerbehebung:

  1. Stellen Sie die folgenden Einstellungen sicher:

    Gehen Sie zu: Systemsteuerung → Verwaltung → Lokale Sicherheitsrichtlinie Wählen Sie: Lokale Richtlinien → Sicherheitsoptionen

    „Netzwerksicherheit: Authentifizierungsebene des LAN-Managers“ → LM- und NTLM-Antworten senden „Minimale Sitzungssicherheit für NTLM SSP“ → deaktivieren: 128-Bit-Verschlüsselung erforderlich

  2. Empfehlen Sie dem Benutzer, sein Passwort zurückzusetzen und es erneut zu versuchen, aber das Problem besteht weiterhin

  3. Habe mein Konto auf dem PC des Benutzers ausprobiert, es gibt keine Probleme. Habe das Benutzerkonto auf mehreren anderen Windows 7-PCs ausprobiert, darunter auch meinem, aber das Problem besteht weiterhin. Unter Windows XP besteht dieses Problem nicht.

  4. Stellen Sie sicher, dass auf dem Windows 7-PC keine Anmeldeinformationen gespeichert sind. Überprüfen Sie den Anmeldeinformations-Manager in der Systemsteuerung und geben Sie diesen Befehl einrundll32.exe keymgr.dll, KRShowKeyMgr

  5. Starten Sie den Winbindd-Daemon auf dem Samba-Server neu, aber ohne Erfolg.

Ich vermute, dass dies an einem Caching-Problem liegt, bin mir aber nicht sicher, wo das Problem liegt. Immer wenn der Benutzer beim Zugriff einen Fehler hat \\sambaservername, werden die folgenden Fehler im Samba-Server protokolliert:

[2012/10/10 17:10:26, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!
[2012/10/10 17:10:27, 1] smbd/sesssetup.c:reply_spnego_kerberos(316)
  Failed to verify incoming ticket with error NT_STATUS_LOGON_FAILURE!

Aber nach der Problemumgehung treten keine Fehler mehr auf. Ich vermute, dass nach dem Lesen des unten aufgeführten Artikels einige Änderungen am \var\samba\cacheVerzeichnis vorgenommen werden müssen:

Es gibt mehrere Benutzer, die den Samba-Server verwenden, und ich würde dieses Problem gerne ohne Auswirkungen lösen.

Ich habe den folgenden Artikel gesehen:

"Winbind Offline-Anmeldung (G) Dieser Parameter steuert, ob Winbind die Anmeldung mit dem Modul pam_winbind unter Verwendung zwischengespeicherter Anmeldeinformationen erlauben soll.Wenn aktiviert, speichert winbindd die Benutzeranmeldeinformationen von erfolgreichen Anmeldungen verschlüsselt in einem lokalen Cache.

Standardmäßig: Winbind-Offline-Anmeldung = false

Beispiel: winbind offline logon = true "

Irgendeine Idee, wie man den Eintrag für einen Benutzer im lokalen Cache löscht?

Antwort1

Ich bin nicht sicher, ob dienbtstat -RBefehl (der"löscht und lädt die Remote-Cache-Namenstabelle neu.") oder nbtstat -RRdiejenige (die"sendet Namensfreigabepakete an WINs und startet dann die Aktualisierung.") kann alles tun, um die Art der Aktualisierung zu erzwingen, nach der Sie suchen ...

Wenn Sie das Handbuch lesen möchten,Schau hier..

Antwort2

Stellen Sie sicher, dass ntpd mit dem Domänencontroller synchronisiert ist. Ich hatte das gleiche Problem, bis mir heute ein Zeitunterschied von 45 Minuten zwischen dem fehlerhaften Server und dem Domänencontroller auffiel. Nachdem ich ntpdate ausgeführt hatte, funktionierte es einwandfrei.

Antwort3

Meiner Erfahrung nach ist dies normalerweise das Ergebnis einer Zeitabweichung entweder auf dem Domänencontroller oder, in Ihrem Fall, wenn nur ein Client ein Problem hat, auf dem verbindenden Client-Rechner. Da Kerberos sowohl in der Authentifizierungsserver-Anforderung als auch in der Authentifizierungsserver-Antwort (AS_Req und AS_rep) zeitbezogene Parameter einschließt, führt eine große Diskrepanz dazu, dass das Sitzungstoken abgelehnt wird.

AS_Req enthält die Lebensdauer für das angeforderte Token: AS_REQ = (PrincipalClient, PrincipalService, IP_list, Lebensdauer)

AS_Rep beinhaltet den DC-Zeitstempel und die angewendete Lebensdauer: AS_REP = { PrincipalService , Timestamp , Lifetime , SKTGS }

Wenn die Zeitabweichung also außerhalb der Lebensdauer liegt, wird die Verbindung abgelehnt.

VERMUTUNG: Ich konnte nicht anhand der Dokumentation bestätigen, dass die Lebensdauer in Minuten angegeben wird, aber ich glaube, das liegt daran, dass ich eine Maschine hatte, die zeitweise funktionierte, und der einzige Grund, der mir einfiel, war, dass sie genau an der Grenze der Lebensdauer war. Sie funktionierte also etwa 30 Sekunden lang, und dann wechselte die Minute und Verbindungen wurden abgelehnt.

verwandte Informationen