Tag Archives: dhcp

Error: DHCP: Credentials for DNS update should be configured if secure dynamic DNS update is enabled and the domain controller is on the same host as the DHCP server.

Symptom: In Windows Server 2008, Windows Server 2008 R2, Windows Server 2012, and Windows Server 2012 R2 you receive the following Warning when running the Microsoft Best Practices Analyzer.

Severity: Error
DHCP: Credentials for DNS update should be configured if secure dynamic DNS update is enabled and the domain controller is on the same host as the DHCP server.
BPA - Error DHCP Credentials for DNS update should be configured if secure dynamic DNS update is enabled and the domain controller is on the same host as the DHCP server

What does this mean?

If you have the DHCP service installed on your domain controller without a service account configured, by default, DNS registrations from DHCP clients will be prevented from being registered and will log event 1056 in event viewer.

Solution: Complete the following steps below to change the credentials of the service account used for DHCP.

  1. Before beginning, make sure you have a service account you can use to set the DHCP Server to run as.  This account should be a domain account (not a local account) and should not have any fancy privileges (standard user account, not an administrator).
  2. Open up Server Manager
    Server 2012 R2 - Server Manager
  3. Click Tools and select DHCP
    Server Manager - Tools - DHCP
  4. Expand your DHCP server and right click on the IPv4 service and select Properties
    DHCP - IPv4 - Properties
  5. Select the Advanced tab and then click the Credentials… button
    DHCP - IPv4 Properties - Advanced - Credentials...
  6. Enter in the User name, domain, password, and confirmation password to the user and click OK
    DNS dynamic update credentials
  7. Click OK on the IPv4 Properties screen
  8. Repeat this step on each of the DHCP servers in your domain.  It is recommended to use the same service account on each of the machines.

Notes: The official KB article from Microsoft on this subject can be found here: http://technet.microsoft.com/en-us/library/ee941181(v=ws.10).aspx
Another very good Technet article written by karammasri on this subject can be found here: http://blogs.technet.com/b/stdqry/archive/2012/04/03/dhcp-server-in-dcs-and-dns-registrations.aspx

Configuring DHCP Failover for Server 2012 R2

In this tutorial, we will implement one of Server 2012’s newest features, DHCP Failover.  Before Server 2012, DHCP failover was achieved through Windows Failover Cluster. Now, Server 2012 has native tools built into the DHCP role to support failover without the need to setup clustering services.  It is nice to note that DHCP failover is fully supported in all server editions of Windows Server 2012 (Foundation, Standard, Data Center), allowing everyone to provide this role in high availability.

Before beginning, this tutorial assumes the following prerequisites to this tutorial:

  • Two Server 2012 servers have been installed and joined to your domain as member servers
  • Both servers have installed the DHCP role
  • One of the servers has been configured with your desired DHCP scopes
  1. Login to your primary DHCP server that has been configured with the DHCP scopes
  2. Open up the DHCP program
    1. Launch Server Manager
      Server 2012 R2 - Server Manager
    2. Click Tools->DHCP
      Server Manager - Tools - DHCP
    3. Expand your DHCP server and right click on IPv4 and select Configure Failover…
      DHCP - IPv4 - Configure Failover
    4. On the Introduction to DHCP Failover page, click Next to allow failover of all DHCP scopes.
      Optionally, uncheck Select all and select the specific scopes you would like to allow to failover and then click Next.
      Configure Failover - Introduction to DHCP Failover
    5. Click on the Add Server button
      Configure Failover - Specify the partner server to use for failover - Add Server
    6. Check This authorized DHCP server, select the server you would like to use to allow failover, and then click OK
      Configure Failover - Specify the partner server to use for failover - Add Server - Authorized DHCP server
    7. Click Next
      Configure Failover - Specify the partner server to use for failover - Partner Server
    8. Enter in the settings you wish to use and then click Next.  I would recommend entering a Shared Secret and checking the State Switchover Interval to failover in the event a server fails unexpectedly.
      Notes:
      If you are failing over to another DHCP server on the same subnet, it is recommended to setup loadbalancing.  If you are failing over your DHCP server to another network, set the mode to Hot standby.  Additionally, here is a list with more indepth details on what each option does.

      • Relationship Name: Descriptive name to describe this DHCP Failover relationship.  This can be named anything to help you understand the server relationship.
      • Maximum Client Lead Time: Specifies the amount of time for which a DHCP lease may be renewed by either failover peer without contacting the other.  It also specifies the amount of time that either DHCP server will wait in a “partner down” state before assuming control of the entire IP address range within the scope.  ( default = 1 hour ).
      • Mode: Select Load Balance ( default – Active / Active ) or Hot Standby ( Active / Passive )
      • Load Balance Percentage: Specifies the percentage of the IP Address range to reserve for each server in the failover relationship.  Each server will use their assigned range of addresses prior to assuming control over the entire IP Address range of a scope when the other server transitions into a “partner down” state and the Maximum Client Lead Time ( specified above ) passes.
      • Auto State Switchover Interval: When selected, specifies the amount of time that elapses before a DHCP Server is automatically transitioned to a “partner down” state when network communication is interrupted to a DHCP Server.  If this option is unchecked, an administrator must manually transition the status of a DHCP Server into a “partner down” state using the DHCP Management console or PowerShell. ( when checked, the default = 60 minutes )
      • Enable Message Authentication: check this checkbox option to enable authentication of failover replication traffic between servers
      • Shared Secret:  Type a “Shared Secret” ( ie., a Password ) to be used to authenticate the failover connection between servers

      Configure Failover - Create a new failover relationship

    9. Click Finish
      Configure Failover - Summary
    10. Click Close on the results dialog, confirming the failover configuration was properly setup.
      Configure Failover - Progress of failover configuration
    11. Optionally, you can login to your secondary DHCP server to confirm failover has successfully been setup.
      1. On the secondary DHCP server, right click on one of your DHCP scopes and select Properties
        DHCP - IPv4 - Scope - Properties
      2. Select the Failover tab and you should see your failover settings in effect.
        DHCP - Scope Properties

That’s all that’s to it!  Hurray for high availability! 🙂

Notes:

Descriptions of each of the failover options were found on the following technet article: http://blogs.technet.com/b/keithmayer/archive/2012/10/28/step-by-step-scoping-out-the-new-dhcp-failover-in-windows-server-2012-31-days-of-favorite-features-part-28-of-31.aspx

An offial Microsoft KB article on configuring DHCP failover can be found here: http://technet.microsoft.com/en-us/library/hh831385.aspx

Migrate DHCP Role from Server 2008 R2 to Server 2012 R2

After doing a quick google search, it appears you can easily migrate your DHCP server as long as you have both your current DHCP server (running Server 2008 R2) and a new Windows Server 2012 server you are going to designate as a DHCP server.

  1. Login to your new Server 2012 R2 machine with the DHCP role installed
  2. Open up a Powershell shell
    Server 2012 - Powershell
  3. Execute the following command to export the configuration from the Server 2008 R2 DHCP Server
    1. Export-DhcpServer –ComputerName win2k8r2-dhcp.corp.contoso.com -Leases -File c:\users\yourusername\Desktop\dhcpexp.xml -verbose
      Export-DhcpServer Server 2012
  4. Execute the following command to import the configuration into your new Server 2012 R2 DHCP Server; must be an Administrator running this PowerShell command.
    1. Import-DhcpServer –ComputerName win2k12r2.corp.contoso.com -Leases –File C:\users\yourusername\Desktop\dhcpexp.xml -BackupPath C:\users\yourusername\Desktop\backup\ -Verbose

Notes: Credit goes to the following technet article for the powershell commands and a more in-depth explanation: http://blogs.technet.com/b/teamdhcp/archive/2012/09/11/migrating-existing-dhcp-server-deployment-to-windows-server-2012-dhcp-failover.aspx

Attempt to configure DHCP server failed with error code 0x8007005. Access is denied.

Symptoms:

When trying to deploy DHCP on a member server (not a DC), you receive the following error:

Attempt to configure DHCP server failed with error code 0x8007005. Access is denied.

DHCP Error 0x8007005

When you go to Authorize the server you receive “Access Denied” as well.

Solution:

This is caused by permission issues on the user’s account.  To fix this, first right click on IPv4 and then select Properties.  Click on the Advanced tab and then click on Credentials.  Inside of here, enter in the credentials you want to use as the service account to run DHCP.

DHCP Credentials

Next, open up Server Manager, expand Configuration, expand Local Users and Groups.  Click on DHCPAdministrators, and then add your service account.

DHCP Administrators group

Next, restart the DHCP Server service.  Inside of server manager, right click on the DHCP server and click Authorize.  Restart the service one last time, and each of your DHCP scopes should now be up (with green checkmarks).

 

 

Site to Site VPN via two Sonicwall firewalls – With DHCP over VPN

Introduction: This document shows an example of how to configure a VPN tunnel between 2 SonicWALL firewalls, one running SonicOS Enhanced at the main site (central site) and the other one running SonicOS standard at the remote site. Remote PC’s located behind the SonicWALL appliance on the remote site will obtain IP addresses automatically from a DHCP server located on the LAN zone of the Enhanced unit.

Versions Used: SonicWALL recommends using the latest firmware version on the units. On this document this feature has been tested on SonicOS Enhanced 5.6.0.11-61o and SonicOS Enhanced 4.2.1.0-20e.  SonicWALL’s original document, which can be found here, shows support for this configuration on SonicOS Enhanced 3.0.0.4-21e and SonicOS Standard 3.0.0.1-28s. Please note that SonicOS Enhanced runs on TZ170, PRO2040, PRO3060, PRO 4060, Pro 5060 models, and NSA 3500. SonicOS Standard only runs on the TZ 150, TZ170, PRO2040, and PRO3060 models. Customers with current service/software support contracts can obtain updated versions of SonicWALL firmware from the MySonicWALL customer portal at https://www.mysonicwall.com. Updated firmware is also freely available to customers who have registered the SonicWALL device on MySonicWALL for the first 90 days.

Network Topology: VPN Network Topology

Prerequisites: This guide assumes the following:

  • DHCP Server is up and running on the Central Site
  • The DHCP Server is in the LAN Zone
  • WAN Interfaces have been configured properly for internet access at both the remote and central site

Task List:

  • Configurations at the central site:
    • Set Firewall Unique Identifier
    • Add and configure a VPN policy 
    • Configure DHCP over VPN 
  • Configurations at the remote site: 
    • Set Firewall Unique Identifier
    • Add and configure a VPN policy 
    • Configure DHCP over VPN 
  • Testing
    • Verify that the VPN tunnel comes up
    • Verify that the DHCP client at the remote site obtains an IP address
    • Verify that traffic flows correctly between the sites
    • Verify that the DHCP client has access to its own network

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ SonicWALL Central Site Configuration

  1. Login to your SonicWALL at the Central Site
  2. Click on VPN->Settings
  3. In the Unique Firewall Identifier box, enter CentralSite and click Apply
    1. VPN-Settings-CentralSite
  4. On the VPN->Settings page, click the Add… button
    1. Use the configuration below:
      1. General Tab
        1. Policy Type: Site to Site
        2. Authentication Method: IKE using Preshared Secret
        3. Name: RemoteSite
        4. IPsec Primary Gateway Name or Address: yourwanipaddressoftheremotesite
        5. IPsec Secondary Gateway Name or Address: Leave this blank
        6. Shared Secret: Enter a good long password here!
        7. Confirm Shared Secret: Enter the same good long password you used above!
        8. Local IKE ID and Peer IKE ID: Leave these settings their default values
        9. CentralSite-General
      2. Network Tab
        1. Local Networks: Select Choose local network from list and select LAN Subnets
        2. Remote Networks: Select Destination network obtains IP addresses using DHCP through this VPN tunnel
        3. CentralSite-Network
      3. Proposals Tab
        1. IKE (Phase 1) Proposal
          1. Exchange: Main Mode
          2. DH Group: Group 2
          3. Encryption: AES-256
          4. Authentication: SHA1
          5. Life Time (seconds): 28800
        2. IKE (Phase 2) Proposal
          1. Protocol: ESP
          2. Encryption: AES-256
          3. Authentication: SHA1
          4. Enable Perfect Forward Secrecy: unchecked
          5. Life Time (seconds): 28800
        3. CentralSite-Proposals
      4. Advanced Tab
        1. Enable Keep Alive: this should be unchecked and grayed out
        2. Suppress automatic Access Rules creation for VPN Policy: unchecked
        3. Require authentication of VPN clients by XAUTH: unchecked
        4. Enable Windows Networking (NetBIOS) Broadcast: unchecked
        5. Enable Multicast: unchecked
        6. Apply NAT Policies: unchecked
        7. Management via this SA: all options unchecked
        8. User login via this SA: all options unchecked
        9. Defualt LAN Gateway (optional): 0.0.0.0
        10. VPN Policy bound to: Zone WAN
        11. CentralSite-Advanced
  5. Click OK
  6. Click on VPN->DHCP over VPN
    1. Select Central Gateway from the dropdown and click the Configure… button
      1. CentralSite-DHCPoverVPN
    2. Click on the Add… button and then type in the IP address of your DHCP server at the CentralSite.
      1. CentralSite-DHCPConfig
    3. Click OK

SonicWALL Remote Site Configuration

  1. Login to your SonicWALL at the remote site
  2. Click on VPN->Settings
  3. In the Unique Firewall Identifier box, enter RemoteSite and click Apply
    1. RemoteSite
  4. On the VPN->Settings page, click the Add… button
    1. Use the configuration below:
      1. General Tab
        1. Authentication Method: IKE using Preshared Secret
        2. Name: CentralSite
        3. IPsec Primary Gateway Name or Address: yourwanipaddressofthecentralsite
        4. IPsec Secondary Gateway Name or Address: Leave this blank
        5. Shared Secret: Use the same secret as the CentralSite
        6. Confirm Shared Secret: Use the same password as the CentralSite
        7. Local IKE ID and Peer IKE ID: Leave these settings their default values
        8. RemoteSite-General
      2. Network Tab
        1. Local Networks: Select Local network obtains IP addresses using DHCP through this VPN Tunnel
        2. Remote Networks: Select Create new address object
          1. Enter in your CentralSite’s LAN information (this will be the network you pull DHCP IPs from.
            1. CentralSite-LAN Config
        3. On the Choose destination network from list, you can now select CentralSite LAN
          1. RemoteSite-Network
      3. Proposals Tab
        1. IKE (Phase 1) Proposal
          1. Exchange: Main Mode
          2. DH Group: Group 2
          3. Encryption: AES-256
          4. Authentication: SHA1
          5. Life Time (seconds): 28800
        2. IKE (Phase 2) Proposal
          1. Protocol: ESP
          2. Encryption: AES-256
          3. Authentication: SHA1
          4. Enable Perfect Forward Secrecy: unchecked
          5. Life Time (seconds): 28800
        3. RemoteSite-Proposals
      4. Advanced Tab
        1. Enable Keep Alive: check this option if it is not grayed out
        2. Suppress automatic Access Rules creation for VPN Policy: unchecked
        3. Require authentication of VPN clients by XAUTH: unchecked
        4. Enable Windows Networking (NetBIOS) Broadcast: unchecked
        5. Enable Multicast: unchecked
        6. Apply NAT Policies: unchecked
        7. Management via this SA: all options unchecked
        8. User login via this SA: all options unchecked
        9. Defualt LAN Gateway (optional): 0.0.0.0
        10. VPN Policy bound to: Zone WAN
        11. RemoteSite-Advanced
  5. Click OK

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Testing/Verification

  1. Open up one of the SonicWALL devices (either Central or Remote) and head over to VPN->Settings
    1. You should see a green dot indicating the connection is active.  Additionally, at the bottom of the same page, you can see the “Current Active VPN Tunnels”.  You should see the tunnel has been established their as well.
      1. Active Connection
    2. Active connections from the RemoteSite’s SonicWALL
      1. Active VPN Tunnels
  2. Next, head over to a workstation on the RemoteSite’s network.
    1. Type ipconfig /release on the workstation
    2. Type ipconfig /renew on the workstation
    3. Type ipconfig and verify the IP address is in the correct range from the Central Site.
  3. On the CentralSite’s SonicWALL, go to VPN->DHCP over VPN
    1. Under Current DHCP over VPN Leases, you should see your client
  4. Try to ping a server at the CentralSite, you should receive a successful reply.

Setting Static IP in Linux

To setup a static IP in ubuntu, edit your networking settings file.

Here is an example of how to do it:

Open /etc/network/interfaces:

Use these configurations:


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
address 192.168.0.10
network 192.168.0.0
netmask 255.255.255.0
broadcast 192.168.0.255
gateway 192.168.0.1

DHCP Address Configuration:


auto lo
iface lo inet loopback

auto eth0
iface eth0 inet dhcp

Then restart the service: /etc/init.d/networking restart (Make sure you are running with admin privileges when restarting 🙂 )