Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
Question
Monday, December 18, 2017 7:03 PM
Hello,
When setting DWORD SmbServerNameHardeningLevel to 1 (Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters), the Default allowed SPNs are not what they should be to allow SMB connections. To be more specific, it's not trusting SMB connections to its own IPv4 IP address.
According to this Microsoft article:
By default, the SMB server will allow the following list of names and IPs:
- "localhost" as a string in English
- All the variants of IP (IPv4 and IPv6) of your own server or computer
- 127.0.0.1 & ::1
- Host name in NetBIOS format
- Host name in FQDN format
- (Failover Cluster nodes only) Cluster host name in NetBIOS format
- (Failover Cluster nodes only) Cluster host name in FQDN format
All of the above is true for Windows 7. However, in Windows 10, the IPv4 address and 127.0.0.1 are not trusted.
- If you try to open a CIFS SMB connection using \127.0.0.1 or \IPv4_Address, then you will get an "Access is denied" message asking for credentials.
- If you use \localhost then the connection is successful. Same for the FQDN.
For the failed connections, a 5168 Security event is logged:
- Spn check for SMB/SMB2 fails.
- SPN Name: cifs/127.0.0.1
- Error Code: 0xC0000022
To work around this, you must:
- Set the multi string SrvAllowedServerNames value to the IPv4 address and 127.0.0.1
Or - Set SmbServerNameHardeningLevel to 0
The problem is that we're not supposed to need to use SrvAllowedServerNames because the IPv4 and 127.0.0.1 are supposed to already be trusted.
Is Microsoft aware of this problem and is there a hotfix available?
Thanks.
All replies (11)
Tuesday, August 21, 2018 2:26 AM ✅Answered | 1 vote
I had a support case open on this, and I can confirm that it was fixed as of the July 24, 2018—KB4340917 (OS Build 17134.191) on 1803. I double tested it last week along with the August cumulative update. According to my support contact, they were only planning to fix it in the 1803 build, but it would make sense to me if they back ported to 1709 as well. I haven't personally tested 1709, but sounds like you're having luck with it.
Tuesday, December 19, 2017 9:10 AM
Hi B.Banner_Hulk,
Did you set “Microsoft Network Server: Server SPN target name validation level” group policy to "require from client" on server side?
If yes, it seems an expect symptom as SPN only sent to server when NTLMv2 or Kerberos protocols are used, and after that SPN can be validated.
For more information please refer to:5168(F): SPN check for SMB/SMB2 failed.
If I misunderstood your issue, please export and upload log files from Event Viewer\Windows Logs\Security. At the same time, upload SMB client logs and SMB server logs from %SystemRoot%\System32\Winevt\Logs location to OneDrive and paste the link here for deep analyses.
Bests,
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Tuesday, December 19, 2017 4:36 PM
Hi B.Banner_Hulk,
Did you set “Microsoft Network Server: Server SPN target name validation level” group policy to "require from client" on server side?
If yes, it seems an expect symptom as SPN only sent to server when NTLMv2 or Kerberos protocols are used, and after that SPN can be validated.
For more information please refer to:5168(F): SPN check for SMB/SMB2 failed.
If I misunderstood your issue, please export and upload log files from Event Viewer\Windows Logs\Security. At the same time, upload SMB client logs and SMB server logs from %SystemRoot%\System32\Winevt\Logs location to OneDrive and paste the link here for deep analyses.
Bests,
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
SPN target name validation level is set to "Accept if provided by client"
Again, we have this setting set on Windows 7 Enterprise and there's no problems. I can establish an SMB connection to the IP of any of our Windows 7 endpoints. This is only getting denied on Windows 10.
Below are the requested logs:
https://1drv.ms/f/s!Avy8q9pEemnQac8qhqUDpRIPs24
Thanks for looking into this.
Thursday, December 21, 2017 11:01 AM
Hi B.Banner,
The problem is that when use \localhost , \hostname or \other PC’s hostname, it can open shared files. However when use \127.0.0.1 , \IP address or \other PC’s IP address, it can’t open shared files. Right?
I have checked the log you upload, however it seem that it does little help to the issue.
According to my understanding and researches, we should try to disable IPv6 on Windows 10 machines.
In addition, please temporarily turn off all anti-virus software and firewall on the machine.
If the problem persists, try to refer to the following steps to catch network packets for analysis:
Please note that clear DNS cache before each time you catch netmons.
How to clear cache:
Open the DNS console, right-click server, and click Clear Cache.
How to catch netmon:
1.Download Microsoft Network Monitor Tool from the following link and install it on one win10 machine.
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=983b941d-06cb-4658-b7f6-3088333d062f
2.Start Network Monitor at "Start" ->"Program"-> "Microsoft Network Monitor 3.4" -> "Microsoft Network Monitor 3.4" on the win10 machine.
3.On the left-panel, check the "LAN connection" and uncheck the other unnecessary connections on the machine.
4.Click "Tools", click "Options", switch to the "Capture" tap, and set the "Temporary capture file size (MB)" to 200 on the machine.
5.On the machines, please run the following command line as administrator to clear client side cache, NetBIOS cache and Kerberos cache.
ipconfig /flushdns
nbtstat –RR
klist purge
6.Click "New Capture", click "Start" on the Capture menu from the machine.
7.Now try to copy the data to reproduce the tests we mentioned before.
8.When the issue occurs, click "Stop" on the Capture menu on the two machines, and click "File"->"Save as" to save the captured files.
Finally, please feedback all test result and upload the six packets to One Drive and paste link here.
Bests,
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Monday, December 25, 2017 1:34 AM
Hi,
Any update?
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, December 27, 2017 1:57 AM
Hi,
Was the issue resolved?
Bests,
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Wednesday, December 27, 2017 3:33 PM
Sorry it's been very busy and I haven't had time to get the requested information. This is not resolved yet and I'm currently using SrvAllowedServerNames as a workaround. I'll try to get the requested information this week.
Thursday, December 28, 2017 2:05 AM
Hi B.Banner,
Thank you for your reply.
We will wait the test result and do our best to help you to troubshoot the issue. The test time is up to you, take it easy, we will wait here all the time.
Bests,
Please remember to mark the replies as answers if they help.
If you have feedback for TechNet Subscriber Support, contact [email protected].
Thursday, June 7, 2018 3:01 AM
I've also struggled with SmbServerNameHardeningLevel=1 in Windows 10, the first issue arrived in Windows 10 version 1703 when they split apart all the svchost.exe processes. In that case you could map via IP address, but not by FQDN. Based on your description though, I'm assuming your working with 1709 which is when the mapping by IP address became broken, and I can also confirm that problem still exists in 1803 as well.
Monday, June 25, 2018 1:55 PM | 1 vote
Hi all,
I also have the same issue with W10 1709. I also posted it to partnersupport.microsoft.com [https://partnersupport.microsoft.com/en-us/par_clientsol/forum/par_win/cannot-connect-to-a-w10-1709-share-using-the-ip/55b9f10b-4524-4511-9c51-1aecbb35579e?tm=1529934475264] but finally found this interesting thread.
Any plan to fix it?
Thanks,
Laurent
Monday, August 20, 2018 11:19 PM
At first I thought this was fixed in Windows 10 v1803 but I went back and tested 1709 and it's working there now as well. Was this suddenly fixed in a recent patch? I'm running a scan on a test box now using our Tenable Nessus scanner. The scan would fail in the past due to it making connections via IP.