NetBIOS — The Service That Wouldn't Die
With the slow but steady migration to Windows 2000, NetBIOS receives another stay of execution. So, how does this collective pet peeve affect you?
most power and function you can get from Microsoft just
might be in Windows 2000 Datacenter Server — the strongest
server operating system we’ve ever offered. Whether you’re
an MCP in a corporate-technology department or with a Solution
Provider company, the newest Windows operating system may
provide the best business investment that your organization
— or your customer — can make for mission-critical computing.
We’re now close to our second year of Windows 2000, and
there are reported to be more than 2 million outstanding
licenses. Besides the obvious implication of millions
of dollars flowing into Microsoft, the number also implies
that the migration process to Win2K is well under way
around the world. It also means there are still many more
sites to go and that it’ll take quite awhile for the process
to be completed in any given company. As much as we’d
like to wave a magic wand and have a simple, immediate
process, the reality is that interoperability issues will
continue to be center stage for quite some time.
It’s Following Us
This is having the unintended effect of dragging out the
lifespan of one of my personal pet peeves with Windows
NT, LAN Manager before that, and MS-Net-based products
before that. This well-festered irritant is still stalking
us under the name of NetBIOS. Oh, I know its days are
numbered, but I remember when its days were numbered in
the late 1980s. I’m not sure if a stake through the heart
is required to rid us of this scourge, but I’m beginning
to wonder. I’ve covered the details of how NetBIOS works
before so I won’t go into too much detail here, but I
do want to cover some of the continuing implications it
raises for Win2K and Active Directory.
NetBIOS has a long history. It was developed in the early
1980s by a company called Sytec (now a part of Hughes
LAN Systems) under contract by IBM to connect those pesky
personal computers at the end of SNA-connected large computers,
which of course were going to be the future of enterprise
computing. Well, things have changed a bit, but you’re
still left with the architectural limitations of NetBIOS
as long as you have Windows 9x and NT clients attached
to your Win2K network.
The main limitation is that — while all movement in the
management of resources on networks today is toward a
hierarchical, enterprise-wide namespace — NetBIOS was
initially designed for a flat namespace with a maximum
of 72 named devices. This, of course, has been corrected
over the years through enhancements in its ability to
uniquely identify many more devices and with tools such
as WINS that trick NetBIOS into thinking it’s on a flat
network even though it may reside on a routed network.
The other main limitation of NetBIOS, which hasn’t been
extended, is that for any device to be recognized on the
network, the name can’t be more than 16 characters long.
This limitation is practically lowered to 15 characters
because the 16th character is reserved by the operating
system to identify the various services that exist on
the device. Since Microsoft recognizes that there won’t
be any overnight migration implementations and that its
previous success has created multiple millions of NetBIOS
nodes on existing networks, it’s built a strong level
of support for backward compatibility into the Win2K platform.
For this reason, continued NetBIOS support is part of
the default configuration for Win2K machines.
The first implication NetBIOS has for a mixed Microsoft
environment is in the naming conventions that you may
have considered with a hierarchical directory in mind.
The Active Directory name follows the DNS requirements
for supported names and provides up to 64 characters for
the host name, which would be joined with the DNS suffix.
These two name components comprise the fully qualified
domain name (FQDN). The suffix isn’t important for the
discussion, but the host name is critical. Best practices
would recommend that you keep your host name well shorter
than 64 characters, but you could make a case for a name
that exceeds the 15-character practical namespace limitation
length of NetBIOS. However, by default, if you add a workstation
with a name longer than 15 characters, it’ll be truncated
to fit into the NetBIOS namespace. This can wreak havoc
with any name standard you may have designed — regardless
of the character length.
What’s in a Name?
If you choose to keep NetBIOS naming conventions for interoperability
considerations while you’re migrating a system, you may
want to take some immediate initial steps. The legal characters
that are supported in NetBIOS and DNS are — for the most
part — comparable except for one major annoyance. Since
the NetBIOS namespace doesn’t allow spaces, it’s been
common practice for people to use underscores. The DNS
namespace uses the hyphen for the same reason. There’s
been a proposal to use the underscore for the names of
services advertised in DNS, but it’s still not a standard.
While Microsoft’s DNS supports Unicode characters, including
the underscore, you can’t count on the underscore to be
recognized by other DNS implementations, which is problematic
in the enterprise. The best practice is to change all
of the NetBIOS names that will be in place for any extended
period of time to support the overlapping NetBIOS and
DNS characters, which means avoiding both the underscore
and the hyphen. This will take some work, but it’ll be
time well spent if you plan a protracted migration.
You can have a different NetBIOS name and DNS name for
the same workstation. However, this approach introduces
questionable complexity. One of the backward-compatibility
features of Win2K is the interoperability between WINS
and DNS, where WINS can be listed in the DNS server to
help resolve names. If a particular machine has a DNS
name and a different NetBIOS name, there’ll be unpredictable
results depending on the source of any queries.
Another issue is that if you’ve decided to support client
names larger than 15 characters you’ll have to make administrative
modifications to the Access Control Entries (ACEs) in
the directory, which make up the Access Control List (ACL).
DNS names longer than the standard 15 characters will
be different from the SAM account name and can cause directory
confusion. The SAM name, designed to support the NetBIOS-based
NT technology, is used when adding a client name to the
directory. The administrator needs to modify the ACE security
properties in the directory security properties to map
the names and allow client names of more than 15 characters
to be written by the system to the ACE in the directory.
A Matter of Security
Beyond some of the administrative issues that need to
be considered, there are security concerns associated
with NetBIOS. They mostly revolve around the fact that
security wasn’t a consideration when NetBIOS was developed.
Greater security has been developed over the years to
surround the services that rely on NetBIOS, but NetBIOS
still behaves in a predictable manner when interrogated.
That behavior is to reply with its own information when
challenged and also assume the best intentions when provided
with a service that knows its name. While the services
themselves are, for the most part, effectively protected
through access control, NetBIOS is a particularly vulnerable
target for Denial of Service attacks.
NetBIOS is based on names rather than addresses. It resolves
naming conflicts by following a standard procedure when
it’s confronted with a challenge that the name it’s using
is claimed by another device. One version of this vulnerability
is manifested by a potential attack generated by a bogus
NetBIOS name server that’s used to send a name-release
datagram to the target machine. When the target machine
responds to the request, it becomes unavailable to legitimate
users. Another way to obtain the same effect is to send
the target machine a NetBIOS name-conflict datagram to
get the target machine to relinquish its name. Now, there
are ways to prevent this from happening, such as closing
the NetBIOS ports 137, 138 and 139 from the outside world
through your firewall. However, that won’t stop internal
attacks on system resources from disgruntled employees.
There’s also a patch that protects a machine from responding
to spoofed NetBIOS commands, but this could also have
the unintended result of preventing legitimate name-conflict
Another broad security issue with leaving the NetBIOS
backward-compatibility feature enabled is that the NBTSTAT
command can send useful information — such as the Active
User, services running, workstation name, and even the
MAC address — back to a requester. This is useful information
when it comes to building a map of a targeted system for
future hacking or other nefarious objectives.
This is not to say that Win2K is a fundamentally unsecured
platform — far from it. With Kerberos as the default authentication
protocol you can verify the client as well as the server,
so both sides of a connection are authenticated. However,
until you’ve completed a Win2K migration and removed all
the clients who need NetBIOS to advertise their presence,
establish sessions and access resources, you need to maintain
and design security enforcement points that include NetBIOS
For more on NetBIOS, read Michael
Chacon’s article, "The NetBIOS Barrier" in the November/December
1997 issue and Doug King’s article, "Living
in a World without NetBIOS" in the September
If you possess a premium certification
from Microsoft, access to these back issues is free
online. For details, visit http://mcpmag.com/subscribe.
Somebody, Get me a Stake
I certainly haven’t covered all of the issues surrounding
NetBIOS, but I hope I’ve reminded you to keep your eye
on the past as you move forward. Bottom line: If you’re
serious about moving to a Win2K enterprise information
system, you need to have the removal of NetBIOS clearly
outlined in your plan. Even if you have all your workstations
and servers on Win2K, you may have left NetBIOS and NTLM
authentication support still enabled. When you build your
project plan, set a milestone at which NetBIOS finally
succumbs to the stake through the heart. I’m sure there’ll
be little mourning from the bleachers.
Michael Chacon, MCSE, MCT, is a directory services architect, focusing on the business and technical issues surrounding identity management in the enterprise. He is the co-author of new book coming from Sybex Publishing that covers the MCSA's 70-218 exam.