DHCP Relay Agent

A DHCP Relay Agent should be configured on you RRAS server if you wish for remote access clients to obtain complete IP settings via DHCP. If you choose to have clients obtain settings from DHCP without setting up a Relay Agent, then the client will only obtain an IP address and subnet mask from the server, regardless of which options may exist. The traditional use of a DHCP Relay Agent was to act similar to a BOOTP Forwarder, a system that allows DHCP broadcasts to be directed to a DHCP server that may exist on another subnet. If DHCP Relay Agents (or equivalent) are not used, then a DHCP server must exist on the same subnet as the client, which may not be practical.

In RRAS, a DHCP Relay Agent is configured under the IP Routing section. By accessing the DHCP Relay Agent properties, you can configure to which servers DHCP requests will be forwarded by this agent.

Note also that by double-clicking on any interfaces in the DHCP Relay Agent interfaces, you can configure both the Hop-count Threshold (which controls the maximum number of relay agents that will handles a request), as well as the Boot Threshold (the number of seconds that the relay agent will wait prior to relaying requests) for the agent. The default value in both cases is 4.

Configuring VPN Services

For the purpose of authentication protocols, IP address assignment, and so forth, the VPN ports use the exact same server properties as those used by dial-in clients, so I will not repeat them here. Because of this, I will only cover settings relating specifically to the configuration of VPN ports in this section.

You probably noticed that by default there were 10 VPN ports automatically configured when RRAS was started, providing 5 PPTP and 5 L2TP ports by default. Since a VPN connection will be coming in over a network card, in theory the number of possible incoming connections is only limited by the processing capabilities of the system, and not by physical ports. However, the maximum number of ports supported is 30,000 for a given type (such a PPTP WAN Miniports for example).

Note that you cannot change the number of ports to 0, even though the system suggests this is possible. At a minimum, you must have one of each port type available. The reason I mention this is because you will need to configure how many of each type of port you wish to have available for connections, as well as which protocol they will use. If you had chosen to use PPTP for VPN connections for example, it would make sense not to allow incoming connections via L2TP. This would be controlled not by setting the number of L2TP ports to 0, but instead by configuring the L2TP WAN Miniport properties to not allow incoming connection.

So why would you choose PPTP over L2TP or vice versa? The answer depends on the level of security you require, as well as the security mechanisms that your network supports. For example, PPTP supports only user-level authentication, meaning that any connection using PPTP that has the correct username/password combination will be allowed. In contrast, L2TP requires 2 levels of authentication – first the machine is authenticated (via a machine certificate that would need to be pre-installed either via group policy or using certificate services) and then the user is authenticated using PPP. This allows a higher degree of security, since both the user and machine must be validated. The downside is the extra effort involved with using L2TP, as well as the fact that only Windows 2000 has built-in L2TP and IPSec capabilities among Microsoft operating systems.

Configuring Dial-in Services

Just as Windows NT Server 4.0 was often used for its RAS server capabilities, Windows 2000 continues the tradition, making it significantly easier in my opinion. Getting started will involve familiarizing yourself with the interface, which can be a little tricky at first look. Always start by accessing the properties of the RRAS server, which allow you to control whether the server will act as a router or as a remote access server, both of which will be chosen by default.

To make this server a dial-in or VPN server only, the second option (Remote access server) must be chosen. The other options on this property sheet will be explored shortly.

For the purpose of configuring RRAS to support remote access, the second area that you’ll need to look at is ‘Ports’.

Note that both hardware ports are listed, as well as ‘virtual’ ports, or those associated with allowing incoming VPN connections (also called WAN Miniports). In order to configure a port to allow (or disallow) an incoming connection, right click ‘Ports’ and choose Properties. After doing this, choose the appropriate device (a modem in this case, since we’re exploring dial-in connections) and choose the ‘Configure’ option.

If the device is only meant to be used for inbound or outbound connections, be sure to check or uncheck the appropriate boxes shown above. Note that you can also provide the phone number for this connection (which can subsequently be used in remote access policies) as well as the maximum number of ports (since some devices, such as WAN Miniports can support multiple ports).

Right-clicking on a particular port, such as the modem port in the ‘Ports’ list, allows me to check the status of a given port.

Note that the device is awaiting an incoming connection, and as such is in a ‘Listening’ state. If a connection has been made on this port, you could then view statistics, error information, as well as network address information for the connection. You can also use the disconnect button to manually disconnect a session if necessary.

Routing and Remote Access (RRAS)

One of the most powerful new tools included with Windows 2000 Server is the Routing and Remote Access (RRAS) tool. The capabilities included with RRAS include the ability to configure Windows 2000 as a basic router (running routing protocols such as RIP and OSPF), a demand-dial router (via a standard dial-up or ISDN interface), a traditional remote access server (using dial-in PSTN or ISDN connections), a VPN server (allowing PPTP or L2TP connections), or a combination of the above. The remote access capabilities in RRAS are the focus of this article, with routing functionality to be covered in the next article in the series. This article will also cover some of the more advanced remote access capabilities, including the ability to configure remote access policies (which allow a much more granular way of granting access).

Prior to configuring Routing and Remote Access in Windows 2000, you will need to ensure that the service is both installed and enabled. Use the RRAS administrative tool to enable Routing and Remote Access.

Choosing ‘Configure and Enable Routing and Remote Access’ will open the Routing and Remote Access Wizard, which allows you to easily configure your services for any of the services listed below, while still offering you the ability to configure the services manually (the last option). Note that the downwards-pointing red arrow designates that the service is not running.

While the wizard provides a quick and easy way to get RRAS up and running, I suggest that you also attempt the manual configuration of the services to get a better idea of what is involved in setting each up.

Advanced DNS Configuration

Certainly there are a great many ways in which DNS can be configured, including as a root server (for your own network if you wanted), a caching-only server, a forwarder, and so forth. There are also a number of more advanced capabilities that you may not understand or appreciate. While you certainly don’t need to understand every tiny detail for the exam, I will use this section to give a brief overview of some of the things you should be aware of that you might have overlooked in exploring Windows 2000 DNS. These are considered on an area-by-areas basis below.

Reverse Lookup Zones – the reverse lookup zone exists for the purpose of mapping IP addresses to host names. This is easier said than done, since FQDNs get more specific when moving from right to left, while IP addresses get more specific when moving from left to right. DNS was designed to resolve the domain, subdomain, and finally the hostname, moving from the right (like .com) to the left (like server16). However, imagine how difficult it would be to figure out how difficult it would be to find the hostname of a machine knowing only that it ends in .200! The number of possibilities makes it almost impossible. For this reason the reverse lookup zone was created, its interesting feature being that it is named using the network portion of the IP address reversed, with the special domain in-addr.arpa appended as the suffix. As such, if the network address for company.com were 131.107.0.0, the associated reverse lookup zone would be named 107.131.in-addr.arpa. This can then be resolved like a normal DNS address, since a limited number of network IDs (256 to be exact) begin with 131, and in theory at least, only one begins with 131.107 (assuming is hasn’t be ‘slashed’ by an ISP) making identification possible. This zone can then be consulted to find records for hostname associated with the sought after IP address. But why do we care? Because many applications actually use reverse lookup as a security device to ensure that a given host is coming from a permitted source. Although your DNS will properly function for the most part with reverse DNS, it is definitely best practice to create associated reverse zones for your forward lookup zones.

Character Sets – something you may not have considered when configuring your DNS server is the character set in use. This is an important consideration, especially is you are using different versions of DNS from different vendors, and wish to have them communicate with one another (for example for the purpose of zone transfers). If one supports a character set that the other does not, the zone transfer might fail, which would obviously be an issue. The reason this actually has to be looked at is because traditionally Microsoft naming has been based in NetBIOS, which allows characters (such as the underscore, for example) that are not traditionally valid within a hostname. There are 3 main character sets supported in Windows 2000 DNS. These include:

a. Strict RFC (ANSI) – allows A to Z (upper and lower case), 0-9, and the hyphen in names, according to RFC 1123

b. Non RFC (ANSI) – allows everything as above, including the ‘_’ character anywhere in a name.

c. Multibyte (UTF8) – allows characters outside of the ASCII character set, such as Unicode.

d. Any Character – allows any character set to be used, including Unicode

The character set should be defined in the Advanced tab of the properties of the DNS server under ‘name checking’.

Interoperability with BIND – Some companies will choose to use their existing DNS infrastructure to support Active Directory or their networking infrastructure in general. For the purpose of the exam, you should be aware of the capabilities supported by BIND, the Berkeley Internet Naming Daemon, which is also the most popular DNS server in use today. Without getting into tremendous detail, you should be aware of supported features in 3 key versions:

a. Version 4.9.7 supports SRV records, the single ‘required’ element to support Active Directory.

b. Version 8.1.2 support SRV records and dynamic updates.

c. Version 8.2 supports SRV records, dynamic updates, and incremental zone transfers.

Note that none of the BIND versions listed support UTF8 character encoding, nor do they support the WINS or WINS-R resource records. As such, these may cause you issues that you may need to address prior to having a Windows 2000 and BIND server interoperate.

Integrating DNS and WINS

Since many networks running NT 4.0 relied on WINS as their primary name resolution facility, Microsoft provided a non-standard method for integrating DNS with WINS. This involved configuring a DNS server with special WINS-related records that would then be used to extend name resolution beyond the records known to DNS. In a nutshell, if configured with the address of a WINS server (using the non-standard WINS record), the DNS server would attempt to query WINS for any records not found in the DNS zone database file. It would do this by reformatting the request as a NetBIOS query, and the WINS server would respond if a match was found. This provided many companies with an efficient way to create a type of dynamic DNS in NT 4, since clients whose IP addresses were not in DNS (since they used DHCP) could still be found via DNS, since WINS is updated dynamically.

This same functionality still exists in Windows 2000, even though dynamic DNS now exists. Remember that non-Windows 2000 clients still do not use dynamic DNS, and many companies have large WINS implementations that work quiet well, and as such, might wish to continue using this rather than switching to DHCP-initiated client updates. Before looking at how integration between WINS and DNS should be handled, remember that a DNS query is resolved by a DNS server that is authoritative for the zone within which a DNS domain exists. That is, a name server whose zone is responsible for the domain company.com will answer a query for server12.company.com. The reason that I mention this is because the placement of the WINS records will differ based on a company’s DNS implementation.

For example, imagine that my company has set up DNS to support Active Directory, and my implementation is such that only records for domain controllers appear in DNS. If I configure my single DNS forward lookup zone with a WINS record pointing to my WINS server, this WINS server will be queried if the associated host record is not found in DNS. While this works fine for a single forward lookup zone, it becomes more complex when my company has many domains in its DNS implementation (perhaps because of a large multi-domain AD design). In cases like these, you might want every forward lookup zone to be configured to do WINS resolution, and this might involve a great deal of administration. For this reason, Microsoft recommends creating a separate Active Directory domain strictly for the purpose of WINS resolution. At first glace this may not may sense, so let me explain. In the Advanced TCP/IP properties of a system (on the DNS tab, as shown below), you can control the order in which domains are searched for the purpose of name resolution. By default, the suffix for the domain in which the local system exists is searched, followed by parent domains. For example, imagine you typed ping server3. If the client system from which the command was issued was in the west.company.com domain, it would first try resolving server3.west.company.com (notice is automatically appends the domain name since you didn’t use an FQDN). If this fails, it will then attempt server3.company.com (appending the suffixes of the parent domain – company.com). If this also fails to resolve the name, resolution fails.

Consider what would happen if you were to create a separate DNS domain just for WINS resolution, however. You might create a special domain within your DNS structure called wins.company.com, and have this be the second domain appended in a search to resolve a hostname.

Now, if a client were to attempt to ping an unqualified hostname, like server3, it would first attempt to query server3.west.company.com followed by server3.wins.company.com. The idea is that if an answer could not be found in subdomain ‘west’, it would then attempt subdomain ‘wins’. The forward lookup zone for subdomain ‘wins’ would only need to be configured with 1 (or more) WINS records (and WINS-R records in the associated reverse lookup zone), pointing to the appropriate WINS servers where clients and servers are registered. This setup is best when you have many domains and/or subdomains, where client DNS properties are set to query their own domain first, followed by the special ‘wins’ domain second, thereby making use of the existing WINS facility for resolution.

Name Resolution Tools and Utilities

A number of hostname resolution utilities and facilities exist that you should be aware of in Windows 2000. These include nslookup, the monitoring tab of the DNS server properties, ipconfig switches, and netdiag.

Nslookup is the most common DNS hostname resolution troubleshooting utility. In effect, this tool is used as a command-line resolver, a DNS client that sends queries of different types to a DNS server and returns a response. This tool provides a quick and easy way of testing whether or not host name queries are capable of being properly resolved via DNS. For example, to test resolution of the server at 10.1.1.1, you could issue the command nslookup 10.1.1.1 192.168.1.200, and be returned the hostname associated with the IP address 192.168.1.200 if DNS is correctly configured.

The Monitoring tab found in the properties of a DNS server also provides a quick way to assess DNS resolution (although I would argue that it can be less reliable at times based on experience), via a simple or recursive query test.

A simple query sends a query from the local resolver (client) to the locally configured DNS server. The recursive query goes a step farther, with the client asking the server to use recursion to find a name server for the root (“.”) domain. This provides a method to ensure that root hints (the list of root servers) and / or forwarding are configured correctly.

Netdiag – although this tool can be used to test many network connectivity and associated issues, it can also be used specifically to troubleshoot DNS-related issues. When issued using the Netdiag /test:DNS command, Netdiag will check to see whether the computer is correctly registered in the listed DNS servers, while also verifying that the DNS cache service is running. When used with the /fix option, Netdiag will attempt to re-register the host in DNS if the entries found are not consistent.

Ipconfig – although most commonly used to view IP address configuration information, the ipconfig command has 3 switches directly related to DNS. The /displaydns switch, allows you to view the DNS entries recently resolved and cached on the client. The /flushdns switch clears the client DNS cache. Finally the /registerdns switch forces the client to attempt name and address registration with the configured DNS server(s).

Event Viewer DNS Server Log file – found on Windows 2000 DNS servers, this Event Viewer log file will provide information on errors and other important information relating to the DNS service. This should be used as a first point of contact when troubleshooting DNS-related issues. The System log should also be consulted for issues relating to client-side resolution problems.

DNS Logging – Another option for monitoring your DNS servers is to configure them to use DNS logging, which logs selected DNS event information (as shown below) to a dns.log file in the %systemroot%\system32\dns folder on the server. This may cause performance degradation on the server. It should be used only for troubleshooting purposes.

Hostname Resolution

Many people confuse the ideas of a host name and a NetBIOS name when first attempting to understand the concepts. Simply put, a host name is an alias for an IP address –a name that is easier to remember than a 32-bit number. If a system doesn’t have an IP address, it doesn’t have a host name, and talking about host name resolution is then a non-issue. The reason for some of the confusion is that traditionally, the host name and NetBIOS name on a Windows-based system are the same by default, although this needn’t be the case, since they can be different. The process of having a host name and attempting to find the associated IP address is referred to as host name resolution, and can be accomplished using two main facilities – the HOSTS file, and DNS.

The HOSTS file is a text file found in the %systemroot%\system32\drivers\etc directory on a Windows 2000-based system. This static file is used by the local system to resolve host names to an associated IP address. This is the first place from which a system will attempt to resolve a name, so it is important that it does not contain incorrect entries. Note also that the files is parsed from top to bottom, such that if multiple entries for a name exist, the first found will be used and the others ignored.

Any entries proceeded by a # symbol are considered comments. Note that HOSTS files were the original name resolution facility on the Internet prior to the creation of DNS. The size of the files eventually made this method impractical, but the simplicity of the file as a name resolution facility make them useful, even today.

DNS was invented largely due to the scalability issues associated with the creation and maintenance of a single flat text file for name resolution on the Internet. The Domain Name System is a distributed database of information maintained on DNS servers (actually more of a series of distributed localized text files called zone files). Having explored the process of DNS name resolution in previous articles, I will not repeat it here. Remember that the main purpose of DNS is to take a host name (or fully qualified domain name) and resolve it to an IP address. DNS forms the naming backbone of the Internet, via the 13 root name servers and thousands of other DNS servers that currently exist. (see the cache.dns file in the %systemroot%\system32\dns\samples directory for the root server list, or the Root Hints tab from the DNS server properties)

WINS Features and Functions

WINS in Windows 2000 still behaves very much like WINS in Windows NT. The section provides an overview of some old functionality you may have forgotten about, as well as some of the new functions that you should be aware of.

WINS Proxy – Just like in NT 4, you can configure a Windows 2000 system as a WINS proxy. A WINS proxy is a system that listens for NetBIOS broadcasts on the network and forwards those broadcasts to a WINS server for resolution. WINS proxies are used when a subnet contains systems that use NetBIOS but do not support WINS, allowing these systems to use NetBIOS naming and communicate across a TCP/IP internetwork. Like in NT 4, a WINS proxy is configured via a registry setting, so you’ll need to add the setting EnableProxy with a value of 1 to the path HKLM\System\CurrentControlSet\Services\NetBT\Parameters

Burst Handling – At certain times during the day, WINS servers may take on a heavy load of registrations, such as when people boot up their PCs when they get into the office at around 9am, or after a network failure. WINS in Windows 2000 has the ability to handle these high-impact times using burst handling (this also existed in NT versions with SP 3 and above). Turned on by default, the WINS server handles requests normally until the burst-queue reaches 500 requests (the medium setting). After it reaches 500 queued registration requests (which can be changed via the WINS console as shown below), the server begins responding positively to clients immediately with a TTL of 5 minutes for the first 100 clients above 500, increasing the TTL by an additional 5 minutes for every 100 clients thereafter. This basically forces the clients to fully reregister with the WINS server once the load had decreased on the server.

Manual Tombstoning – The manual tombstoning feature in Windows 2000 exists to help ensure the consistency of WINS databases in environments where WINS replication is used. In effect, it allows you to manually tombstone records that you wish to have invalidated (not deleted) in WINS, such that the information will be replicated to all other WINS servers. This feature exists because a deleted record (one removed from the WINS database entirely) could be re-replicated to a server, since other servers would think that the record was still valid. The tombstoned record would then replicate and cause that record to be tombstoned on other WINS servers, and so on. The record would eventually be deleted from the WINS database once the tombstone lifetime expires.

Verify Database Consistency – Be careful with this one. WINS in Windows 2000 has a feature available called ‘Verify Database Consistency’ which allows you to verify that the information found in a given WINS database is correct and up-to-date. In effect, the feature forces the local WINS server to check all records replicated from other WINS servers and compare them with the current local versions found on the WINS server that owns the record. The local WINS server will then update the information as necessary. The problem with this command is that it is very resource intensive in large environments – it is suggested that it only be down in periods of low activity, such as after working hours.

Database Backup – In order to have the WINS database backed up automatically, you need to specify a backup path on the server’s General property tab. Once provided, the database will be backed up to this location every 3 hours. You can also specify that the database be backed up automatically when the WINS service stops (as it would on shutdown, for example). The General tab is shown below.

Persistent Connections – Another new feature in Windows 2000, WINS replication partners can now maintain (and do by default) persistent connections with one another. That means that less time and resources are used on the WINS server, since the necessary connection is always established between partners. This can be turned off via the Replication Partners properties (see the screen shot in the WINS replication section)

WINS Users Group – This group is created after WINS is installed, and membership allows a user read-only access to information stored in the WINS console, a useful feature for first-line network support.

Configuring WINS Clients

WINS client settings can be configured manually, or dynamically using the proper DHCP options (044 to assign server addresses, 046 to set the node type). WINS settings are set up by access the WINS tab in the advanced TCP/IP properties.

Note that unlike in NT 4 where you could only enter addresses for a primary and secondary server, in Windows 2000 you can configure the client with a list of up to 12 WINS servers to use in order of preference. Note that the client can be enabled or disabled from using an LMHOSTS file for lookup, and can also be enabled/disabled for NetBIOS over TCP/IP. As a best practice, you should ensure that all client applications run properly before disabling NetBIOS over TCP/IP.