Windows 7 NTLM authentifiziert sich nicht richtig mit Ubuntu 18.04
529
John Byrne
Ich habe heute den größten Teil meines Tages damit verbracht, das herauszufinden ... Nicht genau das, was ich heute vorhatte ... aber ich konnte mir nicht helfen ... Also, hier ist das Problem: Mein Windows 7-Rechner hat gewonnen Authentifizierung (für eine Samba-Freigabe) nicht bei meinem Ubuntu 18.04-System. Ich glaube, ich habe das auf das Protokoll selbst zurückgeführt, aber ich bin mir nicht sicher, was genau das eigentliche Problem ist. Es könnte eine Einstellung sein, die ich irgendwo in Windows vermisse, obwohl ich mit den NTLM-Authentifizierungseinstellungen in der lokalen Richtlinie ziemlich viel gespielt habe. Meine Macintosh-Dateifreigabeverbindung zu Ubuntu funktioniert einwandfrei.
Also hier ist was ich gefunden habe:
Windows setzt die Verbindung vom Ubuntu 18.04-Server zurück und startet den Verhandlungsprozess mit einem anderen Port neu (wobei mein Mac nur die STATUS_LOGIN_FAILURE-Nachricht bestätigt und den Vorgang fortsetzt).
Windows sendet einen anderen Benutzer an den Ubuntu-Server (z. B. systemname\rootim Gegensatz zum Senden meines Mac systemname\\root) (Beachten Sie die 2 Backslashes statt 1?)
Windows sendet einen "Unknown Message Type" an Ubuntu, wo mein Mac überhaupt nichts davon sendet.
Hier ist ein Abbild eines Vergleichs der beiden Protokolle.
Ich habe die Paketaufzeichnungen von meinem Mac und meinem Windows 7-System in .csv-Dateien umgewandelt und sie hier zum Vergnügen eingefügt.
Ja, ich habe mir die Protokolle angesehen (und habe sie beim Versuch, über den Dateiexplorer eine Verbindung herzustellen) "verfolgt". Dies wurde in den Protokollen angezeigt:
Nach ein paar Sekunden, wenn die Verbindung zu niemandem ausfällt (ich denke mal), dass ich nur auf die Auflistung des Computers schaue, bekomme ich dies in der auth.log
22. November 21:59:11 odroid2 smbd: pam_unix (samba: session): Sitzung für Benutzer nobody geschlossen
Ich bekomme auch:
22. November 20:08:42 odroid2 smbd: pam_unix (samba: session): Sitzung für Benutzer root geschlossen
Ich authentifiziere mich auf andere Weise mit "pam", einschließlich sowohl mit sshd als auch mit smbd:
22. November 18:52:34 odroid2 smbd [9524]: pam_unix (samba: session): Sitzung wurde für den Benutzer root von geöffnet (uid = 0)
Diese Sitzungen werden von meinem Mac authentifiziert. Wenn Windows versucht, sich zu authentifizieren, wird in der auth.log nur der nobody angezeigt, wenn ich den Computer ansehe (using - net view). Ich habe jetzt die Netzansicht deaktiviert, da NetBIOS auf Port 139 ausgeführt wurde und ich wollte, dass es das gleiche Setup wie mein Mac (auf Port 445) hat. Also habe ich NetBIOS über TCP / IP deaktiviert.
22. November 16:13:56 odroid2 sshd [428]: pam_unix (sshd: session): Für Benutzer root geöffnete Sitzung von (uid = 0) 22. November 16:13:56 odroid2 systemd-logind [535]: Neue Sitzung 733 vom Benutzer root. 22. November 16:13:57 odroid2 sshd [428]: Empfangene Trennung von 2600: 1700: 7c20: 1fb0: 13f: 338a: e270: 917d Port 60469: 11: Vom Benutzer getrennt. Nov 22 16:13:57 odroid2 sshd [428 ]: Keine Verbindung mit Benutzer root 2600: 1700: 7c20: 1fb0: 13f: 338a: e270: 917d port 60469 22. November 16:13:57 odroid2 sshd [428]: pam_unix (sshd: session): Sitzung für Benutzer root geschlossen
und mein Syslog sagt nichts Interessantes.
In meiner smb.conf habe ich:
log level = 10 logging = 10
Ich nahm an, dass 10 die höchste Stufe war und dass 'all' die Standardeinstellung war, wenn nichts angegeben wurde. Ich habe 10 in einer Beispiel-smb.conf im Internet gesehen, deshalb dachte ich, dass es die höchste Stufe war.
Wenn Sie sie wirklich brauchen ... hier sind die eigentlichen pcap / pcapng-Dateien ... Sobald das Problem gelöst ist, nehme ich sie heraus, weil darin persönliche Informationen enthalten sind und jeder, der die Antwort anzeigen möchte, dies tun muss also ohne die eigentlichen pcap-daten.
Ich würde fast wetten, dass die Backslash-Unterschiede ein Artefakt des CSV-Exports des Capture-Tools sind und nicht auf dem Draht gesendet werden. Können Sie stattdessen die eigentlichen pcap-Dateien anhängen? Und haben Sie schon versucht, die Samba-Protokolle des Servers zu überprüfen? (Verwenden Sie `[global] log level = 1 passdb: 5 auth: 5 auth_audit: 5`.)
grawity vor 5 Jahren
0
Ich lege gerade die eigentlichen pcap-Dateien (mit den mit SMB2 markierten Paketen gespeichert) hoch. Vielen Dank, dass Sie sich das angesehen haben.
John Byrne vor 5 Jahren
0
1 Antwort auf die Frage
1
grawity
SMBv2 / v3 wird immer über den TCP-Port 445 im Raw-Modus ausgeführt, ohne dass ein NetBIOS in Sicht ist. (Das ältere SMBv1 kann entweder über TCP / 445 oder TCP / 139 ausgeführt werden.) Der Port ist jedoch für die Authentifizierung überhaupt nicht wichtig - er erfolgt vollständig auf SMB-Ebene, nicht auf NetBIOS-Ebene (Sitzung / Transport).
Sie sollten prüfen, ob beide Seiten übereinstimmen, welche Authentifizierungsprotokolle verwendet werden sollen. Speziell:
ob Samba NTLMv1 oder NTLMv2 gemäß smb.conf akzeptiert:
(Vorherige Versionen, die yeszum Zulassen von NTLMv1 verwendet wurden, noum NTLMv2 zu erfordern.)
ob Windows NTLMv1 oder v2 gemäß secpol.msc sendet:
Security Settings └─ Local Policies └─ Security Options └─ Network security: LAN Manager authentication level ( ) Send LM & NTLM ( ) Send NTLM response only (*) Send NTLMv2 response only
In den Serverprotokollen werden keine PAM- "Auth" -Nachrichten angezeigt, da für die PAM-Authentifizierung das Klartextkennwort erforderlich ist, das vom Client nicht angezeigt wird. Stattdessen wickelt Samba die Authentifizierung intern ab und ruft PAM nur bei Erfolg auf, um verschiedene andere Prüfungen durchzuführen.
Suchen Sie stattdessen nach den eigenen Protokollen des smbd-Daemons. Möglicherweise möchten Sie aktivieren logging = syslogoder logging = systemdso, dass sie immer auf eine Standard Ort gehen; Standardmäßig werden sie jedoch in / var / log / samba gespeichert.
Ich danke dir sehr! Es funktioniert jetzt. Ich habe gerade die Windows-Aushandlung von NTLMv2 geändert. Es war also immerhin eine Windows-Einstellung ... Ich verbrachte etwa 8 Stunden damit, und ich war ziemlich ratlos. Ich habe nach einem Verhandlungsfehler gesucht, aber es gibt keinen in der Protokollanzeige von Wireshark. In jedem Fall freue ich mich sehr über Ihre Hilfe!
John Byrne vor 5 Jahren
0
Unglücklicherweise werden die beiden NTLM-Versionen, soweit ich weiß, nicht genau als solche ausgehandelt - die Pakete unterscheiden sich nur darin, wie die Herausforderung / Antwort generiert wird ... (Es ist ein altes und unbeholfenes Protokoll, das in MS-DOS begann wie "LM" und hat nur eine dicke Farbschicht.) Wenn möglich, stellen Sie alle Hosts so ein, dass sie nur NTLMv2 verwenden. Dies ist etwas sicherer und in neuen Betriebssystemversionen ist dies bereits der Standard.
grawity vor 5 Jahren
0
