SMB1 compatible device will not connect to Server 2019 share, connects to Server 2012 r2, continuious 4625 with known good credentials

Question

Hello,

I have a very odd issue that I've searched to great legnth but I have been unable to identify a solution.

Here's the situation, an on-site appliance specifically a FaxFinder Fax Server appears to be a Unix based appliance with SMB1/CIFS support to connect to a Windows file share. Currently this appliance connects to a server running Windows Server 2012 R2 Standard that is acting as a DC/File Share. We are intending to retire the 2012 box in favor of a Windows Server 2019 Standard install.

On the Server 2012 r2 box, we use AD credentials to access the share with no issue, I have checked the SMBServer logs on the 2012 r2 box and it doesn't specifically state, like the 2019 box does, that the appliance is attempting to connect via SMB1. I guesstimate this is because the user logins are all successful on the 2012 r2 machine, or 2019 has added logs since SMB1 is disabled by default.

Here's what I see in the SMB Logs on the 2019 box when I see a failure to connect. (I can provide the etlx upon request)
An Event ID 3000
SMB1 access
Client Address: 192.168.88.21
Guidance:
This event indicates that a client attempted to access the server using SMB1. To stop auditing SMB1 access, use the Windows PowerShell cmdlet Set-SmbServerConfiguration.

After this I get a 551 stating this even though I am positive I have the correct credentials
*SMB Session Authentication Failure
Client Name: \192.168.88.21
Client Address: 192.168.88.21:35154
User Name: scan
Session ID: 0x0
Status: The attempted logon is invalid. This is either due to a bad username or authentication information. (0xC000006D)
SPN: session setup failed before the SPN could be queried
SPN Validation Policy: SPN optional / no validation

Guidance:
You should expect this error when attempting to connect to shares using incorrect credentials.
This error does not always indicate a problem with authorization, but mainly authentication. It is more common with non-Windows clients.
This error can occur when using incorrect usernames and passwords with NTLM, mismatched LmCompatibility settings between client and server, an incorrect service principal name, duplicate Kerberos service principal names, incorrect Kerberos ticket-granting service tickets, or Guest accounts without Guest access enabled*

I also get an Event ID 4625 in the Security Logs stating bad username or password but I know they are correct.

So on to what I have tried:

1. Try a different user account with known good password
2. In Group Policy change "Network Security: Lan Manager Authentication Level" to Send NTLMv2 response only. Refuse LM (and all other NTLMv2 options listed) This is set to the default of "Send NTLMv2 response only" on the working 2012 server
3. Verified that "Microsoft Network Client: Digitally sign communications (always) is disabled
4. Verified that User Rights Assignment in GPEdit matches on the servers
5. Restarted both client and server
6. Changed login syntax from "domainname.local\username" to "username"
7. Changed server target on appliance to FQDN of server "\servername.domainname.local\share" as well as IP address "\192.168.0.10\share" and "\servername\share" and changing the all the back slashes to forward slashes since it's a unix based machine I'm connecting from however the working server is using FQDN syntax with 0 problem.
8. Compared most if not all Group Policy settings between machines and they appear near identical from all the security standpoints that I have reviewed.

Just looking to see if anyone else has an idea of where to proceed. This is a very specific issue and I've run into similar problems in the past but I've not nothing on this one. I hope I've provided enough information on this but please ask questions if you'd like clarification!

Thanks!

Answer 1

GOT IT!

I have been hammering at this for... WAY too long searching forums everywhere. I never did find "the answer" online and I stumbled upon it. I even attempted setting up SFTP which is the only other file transfer option and I couldn't get that working to save my life.

What was the issue you may wonder? Network Discovery! What's the weirdest thing about this that I don't understand? I just enabled Network Discovery, then closed the window. I then re-opened the window and it displays as turned off?... what?... On the plus side, post-reboot I still have a solid login!

Holy cow, that took forever to figure out, I hope this helps someone some day.

Answer 2

@Daisy Zhou

No worries on the late reply, we all get busy.

I have verified that other clients, and servers are able to successfully access the network share using the same credentials, I am wondering if this is a user authentication issue more than it is an SMB specific issue because all of the errors point access denials, however the device is able to send good credentials to the 2012 box using the same user ID, and syntax for both the FQDN of the server, and identical user account credentials.

I have verified via that powershell command that SMB1 is definitely enabled, and without it enabled I would not have received the Event ID 3000 messages I mentioned in the original post.

The FaxFinder gives these options for an SMB connection. They are configured with identical accounts (I have only obscured the FQDN) The username also has an associated password on the domain, identical credentials have been entered for both of them.

Please let me know your thoughts.

Answer 3

@Thameur-BOURBITA

Here's a snip of the negotiate protocol response. Definitely appears to be SMB1

SMB1 is enabled as seen here.

Answer 4

Hi,

You have apply a filter to select only SMB protocol. SMB means SMBv1 , When the client and the server negotiate with SMBv2 , wireshark display SMBv2 like image below:

Please don't forget to mark this reply as answer if it help you to fix your issue

Answer 5

@Thameur-BOURBITA

I have run a wireshark trace however I'm not super familiar with what I need to read from the results. I do see communication from device to the server on TCP port 445 as it's destination. Looking further into the logs I have identified an SMB "Negotiate Protocol Request" followed by an SMB "Session Setup AndX Request, User: Username in question

Here's what leads up to the failure. (I obscured the username intentionally)

Let me know if the actual logs would be helpful for you as well.