Your first thought is probably: Who the heck still uses NetBIOS over IP? I know that Windows doesn't need it anymore.
And, you're right. Windows (at least Vista and later) work just fine without NetBIOS over IP. However, there are a lot of devices with older SMB implementations that do require NetBIOS over IP. I ran into one Sharp MFP device today that requires it for scan to folder functionality.
Information about the update is published at: https://support.microsoft.com/en-us/kb/3161949
This update is a security update for WPAD. WPAD is a method for automatically configuring devices with a proxy server. However, as part of locking down this process, it does one critical thing. Here's the quote:
NETBIOS communication outside of the local subnet is hardened. Therefore, by default, some features that depend on NETBIOS (such as SMB over NETBIOS) will not work outside the local subnet.So, communication on the local subnet works, but if the MFP and server hosting the share are on different subnets then it breaks.
Fortunate the fix is pretty quick, add a registry key and reboot the server hosting the share:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\ParametersAnother Microsoft page that describes the same update, but slightly different description: https://support.microsoft.com/en-us/kb/3165191
Value Name: AllowNBToInternet
Type: Dword
Value: 1
It's also worth noting that when troubleshooting this, the Security event log did not contain failed logon attempts for the user accounts. NetBIOS over IP was being dropped at the networking level and authentication was never attempted.
Great article, Mr. Wright! That was a good read :)
ReplyDeleteI just recently ran into this problem. What I found out was very interesting and thought you might appreciate it as well.
ReplyDeleteThis applies to all Windows OSes 2000/XP and newer.
Per: https://support.microsoft.com/en-us/help/204279/direct-hosting-of-smb-over-tcp-ip
If your network adapter is set to allow NetBIOS over TCP (NBT), Windows uses either NetBIOS over TCP (NBT) or Direct hosting (SMB on TCP) to connect to SMB shares. NetBIOS over TCP uses ports 137-139 and Direct hosting uses port 445. So if you establish a connection to a share you can run netstat -an (run this quickly after opening the share) from the connecting PC and locate the IP of the hosted share and see if port 445 or 137-139 are in use. This will tell you what connection protocol is established.
Post Patch KB3161949
If your PC lost share connectivity via short name (\\servername\share) you have one of two issues.
1.) A DNS suffix for your PC is not specified so the domain is not being appended to your shortname search. Open System Properties, click the Computer Name tab, click the Change... button. This will open the Computer Name/Domain Changes window. Click the More... button and verify if the proper domain name is in the Primary suffix of this computer field. Now when you type "\\servername" the DNS suffix is appended and the connection is able to be established via the short name. If you need to work with multiple domain names you will need to add the list of domains to the "Append these DNS suffixes (in order)" section of DNS tab under TCP/IP Settings for the network adapter that you are using. Any unqualified short name will have each domain name in the list, in order from top to bottom, appended until it resolves in DNS or fails.
2.) Since patch KB3161949 has hardened NetBIOS over TCP it will only work for short names via the local subnet. If you specify the domain (\\servername.domain.com\share) it allows NetBIOS to look beyond your local subnet. So, if the proper domain name is in the Primary Suffix of the PC and specifying the FQDN works then you have something (firewall, antivirus, etc.) blocking port 445 between the PC and the share on another subnet. You can verify this by running netstat -an from a command prompt (do it quickly after establishing the share connection). You will see a connection from your machine to the IP of the share host with port "139 ESTABLISHED" and close to that you will see, (if you acted quickly enough) the same host IP with port 445 and a State of SYN_SENT. SYN_SENT indicates that your client has performed the first step of the three-way TCP handshake. Since something (firewall, antivirus, etc.) is blocking port 445 traffic this allows NetBIOS over TCP to win and the connection is established over port 139.
If you can clear what's blocking port 445, then using the short name (\\servername\share) will establish via Direct hosting (SMB on TCP). However, if the far end share is an older NAS, MFP, copier, etc that can only use SMB via NetBIOS over TCP (NBT) then you will have to use either the FQDN, the registry key, or remove the patch.