WindowsNetworking.com Monthly Newsletter of May 2008 Sponsored by: Lockstep
Welcome to the WindowsNetworking.com newsletter by Thomas W Shinder MD, MVP. Each month we will bring you interesting and helpful information on the world of Windows Networking. We want to know what all *you* are interested in hearing about. Please send your suggestions for future newsletter content to: email@example.com
Windows 2000 was the first Microsoft operating system that was almost completely free of the chains of NetBIOS dependence for core network operating system functions. This is a tremendous boon to you, the network administrator. It means that you can, in the right circumstances, completely disable the NetBIOS interface and reduce the amount of broadcast traffic on your network. Even better, you would be free of the dreaded Browser Service, which is responsible for a significant amount of network traffic and can represent a security risk on your network.
However, total freedom has not arrived quite yet. In order to eliminate NetBIOS from your network, you must be sure that all your applications and servers are written to the WinSock interface, rather than the NetBIOS interface, for network calls. The unfortunate truth is that the history of Microsoft networking is firmly entrenched in NetBIOS, and therefore it is likely that you will have some mission critical NetBIOS dependent services running on your network.
So, while we wait for our NetBIOS emancipation day, we must be ready and willing to take on the challenge of NetBIOS. The biggest challenge on our TCP/IP networks is that of NetBIOS Name Resolution. This is because TCP/IP does not care about NetBIOS names; the non-application layers of the TCP/IP protocol stack only care about IP addresses. To make NetBIOS applications work on IP based networks, we have to translate the NetBIOS names handled down from the Application layer to IP addresses.
This is where the Windows Internet Name Service (WINS) comes in. WINS provides us with three primary advantages over other modes of NetBIOS name resolution:
Because of these advantages, you will want to use WINS in any but the smallest of Microsoft network environments. And while Windows Server 2003 and Windows Server 2008 and updated Microsoft Server Applications have gone a long way at reduced dependencies on NetBIOS and NetBT, it is likely that some of your client or server applications are still tied to the NetBIOS interface.
WINS is a Database Server
Something you should keep in mind is that WINS is database server that participates in a client/server environment. The WINS database contains NetBIOS name/IP address mappings that WINS clients can query and resolve NetBIOS names anywhere on the network.
WINS is designed to be a distributed database, similar to DNS, but different in that the WINS database is not “partitioned” like the DNS. Rather, each WINS Server on the network should contain a complete copy of the WINS database for the entire organization, and this copy should be the same for all WINS Servers on the network.
Life would be a lot easier if there were a single WINS database on a single WINS server, to which all NetBIOS Name Query requests could be sent. You could design your network in this way, but there are several disadvantages:
With these considerations in mind, you will want to place at least two WINS Servers on each side of a WAN link in your organization. In this way you significantly reduce the amount of name query traffic traversing the link, and you provide for fault tolerance at each site. Many installations will include a WINS Server on each segment of their LAN to reduce the amount of traffic on the corporate backbone.
Note that multiple WINS servers at each side of a WAN link are helpful when the “far side” has multiple network IDs. If you have branch offices with a single network ID, and not too many hosts, then a single WINS server at the branch office is reasonable, especially since that WINS server is likely located on a branch office domain controller. In that case, if the mixed domain controller and WINS server goes down, you are going to have more problems then just NetBIOS name resolution.
How is the WINS Database Distributed?
The WINS database is distributed via a process known as replication. When WINS Servers are configured to share WINS database information with one another, they are referred to as Replication Partners. The entries in the WINS database are replicated from one WINS Server to another via push or pull replication, or both. The ultimate goal of WINS database replication is that all WINS Servers on the network contain the same, up-to-date copy of the entire NetBIOS name space for the organization.
Pull replication is based on the amount of time that has passed since the previous replication event. When you configure a WINS Server to be a Pull partner of another WINS Server, you also configure how long the WINS Server should wait before sending a Pull Request message to its partner. It you configure the Pull Partner to send a Pull Request every 60 minutes, then that partner will receive any changes to the WINS database that have taken place in the last 60 minutes, which is how long it has been since its last update.
On the other hand, you might want to set up a WINS Server to be a Push Partner of another WINS Server. In this case, time is not an issue. Rather, the WINS Server that has been configured as a push partner of another WINS Server will send the changes in its WINS database after a certain number of changes have taken place.
For example, you could configure a WINS Server to send the changes in its database after 100 records have been changed since its last push replication event with its partner. When the trigger number of changes has taken place, the WINS Server that is the push partner will send a push notification to its partner that it is time to send a pull request.
Note that in the case of both the push and the pull partnerships, the WINS Server receiving the changes must always send a pull request. It is just in the case of the push replication that the push partner “reminds” its partner to send the pull request after a defined number of changes have taken place in the WINS database.
When should I make WINS Servers Push and Pull Partners?
The art of designing a WINS replication network includes your thoughtful construction of the Push and Pull partner relationships in your WINS network. As a general rule of thumb, WINS Servers that are connected via fast links (e.g., 10Mbps or faster) should be configured as push partners, and WINS Servers that are connected via slow links, such as WAN connections, should be configured as pull partners. This is because you have more direct control over when replication takes place when you configure the pull partner relationship.
Now, that is the rule of thumb. In this real world, you are more likely to configure the machines connected via fast links as push and pull partners of each other. You may also choose to configure WINS Servers separated by WAN links as push partners, depending on the specific needs of your organization, and how important WINS database convergence time is to your company (we will talk more about convergence time in detail in the second part of this article).
Why Design a WINS Replication Network?
The whole procedure looks pretty simple at this point, doesn’t it? In fact, if you have only two WINS servers the process of WINS replication is virtually flawless. In this situation, the WINS database on both machines can be made to be almost identical a good fraction of the time. This is especially the case if you choose the “automatic update” feature. However, when you work with WINS in a more complex network, things get more complicated.
But what happens when you have two geographically disparate sites, and each site has multiple segments that include redundant WINS Servers?
For example, imagine that you have a site in Dallas, Texas that has five physical segments, and you have chosen to place a WINS Server on each segment to reduce the amount of traffic on the network backbone. You also have a major facility in Portland, Oregon where there are four physical segments and you have placed a WINS Server on each segment for the same reason you have in Dallas. Suppose that each populated segment has about 500 WINS client computers, with the total number of WINS clients at around 4500 for your company.
How Would You Configure WINS Replication?
How would you configure WINS replication in this network? I have seen too many companies with a similar network infrastructure just configure all WINS Server to be push/pull partners of each other, and always with disastrous results. The administrators end up blaming Microsoft for their problems when in fact the fault lies in the poor configuration of their WINS replication network.
For example, what happens when a WINS client on Segment A in Dallas registers a new IP address with its WINS Server? This information must find its way to all the other WINS Servers in Dallas, and it must also get to all the WINS Servers in Portland.
How would you configure your WINS Replication partners so as to:
You want to make sure you design your WINS network in such a way as to minimize network traffic, especially in light of the fact that the primary reason you have installed multiple WINS Servers was to reduce the amount of NetBIOS traffic on your network. Numbers 2 and 3 above are somewhat related, because database consistency and convergence time are related, although not exactly the same. A consistent WINS database means that all the WINS Server contain accurate copies of all WINS client information throughout the enterprise. An inconsistent WINS database implies that there are inaccurate records. Convergence time has to do with the time it takes for a changed WINS database record to be replicated to the point farthest away on your WINS replication network.
In next month’s newsletter, I will cover the details of how to configure your WINS Replication network. We will go over a few examples of WINS Network topologies, introduce the hub and spoke model, and see how to use that model in different configurations. Finally, we will get into the concept of convergence time, and see how you can configure your WINS replication network to optimize convergence time based on the requirements for your organization.
If you have any questions about WINS or Windows Networking or Windows Network Services, let me know! My answers will show up in next month’s newsletter in the Q&A section. Write me at firstname.lastname@example.org.
Quote of the Month - “I have failed many times, and that’s why I’m a success.”
I am sad to have to tell you that the MCP advanced search is down this month. What is the MCP advanced search? It is a search engine that was available to Microsoft Certificate Professionals that allowed them the search features that used to be available to everyone. Most importantly, the search feature that allowed you to focus your search by date, so that you could find the KB articles that were published in the last week, last month, last three months or last year. Let us hope they get the KB article search feature fixed soon, so that we can find a way to finding the latest KBs.
However, I don't want you to go without any KB articles this month, so I hand picked several that I think you'll benefit from. While these articles aren't the most recent articles published on the KB site, I think you'll still find the information topical.
I notice that I have a lot of certificates that appear in the Certificates MMC that show as expired. Also, I notice that I have multiple certificates that have the same name on them. I have not deleted any of these certificates because I am not sure it is safe. Can you help me with this? Thanks! –Doug.
First, any certificate that’s expired you can delete, as they are not doing anything for you. However, before you delete the expired certificates, try to determine what that certificate is being used for. If you are not using the certificate for anything, then go ahead and delete it right away. However, if you think that it should be used for something, confirm that you have a new, valid certificate that replaces the expired one.
This ties into your second question. If you have multiple certificates that have the same name, it is likely that some of them are expired certificates. If they are expired, then you can delete the expired certificates. If you have multiple certificates that have the same name, but are all valid, check into what the certificate is being used for. Since what is important is the validity and common/subject name on the certificate, you can delete one of them. However, before you delete it, it is a good idea to back it up to a file. That way you can restore it in the unusual circumstance that you might actually need it.
My users use a terminal server to connect to their desktops when on the corporate network. This allows them access to the applications they need to use to get their work done here in the office. Now my users are asking me if they can connect to the Terminal Server from home. I have some concerns about exposing an RDP server over the Internet. What do you think? Thanks! – Jason.
You are right to be concerned about the security of the RDP server over the Internet. There are actually two important security concerns. First, there is the authentication and encryption issue and second and more importantly, is the risk of providing a full desktop to an intruder in the event that user credentials are compromised.
The first issue can be handled by requiring that users use FIPS compliant encryption when connecting to the Terminal Server. You can configure this on the Terminal Server using the Terminal Services Configuration Console. Second, you need to make sure that users are using TLS sessions to the Terminal Server so that the username and password pass within the TLS tunnel. Again, this can be configured in the Terminal Services console.
The second issue is more problematic. Typically, when an external intruder tries to compromise you network, he as access to very limited number of protocols, such as DNS, SMTP, POP3 or IMAP4 or HTTP. While a very sophisticated intruder may be able to carry out some limited number of exploits outside of conventional DoS when connecting to these services, the same is not true if the intruder is able to steal credentials from a user and then connect over an RDP session.
In contrast to the damage that the attacker can do when connecting over SMTP, the amount of damage that can be done over an RDP is cataclysmic. The attacker has access to a full desktop environment and all the tools that a full desktop provides. In addition, it is likely that the attacker will be able to easier download more tools that he can use to compromise your network and its data.
As you know, users have a bad habit of sharing their passwords with one another, making it unviable to provide RDP access over the Internet. However, two-factor authentication can partially solve this problem, because they are less likely to turn over their smart cards. If you do decide to provide RDP access to the Internet for your users, I highly recommend that you require two factor authentication.
Got a question for Dr. Tom? Send it to email@example.com.