I have been involved with a number of Aruba switching roll-outs over the past few years and it still amazes me to this day how network security is either non existent or seriously lacking in companies.

When using SSH to manage a switch or network device most tend to use a secure password and as you should know SSH encrypts the CLI session, unlike Telnet that can expose these passwords in clear text rendering any password you use ineffective.

We are going to kick this up a notch and lock our CLI down to a Network Administrators security group in Active Directory where authentication will be passed from the switch via Windows Server Network Policy Server (NPS).

Assumptions:

• You have a working Active Directory Domain Controller

• You have a NPS server (Mines 192.168.200.1) with Network Policy Server Role Installed

• Admin access to your switching

• A Switch SVI to reach the switch on MGMT VLAN or OOB Management port (My case the switch management is VLAN 200 (192.168.200.10) with access via SSH.

If your NPS sits on a separate VLAN to your switch management (NOT my case) make sure you have inter-VLAN routing enabled

If you have a firewall in-between, make sure you have relevant access and firewall rules to allow NPS ports (1812 authentication/ 1813 Accounting)

Objectives:

• Configure NPS Network Policy

• Configure RADIUS clients in NPS

• Configure or switch via the CLI for RADIUS Auth

Configure NPS Network Policy

When authentication is passed to the NPS server by a valid RADIUS client, NPS evaluates the login against it's network policies. Here we can define connection conditions such as security group etc that determine if we are allowed or disallowed access. (This just scratches the surface).

For more info on NPS check out Microsoft's Documentation:
docs.microsoft.com/en-us/windows-server/net..

We are going to create a network policy called "ArubaOS-Management" that will allow connections to the switch Command line/GUI IF we are members of the Network Admins Security Group in Active Directory. See the security group I have created in AD below:

On the first page of our Network Policy in NPS we will name the policy "ArubaOS-Management", Secondly, we obviously want this policy to GRANT access and ignore the users remote dial in attributes that may exist on their AD profile.

On the second page of our policy we actually stipulate what conditions are evaluated as part of our GRANT access. Here we are going to select a windows group called "Network Administrators". There are many conditions you can pick if you wish to harden your security posture further. We will keep things simple for this demo.

Encryption under Constraints tab we are going to select no encryption PAP/sPAP

Finally, we need to add a Radius Standard on the settings tab.

Configure RADIUS clients in NPS

The RADIUS client is our switch (192.168.200.10). It is also common to see Access Points as RADIUS Clients to authenticate users on corporate WiFi and 802.1x implementations (way beyond the scope of this article). We will add this switch as a RADIUS client in NPS and give it a secret of "SecretKey" this key will need to match our configuration on the switch CLI when we setup the radius settings for it to be able to initiate a connection with NPS.

Configure the Switch for RADIUS

The final phase required is to actually configure the switch.

• We will disable the clear text protocol telnet to force connections via SSH/GUI

• We will then tell our switch how to reach our NPS box via its IP and the secret key we created for it to authenticate with the server.

• Because Aruba switches have a GUI we also want to lock this down to Network Admins only like our CLI.

The following CLI commands show how to achieve the above:

###Disable Telnet###
2930f-SW1(config)# no telnet-server

###define RADIUS Server IP (NPS) and secret key###
2930f-SW1(config)# radius-server host 192.168.200.1 key SecretKey

###define AAA settings to lock down WEB GUI and SSH CLI to radius authentication IF this fails failback to localDB login.###
2930f-SW1(config)# aaa authentication web login radius local
2930f-SW1(config)# aaa authentication ssh login radius local

###When authenticated put us directly in priviledge-mode###
2930f-SW1(config)# aaa authentication login priviledge-mode

to prevent locking yourself out of the switch we allow fallback to login with localDB account on the switch. This will only fail back if the Switch is unable to communicate with the NPS server. If a connection can be made but there is another error you will not be forced to use local login. Bear this in mind for testing purposes.

Talking of locking yourself out, I have done this a number of times where I have not verified my CLI commands, logged out of the switch, then can't get back in (this can easily happen with your radius key). TEST your config by keeping your current SSH session open, then create a new SSH session and making sure you can actually log in with your Active Directory credentials. If you cannot, you can use your existing session to remove your radius config or troubleshoot the commands you have issued to fix the issue!

With this setup we can login into our CLI with our Active Directory account that is a member of our Network Admins Security group. Below I created a AD user called Radius.test a member of "Network Admins" and we are authenticated and granted access to the switch.

Also if you try and create a telnet session you won't be able to as we disabled telnet!

The commands used in this demo work on ArubaOS-S switching and most older HP iterations. I completed these on both 2930F and 2930M models

Aruba also have their own product called Clear-pass Policy Manager (CPPM) which can be used instead of Windows NPS to achieve the above, however, I do find CPPM to be a lot more complex to achieve the goal but you also get other features such as Mobile Device Management (MDM) and alot more authentication features for your network stack.

Check it out here:
arubanetworks.com/resource/clearpass-policy..