Rogue DHCP Server detection

Overview

Rogue DHCP servers are those DHCP servers that are misconfigured or unauthorized unknowingly or those that are configured with a malicious intent for network attacks. Either be the case the impact on clients that are serviced by the rogue DHCP servers are critical. That is the clients would experience network access problems due to rogue DHCP server leasing incorrect IP addresses & incorrect options to the client. Security threats are caused when malicious user with rogue DHCP server can spread bad network parameters and thereby sniff the traffic sent by the clients. There are also certain Trojans like DNS-changing that uses a compromised machine in the network to pollute the network by installing rogue DHCP servers on the machine.

Rogue detection tool is a GUI tool that checks if there are any rogue DHCP servers in the local subnet.

Following are the features with this tool:

1.     The tool can be run one time or can be scheduled to run at specified interval.

2.     Can be run on a specified interface by selecting one of the discovered interfaces.

3.     Retrieves all the authorized DHCP servers in the forest and displays them.

4.     Ability to validate (not Authorize in AD) a DHCP server which is not rogue and persist this information

5.     Minimize the tool, which makes it invisible. A tray icon will be present which would display the status.

Thanks,

Subhash Badri

DHCP Server Team

DHCP Server Performance in Windows Server 2008 R2

 

With the proliferation of IP devices on the enterprise network, network services like DHCP are expected to deliver on ever increasing load while maintaining low response times. DHCP Server in Windows Server 2008 R2 has been enhanced and tested to deliver far higher levels of performance and scalability than in previous releases of Windows. The cornerstone of the performance improvement in the DHCP server in the latest release has been aggressive caching of the lease records in database.

A bit of context to let you see how the cookie crumbles: DHCP server uses Jet database engine also referred as Extensible Storage Engine (ESE). ESE provides a facility where the whole or part of the database can be cached in memory to improve lookup performance and to reduce dependence on expensive file IO which can drain performance. In Windows Server 2008 R2, DHCP Server sets the Jet db cache to “autotune” mode which allows Jet db to aggressively cache the DHCP database in main memory. The cache is built up as and when the database records (in the case of DHCP, lease records) are accessed (renew existing lease) or created (assign a new lease). So, you are likely to see a growth in the DHCP server process size over a period of time as the existing records in the db are accessed or new records are created.

A new DHCP registry parameter of type DWORD can be added to exercise greater control over the size of the database cache: the value JetDatabaseMaxCacheSize can be added under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DHCPServer\Parameters. The value entered is taken as the maximum size (in MB) of the cache that DHCP server can use. If the value is set to greater than the physical memory in the system, the cache is automatically capped at the size of physical memory in the system. If set to a value lesser than 2 MB, the cache is set to 2 MB – in other words, cache cannot be set to a value lower than 2 MB (floor value). It is recommended not to set any value here and let the DHCP server allocate memory for cache as needed unless there are other services/roles running on the same computer. If there are other services/roles running on the same computer as the DHCP Server, you may want to set a cap on the DHCP server cache so that other services/roles are not starved of memory.

Now onto some test results: we fired up our scalability and performance tests to see how far this change would take us in terms of performance and scalability.  The objective of the scalability test was to ascertain the throughput that the DHCP server was able to deliver on a) New leases being granted per second b) Renewal of existing leases per second. The test runs to determine new leases per second and renewal of existing leases per second were conducted separately (i.e. there was no renew traffic to the server in the test for new leases per second and vice-versa).

The hardware configuration used for conducting the tests was as follows:

·         Model: HP  ProLiant DL385 G1 (HP server for small-medium business)

·         Processor: 2 Dual Core AMD Opteron 64 bit 2.2 GHz

·         RAM:  6 GB

·         Storage: 136 GB SCSI hard disk.

Here the test results:

Active IP address leases in the DHCP db	New IP leases granted per second	Renew of leases per second	Size of database on disk (in MB)	DHCP Server process size (in MB)
2,000,000	1500	7400	875	660

 

As can be seen from the results above, the DHCP server on afore mentioned hardware was able to assign, on an average, 1500 IPv4 leases per second. This was on a database which had 2 million active IPv4 lease records. On the same test setup, the DHCP server was able to renew leases at the rate of 7400 renews per second on an average. These results are indicative of the ability of the Windows DHCP server to deliver higher performance in terms of new IP address leases per second and IP address renews per second with a very high number of active IP address leases already in the database. The DHCP server database size on disk for 2 million leases was around 875 MB and the process size was around 660 MB.

 In a pure performance test (low number of active leases in the database), the DHCP Server clocked 3200 IPv4 leases per second showing a 4 fold increase in performance over Windows Server 2008.

Test Scenario	Windows Server 2008 R2	Windows Server 2008
Address Acquisition	3421 leases per second	853 leases per second
Address Acquisition and Address renew operations (in ratio of 60:40)	4400 transactions* per second	676 transactions* per second

 * A transaction is either a new address (lease) acquisition or a renew of an exisiting address.

A similar test for IPv6 had the server clock close to 2800 leases per second – a staggering 50X improvement over Windows Server 2008.

When it comes to scalability, people often get too focused on the scalability figures for number of active leases which the server can handle. It is equally important from a real world deployment point of view to ensure that the management and maintenance operations of the server keep up at the high scale.  In line with that thought, we did a series of tests to test the scalability of MMC, export/import and backup/restore operations. With over 1 million IPv4 leases spread over 6000 IPv4 scopes, using DHCP MMC, it took about 25 seconds to expand the IPv4 node while any scope expansion was complete in 1-2 seconds. Time taken for backup of the database was about 13 seconds while export took 2 mins 15 seconds. Dump of the database took 45 seconds to complete.

Operation (on a database with 1 million IPv4 leases)	Time Taken (in seconds)
Expand IPv4 node	25
Expand a scope	2
Database Backup	13
Export	135
Dump	45

 

A similar test for over 1 million IPv6 leases spread over 6000 IPv6 scopes, yielded 2 minutes for IPv6 node expansion and 2 minutes for any scope expansion in MMC. Backup of the database took about 20 seconds while export of the database took about 1.5 min. Dump of the database took 48 seconds.

Operation (on a database with 1 million IPv6 leases)	Time Taken (in seconds)
Expand IPv6 node	120
Expand a scope	120
Database Backup	20
Export	90
Dump	48

 

As you can see from these results, the management and maintenance operations of the server maintain their responsiveness with high number of active leases in the database. These results hold good for all the Windows Server 2008 R2 SKUs.

Though in a lab environment, the above results stand testimony to the high scale and performance that Windows DHCP server can deliver in enterprise as well as in carrier grade deployments.

We did like to hear from you if this test data was useful and what other performance or scalability metrics you would like to know about.

Prasad

 

Option based IP Address assignment Callout Dll

Overview

DHCP administrators would like to manage address assignment in the network, by assigning IP address to DHCP clients based on vendor/user class identifier from distinct address ranges in the subnet. This functionality can be added to the Microsoft DHCP Server, by installing DHCP Server Option Based IP Address Assignment Callout package.

This callout dll allows the administrators to define rules for assigning IP addresses from specific IP address ranges based on the vendor/ user classes of the DHCP clients in the network. The IP address to these DHCP clients will be leased/ renewed based on the rules configured by the administrator. Alternatively, the administrator could also implement a light weight network access control by denying IP addresses based on vendor/ user class of the device.

It can be configured for address assignment based on any one of the below:

• Vendor class identifier (option 60)
• User class identifier (option 77)　

This will provide administrator the following advantages:

• Network access control, denial of IP based on vendor/ user class
• Better manageability, as different vendors are assigned IP addresses from different ranges
• Ability to configure options with different values for different DHCP clients, in the same subnet, based on the vendor/ user class.

This callout dll is supported on Windows Server 2008 (Standard or higher, 32 or 64 bit) and above, running DHCP Server (only English builds).

The callout dll can be configured using an MMC snapin. For usage information refer to the setup document present in the zip file attached to the blog.

Thanks,

DHCP Server Team

Windows 7 RC is available for TechNet and MSDN subscribers to download

We are pleased to announce that the Windows 7 Release Candidate (RC) is available for immediate download to our TechNet and MSDN subscribers. If you’re not a TechNet Plus subscriber, please click here to learn about the benefits of becoming one.

Windows 7 RC will be made available to the general public on May 5, 2009. You will then be able to download Windows 7 RC here, through the Springboard Series on TechNet. Windows 7 Ultimate is the Release Candidate edition; it will be available in 32-bit and 64-bit versions in English, French, Japanese, German, and Spanish.

Windows 7 RC offers many improvements over the beta release, including:

• DirectAccess User Experience — Corporate Connectivity Notification has been removed to simplify the user experience; only Internet Access is displayed.
• User Account Control (UAC) — In the beta release, a user could change the notification level in the UAC control panel without receiving a prompt for administrative credentials. The UAC control panel now runs in a high integrity process; changing the level of the UAC will prompt for confirmation. When a user is logged on with a standard user account, that user must provide administrative credentials to change the default UAC notification level.
• AppLocker — The AppLocker UI includes a new Group Policy administrative template, which can be configured by an administrator to display a customized URL when AppLocker blocks an application from starting. The message can be used to reduce help desk calls by directing users to a helpdesk intranet site.
• System Partition Size — The Windows 7 partition drive size (required for Bit Locker and Windows Recovery Environment) has been reduced from 200MB to 100MB.
• Network Troubleshooting — Support for diagnostics is greatly enhanced, including a new Windows Troubleshooting Pack for DirectAccess within Control Panel. If a resource is not reachable (for example, a Web site fails to load), use 'Diagnose Connection' in Internet Explorer or 'Troubleshoot problems' diagnostic entry points to help determine the cause of the issue.

To learn more about Windows 7 from an IT professional perspective, check out our screencasts as well as our resources on Deployment, Application Compatibility, Security, Imaging, and more—all of which are available through the Springboard Series on TechNet.

Test drive Windows 7 RC today to see for yourself—and to show your colleagues, users, and customers—how Windows 7 delivers improved management, security, reliability, productivity, and performance.

Some things to be aware of with the Windows 7 Release Candidate:

• Please plan ahead for Windows 7 Beta and Windows 7 RC expiration dates. To avoid interruption, you’ll need to rebuild your test machine using a genuine version of Windows 7 before the software expires. Windows will remind you when the expiration process is beginning; two weeks after this notification your PC will begin shutting down every two hours.
  • Windows 7 Beta expires on August 1, 2009, and bi-hourly shutdowns will begin July 1, 2009.
  • Windows 7 RC will expire June 1, 2010, and the bi-hourly shutdowns will begin on March 1, 2010.
  In both cases, you’ll need to rebuild your test PC to replace the operating system and reinstall all your programs and data.
• Since Windows 7 RC is not the final release, your PC will gather and send information to Microsoft engineers to help them check the fixes and changes made based on testing of Windows 7 Beta.
• Windows 7 RC requires that you do a clean install. Before installing Windows 7 RC, please read the Release Notes and Things to Know for important information.*
• Keep your PC updated. Be sure turn on automatic updates in Windows Update in case we publish updates for Windows 7 RC.
• Microsoft doesn’t offer technical support for prerelease software, including Windows 7 RC. If you have problems or questions, we encourage you to visit our online forums, where you can get answers from our Windows Community and Support Professionals.

*These documents will be updated on May 5, 2009.

DHCPv6 Information-Refresh Time Option

DHCPv6 Stateless Clients obtain configuration data from DHCP Server, by sending Information-request messages. The configuration data typically has no associated lifetime, hence there is no information telling a host when to refresh its configuration information. DHCPv6 Information-Refresh time option (Option 32), specified in RFC-4242 allows stateless clients to refresh configuration data periodically. The information refresh time specifies an upper bound for how long a client should wait, before refreshing the configuration information received from DHCP Server. This option has particular reference in very dynamic environments like the periodic change of address of infrastructure servers like DNS.

Windows Server 2008 R2 DHCP Server Behaviour:

Microsoft DHCP Server allows the administrator to configure Information Refresh time option at server or scope level from MMC or command-line using netsh. The minimum value of Refresh time that can be configured for option 32 is 600 seconds (IRT_MINIMUM). A value of 0xffffffff for Refresh time is considered infinite time and indicates that the client should never refresh its options.

The DHCP Server includes Information-Refresh time option in Reply message, if this option is requested in ORO of Information-Request message received from client.

Windows7 DHCP Client Behaviour:

DHCPv6 client in stateless mode includes option 32 in ORO of information request messages sent to Server. DHCP Server responds back with Reply that includes configuration data and Information refresh time (if option 32 is configured on Server). DHCPv6 client sends Information Request message to update configuration data, whenever Information-Refresh time expires.

In case, if reply from Server does not include option 32, then client uses 86400 seconds (IRT_DEFAULT) as Information-Refresh time value. In case if client receives 0xffffffff as Information-Refresh time value, then client would not refresh configuration data at all, unless there is some trigger like movement to a new network etc. In case Information refresh time expires and the server does not respond to Information-request messages, then client continues to use configuration data and refresh time that is previously received from Server.

DHCPv6 User Class Option

RFC3315 specifies User Class Option for IPv6 hosts. DHCP administrators may define specific user class identifiers to convey information about a client's software configuration or about its user's preferences. User classes are created to support the implementation of various scenarios like:

1. To identify various clients in specific site and location. For example the computers and printers on the same floor can be configured with the same user class.
2. Assign specific options based on the client’s user class. Some administrators also use User class to allow internet access to a specified user groups.

DHCPv6 User class option is implemented in windows7 for DHCPv6 client, which enables client to configure and send the User class name to the DHCP server.

DHCP Server Behaviour:

Microsoft Windows 2008 DHCP Server allows the administrator to configure multiple user classes and options specific to User classes, through MMC or command-line using netsh.

DHCPv6 Server responds with all User classes configured, when option 15 is included in ORO in message sent by the client. In case if DHCPv6 client includes option 15 in Request / Renew/ Rebind / Information-Request message, then Server responds with options configured for specific User class included in option-15 by the client. If User class in option 15 sent by DHCPv6 client, is not configured on Server, then Server ignores User class option and responds with options that are not specific to User classes.

DHCP Client Behaviour:

DHCPv6 client retrieves all the class IDs configured on DHCP server, when following command is executed in elevated prompt: Ipconfig /showclassid6 adapter_name.

Internally DHCPv6 client sends Information-Request message to server with option 15 included in ORO and Server responds with all User classes configured on DHCP Server.

DHCPv6 client configures User class and renews configuration data specific to User class, when following command is executed in elevated prompt:

 Ipconfig /setclassid6 Userclass_name adapter_name, where Userclass_name is name of the User class to be configured on client.

Internally DHCPv6 client sends Information-Request message to server with option 15 included in ORO and Server responds with all User classes configured on DHCP Server. DHCPv6 client obtains options configured specific to User Class by sending Renew / Information-Request (depending on whether client is in Stateful or Stateless mode) with User Class option included.  If User class name that is being set is configured on Server, then User Class option in Client message contains User class Binary data received from Server’s Reply, else User class name itself is included in User Class option. Also, DHCPv6 Client includes the same user class option in all subsequent messages transmitted.

The User class configured on client can be cleared by executing following command in elevated prompt:

 Ipconfig /setclassid6 adapter_name

The above command does not expect User class name to be specified.

DHCP Server Events Tool

This tool can be used by DHCP Administrators to view all the events generated by DHCP Server directly in MMC. This tool can also be very handy in managing the MAC Based Filtering where you can see the list of people entering your network and you will be able to remotely add them to Allow/Deny list without affecting the Service.

You can also see the scope change/Activity Logs and System Events in this MMC.

This tool is a MMC Snap-In and can be used to view the events from a Remote Server similar to the Remote Management Tools of DHCP Server. Multiple DHCP Servers can also be managed from a same console.

MACFilters Logs:

Windows 2008-R2 DHCP Server creates event logs for all the users which are denied IP Address. This tool will extract this information from Event Logs and present them in a readable fashion removing duplicate entries in the Event Log. This feature will be really helpful in deploying the MACFIltering feature as Administrators can monitor what’s going on the network and can control the MACFilte configuration directly from this tool.

Filter Profile: Filter Profile column represents the current status of the machine. A machine can have following filter profiles.

§  Allow: Machine is in Allow list. Generally the machine will have this profile if machine is added recently or the logs are not removed after adding it to the Allow List.

§  Deny: Machine is in the Deny List

§  None:  Machine is neither in Deny nor in Allow List

§  Deny (Wildcard): Machine is denied IP Address by a wild card entry in Deny List. Machines with this profile can’t be added to allow list.

§  Server Not Available: DHCP Server is not installed or dhcp service is not running on the server.

Actions Supported

§  Add To Allow List: Adds the user’s MAC address to Allow List.

§  Add To Deny List: Adds the user’s MAC address to Deny List.

Activity Logs/Scope Change Logs:

This node will list out all the configuration changes done on the DHCP Server. Windows 2008-R2 DHCP Server creates event logs for all the configuration changes done on DHCP Server. This tool will extract that information and list it in a readable fashion.

Scope: This column represents the name of the scope on which the configuration change has happened. If the configuration change has happened on at the server level the scope name will be “Server”.

Administrator: This column will represent the name of the administrator who has done the change.

System Logs

This node will list out all the System Events generated by DHCP server. This will extract all the DHCP Server related events from the System Node and present them in a readable fashion.

--

Common Actions

§  Copy:  Copy the selected rows to clipboard.

§  Filter: Filter out the events based on the text input.

§  Clear Filter: Will clear the filters.

Supported OS

§  Window7/Windows Server 2008 R2.

 

Installation Steps

1.       Install .NET 3.5 on your PC. For Windows7/Windows Server 2008-R2 .NET 3.5 is an optional component. This Snap-In can only work with .NET 3.5.

2.       UnZip the tool and copy the contents to %ProgramFiles%\DHCPServerExtras

3.       Open a command shell with Administrator privileges

4.       CD to %ProgramFiles%\DHCPServerExtras

5.       Run setup.cmd

6.       Verify the message on command shell that MMC Snap-In is successfully installed.

7.       Open mmc.exe

8.       Add “DHCP Server Extras” from File>Add/Remove Snap-In

9.       In MMC Add the DHCP Server you want to manage. If you are running this tool on DHCP Server, the local machine will be added automatically.

10.   For remote management make sure you are the member of Administrators or Event Log Readers group on the target server. Also make sure that Firewall Rule "Remote Event Log Management(RPC)" is enabled. 

If you are a DHCP Administrator you can also add “DHCP” Snap-In to the same console which can be used to manage DHCP Server. Save the console to a local folder or desktop.

 

Trouble Shooting

§  Make sure .NET 3.5 is installed.

§  If “DHCP Server Extras” does not show up in MMC please look into log file > %ProgramFiles%\DHCPServerExtras\InstallUtil.InstallLog.

§  On expanding the node if you are getting error Message please verify that server name provided is correct. Please verify that you have proper permissions on the DHCP Server to view event logs remotely. If you are remotely managing the server you should be  a member of Administrators or Event Log Readers.

 

Thanks

Nimish Aggarwal

 

DHCPv6 - Understanding of address configuration in automatic mode and installation of DHCPv6 Server

Understanding of address configuration in automatic mode

 

 

Windows Server 2008 and Windows Vista include a DHCPv6-capable DHCP client that will perform stateful address autoconfiguration with a DHCPv6 server. Windows Server 2008 includes a DHCPv6-capable DHCP server.

 

A host (DHCP Client) can configure itself with an IPv6 address to be used on the network. Address

configuration can be performed in a stateful or a stateless mode. A host can use both stateless and stateful address configuration completely independent of each other. The router advertisement messages with the appropriate flags set would indicate the precise method to be used. However the host (DHCP Client) can also be configured by manual means. The latter is seldom an occurrence in a well managed network.

 

Stateless Address Configuration

 

The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. The stateless approach is used when a site is not particularly concerned with the exact addresses hosts use, so long as they are unique and properly routable. 

Stateless Address Autoconfiguration is used to configure both link-local addresses and additional non-link-local addresses by exchanging Router Solicitation and Router Advertisement messages with neighboring routers.

 

Following are the two approaches with which IPv6 node can configure its address in a stateless fashion:

·         Using automatic address configuration with prefix discovery: This is based on RFC2462. If the ‘autonomous’ flag of a Prefix Information Option contained in a router advertisement is set, the IPv6 host may automatically generate its global IPv6 address by appending its 64-bit interface identifier to the prefix contained in the router advertisement.

·         Stateless DHCPv6: This is not mentioned as an option given in router advertisements [RFC2461].

 

Stateful Address Configuration

 

In the stateful address auto-configuration model, hosts obtain interface addresses and/or configuration information and parameters from a server. The stateful approach is used when a site requires tighter control over exact address assignments.

 

Stateful Address Autoconfiguration is used to configure non-link-local addresses through the use of a configuration protocol such as DHCP.

 

As far as the IPv6 host is concerned, using stateful DHCPv6 is little different to using stateless

DHCPv6 as the observed request/response times should be the same in most cases. However, it is possible that the extra overhead of reading and writing state to memory inside the DHCPv6 server may lead to a small increase in latency when compared to its stateless equivalent. This may be important for the configuration time of mobile nodes, which must perform address configuration when moving into a new network.

 

Delegating a prefix to an entire site is commonly a stateful operation, as the service provider routing scheme must always know where a site topologically resides, a packet targeted to a site must be routed back to the site. DHCPv6 server typically stores the DHCPv6 delegated prefix.

 

IPv6 host behaviour

 

An IPv6 host performs stateless address autoconfiguration automatically and uses a configuration protocol such as DHCPv6 based on the following flags in the Router Advertisement message sent by a neighboring router:

 

Managed Address Configuration Flag, which is also known as the M flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain stateful addresses.

 

Other Stateful Configuration Flag , which is also known as the O flag. When set to 1, this flag instructs the host to use a configuration protocol to obtain other configuration settings.

Combining the values of the M and O flags can yield the following:

 

Both M and O Flags are Set to 0. This combination corresponds to a network without a DHCPv6 infrastructure. Hosts use router advertisements for non-link-local addresses and other methods (such as manual configuration) to configure other settings.

 

Both M and O Flags are Set to 1. DHCPv6 is used for both addresses and other configuration settings. This combination is known as DHCPv6 stateful, in which DHCPv6 is assigning stateful addresses to IPv6 hosts.

 

The M Flag is Set to 0 and the O Flag is Set to 1. DHCPv6 is not used to assign addresses, only to assign other configuration settings. Neighboring routers are configured to advertise non-link-local address prefixes from which IPv6 hosts derive stateless addresses. This combination is known as

DHCPv6 stateless: DHCPv6 is not assigning stateful addresses to IPv6 hosts, but stateless configuration settings.

 

The M Flag is Set to 1 and the O Flag is Set to 0. In this combination, DHCPv6 is used for address configuration but not for other settings. Because IPv6 hosts typically need to be configured with other settings, such as the IPv6 addresses of Domain Name System (DNS) servers, this is an unlikely combination.

 

Like DHCP for IPv4, the components of a DHCPv6 infrastructure consist of DHCPv6 clients that request configuration, DHCPv6 servers that provide configuration, and DHCPv6 relay agents that convey messages between clients and servers when clients are on subnets that do not have a DHCPv6 server.

 

 Installation of DHCP Server

 

In the installation of DHCP Server using the role installation in the Server Manager, following is specific details with regard to IPv6 configuration during the role installation:

               

Behavior - 1

In case, “Enable DHCPv6 stateless mode for this server” option was selected during role installation

 

It would have asked for Parent Domain and IPv6 DNS Server (primary – mandatory and secondary – optional) information.

 

Therefore, in the post installation phase following Server Options under IPv6 node in the DHCP MMC will be with the configured values:

-          00023 DNS Recursive Name Server IPv6 Address List

-          00024 Domain Search List

 

Behavior - 2

In case, “Disable DHCPv6 stateless mode for this server” option was selected during role installation

 

It would NOT have asked for Parent Domain and IPv6 DNS Server (primary – mandatory and secondary – optional) information at all as that page in wizard will be hidden.

 

Therefore, in the post installation phase if you do not see Server Options under IPv6 node in the DHCP MMC.

 

In this case, this means the DHCPv6 Stateless mode is NOT configured on the DHCP Server.

However, in this stage if Admin wants to configure DHCP Server as stateless mode, he needs to configure the above mentioned Server Options explicitly.

 

Following are the options that can be configured at the IPv6 Scope Level and/or the IPv6 Server Level

  

Server Options	Description
00021 SIP Server Domain Name List	This option specifies a list of the domain names of the SIP outbound proxy servers for the client to use.
00022 SIP Servers IPv6 Address List	This option specifies a list of IPv6 addresses indicating SIP outbound proxy servers available to the client.  Servers MUST be listed in order of preference.
00023 DNS Recursive Name Server IPv6 Address	The DNS Recursive Name Server option carries a list of IPv6 addresses of RDNSSes to which the host may send DNS queries.   The DNS servers are listed in the order of preference for use by the DNS resolver on the host.
00024 Domain Search List	The Domain Search List option specifies the domain search list the client is to use when resolving hostnames with DNS.  This option does not apply to other name resolution mechanisms.
00027 NIS IPv6 Address List	This option specifies a list of IPv6 addresses indicating Network Information Services (NIS) Servers available to the client. Clients MUST treat the list of NIS servers as an ordered list.  The server MAY list the NIS servers in the order of   preference.
00028 NIS + IPv6 Address List	This option specifies a list of IPv6 addresses indicating Network Information Services v2 (NIS +) Servers available to the client. Clients MUST treat the list of NIS+ servers as an ordered list.  The server MAY list the NIS+ servers in the order of   preference.
00029 NIS Domain List	The Network Information Service (NIS) Domain Name List is used by the server to convey client's list of NIS Domain Name info to the client.
00030 NIS + Domain Name List	The Network Information Service v2 (NIS+) Domain Name List is used by the server to convey client's list of NIS+ Domain Name info to the client.
00031 SNTP Servers IPv6 Address List	Simple Network Time Protocol (SNTP) servers option provides a list of one or more IPv6 addresses of SNTP [3] servers available to the client for synchronization.

 

Posted: Tuesday, March 03, 2009 2:58 PM by teamdhcp | 1 Comments

Filed under: DHCPv6

How to monitor and audit DHCP Server configuration changes for compliance

DHCP Server of Windows Server 2008 R2, supports DHCP activity logging, that is it allows DHCP Administrators to monitor the configuration changes of the DHCP Servers.

Therefore the events pertaining to DHCP activity logging, will be logged with additional information like: Date and time of event occurrence, IP Address and host name of the DHCP Server on which the event occurred and user name of the administrator who made the change.

These events can be seen in the following location in eventviewer:
Applications and Services Logs > Microsoft > Windows > DHCP Server > Microsoft-Windows-DHCP Server Events/Operational

DHCP Administrators would use this feature for network security / IT compliance auditing purposes.
 

Download this tool to directly view all the activity logs in MMC.

DHCP Server service security enhancement

DHCP Server service is moved under Network Service account from what it used to be a Local System account untill Windows Server 2008. With this the DHCP Server service that runs in the context of the Network Service account presents the computer's credentials to remote servers. Also the advantage with Network Service is it has very few privileges and can do less damage on the server if compromised.

New features in DHCP for Windows Server 2008 R2 / Windows 7

What are the major changes?

The DHCP server in Windows Server 2008 R2 has invested in the areas of security, reliability, manageability and usability. Similarly on the DHCP Client in Windows 7 has invested on certain optimization for obtaining IP Address.

 

The following changes are available in DHCP server in Windows Server 2008 R2:

 

·         Supports MAC address based network access control mechanism, with the Link Layer based Filtering feature. With this feature DHCP Administrator can control issuance/denial of DHCP leases/IP addresses.

 

·         Supports prevention of name squatting issues caused due to non-Windows OS machines, with the Name Protection feature. Using this feature one could prevent registration of non-Windows OS machine with a same name that is already registered for another machine in DNS Server.

 

·         Supports prevention of exhaustion of IP addresses at scope level especially for the deployments catering to redundancy/high-availability scenarios like Split-Scope. This feature is available only for IPv4 network and not for IPv6 network as in case of latter exhaustion of addresses is not an issue.

 

·         Supports DHCP activity logging, allows DHCP Administrators to monitor the configuration changes of the DHCP Servers. DHCP Administrators would use this feature for network security / IT compliance auditing purposes.

 

·         Supports migration of DHCP Server role using Windows Server Migration Tool (WSMT).

 

·         DHCP Server service is moved under Network Service account from Local Service account. With this the DHCP Server service that runs in the context of the Network Service account presents the computer's credentials to remote servers. Also the advantage with Network Service is it has very few privileges and can do less damage on the server if compromised.

 

·         Usability and operability enhancements of DHCP Server like:

-          Auto-population of certain network interface fields like DNS Server addresses (both IPv4 and IPv6), WINS Server addresses, during installation and configuration of scope.

-          Interpretive Icons for better readability.

-          Wizard based split-scope configuration for ease and error free split-scope deployment.

-          Address leases to filter (multiple select supported) for ease of Link Layer based filter configuration for leased clients.

-          Address leases to reservation (multiple select supported) for ease of reservation configuration for leased clients.

-          In the product scenario/task based help content for Windows Server 2008 R2 features.

 

·         Supports DHCPv6 Option 15 (User Class). This is used by client to identify the type or category of user or application it represents. It involves both DHCP Server and Client side implementation.

 

·         Support of DHCPv6 Option 32 (Information Refresh Time). This specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6. It involves both DHCP Server and Client side implementation.

 

·         Better performance and scalability achieved through lease database caching. Read more about it here. 

 

The DHCP client of Windows 7 has support for optimization to obtain IP Address using SSID caching.

 

·         Supports SSID caching so that, laptop devices with Windows 7 could get IP Address in a lesser time in a Wireless LAN network during revisits to the same.

 

·         Extended NDF and unified tracing to support additional scenario.

 

·         Broadcast bit flag behaviour is updated to toggle between ‘0’ and ‘1’ and also would cache the last successful broadcast bit setting for which the client received IP Address. This way it would ensure the client to acquire the address properly, irrespective of the support for the flag by the 3rd party DHCP Server \ Relay Agent.

 

·         Support of DHCPv6 Option 32 (Information Refresh Time). This specifies an upper bound for how long a client should wait before refreshing information retrieved from DHCPv6.

 

 

 Team DHCP

Migration of DHCP Server from Windows Server 2003 to Windows Server 2008

Microsoft product support team often encounters migrated DHCP servers which are dysfunctional. The reason quite often for the bad state of the DHCP server is because backup/restore has been used by the customers for migrating the DHCP server across server versions (e.g. migrating from Windows Server 2003 DHCP to Windows Server 2008).  Backup and Restore are not expected to work across server versions as the DHCP database format has changed between Windows Server 2003 and Windows Server 2008.

The recommended procedure for DHCP server migration is to use the export import commands through netsh. Following is the procedure for migrating DHCP server from Windows Server 2003 to Windows Server 2008 outlined in brief:

Export the DHCP database from the server that is running Microsoft Windows Server 2003

To migrate a DHCP database and configuration from a server that is running Windows Server 2003 to another server that is running Windows Server 2003:

1.       Log on to the source DHCP server by using an account that is a member of the local Administrators group or the DHCP Administrators group

2.       Click Start, click Run, type cmd in the Open box, and then click OK.

3.       Type netsh dhcp server export C:\dhcpdatabase.dat all, and then press ENTER.

Note: While the export command runs, DHCP server is stopped and does not respond to clients seeking new leases or lease renewals.

At the end of this step, you will have the DHCP configuration as well as address lease information exported into the dhcpdatabase.dat file.  You can now stop the DHCP service on the source server.

Install the DHCP server service on the server that is running Windows Server 2008

To install the DHCP Server service on an existing Windows Server 2008 computer:

1.       Start Server Manager.

2.       Click on Add Roles.

3.       Select the DHCP server role and press Next.

4.       Click through the next sequence for screens of the installation wizard to complete the DHCP server installation. You should not authorize the DHCP server at this point.

Import the DHCP database

1.       Log on as a user who is a member of the local Administrators group or DHCP administrators group.

2.       Copy the exported DHCP database file to the local hard disk of the Windows Server 2008 computer.

3.       Verify that the DHCP service is started on the Windows Server 2008 computer.

4.       Click Start, click Run, type cmd in the Open box, and then click OK.

5.       At the command prompt, type netsh dhcp server import c:\dhcpdatabase.dat all, and then press ENTER, where c:\dhcpdatabase.dat is the full path and file name of the database file that you copied to the server.

6.       After you receive the message that the command completed successfully, quit the command prompt.

Authorize the DHCP server

1.       Click Start, point to All Programs, point to Administrative Tools, and then click DHCP. You must be logged on to the server by using an account that is a member of the Administrators group. In an Active Directory domain, you must be logged on to the server by using an account that is a member of the Enterprise Administrators group.

2.       In the console tree of the DHCP snap-in, expand the new DHCP server. If there is a red arrow in the lower-right corner of the server object, the server has not yet been authorized.

3.       Right-click the server object, and then click Authorize.

4.     After several moments, right-click the server again, and then click Refresh. A green arrow indicates that the DHCP server is authorized.

While the netsh export command exports the lease database as well as the configuration of the DHCP server, the DHCP server registry settings are not handled by export/import. Attached with this post is a tool which will help you migrate all the DHCP configuration including the registry settings. Type dhcmpmig -help for usage information on the tool.

The scripted tool (bat file) is provided on an "as is" basis and not supported by Microsoft.

Prasad

DHCP Server Team

MAC Filter Import Tool

Hello Everybody,

Thanks for all those who tried the MacFilterCallout dll. As you all must have checked out by now that Link Layer Filtering feature is a part of Windows Server 2008 R2 DHCP Server. DHCP Server team has come up with a GUI based tool which will let an administrator import the MAC addresses specified in MACList.txt file (used by MacFilterCallout dll), into the allow/deny list of Windows Server 2008 R2 DHCP Server.

This tool will work only on Windows Server 2008 R2 or above. DHCP Server role must be installed and the service must be up and running. Comments corresponding to each MAC address entry can be edited in place before you import the entries into the DHCP Server database.

 

Raunak Pandya

DHCP Server Team

DHCP Broadcast flag handling in Windows 7

1.     DHCP Broadcast flag:

DHCP messages have ‘flags’ field. The first bit in this field indicates whether the client is expecting a broadcast or unicast response from the DHCP server \ Relay agent. When the bit is set to 1, it indicates that the client expects broadcast response, and when the bit is set to 0, it indicates that the client expects a unicast response. While the majority of the DHCP Servers and Relay Agents support both the values for the broadcast flag, there are still few of them which support only either of the values of the broadcast flag.

2.     Behaviour change in Windows 7:

           In Vista, the default broadcast flag value is set to ‘1’. But it had caused inter-operability issues with some 3^rd party router based DHCP Servers \ Relay agents  that did not support broadcast flag ‘1’. Therefore in Windows 7, the behaviour change introduced would try with both the values for the broadcast flag (toggling between ‘0’ & ‘1’) and also would cache the last successful broadcast bit setting for which the client received IP address. This is to ensure that the client acquires the address properly, irrespective of the support for the flag from DHCP Server \ Relay Agent. That is, during address acquisition, first the client will try with the broadcast flag set to 0 and it sends 4 DHCP DISCOVER messages at exponential intervals for a total duration of one minute. If the client does not get any response (i.e. DHCP OFFER), then broadcast flag is toggled to 1 and again 4 DISCOVER messages are sent at exponential intervals. At least one of the flag setting is expected to succeed when the DHCP server \ Relay Agent is reachable. The successful broadcast flag is cached, and that cached flag is used as the starting broadcast flag, during the next time of address acquisition.

Another difference is, in Vista, toggling can happen (if configured) only for the address acquisition. But in Windows 7, toggling is extended to INIT-REBOOT scenario as well. In this scenario, after getting valid address, if the client gets a disconnect - connect, then the client will first send 3 DHCP REQUESTs with the broadcast flag (with which it had acquired the address). If there is no response from the server, the client will then send 3 DHCP REQUEST with the alternate Broadcast flag. If again, there is no response, then the gateway reachability check is done. If the gateway is reachable, the old IP configuration is kept. If the gateway is also not reachable, then the old configuration is removed.

So, the default behaviour is to have starting broadcast flag as 0 and toggling is ON. This can be changed by changing the configuration settings in registry as given below.  

3.     Configuring broadcast flag settings:

 

      The default broadcast bit behaviour of Windows 7 is expected to work fine in most of the scenarios, and therefore it is least expected from the users to modify any broadcast bit related settings, unless the user clearly understands the impact. Also note that the explained registry based procedure to configure broadcast bit settings may not be maintained in future versions of windows, unless it is required. There are two kinds of broadcast flag settings that can be configured.

 

i)                    The starting broadcast flag, with which the first set of DHCP DISCOVERs start. By default it starts with ‘0’.

ii)                  The toggle setting, which will indicate whether the broadcast flag can be toggled (if the starting broadcast flag fails). By default, toggling is ON.

  

3.1 Configuring the starting broadcast flag:

The starting broadcast flag value can be specified at two levels.

i)                    For a specific interface.

ii)                  Globally based on the interface type. This option needs to be chosen, only if the value of the MediaType and PhysicalMediumType of the interface are known.

 

3.1.1  Configuring the starting broadcast flag for a specific interface :

i)                   Click Start, type regedit in the Start Search box, and then click regedit in the Programs list. If you are prompted for an administrator password for  confirmation, type your password, and click Continue.

ii)                 Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID}.  In this registry path, click the (GUID) subkey that corresponds to the network adapter that is connected to the network.

iii)               Right-click DhcpConnForceBroadcastFlag, and then click Modify.

iv)                In the Value data box, type the broadcast flag (0 or 1), and then click OK.

v)                  Close Registry Editor.

vi)                Restart the machine.

 

3.1.2  Configuring the starting broadcast flag globally for an interface type:

i.                    Click Start, type regedit in the Start Search box, and then click regedit in the Programs list. Collapse this imageExpand this image If you are prompted for an administrator password for confirmation, type your password, and click Continue.

ii.                  Locate and then click the following registry subkey: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters

iii.                On the Edit menu, point to New, and then click Key.

iv.                 Type DhcpGlobalForceBroadcastFlag for the name of the registry subkey, and then press ENTER.

v.                   Click DhcpGlobalForceBroadcastFlag, point to New on the Edit menu, and then click Key.

vi.                 Type the Value of MediaType(Real Value, not this string) for the name of the registry subkey, and then press ENTER. Following are some of the possible values.

 

Value of MediaType	Media
0	Unknown adapters like remote access adapters
1	Wireless
14	Ethernet

vii.                 Click Value of MediaType, point to New on the Edit menu, and then click DWORD Value to create a new registry entry.

viii.               Type Value of PhysicalMediumType (Real Value, not this string) for the name of the registry entry, and then press ENTER.

ix.                   Right-click on this registry entry, and then click Modify.

x.                     In the Value data box, type the broadcastflag(0 or 1), and then click OK.

xi.                   Review the final output. The final output should resemble the following:

[HKEY_LOCAL_MACHINE \ SYSTEM \ CurrentControlSet \ Services \ Dhcp \ Parameters \ DhcpGlobalForceBroadcastFlag \ Value Of MediaType] "Value of PhysicalMediumType"= dword : [1 or 0]

xii.                 Close Registry Editor.

xiii.               Restart the machine.

3.2 Configuring the toggle settings:

 This setting is used to indicate whether the client can perform toggling of broadcast flag. This setting can be defined only at the interface level. By default toggling is ON.

i.                      Click Start, type Regedit in the Start Search box, and then click regedit in the Programs list. If you are prompted for an administrator password 

             for confirmation, type your password and click Continue.

ii.                    Locate and then click the following registry subkey:  

             HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{GUID} . In this registry path, click the (GUID) subkey 

             that corresponds to the network adapter that is connected to the network.

iii.                  On the Edit menu, point to New, and then click DWORD (32-bit) Value.

iv.                  In the New Value #1 box, type DhcpConnEnableBcastFlagToggle, and then press ENTER.

v.                    Right-click DhcpConnEnableBcastFlagToggle, and then click Modify.

vi.                  In the Value data box, type 1 or 0 (ON\OFF), and then click OK.

vii.                Close Registry Editor.

viii.              Restart the machine.

4.     Verification of broadcast flag settings:

 

i)                    Install the latest network monitor from http://www.microsoft.com/downloads/ .

ii)                  Apply filter ‘DHCP’ and start capturing the packets.

iii)                In an elevated command prompt, do ipconfig /release “Name of Interface”, specify the interface name in which you want to verify.

iv)                 Then, do ipconfig /renew  “Name of Interface”

v)                  You can find that DHCP packets are getting captured on network monitor. Expand the flags field of DHCP DISCOVER packet, the first bit of this 

            field  denotes the broadcast flag set.

vi)                By default, you should be seeing 8 DISCOVER packets for a total duration of 2 mins. The first 4 DISCOVER packets will have the flag set to ‘0’ and the 

            next 4 will have the flag set to ‘1’.

 

5.     FAQ on broadcast flag settings:

 

i)                   I have configured the broadcast flag settings, but still the setting does not come up in DHCP messages?

            Follow the steps exactly as specified in section 3. After modifying the registry settings, immediately restart without doing any other IP  related operations. As specified in verification section (4), use netmon to verify the broadcast flag set in the DHCP message. Ensure that you are verifying the broadcast flag on the DHCP messages that originate only from your machine.

 

ii)                  I have a domain joined IPsec enabled machine and the machine does not get IP address in certain routers?

This will happen when the router does not support broadcast flag ‘1’. When DHCP DISCOVERs are sent with broadcast flag 0, the corresponding OFFERs are dropped by IPsec as they are unsolicited unicast messages. To resolve this issue, the IPsec administrators are recommended to have UDP traffic exemption from port 67 to 68 (for DHCP messages). The issue could also be solved by updating the router firmware. But since, the external routers cannot be controlled always, IPsec admins are advised to have this exemption.

 

iii)                The machine takes around a minute to get the IP configuration, when I move between networks?

This can happen if the broadcast flag supported at your source network and destination network are different. Please update your router firmware for the issue to be fixed.

 

iv)                Does the above method to configure broadcast flag settings apply to Vista as well ?

Yes. Though the default behaviour of Vista is different, the configuration and verification methods specified here, can be applied to Vista as well. In Vista, by default, the starting broadcast flag is 1 and toggling is OFF.

 

v)                  My WWAN card does not get IP address on a domain joined IPsec enabled machine ?

This is known issue in Windows 7 Beta, which is fixed in further releases of Windows 7 versions. Temporarily this be could be solved, by changing the interface-specific ‘starting broadcast flag’ to ‘1’ [See configuration section 3.1.1] 

 

6.     Troubleshooting Broadcast flag issues:

If you think, that your machine is not getting an address, because of broadcast flag issue, then here are steps to troubleshoot.

i)                    Start capturing DHCP packets on the interface, as specified in the verification section (4).

ii)                  If the default settings are not modified, you should be seeing 4 DISCOVERs sent on the first minute with a specific broadcast flag (0 by default), and during the second minute another 4 DISCOVERs will be sent with the alternate broadcast flag.

iii)                If 8 DISCOVERs are not sent as mentioned above, then verify whether the toggle setting [specified in configuration section 3.2] is correct.

iv)                If 8 DISCOVERs are properly sent and none of them got any response from the DHCP server, then it is likely that DHCP server is not reachable, and the issue is not associated with broadcast flag.

v)                  If a specific set of DISCOVERs got OFFER as the response, but still the client did not accept the OFFER, and continues sending the DISCOVER, then it is likely that you are having a router which does not support broadcast flag 1 and a domain joined IPsec enabled machine. Refer to FAQ section for the resolution.

 

 

 

 

 

Posted: Thursday, February 12, 2009 9:44 PM by teamdhcp | 7 Comments

How to configure Link Layer based filtering

In the scenarios where there are increasing security concerns and potential threats in networks, Link Layer based filtering feature in Windows Server 2008 R2 DHCP Server provides administrators the ability to specifically control network resource access to the clients by issuance or denial of IP Address to them, based on MAC address of clients configured in allow or deny filter respectively.

 

Here is the step by step guide for configuring Link Layer based filtering.

 

(I) Enabling/Disabling Allow and Deny Link Layer filters.

1. From the Network Administration group, start DHCP Manager. The DHCP Manager window appears.

2. Under the server node for which you want to configure Link Layer based filtering, go to IPv4 node.

3. From the right click menu, choose Properties. This shows the properties page for IPV4 node.

4. Go to the filter tab, check/uncheck the checkboxes to enable/disable MAC based allow or deny filters.

5. Choose Ok when done.

 

Also filters can be enabled/disabled the command line

netsh dhcp server v4 set filter EnforceAllowList=0 EnforceDenyList=1

 

(II)Adding a new MAC Address to any of the lists.

1. From the Network Administration group, start DHCP Manager. The DHCP Manager window appears.

2. Under the server node for which you want to configure Link Layer based filtering, go to IPv4 node.

3. Expand the filter node under IPV4 node to list allow and deny filter nodes.

4. To add a MAC address to the allow list, choose new filter from the right click menu.  The New Filter dialog box   appears.

      5. Enter the MAC address and the description for the new filter.

6. Click Ok when done.

 

Also from the command line, filters can be added using following command.

netsh dhcp server v4 add filter allow 00-1C-23-20-AF-4E "filter description"

 

(III) Configuring Filter Exemptions

By default, all the hardware type other than ethernet are exempted from filtering. Any of these exemptions can be removed at any time. Steps to remove filter exemption for a hardware type.

1. From the Network Administration group, start DHCP Manager. The DHCP Manager window appears.

2. Under the server node for which you want to configure Link Layer based filtering, go to IPv4 node.

3. From the right click menu, choose properties. This shows the properties page for IPV4 node.

4. Click Advanced button at the bottom right corner. Advance Filter Properties page is shown.

5. To add/remove filter exemption for a hardware type, check/uncheck the checkbox associated with that hardware type.

            6. Click Ok and Apply when done.

 

From the command line, execute the following command to change filter exemption settings.

netsh dhcp server v4 add/delete filterexemption <hardware type>

 

(IV) Active Lease to Filter

In the scenarios where there already exist active leases and the admin wants to configure Link Layer based filters, it would be an additional overhead for him to add a new filter for each of the active leases. Below is a quick and easy way to do the same.

            1. From the Network Administration group, start DHCP Manager. The DHCP Manager window appears.

            2. Under the scope node for which you want to add the Link Layer based filters, go to lease node.

            3. One the right hand side pane of the MMC, select the leases for which filters have to be created.

            4. Right click and from the menu, choose add to filter. Select the filter type(allow/deny) from the sub-menu.

            5. Click Yes when prompted for a confirmation.

 

 Dhcp Server Management API’s for Link Layer based Filters

DWORD

DhcpAddFilterV4(

    __in_z_opt   DHCP_CONST WCHAR          *ServerIpAddress,

    __in              DHCP_FILTER_ADD_INFO   *AddFilterInfo,

    __in              BOOL                                          ForceFlag

    )          

DWORD

DhcpDeleteFilterV4(

    __in_z_opt   DHCP_CONST WCHAR         *ServerIpAddress,

    __in              DHCP_ADDR_PATTERN      *DeleteFilterInfo

    )

DWORD

DhcpSetFilterV4(

    __in_z_opt   DHCP_CONST WCHAR                *ServerIpAddress,

    __in              DHCP_FILTER_GLOBAL_INFO *GlobalFilterInfo

    )

DWORD

DhcpGetFilterV4(

    __in_z_opt  DHCP_CONST WCHAR                 *ServerIpAddress,

    __out           DHCP_FILTER_GLOBAL_INFO  *GlobalFilterInfo

    )

DWORD

DhcpEnumFilterV4(

    __in_z_opt  DHCP_CONST WCHAR                 *ServerIpAddress,

    __inout        LPDHCP_ADDR_PATTERN            ResumeHandle,

    __in             DWORD                                              PreferredMaximum,

    __in             DHCP_FILTER_LIST_TYPE            ListType,

    __out           LPDHCP_FILTER_ENUM_INFO  *EnumFilterInfo,

    __out           DWORD                                           *ElementsRead,

    __out           DWORD                                           *ElementsTotal

    )

 

 

You can download this tool which can help you manage the Link Layer Filtering by giving you a list of users who are denied IP address

and allowing you to directly manage their filter profiles from the same UI.

 

 Thanks,

TeamDHCP

Posted: Thursday, January 29, 2009 4:07 PM by teamdhcp | 1 Comments

Filed under: MAC Filtering, LLF