Is NetBIOS Over TCP Required For Authentication?

[CHANGE USERNAME TO westes]

I'm having some configuration issues with a Microsoft Proxy Server 2.0 that
I would like help resolving.

The proxy server is configured to authenticate each user request, and
permissions to reach the Internet for various protocols is granted only to
specific userids in the Windows domain. What we are noticing is that any
time we turn off NetBIOS over TCP, the proxy server cannot authenticate
*any* user. Is NetBIOS over TCP really required for Windows 2000
authentication? If not, how can we get authentication to work when NetBIOS
over TCP is turned off?

The most serious problem with leaving NetBIOS over TCP turned on for the
internal ethernet segment is that our firewall is seeing nbname requests
going out from our proxy server every time there is a traceroute from the
console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of our
proxy server showing as the source ID on the packet!! Of course we can
trap those packets on the firewall and drop them, but I still don't want
them going out at all. Is there a trick to confining nbname lookups to
the internal interface and preventing those lookups from heading outbound on
the external ethernet segment of the proxy server?

 

[Phillip Windell]

Proxy2 is designed for NT4 (not 2000 or 2003). So I believe Netbios over
TCP/IP may be required.

But that isn't your problem. The problem is that you should not have any of
the Netbios/WINS stuff still bound to the external NIC in the first place.

Q257685 - Proxy Server 2.0 Security Checklist
http://support.microsoft.com/support/kb/articles/Q257/6/85.ASP

 

[CHANGE USERNAME TO westes]

Philip, of course we NEVER enabled NetBIOS over TCP on the *external*
interface. As I said in the original post,

"The most serious problem with leaving NetBIOS over TCP turned on for
the internal ethernet segment is that our firewall is seeing nbname requests
going out from our proxy server every time there is a traceroute from the
console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of our
proxy server showing as the source ID on the packet!! "

So just by enabling NetBIOS over TCP on the internal interface, NetBIOS over
TCP packets get sent out over the *external* interface, even though NetBIOS
over TCP is disabled on the external interface.

I think we have a routing error in our configuration. What routing
configuration will guarantee that NetBIOS over TCP requests stay put on the
internal ethernet segment?

--
Will
westes AT earthbroadcast.com

Proxy2 is designed for NT4 (not 2000 or 2003). So I believe Netbios over
TCP/IP may be required.

But that isn't your problem. The problem is that you should not have any of
the Netbios/WINS stuff still bound to the external NIC in the first place.

Q257685 - Proxy Server 2.0 Security Checklist
http://support.microsoft.com/support/kb/articles/Q257/6/85.ASP


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I'm having some configuration issues with a Microsoft Proxy Server 2.0 that
I would like help resolving.

The proxy server is configured to authenticate each user request, and
permissions to reach the Internet for various protocols is granted only to
specific userids in the Windows domain. What we are noticing is that any
time we turn off NetBIOS over TCP, the proxy server cannot authenticate
*any* user. Is NetBIOS over TCP really required for Windows 2000
authentication? If not, how can we get authentication to work when NetBIOS
over TCP is turned off?

The most serious problem with leaving NetBIOS over TCP turned on for the
internal ethernet segment is that our firewall is seeing nbname requests
going out from our proxy server every time there is a traceroute from the
console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of our
proxy server showing as the source ID on the packet!! Of course we can
trap those packets on the firewall and drop them, but I still don't want
them going out at all. Is there a trick to confining nbname lookups to
the internal interface and preventing those lookups from heading

outbound

on
the external ethernet segment of the proxy server?

 

[Steven L Umbach]

What kind of clients are on the network and is this a W2K domain?? Downlevel clients
will use netbios name resolution first. You might want to check the order of the nics
in network connections/advanced so that the internal nic is at the top of the
ist. --- Steve

Philip, of course we NEVER enabled NetBIOS over TCP on the *external*
interface. As I said in the original post,

"The most serious problem with leaving NetBIOS over TCP turned on for
the internal ethernet segment is that our firewall is seeing nbname requests
going out from our proxy server every time there is a traceroute from the
console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of our
proxy server showing as the source ID on the packet!! "

So just by enabling NetBIOS over TCP on the internal interface, NetBIOS over
TCP packets get sent out over the *external* interface, even though NetBIOS
over TCP is disabled on the external interface.

I think we have a routing error in our configuration. What routing
configuration will guarantee that NetBIOS over TCP requests stay put on the
internal ethernet segment?

--
Will
westes AT earthbroadcast.com

Proxy2 is designed for NT4 (not 2000 or 2003). So I believe Netbios over
TCP/IP may be required.

But that isn't your problem. The problem is that you should not have any of
the Netbios/WINS stuff still bound to the external NIC in the first place.

Q257685 - Proxy Server 2.0 Security Checklist
http://support.microsoft.com/support/kb/articles/Q257/6/85.ASP


--

Phillip Windell [MCP, MVP, CCNA]
www.wandtv.com

I'm having some configuration issues with a Microsoft Proxy Server 2.0 that
I would like help resolving.

The proxy server is configured to authenticate each user request, and
permissions to reach the Internet for various protocols is granted only to
specific userids in the Windows domain. What we are noticing is that any
time we turn off NetBIOS over TCP, the proxy server cannot authenticate
*any* user. Is NetBIOS over TCP really required for Windows 2000
authentication? If not, how can we get authentication to work when NetBIOS
over TCP is turned off?

The most serious problem with leaving NetBIOS over TCP turned on for the
internal ethernet segment is that our firewall is seeing nbname requests
going out from our proxy server every time there is a traceroute from the
console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of our
proxy server showing as the source ID on the packet!! Of course we can
trap those packets on the firewall and drop them, but I still don't want
them going out at all. Is there a trick to confining nbname lookups to
the internal interface and preventing those lookups from heading

outbound

on
the external ethernet segment of the proxy server?

 

[Phillip Windell]

console of the proxy server. Apparently Windows tries to do an nbname
lookup prior to doing a DNS lookup using pure IP. Those requests are
getting routed to the external interface with the internal IP address of

our

Netbios is not routable, so it isn't getting "routed" anywhere so they would
have to originate at the external NIC itself. If you are trace routing
outbound then that would be logical. Even if they go out the external
interface they can't go past your Router (or firewall) because they aren't
routable, that's why a WINS server is required to cross subnets with netbois
naming, so I think you are worried for nothing anyway. But checkout
Steven's reply, I think that is a good idea to check if this is a Win2000 or
2003 machine.

 

[CHANGE USERNAME TO westes]

NetBIOS over TCP is routable isn't it? On our firewall log, we are
attacked by hosts all over the world with nbname requests to all of our
public IPs, at least 40 times each hour.

The proxy server is Windows 2000, in a Windows 2000 domain. I was
tracerouting outbound, but why would this generate an nbname on the outbound
adapter when that adapter specifically disables NetBIOS over TCP? If this
is how it is supposed to work, then what exactly does disabling NetBIOS over
TCP disable on that outbound adapter? It's either far more subtle than I
am seeing or its just not well-implemented functionality.

I'll check on adapter order as well.

 

[Phillip Windell]

NetBIOS over TCP is routable isn't it? On our firewall log, we are

Sorry, I was thinking of Netbois broadcasts. Broadcasts aren't, but directed
ones with "Netbios over TCP/IP" would be.

adapter when that adapter specifically disables NetBIOS over TCP? If this
is how it is supposed to work, then what exactly does disabling NetBIOS over
TCP disable on that outbound adapter?

Did you "uncheck" Client for Microsoft Networking" and "Printer Sharing"?
The only thing you need enabled on the external NIC is TCP/IP.

 

[CHANGE USERNAME TO westes]

On the external NIC we enable TCP and Network Monitor, and that is all we
enable.

Again, I think this must be some kind of routing issue. I think the nbname
inquiry is generated on the internal NIC, and for some reason is getting
routed outbound. I would have hoped that it would have been filtered out
as soon as the external NIC handled it, but that is not happening.

I hate to have to spend an hour with a packet dump, and even then I'm not
sure that would suggest the solution right away.

 

[CHANGE USERNAME TO westes]

Steve, could you clarify how I sort the order of the NICS in Network
Connections? In Windows 2000 I am not seeing a way to affect their order of
operation.

 

[Phillip Windell]

Steve, could you clarify how I sort the order of the NICS in Network
Connections? In Windows 2000 I am not seeing a way to affect their order of
operation.

Network Neighborhood ---> Properties --->Advanced (on menu) ---> Advanced
Settings...(on menu dropdown).

The NICs are listed in the upper box. Use the "Arrow Buttons" on the right
to move the NICs up or down. You want the Internal NIC at the top.

 

[CHANGE USERNAME TO westes]

Are you sure you are not referring to Windows NT 4.0? On my Computer there
is a "My Network Places" and right clicking on this and then Properties
brings you to a list of NICs that cannot be re-ordered. If I right click
on a NIC and select Properties, I can select TCP/IP but nowhere on those
dialogs do I see a NIC ordering interface.

--
Will
westes AT earthbroadcast.com


If I right click on a NIC

 

[Phillip Windell]

No, I'm refering to Win2000(2003)

From My Network Places -->Properties (as you did)
Then from the *menu* at the *top* choose "Advanced" and from there choose
"Advanced Settings...". You will probably know what to do from there.

 

[CHANGE USERNAME TO westes]

Steve, I found the interface to arrange NIC order, and the internal
interface was already the one at the top.

In our case, we do not want anyone at the proxy server console to be able to
easily resolve hostnames on the internal network using DNS. Why wouldn't
we put the external NIC at the top of the list?

 

[Phillip Windell]

In our case, we do not want anyone at the proxy server console to be able to
easily resolve hostnames on the internal network using DNS.

I'm sorry, but that is an unrealistic thing to "want". If the proxy cannot
resolve internal names then it will not be able to verify if a FQDN is
internal of external because it won't be able to resolve it, then it will
not be able to compare it to the LAT to determine if it should be processed
by the proxy services or allow to function directly.

In an Active Directory Environment (Win2000 or 2003) the proxy must use the
Internal DNS to resolve names, then the DNS Server will use "Forwarders" to
pass the requests to the ISP's DNS for name it cannot resolve from its own
database.

Why wouldn't
we put the external NIC at the top of the list?

Because it won't function on the Domain properly. It will start having
trouble finding the Domain Controller and authentication will either fail or
at least become unreliable.

 

[Steven L Umbach]

Ok. It should be at the top in order to function correctly within the local network.
I don't quite understand what your issue is with users at the proxy server console
and dns. I would suggest that you limit who can logon to the proxy server locally by
modifying the Local Security Policy for logon locally user right to be just
authorized users. I don't have a proxy server handy, but I would make sure file and
print sharing is disabled on the proxy server and configure the rules to block all
but authorized traffic to the internet and you should have good security. --- Steve

 

[Phillip Windell]

I wasn't sure about that first part either. It is an unrealistic
expectation, Proxy2 will not function properly if it doesn't have properly
functioning resolution on the LAN.

authorized users. I don't have a proxy server handy, but I would make sure file and
print sharing is disabled on the proxy server

Sharing must be enabled to install the WSP Client from the Proxy to the
Clients. But if that is never used then it could be disabled.

and configure the rules to block all
but authorized traffic to the internet and you should have good

ecurity. --- Steve

Proxy2 takes the "Deny All - Then Allow" approach to security, so whatever
wasn't specifically allowed will already be denied. If it worked the other
way around then it would become impossible to manage with the way it was
designed. Proxy2 doesn't have rules in the way the ISA does, ISA is
massively different than Proxy2 when it comes to that stuff.