ich habe - bin mir fast sicher - seit dem Update auf 4.3.1 das Problem das Geräte wie (Scanner, Fräsmaschinen etc.) nicht mehr auf die Shares des UCS-Master (Windows AD) zugreifen können.
Das Problem habe ich auf verschiedenen Installationen/Netzwerken.
Bei diesen Clients handel es sich allesamt um ältere Systeme. Diverse Fräsmaschinen in der Produktion laufen noch mit WindowsXP als und da diese fest verbaut sind kann ich dies nicht selbst ändern. Die Multifunktions-Geräte (Develop) die beim scannen aus SMB-Share schreiben haben diese Funktion fest eingebaut.
Kann es sein das beim Update in irgend einer Form die Mindestanforderungen für die Clients angehoben wurden? Ich habe mal erfolglos die Variabeln:
samba/client/min/protocol
samba/min/protocol
auf SMB2 und danach auf NT1 gesetzt was aber keine Besserung brauchte.
ich habe mal das Log-Level am samba hoch gesetzt. Beim Versuch com Scanner auf das Share zu schreieben finde ich dort:
sesssetupX:name=[peka.lan]\[scanner]@[192.168.100.31]
attempting to make a user_info for scanner (scanner)
making strings for scanner's user_info struct
making blobs for scanner's user_info struct
made a user_info for scanner (scanner)
auth_check_password_send: Checking password for unmapped user [peka.lan]\[scanner]@[192.168.100.31]
auth_check_password_send: user is: [peka.lan]\[scanner]@[192.168.100.31]
expr: (&(sAMAccountName=scanner)(objectclass=user))
dn: <GUID=f860e742-673c-4c7b-8981-66aea0a0a5bc>;<SID=S-1-5-21-629818648-978642449-4272356126-1135>;CN=scanner,CN=Users,DC=peka,DC=lan
sAMAccountName: scanner
userPrincipalName: scanner@PEKA.LAN
ntlm_password_check: NTLMv1 passwords NOT PERMITTED for user scanner
ntlm_password_check: Lanman passwords NOT PERMITTED for user scanner
ntlm_password_check: LM password and LMv2 failed for user scanner, and NT MD4 password in LM field not permitted
Not updating badPwdCount on CN=scanner,CN=Users,DC=peka,DC=lan after wrong password
auth_check_password_recv: sam authentication for user [peka.lan\scanner] FAILED with error NT_STATUS_WRONG_PASSWORD, authoritative=1
Auth: [SMB,bare-NTLM] user [peka.lan]\[scanner] at [So, 26 Aug 2018 09:30:58.027226 CEST] with [NTLMv1] status [NT_STATUS_WRONG_PASSWORD] workstation [192.168.100.31] remote host [ipv4:192.168.100.31:35742] mapped to [peka.lan]\[scanner]. local host [ipv4:192.168.100.11:445]
JSON Authentication: {"timestamp": "2018-08-26T09:30:58.027303+0200", "type": "Authentication", "Authentication": {"version": {"major": 1, "minor": 0}, "status": "NT_STATUS_WRONG_PASSWORD", "localAddress": "ipv4:192.168.100.11:445", "remoteAddress": "ipv4:192.168.100.31:35742", "serviceDescription": "SMB", "authDescription": "bare-NTLM", "clientDomain": "peka.lan", "clientAccount": "scanner", "workstation": "192.168.100.31", "becameAccount": null, "becameDomain": null, "becameSid": "(NULL SID)", "mappedAccount": "scanner", "mappedDomain": "peka.lan", "netlogonComputer": null, "netlogonTrustAccount": null, "netlogonNegotiateFlags": "0x00000000", "netlogonSecureChannelType": 0, "netlogonTrustAccountSid": "(NULL SID)", "passwordType": "NTLMv1"}}
das liegt vermutlich an den neuen Standardwerten für die UCR-Variable samba/ntlm/auth. Seit Errata 166 ist der Standard »nur noch NTLMv2«; vorher war auch noch NTLMv1 erlaubt.
… NTLMv2 wurde ja mit Windows NT 4 SP4 released. Da kann man den Gerätehersteller (Develop) doch zurecht mal anschreiben warum seine Geräte (gerade neu gekauft für nicht wenig Mana!) dies nicht unterstüzen, oder?
Vielen Dank dir! … Ich hätte Montag jetzt hier richtig Wallung gehabt
In einem anderen Thread, den ich gerade nicht wiederfinde, schrieb jemand mit einem ähnlichen Problem. Er musste seine Geräte fest auf NTLMv2 einstellen — in der Standardeinstellung (automatische Erkennung oder so?) klappte die Verbindung nicht.
wie hast Du den schönen Log-Eintrag bekommen? Welche Einstellung und welche Log-Datei?
Ich versuche schon ein paar Stunden meinen Scanner wieder Zugriff zu einem Netzwerkshare zu gestatten, allerdings hilft samba/ntlm/auth=yes bisher nicht.
Das Share liegt allerdings auch nicht direkt auf einem UCS-Server, sondern auf einem extra Datenserver, der über AD angebunden ist.
Grüße,
Bernd
OK, das hat sich erledigt - an einen Neustart der Samba-Dienste sollte man denken…
