WindowsNetworking.com Monthly Newsletter of September 2010
Sponsored by: GFI <http://www.gfi.com/landing/webmon.asp?adv=191&loc=74>
-----------------------------------------
Welcome to the WindowsNetworking.com newsletter by Debra Littlejohn Shinder <http://www.windowsnetworking.com/Deb_Shinder/>, 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: dshinder@windowsnetworking.com
1. WINS Replication Networks
---------------------------------------------------------
Windows 2000 was the first Microsoft operating system that is almost completely free of the chains of NetBIOS dependence for core network operating system functions. This is 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'll 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 hasn't 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's likely that you'll 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 doesn't 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 three primary advantages over other modes of NetBIOS name resolution:
1. WINS Significantly reduces NetBIOS related broadcast traffic
2. WINS greatly simplifies name resolution in routed networks
3. WINS allows for automatic registration of NetBIOS names and IP addresses
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's 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:
1. WINS Servers on the far side of a WAN link may become unreachable
2. WINS Servers on the far side of a WAN link may respond slowly and lead to frequent time-outs on NetBIOS name queries
3. A single WINS Server does not provide for fault tolerance.
4. A single WINS Server may become overwhelmed by Name Registration and Name Query traffic.
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're going to have more problems than 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 have taken place, the WINS Server that is the push partner will send a push notification to its partner that its 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's 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's 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 (well 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've 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:
1. Minimize the network traffic related to WINS database replication
2. Insure that the distributed database is consistent throughout the organization
3. Maintain a reasonable convergence time
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.
I hope you enjoyed this article on WINS replication networks. Please feel free to write to me if you have any questions on this subject. My email address is dshinder@windowsnetworking.com See you next month!
By Debra Littlejohn Shinder, MVP
dshinder@windowsnetworking.com
=======================
Quote of the Month - Giving money and power to government is like giving whiskey and car keys to teenage boys. - P.J. O'Rourke
=======================
2. ISA Server 2006 Migration Guide - Order Today!
---------------------------------------------------------
Dr. Tom Shinder's best selling books on ISA Server 2000 and 2004 were the "ISA
Firewall Bibles" for thousands of ISA Firewall administrators. Dr. Tom and his
illustrious team of ISA Firewall experts now present to you , ISA Server 2006
Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. This book
leverages the over two years of experience Tom and his team of ISA Firewall
experts have had with ISA 2006, from beta to RTM and all the versions and builds
in between. They've logged literally 1000's of flight hours with ISA 2006 and
they have shared the Good, the Great, the Bad and the Ugly of ISA 2006 with
their no holds barred coverage of Microsoft's state of the art stateful packet
and application layer inspection firewall.
Order your copy of ISA Server 2006 Migration Guide
<http://www.amazon.com/exec/obidos/ASIN/1597491993/isaserver1-20/>. You'll be
glad you did.
3. WindowsNetworking.com Articles of Interest
---------------------------------------------------------
* What's New and Cool in Windows Server 2008 R2 Networking <http://www.windowsnetworking.com/articles_tutorials/Whats-New-Cool-Windows-Server-2008-R2-Networking.html>
* Storage Configurations <http://www.windowsnetworking.com/articles_tutorials/Storage-Configurations.html>
* Windows User State Virtualization - Part 3: Virtualizing Application State <http://www.windowsnetworking.com/articles_tutorials/Windows-User-State-Virtualization-Part3.html>
* Windows 7 Compatibility Testing (Part 8) <http://www.windowsnetworking.com/articles_tutorials/Windows-7-Compatibility-Testing-Part8.html>
* Microsoft System Center Service Manager - Part 2: Installation <http://www.windowsnetworking.com/articles_tutorials/Microsoft-System-Center-Service-Manager-Part2.html>
* Windows User State Virtualization - Part 2: Scenarios <http://www.windowsnetworking.com/articles_tutorials/Windows-User-State-Virtualization-Part2.html>
* Cisco ASA 5500 Series SSL/IPsec VPN Edition - Voted WindowsNetworking.com Readers' Choice Award Winner - Firewalls & VPN Hardware <http://www.windowsnetworking.com/news/WindowsNetworking-Readers-Choice-Award-
Firewalls-VPN-Hardware-Cisco-ASA-5500-Series-SSL-IPsec-Jul10.html>
* Windows 7 Compatibility Testing (Part 7) <http://www.windowsnetworking.com/articles_tutorials/Windows-7-Compatibility-Testing-Part7.html>
4. Administrator KB Tip of the Month
---------------------------------------------------------
Disable Built-in Zip Support for Windows Vista
As you probably know, Microsoft added support for zip or compressed folders to Windows with the release of XP. However, if you rather use a third-party tool, you can disable the support in Windows Vista by deleting the following registry keys:
Hive: HKEY_CLASSES_ROOT
Key: CLSID
Name: {E88DCCE0-B7B3-11d1-A9F0-00AA0060FA31}
Hive: HKEY_CLASSES_ROOT
Key: CLSID
Name: {0CD7A5C0-9F37-11CE-AE65-08002B2E1262}
Don’t forget to restart Windows for the change to take effect.
For more administrator tips, go to WindowsNetworking.com/WindowsTips
<http://www.windowsnetworking.com/kbase/WindowsTips/>
5. Windows Networking Tip of the Month
---------------------------------------------------------
Most of us know that Internet Explorer includes the InPrivate Browsing feature. However, by default, you have to activate it after you start the browser. In some situations, such as when you are using a corporate laptop or another high security machine, you might want to enable InPrivate browsing by default. You can do this by editing the shortcut you use to launch Internet explorer. To do this, you can edit or create a shortcut and add the –private to end of the location.
For example:
"C:\Program Files\Internet Explorer\iexplore.exe" -private
Start Internet Explorer with that link and all your browsing will be private. Enjoy!
6. WindowsNetworking Links of the Month
---------------------------------------------------------
* Windows Internet Name Service (WINS) Overview
<http://technet.microsoft.com/en-us/library/cc725802.aspx>
* Install Windows Internet Name Service (WINS)
<http://technet.microsoft.com/en-us/library/dd894432(WS.10).aspx>
* Can't Shake WINS? Consider the GlobalNames zone in Windows Server 2008 DNS
<http://blogs.techrepublic.com.com/networking/?p=608>
* Windows Server 2008 R2 Core Network Guide
<http://technet.microsoft.com/en-us/library/dd894461(WS.10).aspx>
* Installing and Creating the Lab Domain Controller
<http://www.windowsnetworking.com/articles_tutorials/Running-Windows-Server-2008-R2-Installing-Creating-Lab-Domain-Controller-Part2.html>
* Dual booting Windows Server 2008 R2 with Windows 7 using VHD booting
<http://www.microsoftnow.com/2009/11/dual-booting-windows-server-2008-r2.html>
7. Ask Sgt. Deb
---------------------------------------------------------
* QUESTION:
Hey Deb,
My name is Howard G. I came across an article you wrote about IPsec and it is linked closely to what we are trying to achieve. What we want to do is to create a secure connection between servers in our DMZ and through the firewall into our AD domain. We are thinking of using VPN with IPsec but I haven't been able to come across a good article that will tell us what we need to do to set this up, or if there is perhaps a better way to do this. I was hoping you might be able to point me in to correct direction.
Thank you - Howard
* ANSWER:
Hi Howard!
You are definitely on the right track. If I understand your requirements correctly, what you would like to do is to put a non-domain member in the DMZ and allow that non-domain member server in the DMZ to communicate securely to hosts on the intranet.
While you could use an L2TP/IPsec VPN to do this, a better way is to use IPsec transport mode to accomplish this task. When you use an IPsec transport mode connection, you can configure your server in the DMZ to use an IPsec authenticated and encrypted sessions with one or more servers on your intranet. In fact, you have the option to just authenticate the connection and not encrypt it (you might want to do this if you have Network IDS devices that need to see the traffic) or even just authenticate only the first packet and leave the rest in the clear (to support network IDS devices that don't understand ESP-(NULL).
Since the DMZ server is not a domain member, you can not use Kerberos authentication. In this case, you can use either computer certificate authentication or a pre-shared key. I recommend that you use a computer certificate for authentication, as a pre-shared key is less secure and not very scalable. After you install the CA certificate on the DMZ server that tells the DMZ server that it trusts all certificates signed by the CA that signed the certificates of the intranet servers, you can create a connection security rule on the DMZ server using the IP address of the DMZ server as endpoint 1 and the IP addresses of the intranet servers as endpoint 2. Make sure you mirror the rules on the intranet servers that you want to participate in this IPsec topology.
When you configure your back-end firewall, make sure you allow UDP port 500 and IP Protocol 50 from the DMZ server to the servers on the intranet that will be participating in your IPsec topology. UDP port 500 allows IKE traffic through the firewall, and IP Protocol 50 allows ESP traffic. In most cases you won't be using AH (Authentication Header), but if you choose to use AH, then you will need to allow IP Protocol 51. Since the DMZ server is not a domain member, you do not need to allow ports that support Kerberos.
For more information on Windows Server 2008 R2 (and other OS versions) and IPsec, check out this TechNet page <http://technet.microsoft.com/en-us/network/bb531150.aspx>.
TechGenix Sites
---------------------------------------------------------
MSExchange.org <http://www.msexchange.org/>
WindowSecurity.com <http://www.windowsecurity.com/>
ISAserver.org <http://www.isaserver.org/>
VirtualizationAdmin.com <http://www.virtualizationadmin.com/>
--
Visit the Subscription Management <http://www.techgenix.com/newsletter/>
section to unsubscribe.
WindowsNetworking.com is in no way affiliated with Microsoft Corp.
http://www.techgenix.com/advert/index.htm for sponsorship
information or contact us at advertising@windowsnetworking.com
Copyright c WindowsNetworking.com 2010. All rights reserved.
No comments:
Post a Comment