Everyone hates NetBIOS, so why is it still around? If you recall, NetBIOS is an ancient (1983) session-level interface and transport protocol developed by Sytec for IBM to network together PCs. It's noisy (broadcast-based), insecure (commands like net view and nbtstat can tell attackers a lot about a NetBIOS network), and scales poorly (its flat namespace was originally designed for LANs with a maximum of 72 hosts).
Microsoft adopted it in the late 1980s for their LAN Manager product and it found its way into early versions of Windows and from there into Windows NT. And it's still present (and turned on by default) in Windows 2000, Windows XP, and Windows Server 2003 because many corporate networks still have legacy (Windows 9x or Windows NT) machines on their network. These machines need NetBIOS to function properly on a network because they use NetBIOS to logon to domains, find one another, and establish sessions for accessing shared resources.
Since Windows 2000 however, DNS has become the default name resolution method for Windows-based networks and is required if you want to deploy Active Directory domains. So if DNS can be used to find domain controllers for logon purposes and file/print servers for resource access, what's the point of leaving NetBIOS enabled on a pure Windows-2000/XP/2003 network where there are no more legacy machines?
After all, in this knowledge base article Microsoft seems to suggest that it's quite OK to disable NetBIOS over TCP/IP (NBT) on your machines, provided certain conditions are met:
"Before you turn off WINS/NetBT name resolution, verify that you do not need to use WINS or earlier NetBT-type applications for this network connection. For example, you can turn off WINS/NetBT name resolution if you communicate only with others that run a product in Windows Server 2003 (Microsoft Windows XP, or Microsoft Windows 2000), that use DNS and that register their names with DNS, or if you communicate with Internet computers using DNS-aware applications. Do not turn off WINS/NetBT name resolution if you communicate with computers that run a version of Windows that may use WINS or earlier NetBT-type applications (such as Microsoft Windows NT, Microsoft Windows Millennium Edition, Microsoft Windows 98, or Microsoft Windows 95)."
Related Reading  Windows Server Hacks |
After reading this, you may be tempted to disable NetBIOS on all your machines for greater security. I mean, even if you're already blocking ports 137 (for NetBIOS name resolution), 138 (for NetBIOS browsing and logon), and 139 (for NetBIOS file and print sharing using SMB) on your firewall, you're protecting your network from external attackers trying to exploit NetBIOS to find out information about your network. But this doesn't prevent an insider attack that uses nbtstat to enumerate your network by listing NetBIOS name tables and sessions as a prelude to further penetration.
Unexpected Consequences
One of the unexpected consequences of disabling NetBIOS completely on your network is how this affects trusts between forests. Windows 2000 let you create an external (non-transitive) trust between a domain in one forest and a domain in a different forest so users in one forest could access resources in the trusting domain of the other forest. Windows Server 2003 took this a step further by allowing you to create a new type of two-way transitive trusts called forest trusts that allow users in any domain of one forest access resources in any domain of the other forest.
Amazingly, NetBIOS is actually still used in the trust creation process -- even though Microsoft has officially "deprecated" NetBIOS in versions of Windows from 2000 on.
Here's a simple illustration. Install Windows Server 2003 on two machines as standalone servers. Use dcpromo (or Manage Your Server) to install Active Directory on one of them, using test.local as the DNS name of the forest root domain. As you walk through this process, dcpromo will automatically suggest TEST as the NetBIOS name for the new domain, and accept this default.
Then promote the second machine and try to create a second forest whose root domain is named test.com. Notice when you do this the wizard automatically suggests TEST0 as the NetBIOS name for the second domain so there won't be any NetBIOS name conflict with the first domain -- even though the two domains are in different forests. Once you're done you can use Active Directory Domains and Trusts in either forest to create a two-way transitive forest trust between the two forests as desired.
Now try it again, but this time after installing Windows Server 2003 on your machines disable NetBIOS on them as follows: open Local Area Connection, double-click on Internet Protocol (TCP/IP), click Advanced, go to the WINS tab, and select the Disable NetBIOS over TCP/IP option (you don't have to reboot for the change to take effect). Now continue as before, creating the forest root domain test.local for the first forest.
But now when you try to create the forest root domain test.com for the second forest, the second machine can't use NetBIOS to detect that another domain is already using TEST for its NetBIOS name and so you end up with two forests, test.local and test.com, both of which have forest root domains whose NetBIOS name is TEST.
Before you try to get the two domains to trust each other, you have to allow them to somehow resolve each other's names. Since NetBIOS is disabled, you must use DNS to do this. The simplest way is to configure conditional forwarding on the test.local domain controller so it forwards all name resolution requests to the test.com domain controller, and vice versa (both machines are also DNS servers since they are the first domain controllers in their respective forests).
Once you've done this extra step, go ahead and try establishing a forest trust (or even an external trust) between the two domains. You can't -- the process fails with an error message even though it walks you through all the steps of the wizard and the domains resolve each other. And enabling NetBIOS at this point on the machines doesn't help either; the problem is the two domains have identical NetBIOS names. So you're stuck and will have to reinstall one of the domains from scratch, for even the domain rename tool (rendom.exe) won't let you rename the forest root domain.
It Gets Worse
The fact that NetBIOS support is required for establishing trusts seems unfortunately to be by design to allow legacy Windows NT domains participate fully in Windows 2000/2003 forests. In fact, in the first example above of two forests trusting each other, NetBIOS limitations stare you in the face each time you log on to the network.
For example, say we went on and created a child domain one.test.local in the first forest and two.test.com in the second forest. Note first of all that all domains in both forests must have unique NetBIOS names in order for name resolution to work properly and support access to resources across forest boundaries. So naming the first one.test.local and the other one.test.com is usually not a good idea unless you are willing to accept ONE0 as the NetBIOS name for the second child domain (and if your two networks are disconnected when the child domains are created, you'll end up with identical NetBIOS names for these domains with attendant issues).
Now go to a machine in the one.test.local domain and press CTRL+ALT+DEL to display the logon box. Let's say for example that you're an employee of test.com who is visiting test.local and you want to log on from a machine in the one.test.local domain to the two.test.com child domain in the other forest where your user account resides.
So you click the Log On To list box to view a list of logon domains, and what do you see? You see the following NetBIOS (not DNS) names of domains in both forests:
- TEST
- ONE
- TEST0
Where is domain TWO? Unfortunately the Windows logon box can only display:
- NetBIOS names of all domains (TEST and ONE) in the current forest.
- The NetBIOS name of the forest root domain (TEST0) of the trusted forest.
All other domains in the trusted forest are not displayed. Fortunately you can still log on to two.test.com by entering your User Principal Name (UPN) in the logon box, for example joesmith@two.test.com. But it's an annoyance that you can't simply select TWO from the Log On To list box and type your plain old username joesmith and log on. And as I understand it, this annoyance is by design to ensure compatibility with NT domains, and it has to do with NetBIOS. Weird.
Conclusion
There are probably other subtle ways disabling NetBIOS might adversely affect your network even if it is running only Windows 2000 or above. The bottom line is, before you go around disabling NetBIOS on all your machines, thoroughly test how this step will affect resource access and legacy applications running on your servers.
And perhaps use other approaches to prevent inside attackers from enumerating your network using NetBIOS. For example, try disabling NetBIOS only on critical file servers since Windows 2000 or later can use SMB over TCP/IP (Windows NT required SMB over NBT) using port 445. Or you could leave NetBIOS enabled on these servers and configure IPSec filters to block the NetBIOS ports (137-139) on these machines. See KB 323357 for more help on this matter.
One type of machine you really need to disable NetBIOS on, however, is edge machines such as bastion hosts or proxy servers, as you don't want people trying to enumerate the NetBIOS table on these machines from over the Internet.
Mitch Tulloch
is the author of Windows 2000 Administration in a Nutshell, Windows Server 2003 in a Nutshell, and Windows Server Hacks.
REFERENCES
http://windowsdevcenter.com/pub/a/windows/2004/05/11/netbios.html
