Samba Shares nicht erreichbar

[Tigger]

Hallo,

ich habe nach einenm Update von Ubuntu 16.04 auf 20.04 und Opsi 4.1 auf opsi 4.2 das Problem das die Samba Shares nicht ereichbar sind.

Ich kann zwar den Server via SMB erreichen und seheh auch die Freigaben, aber wenn ich eine Öffnen will kommt das die Anmeldung falsch ist.
Ich habe das Log auf dem Samba aufgedreht und dorst sehr Password Falsch, das habe ich mit smbpasswd zurück gesetzt, Bringt nur leider nix.

der Server ist als Standalon Server Konfiguriert.

smb.conf

Code: Alles auswählen

[global]
log level = 3 passdb:5 auth:5
client min protocol = NT1
server min protocol = NT1
workgroup = FRITZWEG
server string = %h server (Samba, Ubuntu)
log file = /var/log/samba/log.%m
max log size = 1000
logging = file
panic action = /usr/share/samba/panic-action %d
acl allow execute always = true
server role = standalone server
obey pam restrictions = yes
unix password sync = yes
passwd program = /usr/bin/passwd %u
passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\supdated\ssuccessfully* .
pam password change = yes
map to guest = bad user
usershare allow guests = yes

[printers]
   comment = All Printers
   browseable = no
   path = /var/spool/samba
   printable = yes
   guest ok = no
   read only = yes
   create mask = 0700

[print$]
   comment = Printer Drivers
   path = /var/lib/samba/printers
   browseable = yes
   read only = yes
   guest ok = no

[opsi_depot]
   available = yes
   comment = opsi depot share (ro)
   path = /var/lib/opsi/depot
   follow symlinks = yes
   writeable = no
   invalid users = root
   acl allow execute always = true
[opsi_depot_rw]
   available = yes
   comment = opsi depot share (rw)
   path = /var/lib/opsi/depot
   follow symlinks = yes
   writeable = yes
   invalid users = root

[opsi_images]
   available = yes
   comment = opsi ntfs images share (rw)
   path = /var/lib/opsi/ntfs-images
   writeable = yes
   invalid users = root

[opsi_repository]
   available = yes
   comment = opsi repository share (ro)
   path = /var/lib/opsi/repository
   follow symlinks = yes
   writeable = no
   invalid users = root

[opsi_workbench]
   available = yes
   comment = opsi workbench
   path = /var/lib/opsi/workbench
   writeable = yes
   invalid users = root
   create mask = 0770
   directory mask = 0770
   
[opsi_logs]
   available = yes
   comment = opsi logs share (ro)
   path = /var/log/opsi
   follow symlinks = yes
   writeable = no
   invalid users = root

MfG Alexander

[m.radtke]

Moin

probiere es mal mit

Code: Alles auswählen

apt install --reinstall opsiconfd

Gruß
Mathias

[Tigger]

Hallo Mathias,


Danke für die Schnelle Antwort, Leide hilft es nicht.

Weitere Ideen oder Fragen?

MfG Alexander

[ThomasT]

Vorweg: Ich persönlich würde versuchen die smb.conf so schlank wie möglich zu halten, das erleichtert meist die Fehlersuche. Hier würde ich mir mal über die min protocol Einstellungen gedanken machen, sowie über das "acl allow execute always" in der global Sektion

Dann bitte mal versuchen vom Server direkt aus mit smbclient den Share zu öffnen und mal ein Listing mit ls der einzelnen Verzeichnisse zu bekommen.
Manchmal ist Windows da etwas eigen, welche Credentials wann genau genutzt werden.
Mit smbstatus -v oder smbstatus -b kann man sich auch mal anschauen, was sich denn genau zum Zeitpunkt x auf dem Server tut.

Passwort falsch ist auch so eine Sache, was genau steht denn da? Kann es sein, dass der User sich mit einem Domänen Prefix meldet und dann nicht mit den Usern gematcht wird.

Apropos Password ändern, wenn du mit smbpasswd das Passwort geändert hast, aber gleichzeitig obey pam restrictions = yes und unix password sync = yes gesetzt sind, kann das auch ein Problem sein? Ich persönlich habe noch nicht mit diesen Parametern gearbeitet, daher weiß ich nicht wie die sich verhalten...

[mattiasmab]

die Samba Shares nicht ereichbar sind

Von wo aus nicht erreichbar? Windows/Linux/Mac per Filemanager oder der opsi-client?

In ersterem Fall kann es sein, dass Windows die anonyme Anmeldung verhindert (was neue Win10-Versionen durchaus tun). Durch

map to guest = bad user

wir aber automatisch eine anonyme Anmeldung durchgeführt, da Windows stets versucht sich mit den eigenen Daten anzumelden und somit IMMER in den Fallback (bad user -> map to guest) gelangt, da die Anmeldedaten des Windows-PCs vermutlich nicht im Samba hinterlegt sind.

Die Zeile testweise auf

Code: Alles auswählen

map to guest = never

ändern und Samba neustarten. Generell empfehle ich das ganze schmal zu halten, wie der Vorredner bereits anmerkte.
Testweise/Alternativ sollte es bei diesem Problem auch ohne die Änderung möglich sein, wenn sich manuell mit anderen Daten verbunden wird - per cmd mit (wichtig - es darf bei "net use" keine bestehende Verbindung zu dem Server existieren):

Code: Alles auswählen

net use \\OPSI.SERVER.TLD\IPC$ /user:OPSI_SERVER_USER

Zum Fall Opsi-Client hat keine Verbindung gab es schon ein paar Anmerkungen, dass eine Domain SAMBA von opsi genutzt wird und die Änderung dessen geholfen hat, das Mapping bei Samba zu korrigieren. Dazu den Hostparameter

Code: Alles auswählen

clientconfig.depot.user	[SAMBA\pcpatch]

zu

Code: Alles auswählen

clientconfig.depot.user	[pcpatch]

Als dritten Fall - Rechte prüfen. Sind die Ordner von SAMBA lesbar (SELinux/AppArmor) und den zugrundeliegenden Benutzer von SAMBA (läuft meist als root damit die ForceUser-Geschichten und ähnliches funktionieren, muss aber nicht).

[Tigger]

Hallo,

danke für die Antworten,

Ich habe alles umgesetzt und getestet, mit Windows 8.1 und 10 komme ich nicht auf die Shares.

im Log kommt Folgendes:

Code: Alles auswählen

[2021/11/18 10:34:15.029126,  3] ../../auth/ntlmssp/ntlmssp_server.c:509(ntlmssp_server_preauth)
  Got user=[adminuser] domain=[FRITZWEG] workstation=[WN005] len1=24 len2=24
[2021/11/18 10:34:15.029253,  3] ../../source3/auth/auth.c:200(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [FRITZWEG]\[adminuser]@[WN005] with the new password interface
[2021/11/18 10:34:15.029362,  3] ../../source3/auth/auth.c:203(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [FRITZWEG]\[adminuser]@[WN005]
[2021/11/18 10:34:15.029816,  3] ../../source3/passdb/lookup_sid.c:1710(get_primary_group_sid)
  Forcing Primary Group to 'Domain Users' for adminuser
[2021/11/18 10:34:15.030035,  2] ../../libcli/auth/ntlm_check.c:472(ntlm_password_check)
  ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user adminuser
[2021/11/18 10:34:15.030148,  3] ../../libcli/auth/ntlm_check.c:479(ntlm_password_check)
  ntlm_password_check: NEITHER LanMan nor NT password supplied for user adminuser
[2021/11/18 10:34:15.030415,  2] ../../source3/auth/auth.c:344(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [adminuser] -> [adminuser] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1
[2021/11/18 10:34:15.030545,  2] ../../auth/auth_log.c:635(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [FRITZWEG]\[adminuser] at [Do, 18 Nov 2021 10:34:15.030527 CET] with [NTLMv1] status [NT_STATUS_WRONG_PASSWORD] workstation [WN005] remote host [ipv4:129.0.1.6:61673] mapped to [FRITZWEG]\[adminuser]. local host [ipv4:129.0.0.24:445] 
  {"timestamp": "2021-11-18T10:34:15.030684+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:129.0.0.24:445", "remoteAddress": "ipv4:129.0.1.6:61673", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "FRITZWEG", "clientAccount": "adminuser", "workstation": "WN005", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "adminuser", "mappedDomain": "FRITZWEG", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 2475}}
[2021/11/18 10:34:15.030790,  3] ../../auth/gensec/spnego.c:1443(gensec_spnego_server_negTokenTarg_step)
  gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_WRONG_PASSWORD
[2021/11/18 10:34:15.030887,  3] ../../source3/smbd/smb2_server.c:3861(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../../source3/smbd/smb2_sesssetup.c:146
[2021/11/18 10:34:15.031498,  3] ../../source3/smbd/server_exit.c:220(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)
[2021/11/18 10:34:15.035033,  3] ../../source3/smbd/oplock.c:1427(init_oplocks)
  init_oplocks: initializing messages.
[2021/11/18 10:34:15.035110,  3] ../../source3/smbd/process.c:1956(process_smb)
  Transaction 0 of length 248 (0 toread)
[2021/11/18 10:34:15.035359,  3] ../../source3/smbd/smb2_negprot.c:293(smbd_smb2_request_process_negprot)
  Selected protocol SMB3_11
[2021/11/18 10:34:15.036739,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'gssapi_spnego' registered
[2021/11/18 10:34:15.036766,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'gssapi_krb5' registered
[2021/11/18 10:34:15.036776,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'gssapi_krb5_sasl' registered
[2021/11/18 10:34:15.036787,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'spnego' registered
[2021/11/18 10:34:15.036796,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'schannel' registered
[2021/11/18 10:34:15.036809,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'naclrpc_as_system' registered
[2021/11/18 10:34:15.036817,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'sasl-EXTERNAL' registered
[2021/11/18 10:34:15.036826,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'ntlmssp' registered
[2021/11/18 10:34:15.036835,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'ntlmssp_resume_ccache' registered
[2021/11/18 10:34:15.036848,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'http_basic' registered
[2021/11/18 10:34:15.036860,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'http_ntlm' registered
[2021/11/18 10:34:15.036869,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'http_negotiate' registered
[2021/11/18 10:34:15.036880,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'krb5' registered
[2021/11/18 10:34:15.036892,  3] ../../auth/gensec/gensec_start.c:987(gensec_register)
  GENSEC backend 'fake_gssapi_krb5' registered
[2021/11/18 10:34:15.037977,  3] ../../auth/ntlmssp/ntlmssp_util.c:72(debug_ntlmssp_flags)
  Got NTLMSSP neg_flags=0xe2088297
[2021/11/18 10:34:15.038608,  3] ../../auth/ntlmssp/ntlmssp_server.c:509(ntlmssp_server_preauth)
  Got user=[adminuser] domain=[FRITZWEG] workstation=[WN005] len1=24 len2=24
[2021/11/18 10:34:15.038645,  3] ../../source3/auth/auth.c:200(auth_check_ntlm_password)
  check_ntlm_password:  Checking password for unmapped user [FRITZWEG]\[adminuser]@[WN005] with the new password interface
[2021/11/18 10:34:15.038657,  3] ../../source3/auth/auth.c:203(auth_check_ntlm_password)
  check_ntlm_password:  mapped user is: [FRITZWEG]\[adminuser]@[WN005]
[2021/11/18 10:34:15.038879,  3] ../../source3/passdb/lookup_sid.c:1710(get_primary_group_sid)
  Forcing Primary Group to 'Domain Users' for adminuser
[2021/11/18 10:34:15.038954,  2] ../../libcli/auth/ntlm_check.c:472(ntlm_password_check)
  ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user adminuser
[2021/11/18 10:34:15.038968,  3] ../../libcli/auth/ntlm_check.c:479(ntlm_password_check)
  ntlm_password_check: NEITHER LanMan nor NT password supplied for user adminuser
[2021/11/18 10:34:15.039107,  2] ../../source3/auth/auth.c:344(auth_check_ntlm_password)
  check_ntlm_password:  Authentication for user [adminuser] -> [adminuser] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1
[2021/11/18 10:34:15.039145,  2] ../../auth/auth_log.c:635(log_authentication_event_human_readable)
  Auth: [SMB2,(null)] user [FRITZWEG]\[adminuser] at [Do, 18 Nov 2021 10:34:15.039132 CET] with [NTLMv1] status [NT_STATUS_WRONG_PASSWORD] workstation [WN005] remote host [ipv4:129.0.1.6:61674] mapped to [FRITZWEG]\[adminuser]. local host [ipv4:129.0.0.24:445] 
  {"timestamp": "2021-11-18T10:34:15.039202+0100", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 2}, "eventId": 4625, "logonId": "0", "logonType": 3, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:129.0.0.24:445", "remoteAddress": "ipv4:129.0.1.6:61674", "serviceDescription": "SMB2", "authDescription": null, "clientDomain": "FRITZWEG", "clientAccount": "adminuser", "workstation": "WN005", "becameAccount": null, "becameDomain": null, "becameSid": null, "mappedAccount": "adminuser", "mappedDomain": "FRITZWEG", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": null, "passwordType": "NTLMv1", "duration": 1328}}
[2021/11/18 10:34:15.039260,  3] ../../auth/gensec/spnego.c:1443(gensec_spnego_server_negTokenTarg_step)
  gensec_spnego_server_negTokenTarg_step: SPNEGO(ntlmssp) login failed: NT_STATUS_WRONG_PASSWORD
[2021/11/18 10:34:15.039290,  3] ../../source3/smbd/smb2_server.c:3861(smbd_smb2_request_error_ex)
  smbd_smb2_request_error_ex: smbd_smb2_request_error_ex: idx[1] status[NT_STATUS_LOGON_FAILURE] || at ../../source3/smbd/smb2_sesssetup.c:146
[2021/11/18 10:34:15.039840,  3] ../../source3/smbd/server_exit.c:220(exit_server_common)
  Server exit (NT_STATUS_CONNECTION_RESET)

Ich vermute es hat tatsächlich mit der Domain zu tun.

Mount auf Localhost auf die SMB Freigabe Funktioniert mit dem Benutzer und dem Password.

MfG Alexander

[mattiasmab]

Wenn ich das Log korrekt verstehe, versucht dein Client sich immer mit SMB2 und NTLMv1 zu verbinden. Das wäre aber doppelt fragwürdig, da SMB1 eigentlich nicht mehr genutzt werden soll und somit auch NTLMv1 auch. Letzteres sah man zuletzt eigentlich nur bei Windows XP.

Trage mal folgendes testweise in deiner smb.conf ein:

Code: Alles auswählen

server min protocol = LANMAN1
lanman auth=yes
ntlm auth=yes

Aber aus Sicherheitsgründen unbedingt anschließend wieder rausnehmen. Wenn es damit geht muss mal geschaut werden wieso NTLMv1 genutzt wird. Eigentlich benutzt Windows das neuste, was im Handshake ausgehandelt werden kann und es selbst bereit ist anzubieten (wie erwähnt ist z.B. SMB1 bei Win10 mittlerweile per Default aus).

[Tigger]

Hallo,

Ich vermute das es zu den Alten Protokollen kommt hat damit zu tun, da es das ende der Logdatei war, vermutlich versucht Windows alle Varianten durch bis eine Funktioniert.

Nichts desto trotz habe ich die Parameter mal eingestellt, leider ohne Erfolg.

[mattiasmab]

Ich vermute das es zu den Alten Protokollen kommt hat damit zu tun, da es das ende der Logdatei war, vermutlich versucht Windows alle Varianten durch bis eine Funktioniert.

Dem ist nicht so - zumal auch das Log keine anderen Versuche zeigt. Der Default von einem normalen Windows 10 ist NTLMv2-only - kein Fallback.

[2021/11/18 14:08:50.184836, 2] ../../libcli/auth/ntlm_check.c:472(ntlm_password_check)
ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user adminuser

Dein Log passt nicht zu dem was definitiv da sein müsste.
Hier steht nach wie vor, das NTLMv1 nicht erlaubt ist. Das bedeutet, dass die Einstellung von oben nicht gesetzt worden ist oder der Dienst nicht neugestartet worden ist. Anders ist diese Log-Meldung nicht nachvollziehbar.

Bitte nochmals folgende Zeile in die smb.conf am Ende des [global] Bereichs einfügen (die anderen Zeilen sind nicht notwendig, da es mit SMB2 verbunden wird):

Code: Alles auswählen

ntlm auth=yes

Anschließend den Dienst neustarten - sonst greift die Einstellung nicht! Auch nicht für neue Verbindungen.

Code: Alles auswählen

systemctl restart smbd

Außerdem sollte geprüft werden, warum ein Windows 8.1 und Windows 10 NTLMv1 schickt, wenn der Default seit Windows 7 NTLMv2 ist. Siehe dazu mal folgende Seite bei Microsoft und schau mal, ob die Richtlinie (oder der Registry-Eintrag) geändert worden ist. Alternativ kann der Wert auch selbst auf Stufe 3 (oder höher) eingestellt werden, falls irgendetwas anderes dies beeinflusst hat. Zu Testzwecken definitiv als Ausschlusskriterium zu probieren.
In einer sicheren internen Umgebung ist die obige Änderung der smb.conf egal, aber in einem Netz mit Angriffpotenzial bietet NTLMv1 eine große Angriffsfläche z.B. für Replay-Attacken, da es nur eine Zufallszahl als Challange nutzt. Hier sollte wirklich Wert darauf gelegt werden dem Grund der gesendeten NTLMv1 auf den Grund zu gehen.

[Tigger]

OK,
Gelöst, eine Uralte Einstellung in der GPO Stellte unsere Clients auf NTLMv1