Thursday, November 20, 2008

Manage Windows Server 2008 DHCP Servers From Command Line

Installing the DHCP Feature from the Command Line

A Windows Server 2008 system can only act as a DHCP server if the DHCP feature has been installed. This can be achieved from the command prompt using the servermanagercmd utility as follows:

servermanagercmd -install dhcp

[edit] Authorizing DHCP Servers in Active Directory

If a DHCP server is to operate within an Active Directory domain (and is not running on a domain controller) it must first be authorized. This can be achieved either as part of the DHCP Server role installation, or subsequently using either DHCP console or at the command prompt using the netsh tool. To achieve this, open a command prompt and enter the following command:

netsh dhcp server serverID initiate auth

In the above command syntax, serverID is replaced by the IP address or full UNC name of system on which the DHCP server is installed.
[edit] Configuring Scopes at the Command Prompt

DHCP scopes may be configured from the command prompt using the netsh tool. netsh may be run as a single command, or interactively. To run interactively. To run in interactive mode follow these steps:
  1. At the command prompt enter netsh.
  2. At the netsh> prompt enter dhcp.
  3. At the netsh dhcp> prompt enter server \\servername where servername is the UNC name or IP address of the server to be managed. For example:
  4. netsh dhcp>server \\winserver-1
  5. At the netsh dhcp server prompt, enter the commands to be executed.
Alternatively, run each netsh command separately, using the following syntax:

netsh dhcp server \\servername commands

To create a new DHCP scope the command syntax is as follows:

netsh dhcp server \\servername scope subnetID add iprange startIP endIP

For example, to create a scope on subnet 192.168.2.0 ranging from 192.168.2.1 through 192.168.2.100:

netsh dhcp server \\winserver-1 scope 192.168.2.0 add iprange 192.168.2.1
192.168.2.100

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To list a scope IP address range:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show iprange

Changed the current scope context to 192.168.2.0 scope.

=========================================================
Start Address - End Address - Address type
=========================================================
192.168.2.1 - 192.168.2.100 - DHCP ONLY

Number of IP Ranges : 1 in the Scope : 192.168.2.0.

Command completed successfully.

To delete a scope using netsh:

netsh dhcp server \\winserver-1 scope 192.168.2.0 delete iprange 192.168.2.1
192.168.2.100

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To display the current state of a scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show state

Changed the current scope context to 192.168.2.0 scope.

Current State of the Scope 192.168.2.0 : Active

Command completed successfully.

To add an exclude range to a scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 add excluderange
192.168.2.10 192.168.2.20

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To display an exclude ranges:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show excluderange

Changed the current scope context to 192.168.2.0 scope.

=====================================
Start Address - End Address
=====================================
192.168.2.10 - 192.168.2.20

Number of ExcludeRanges : 1 in the Scope : 192.168.2.0.

Command completed successfully.

To list the clients using a DHCP scope:

netsh dhcp server \\winserver-1 scope 192.168.2.0 show clients

Changed the current scope context to 192.168.2.0 scope.

Type : N - NONE, D - DHCP B - BOOTP, U - UNSPECIFIED, R - RESERVATION IP
==================================================================================
IP Address - Subnet Mask - Unique ID - Lease Expires -Type
==================================================================================


No of Clients(version 4): 0 in the Scope : 192.168.2.0.

Command completed successfully.

[edit] Activating and Deactivating DHCP Scopes using Netsh

DHCP scopes must be activated before they can be used and may also be deactivated at any time. Both of these tasks may be performed at the command prompt using the 'netsh tool. For example, to activate a scope the following command line syntax is used:

netsh dhcp server serverID scope subnetID state status

where serverID is the name or IP address of the computer running the DHCP server, subnetID is the network ID of the subnet on which the scope is to be configured, and status is either 1 or 0 depending on whether the scope is to activated (1) or deactivated (0). On a switched network with multiple virtual networks are hosts on a single network use 2 and 3 respectively to deactivate and activate the scope.
[edit] Terminating a DHCP Lease using Netsh

The lease associated with an IP address may be terminated at the command prompt using the following command syntax:

netsh dhcp server serverID scope subnetID delete lease IPaddress

where serverID is the name or IP address of the computer running the DHCP server, subnetID is the network ID of the subnet on which the IP address resides, and IPaddress is the IP address on which the lease is to be terminated. For example,

netsh dhcp server \\winserver-1 scope 192.168.2.0 delete lease 192.168.2.101

[edit] Configuring DHCP Reservations using Netsh

DHCP reservations provide a mechanism by which IP addresses may be permanently assigned to a specific client based on the MAC address of that client.

The MAC address of a Windows client can be found running the ipconfig /all command. For Linux systems the corresponding command is ifconfig -a. Once the MAC address has been identified, the reservation may be configured using either the DHCP console or at the command prompt using the netsh tool.

To add a reservation using netsh the following syntax is used:

netsh dhcp server \\servername scope subnetID add reservedip IPaddress MacAddress ReservationName Comment

For example the following command reserves an IP address for a specific MAC address (note that the MAC address must be entered without any delimiters):

C:\Users\Administrator>netsh dhcp server \\winserver-2 scope 192.168.2.0 add reservedip
192.168.2.12 0013720B1457 "CEO Printer" "Printer in Exec Suite"

Changed the current scope context to 192.168.2.0 scope.

Command completed successfully.

To list the current reserved IP addresses for a particular scope the following netsh command may be used:

C:\Users\Administrator>netsh dhcp server \\winserver-2 scope 192.168.2.0 show
reservedip

Changed the current scope context to 192.168.2.0 scope.

===============================================================
Reservation Address - Unique ID
===============================================================

192.168.2.10 - 00-0b-db-18-a0-db-
192.168.2.11 - 06-ec-e6-11-47-bd-
192.168.2.12 - 00-13-72-0b-14-57-


No of ReservedIPs : 3 in the Scope : 192.168.2.0.

Command completed successfully.

[edit] Configuring DHCP Conflist Detection

By default, if a DHCP server assigns an IP address to a client which conficts with another client, it is the job of the client to decline the assigned address and request that the DHCP server send another. A faster option is to enable DHCP Conflict Detection on the DHCP server, whereby the server checks that there are no conflicts associated with an IP address before it is assigned to a client. The DHCP server will repeat this process until a valid IP address is found, or a specified number of attempts to find a non-conflicting IP address is reached. The syntax to enable conflict detection and specify the number of retry attempts is as follows:

netsh dhcp server servername set detectionconflictretry no_of_attempts

where servername is the name or IP address of the DHCP server and no_of_attempts is the maximum number of times the DHCP server will attempt to find a non-conflicting IP address. To disable confict detection simpy run the above command setting no_of_attempts to 0. For example:

netsh dhcp server \\winserver-1 set detectionconflictretry 0

[edit] Backing Up and Restoring DHCP Configuration Information

The current configuration of a DHCP server can quickly and easily be saved and restored using the dump option of the netsh tool. This enables a server to be quickly restored to its original state in the case of a system failure, or for the configuration to be duplicated on another server.

For example, to back up the configuration on a local server to a file named DHCPconfig.cfg:

netsh dhcp server dump > DHCPconfig.cfg

The configuration on a remote system may be similarly saved by specifying the name or IP address of the server:

netsh dhcp server winserver-1 dump > DHCPconfig.cfg

Source:techotopia.com/index.php/Managing_a_Windows_Server_2008_DHCP_Server_from_the_Command_Line

Wednesday, November 12, 2008

DHCP Server Security

Although DHCP servers are critical to the operation of most enterprise networks, DHCP server security is often one of the most overlooked areas of network security. One reason for this might be the simplicity of how DHCP works: DHCP clients broadcast discovery messages (DHCPDISCOVER) containing their MAC addresses and DHCP servers respond by offering (DHCPOFFER) to lease an IP address and other TCP/IP settings that the client can use to communicate on the network. The client responds (DHCPREQUEST) to the first lease offer it receives and the server acknowledges (DHCPACK) the request and marks the address as leased in its DHCP database. That's all there is to it—who needs to worry about security?

Attacking DHCP

Unfortunately it's the very simplicity of DHCP that's actually the problem as far as security goes. No authentication or authorization takes place during an exchange between a DHCP server and DCHP client, so the server has no way of knowing if the client requesting the address is a legitimate client on the network, and the client has no way of knowing if the server that assigned the address is a legitimate DHCP server. The possibility of rogue clients and servers on your network can create all kinds of problems.

For example, a rogue DHCP server could provide legitimate clients with bogus TCP/IP information that prevents the clients from communicating on the network. A denial of service (DoS) condition then results, and users are unable to connect to network resources to perform their work. Setting up a rogue DHCP server could be as simple as conducting a social engineering attack to gain physical access to your network and plugging in a laptop configured as a DHCP server.

Another scenario might involve an attacker compromising a client computer on your network and installing software that repeatedly requests new IP addresses using spoofed MAC addresses until the entire pool of addresses in your DHCP server's scope is leased. When this happens, legitimate clients that boot onto the network can't acquire an address and again users are unable to access the network and can't do their work.

A more sinister result happens when an attacker breaches network security and gains control of your own DHCP servers. At that point the attacker might proceed to modify the DHCP server to assign clients an incorrect subnet setting and thus create another DoS condition. Or they might modify the server to assign clients incorrect DNS settings and redirect clients to rogue or hijacked DNS servers, which could then redirect clients to hostile websites where they unknowingly download a trojan.

Worse yet, if you're running your DHCP server on a domain controller then an attacker who compromises your DHCP server gains access to your accounts database and can cause all sorts of further problems. The result is usually your worst nightmare. Fortunately, there are some measures you can take to protect your DHCP servers and avoid many of these scenarios, provided you're also following all the usual best practices for securing Windows-based networks. Let's look at some specific threats to DHCP on your network and the countermeasures you can take to mitigate these different threats.

Threats and Countermeasures

On the face of it, the requirement that Windows 2000 and Windows Server 2003 DHCP servers be authorized in Active Directory before they can start leasing addresses to requesting clients seems to mitigate the threat of rogue DHCP servers on your network. Authorization means that when a Windows 2000 or Windows Server 2003 DHCP server boots onto an Active Directory network it first contacts a domain controller to check if its own IP address is found on the list of authorized DHCP servers maintained by the domain controller. If the DHCP server determines that it is authorized to lease addresses to clients, it begins to do so. If it's not authorized, Windows shuts down the DHCP Server service on the machine so it won't be able to lease addresses.

The real benefit of this is to protect your network against legitimate DHCP servers that are badly configured, though it has the added side effect of guarding against accidental or rogue DHCP servers running Windows 2000 or Windows Server 2003. What happens though if an attacker compromises your network with a rogue DHCP server not running Windows 2000 or Windows Server 2003? In this case authorization won't help because non-Microsoft DHCP servers may not respond the same way as Microsoft ones to the DHCPINFORM messages Windows uses to check if DHCP servers are authorized.

Rogue clients is another problem entirely though, as DHCP is designed to make it easy for clients to obtain IP addresses so they can participate on a network. The obvious way of dealing with the problem of rogue clients would seem at first to be DHCP reservation, though on large networks this entails considerable administrative overhead. A reservation is a predefined setting that maps a MAC address to an IP address so that only a client with a particular MAC address can lease the IP address associated with that reservation. If security is critical an administrator could create reservations for each and every client machine on the network, and if unreserved IP addresses still remain in the DHCP server's cope then these could be reserved using invalid or non-existing MAC addresses. Then when a rogue client tries to boot on the network the result is that the DHCP server has no free addresses to lease and the client can't connect.

If only it were that simple. While this approach might foil a casual attack, sophisticated attackers have ways for circumventing DHCP reservations. The simplest approach is for the attacker to run a program that listens for DHCPDISCOVER broadcasts from clients and harvests their MAC addresses. Then when a legitimate client shuts down the rogue client can reconfigure its MAC address to match that of the legitimate client and hijack the legitimate client's lease or try to disrupt communications for the client. Considering this, security-conscious administrators might consider dropping DHCP entirely in favor of static addressing, but what's to stop an attacker who has physical access to your network from assigning a static address to their own machine and joining the network?

Via:windowsecurity.com/articles/DHCP-Security-Part1.html

Friday, November 7, 2008

How to reinstall a dynamic DNS Active Directory-integrated zone

Under the following situations you may want to reinstall the dynamic DNS in a Windows 2000 Active Directory:


  • Multiple DNS errors have occurred and methods have been unsuccessful.

  • Services that depend upon DNS, such as, the File Replication service (FRS) and/or Active Directory are failing. Also, the standard troubleshooting procedures have been unable to locate the exact cause of the problem.

  • DNS had been built as a secondary DNS server or files copied from a DNS server do not support dynamic updates.
To create a better name space design, such as, splitting the internal and external name spaces.
You have to remove DNS and the DNS cache. Then, you must rebuild one Active Directory DNS server to set up long term stability.

The following steps can remove the defective information in Active Directory-integrated DNS:

  • Go to the properties of the DNS zone files and change them to be a "Standard Primary".

  • In the %Systemroot%\Winnt\System32\DNS folder, delete the text DNS Zones files.

  • Delete the object in Active Directory Users and Computers.

  • On the View menu, click Advanced Features, expand the System folder, click MicrosoftDNS, and then delete the zone file objects.

  • For each Active Directory-integrated DNS server, repeat steps 1-3.

  • In the Transmission Control Protocol/Internet Protocol (TCP/IP) properties of the first Active Directory-integrated DNS server, point it to itself.

  • To obtain proper resolution, you must clear the Caching Resolver, which is the DNS client on the DNS server. At the command prompt, type: ipconfig /flushdns.

  • Stop and restart DNS and the NetLogon service. Then, remove and re-add the DNS service.
You have completed the process to clear out a DNS server. You must complete the process for any additional DNS servers that you plan to integrate with Active Directory.

The following steps can assist you to build a strong foundation for DNS, Active Directory, and FRS:


  • Configure all DNS servers to point to the same DNS server in the domain or forest under TCP/IP properties in DNS: Right-click My Network Places, click Local Area

    Connection
    , right-click Local Area Connection, click Properties, select the properties of TCP/IP, and then point all DNS servers to the same DNS server. Also, click the Advanced DNS tab, and then confirm that secondary DNS servers are not configured.

  • Re-add the DNS service, or re-add the zones and configure them to be Active Directory integrated. For troubleshooting purposes, you may want to set "Allow Dynamic Updates?" to Yes. Later, you can change this setting to "Allow Only Secure Updates".

  • Run the ipconfig /flushdns command, and then run the comand. This command can help you to register your A resource record for DNS as well as your start of authority (SOA). You may want to run this command on any other servers that are critical to you.ipconfig /registerdns
  • NOTE: The Dynamic Host Configuration Protocol (DHCP) client service needs to be running on each of these computers to register the records in Dynamic DNS. It is not relevant if the computer is a DHCP client or not. You must have this service set to "start" and the "Start up" type set to "automatic." The DHCP client service is what registers records in Dynamic DNS. (Refer to the description in the Computer Management snap-in.)

  • Active Directory-integrated DNS is now working on your first Dynamic DNS server. You must point additional Dynamic DNS servers to the first DNS server under TCP/IP properties. You must confirm that a full and complete replication process has occurred before you change the TCP/IP properties to point to itself for any additional DNS servers.
Before you configure DNS, you must research the benefits of various DNS name space architectures, such as, internal name spaces, external name spaces, child domains, caching only DNS servers, and reverse look-up zones. Then, you must consider how to develop a design architecture that can work for your organization.

Source:support.microsoft.com/kb/294328

Friday, October 31, 2008

Install a Windows 2003 DNS server

Every network needs a DNS (domain name service) server, right? Windows comes with a DNS server, but it isn’t installed by default. This will tell you how to install a DNS server on a Windows 2003 server.

As an administrator on the system, click Start -> Control Panel -> Add or Remove Programs -> Add/Remove Windows Components.

In the window that opens, click on the Networking Services line (careful not to uncheck the box to the left) and click Details.

Find the line for Domain Name System (DNS), click the checkbox on its left, and Click OK. Click Next.

If Windows asks for a CD-ROM, do as it requests. When it is done, click Finish and you’ll have your very own DNS server.

Source:tech-recipes.com

Friday, September 26, 2008

Boost Email Deliverability With a Static IP Address

DNS stands for Domain Name System, which is basically the protocol computers use to connect to each other across the web. If you sent an email to "JaneDoe@AnySite.com" your mail server would do a DNS lookup on "AnySite.com" so it would know to actually send your message to the mail server at "123.45.67.890". That mail server would then route your message to its user named "JaneDoe". DNS works both ways - the receiving email server has an IP number and the sending email server has an IP number. Until a few years ago, the IP address of the sending email server wasn't all that important. But, with the onslaught of spam, all that has changed.

Today, most mail servers will check the IP address of the sending server before accepting the message, to see if the mail is coming from a static or dynamic IP address. The receiving mail server performs a reverse DNS lookup - it checks the IP address that the email is coming from to make sure that address belongs to the sending mail server.

If an email message is claiming to be from "YourCompany.com" the receiving mail server will make sure the IP address does indeed belong to YourCompany.com. It's easy to check this when the sending IP address is a static one. A static IP address belongs to one particular computer and the address always stays the same.

However, a dynamic IP address changes every time the computer connects to a network or the web. It's not possible to perform a reverse DNS lookup on a dynamic IP address. Dynamic IP addresses are used by individuals with dial-up or DSL accounts on personal computers. Unfortunately, they are also used by spammers. So if a bulk of mail is coming from a dynamic IP address, there's a good chance the mail will be sent immediately to the spam folder.

If you're sending your marketing messages directly from your own computer using the email configuration provided by your internet service provider, you're probably using a dynamic IP address with no reverse DNS lookup. Now, this isn't a problem if you're sending one-off messages to Aunt Betty, but it does become a problem if you're sending a bulk email to your entire client database. If you're using a from address like "JoeSmith@YourCompany.com", since the dynamic IP address assigned by your ISP does not belong to "YourCompany.com", there's a good chance your message will be rejected.

You might think you can resolve this issue simply by using "JoeSmith@YourISP.com" as your from address; unfortunately, this doesn't always work either. In an effort to protect their users from unwanted spam, ISPs treat bulk email differently than they do individual messages. And, since the sending IP address is still a dynamic one, there's a good chance your message will still end up in the spam folder.

The best thing to do is to ensure that your website's DNS entry is complete and is capable of a reverse lookup. Then use your webhost's email server to send all your marketing messages. Check with your web hosting company's technical department to verify that your website and its corresponding email server are both using static IP addresses with complete DNS entries. And while you're at it, ask them to set up an SPF record for your domain.

Using complete DNS entries will not guarantee that your email is delivered 100% of the time, since there are still many more issues that affect deliverability. But it's one step toward reducing the likelihood that your email will be mistaken as spam.

Time to implement: this shouldn't require more than a fast phone to your webhost's technical department. If you've been your ISP's mail configuration, your webhost can walk you through the correct steps for setting up your email client to use your host email server

Sunday, August 31, 2008

iYogi Computer Repair, PC Repair Support Video

Monday, August 4, 2008

MintDNS 2006 Tutorials

MintDNS 2006 is a fully featured server suite that allows you to run your own enterprise level DDNS Server.

Supporting both Dynamic and Static DNS MintDNS also supports several standard update protocols. Which enables support for many existing third party IP address update clients, and many hardware(Firmware) clients. This allows you to provide time tested reliable Dynamic DNS services to most all internet connected computers, or even remote cameras.

MintDNS is completely template based, so the look and feel of your DNS service can easily be adapted to match your existing website or modified to suite your specific needs.

We have provided Dynamic DNS solutions for more than 5 years. MintDNS 2006 Enterprise is our latest product and is also the most dependable, feature rich and scaleable product we have ever offered.

If your interested in custom development you may like to know that MintDNS is almost completely open sourced allowing you to easily expand on the existing system to meet any special needs your company may have. The advantage to having an established time tested platform to build on could save months of development time.

The all new web based administration console gives you instant access to advanced user management features, statistics charts, accounting features and complete control over server settings.