Do you password protect your network devices? If so, are you using the same generic password? Wouldn’t it be awesome to leverage your Active Directory logon to sign into your switches?
In this guide, we are going to enable AD authentication on network switches and routers. The workhorse will be the Network Policy Server role in Server 2012/R2. After our server configuration, we will then configure our switches to point to our NPS (RADIUS) device and change their authentication method.
Install and Configure Network Policy Server
As a best practice, use a dedicated server to handle device authentication. In the past, I made the mistake of adding the role to a Domain Controller – this complicated by environment later.
Start the Add Roles and Features Wizard and proceed to the Server Roles screen. Expand Network Policy and Access Services and check the Network Policy Server box. Continue through the Wizard.
From the tools menu, launch the Network Policy Server MMC. For this particular use of NPS, we are going to deal with three specific sections.
The first section, RADIUS Clients, will contain a list of the devices needing to authenticate against Active Directory. The second section, Connection Request Policies, determines what devices can authenticate. The final section, Network Polices, determines who can authenticated and how it is done.
Right click on RADIUS Clients and select New. Start your Friendly Name with a prefix (ex: “SW:” for switches); then finish the name of the network device. Enter the IP address of the device. Finally, enter a shared secret (password). I prefer to use a randomly generated secret that has been cut down to 12-16 characters. Copy this secret down – you will need to configure it on your network devices.
Create a single RADIUS client (preferably within the same subnet as your NPS server as this makes testing a bit easier). Head to the Connection Request Policies section. Right click on the default rule (Use Windows Authentication for All Users) and select Disable.
Create a new policy and name it something like Network Switches with AAA. Select next and add a new condition. Scroll down to RADIUS Client Properites and select Client Friendly Name. Enter SW:? for the name. SW: is the prefix that you used earlier. ? is a wildcard. This condition will apply to any RADIUS client that has a Friendly Name starting with this prefix. Continue through the wizard by accepting the default settings.
Right click on Network Policies and select New. Give your policy a descriptive name (ex: Network Switch Authentication for Domain Admins). Select next and add a new Windows Groups condition. Members of this group will be able to login to your network switches. Add a second condition and scroll down to Authentication Type. Check PAP and press OK.
Continue until you reach the Configure Authentication Methods window. Uncheck every item but PAP and press No to the prompt. Continue until you reach the Settings window. Change Service-Type to Administrative. Finish the wizard.
One last item to configure. Right click on your new policy and move it up until it’s processing order is 1. Here is a screenshot showing the finished result:
Configuring Your Switch to Support AAA for Active Directory Authentication
Launch a telnet session to one of your switches and paste in the following configuration changes. Be sure to change the RADIUS secret to match your RADIUS client. It is listed twice in the config. You will also need to change the IP to your authenticating server.
aaa authentication console enable radius local aaa authentication telnet login radius local aaa authentication telnet enable radius local aaa authentication ssh login radius local aaa authentication ssh enable radius local aaa authentication login privilege-mode radius-server key INSERT-YOUR-SECRET-HERE radius-server host 192.168.0.2 INSERT-YOUR-SECRET-HERE auth-port 1645 acct-port 1646 radius-server host 192.168.0.2 auth-port 1645 radius-server host 192.168.0.2 acct-port 1646
This configuration should work on all HP Procurve switches. I would believe Cisco switches work just fine as well. If you use this on any other type and it works, leave a comment to let me know. The last three lines are included because some HP switches didn’t like the auth-port and acct-port parameters in the same line. Do not close this telnet window yet!
After pasting the config, launch a second telnet session to your switch. You should notice a new logon screen that prompts for a login name/login as. Login as yourself and ensure that it is successful. If so, write the config to memory and close both telnet sessions.
If you have problems, check the following:
- Do your secrets match up? If you are unsure, set both secrets (on the switch and in NPS) to test
- Is the IP correct in the config? Can you ping that IP from the switch?
- Do you have a firewall blocking ports 1645 and 1646?
on Connection Request Policies, why do i have to “Right click on the default rule (Use Windows Authentication for All Users) and select Disable.”?
NPS has a default allow rule. I prefer a default deny rule instead. That is why I disable it.
To configure a RADIUS login on a Ubiquiti networking device, use the following commands in the CLI:
configure
set system login radius-server secret
commit
save
exit
NOTE: You MUST have the SAME User name you are going to log in with from AD DS, as a User on the Ubiquiti network device (The password can be different). I don’t know why, but it’s the only it works.
PS a huge THANK YOU to the author. Helped me out a ton!
Looks like the comment section removed my brackets and the info in them…
set system login radius-server secret
should be
set system login radius-server (ip-address of NPS server) secret (your password aka key)
(IE set system login radius-server 10.0.0.10 secret IlikeFREEtacos!)
Thank you Jason for posting these steps!!
Hi,
Thanks for posting this.
We are using HP procurve switches (2650 & 5412/5406). Do you have any ‘troubleshoot’ commands for me if we can’t reach the NPS server?
From the switch, ping the server. If you can’t ping it, check firewalls at the server. Check your connection between the devices. As a best practice, you should list two authentication servers in your configs. You can sync the NPS configs by using these steps: https://deployhappiness.com/two-network-policy-server-tricks-subnets-and-syncing/
Thanks,
I have an other question, the radius authentication is working with PAP. If I change it to PEAP the switch give the output : Access denied. Do you know how I can get it work with PEAP?
The second question do you know how I can configure radius authentication voor the H3C A5120 switch?
Regards,
Roene
does PAP have to be used or can a more secure authentication method like peap be used?
If your switch will support it, you should be able to use it. After you get it to work with PAP, change the type to PEAP and test your logons.
Don’t these two lines allow the use of the telnet protocol:
aaa authentication telnet login radius local
aaa authentication telnet enable radius local
…and these two allow the use of the ssh protocol:
aaa authentication ssh login radius local
aaa authentication ssh enable radius local
If that’s the case, can’t the first two lines be chopped out to disallow the use of the telnet protocol and accept ssh connections only?
That is correct Dave! If you only want SSH access (which is a best practice), remove the two telnet lines.
In order to completely disable telnet on the switch, enter this command in config mode – no telnet-server. I would also disable TFTP client & server, which you can do with the command – no tftp (that’ll disable both the client & server).
I forgot about telnet access without radius. 🙂
Thanks for posting this Joseph. We recently moved from Cisco to HP switching so this is well timed.
Do you know of any way to have local users on the switch also work alongside RADIUS/AD users? We enable and set passwords for the default manager & operator users on all of our switches, but once I enabled RADIUS on the switch, those logins always fail.
No problem at all! I am not sure how to swap to a local user. The config in this post is set to failover to local logon (the manager/operator user) if NPS is unavailable. On HP Switches, the login will be tried four times before swapping over to the local prompt.
Thanks Joseph! I’ll check with one of the HP engineer’s we’ve been working with to see if it’s possible to have both RADIUS and local active at the same time. I don’t think it is, but it’d be nice if it’s possible.
One addition – you can use RADIUS for “operator” level users as well. In the Network Policy, the Service-Type attribute can be set to NAS Prompt to give operator access.
Thanks! That is a good tip!
Let me know what the HP engineer finds out about switching user modes.
He confirmed that the local users are only a fallback when the RADIUS server doesn’t reply. So it’s not possible to have both active, but if your switch loses access to the RADIUS server, the local logins do work correctly.
Good to know!
Isn’t telnet a plain text protocol? Doesn’t this send your password (and you’re a domain admin) in plain text across the wire? Although it’s nice to have user accounting, telnet is an inherently insecure protocol.
Can you do the same thing with ssh access to those switches?
You are right about telnet being an insecure protocol. SSH should certainly be used over telnet. That is why the switch config includes two lines:
aaa authentication ssh login radius local
aaa authentication ssh enable radius local
I am actually working on a follow-up article covering some common network security issues and how to fix them.