Changing DHCP scopes with zero downtime for your users

Changing scopes for user PCs with no downtime is easier than you may think.

Process;

• Find devices with static IPs within the current scope
• Create new DHCP scope
• Configure the gateway device
• Deactivating the old scope

---

Find devices with static IPs within the current scope

You will need to locate all the devices with static IP and make plans to port them to the new scheme.

There are many tools that you can use but I would recommend Lansweeper, use the free trial or even purchase a 12 month subscription…it will be worth the cost.

Once you find devices with static IPs, make your plan to move them to the new scheme.

---

Create new DHCP scope

Open the DHCP MMC and create your new scope, remember to match any extra options that is configured in the existing scope and any exclusions that need to be configured.

Right click on the DHCP server within the MMC and select Create Superscope, within the wizard give the superscope a name and select the current and new scopes (ctrl+mouse click).

This will join the two scopes into the superscope and make sure the new scope is deactivated.

---

Configure the gateway device

We use Hewlett Packard Procurve L2/L3 switches which don’t have the option of using a secondary IP address on a VLAN.

This creates an issue that the lowest IP address configured on the VLAN interface is the one that will be used as the source IP when connecting to the IP Helper (DHCP server).  Take a look at the following VLAN configuration, devices will get an IP from the 192.168.36.0 scope and NOT 192.168.80.0 scope as the 36 scheme is the lowest IP on the interface.

vlan 80
	Name Users
	ip helper 192.168.1.10
	ip address 192.168.36.0 255.255.255.0
	ip address 192.168.80.0 255.255.255.0
	exit

Knowing this, if the new scheme is LOWER than the current one, the new scheme will be used as soon as it’s configured on the VLAN – reason why you should make sure the scope is deactivated.

At this point you can test by using a statically assigned IP to a device to make sure the new scheme works as expected.

---

Deactivating the old scope

Before you can deactivate the old scope, you need to activate the new one…remember if the new scope is LOWER it will be used straight away.

If the new scope is higher, you need to deactivate the old one before it will be used.  Once deactivated keep an eye on the allocations for the new scope and once some IPs have been allocated make some checks to make sure all is ok.

Once you’re confident all is ok, you can force the move of devices to the new scope quicker by deleting all the allocated addresses on the old scope.

A device using DHCP will request an extension to the allocated address three times before it asks for a new address;

1. After 50% of the lease time – on an 8 day lease, the device will ask for an extension after 4 days
2. After 87.5% of the lease time – on an 8 day lease, it will request a renewal after another 3 days
3. The last request is at 100% and will send out a new address request for any available DHCP server

As you can see, deleting the allocations and disabling the the old scope will speed up the transition to the new scope.

Once there are no devices on the old range, remove the scopes from the superscope and delete the old scope and the old IP address from the VLAN interface.

Dynamic VLANs with 802.1x Authentication

VLAN configuration can be a large overhead on resources making sure the right device is in the right VLAN.

Constantly re-configuring switches trying to keep on top of users moving their PCs.

With dynamic VLANs that task can (almost) be a thing of the past.

Steps required;

1. Build RADIUS server
2. Configure RADIUS server
   1. Add a RADIUS Client
   2. Create Connection Request Policy
   3. Create Network Policy
3. Configure switch
4. Active Directory configuration
5. PC Configuration
6. Debugging

---

1. – BUILD RADIUS SERVER

Check out step 1 of my previous post titled HP Procurve with RADIUS authentication using NPS

---

2. – BUILD RADIUS SERVER

2.1 – Add a RADIUS Client

Check out step 2 of my previous post titled HP Procurve with RADIUS authentication using NPS

---

2.2 – Create Connection Request Policy

Open Network Policy application and expand Policies and right click on Connection Request Policies then click ‘New’.
Configure the Connection Request Policy (CRP) as;

Conditions;

• NAS port type = Ethernet

Settings;

• Authentication Provider = Local Computer
• 

---

2.3 – Create Network Policy

Network Policy (NP) as;

Conditions;

• NAS Port Type = Ethernet
• Windows Groups = Domain\SecurityGroup
  • The SecurityGroup is a security group containing the devices for this specific VLAN
  • Call it something meaningful eg VLAN64

Settings;

• Extensible Authentication Protocol Configuration = Configured
• Ignore User Dial-in Properties = True
• Access Permission = Grant Access
• Extensible Authentication Protocol Method = Microsoft Protected EAP (PEAP)
• Authentication Method = EAP OR MS-CHAP v2 OR MS-CHAP v2
• NAP Enforcement = Allow full network access
• Framed-Protocol = PPP
• Service-Type = Framed
• Tunnel-Medium-Type = 802
• Tunnel-Pvt-Group-ID = <VLAN-Number>
• Tunnel-Type = Virtual LANs (VLAN)

When need to create other policies for different VLANS, you can duplicate your first CP and change the name, Windows Group & Tunnel-Pvt-Group-ID to match the VLAN you need to use.

---

3. – Configure Switch

Add the radius server and key you used in step 2
radius-server host <NPS ServerIP> key XXXXXXXXXXXXXXXXXXXXX

aaa authentication port-access eap-radius

Configure which ports will be used
aaa port-access authenticator <PortList>

eg
aaa port-access authenticator A1-A13,A20-A24,C1-C24

Configure the ports that can use the Guest VLAN – this can be the same port list as above
aaa port-access authenticator <PortList> unauth-vid <GuestVLANID>

nb: You can use a guest VLAN for devices that fail the NPS policies, this VLAN can have an access control list or you can have a firewall interface as the gateway for better control.

Acticate the dynamic VLAN configuration
aaa port-access authenticator active

Add the VLANs that will be used
vlan <VLANID>
tag <UplinkPorts>
name “VLAN Name”
exit

Configure a GUEST VLAN
vlan <GuestVLANID>
tag <UplinkPorts>
name “Guest VLAN”
exit

---

4. – Active Directory configuration

Within the example NP above I added DOMAIN\VLAN64 as the Windows Group, create a security group within Active Directory called VLAN64 and add all the PCs to that group.

When the PCs in that group connect to a configured switch port, the VLAN should be changed as per the Connection Policy Tunnel-Pvt-Group-ID setting.

For none-domain PCs, eg printers, create a user account and set the Display Name as the host name but the username & password must be the MAC address of the device without any colons or dashes eg 11AA22BB33CC44DD and add that account to the VLAN group as with domain PCs.

---

 

5. – PC Configuration

Make sure the Wired AutoConfig service is set to Automatic.

Go to the network adapter properties and select the Authentication tab, make sure the following is set;

• Enable IEEE 802.1X authentication is selected
• Microsoft Protected EAP is selected
• On the Additional Settings specify Computer authentication

To be continued…

HP Procurve with RADIUS authentication using NPS

The two main chassis I used are from Hewlett Packard which are;

HP Procurve 5406 – J9823A	HP Procurve 5412 – J9532A

Steps required;

1. Build RADIUS server
2. Configure RADIUS server
   1. Add a RADIUS Client
   2. Create Connection Request Policy
   3. Create Network Policy
3. Configure switch.
4. Debugging

---

1. – BUILD RADIUS SERVER

For the server we use Windows 2008 R2

Go to Administrative Tools –> Server Manager, make sure the Roles is selected to the left and click on Add Roles from the far right.

Select the Network Policy and Access Services role and click Next

Select the Network Policy Server role, the other role services are not required

Click next through the option boxes to complete the install.

---

2. – CONFIGURE RADIUS SERVER

2.1 – Add a RADIUS client

Open Network Policy Server from the administrative tools and expand RADIUS Clients and Servers and right click on RADIUS Clients –> New

When you create the key, you need to make a note of it as this will be needed for the switch configuration later.

Be aware that if using an IP range for the RADIUS client, you must use bitmask – how many BITS in the network address.  In this case 24, which would be equivalent to a subnet mask of 255.255.255.0

---

2.2 – Create Connection Request Policy

Expand Policies and right click on Connection Request Policy then click ‘New’.
Configure the Connection Request Policy (CRP) as;

Conditions;

• NAS IPv4 Address = Switch management address range, eg 192.168.3.*

Settings;

• Authentication Provider = Local Computer
• Override Authentication = Disabled

Just to confuse people, the NAS IPv4 address should use a wildcard for a range of IPs and not a bitmask as you did when you created the RADIUS client.

---

2.3 – Create Network Policy

Network Policy (NP) as;

Conditions;

• Authentication Type = PAP
• User Groups = The domain user group, eg CIFT\IT

Settings;

• Extended State = <blank>
• Access Permission = Grant Access
• Authentication Method = Unencrypted Authentication (PAP, SPAP)
• NAP Enforcement = Allow full network access
• Framed-Protocol = PPP
• Service-Type = Administrative

---

3. – Switch Configuration

Add the radius server and key
radius-server host <NPS ServerIP> key <SecretKey>

Disable telnet and Web access
no telnet-server
no web-management

Once authenticated, go straight to privilege/enable mode
aaa authentication login privilege-mode

Set the console and SSH authentication order to Radius then Local
aaa authentication console login radius local
aaa authentication console enable radius local
aaa authentication ssh login radius local
aaa authentication ssh enable radius local

Set a local manager password to use when Radius server is unavailable
password manager user admin plaintext
<LocalAdminPassword>

Be aware that LOCAL authentication will only be used if the radius server does not respond and it will take several failed attempts to contact the server before you get a local authentication prompt.

---

4 – Debugging

To see all the authentication attempts from the RADIUS clients on the NPS server, open Event viewer and go to Custom Views –> Server Roles –> Network Policy and Access Server

Clicking on one of the events will display information similar to the following;

This is split up into sections;

• User – The username used to authentication with the NPS server
• Client Machine – The hardware address of the device the user was using, not used as you’re authenticating directly from the RADIUS client and not from a PC that forwards to the client, that forwards it to the NPS server
• NAS – The device the authentication request is coming from, in this example, the 5406 switch
• Radius Client – The configured RADIUS client being used
• Authentication Details – Which Connection Request & Network policies being used

A failed authentication would display no Network Policy Name – As long as you’ve disabled the default policies after installing the NPS role.

From my example configuration you can see how it matches the event output;

The RADIUS client is called NET-DEVICES (using IP range 192.168.3.0/24), but the event will show the IP of the device, not the configured client range…far more useful.

The Authentication Details show the CRP & NP being used, (to keep it simple I’ve called them the same NET-DEVICES) authentication server (useful if you forward events to another server) and authentication type.