Interesting Scenario today, spent most of the day trying to hook a Juniper EX 2300 into Windows Server NPS to secure the command line. This was overly complicated for some reason, and we couldn't get RADIUS packets to reach our NPS box. There's not much clear information out there in regard to this, especially on the NPS side of things, after many hours googling and trying multiple methods, this is what got it working. so hopefully for you Juniper fans out there this may help.
You have a working Active Directory Domain Controller
You have a NPS server with Network Policy Server Role Installed (Mine is VLAN 100 192.168.100.21/24)
Admin access to your switching CLI
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.4) with access via SSH.
If your NPS sits on a separate VLAN to your switch management (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)
- 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 its 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:
We are going to create a network policy called "Switch_MGMT" that will allow connections to the switch Command line/GUI IF we are members of the "SG Switch_Admins" Security Group in Active Directory. See the security group I have created in AD below:
We added a Switch_Admin user account to the security group. This will be the account we log into the switch with via SSH
On the first page of our Network Policy in NPS we will name the policy "Switch_MGMT", 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 security group we created above called "SG Switch_Access". 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 MSChapV2
Finally, we need to add what's called a RADIUS VSA (Vendor Specific Attribute), these vary from vendor to vendor for Juniper see this article:
The values we care about are:
Vendor Code = 2636
Attribute = 1
format = String
If we lookup VSA 1 for juniper we get the following:
What this actually does is map our "Switch_Admin" account in AD to a template account on the switch called "remote" which is a default template. We will give this remote user account Super-User privileges when we configure the switch. You can create another user account which I will also quickly go through in the relevant section. **If you do this you will need to change your Value to the account name you created!
Save your Policy and we will move onto the RADIUS CLIENT setup on the NPS.
Configure RADIUS clients in NPS
The RADIUS client is your switch IP (192.168.200.4). 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 "Password1" 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. Please change this in production!
Configure the Switch for RADIUS
The final phase required is to actually configure the switch.
##Use RADIUS but fail back to local password if NPS is non-contactable set system authentication order [radius password] ##Set NPS IP secret password used for NPS Client and the source address RADIUS packets will be coming from (This switch) set system radius-server 192.168.100.21 secret Password1 source-address 192.168.200.4 ##Set Authentication Protocol to MSCHAP-V2 to match NPS set system radius-options password-protocol mschap-v2 ##Apparently by default Juniper will try to use the last IP entered on an interface to contact RADIUS this apparently forces it to use the correct interface. not verified this. set system radius-options attributes nas-ip-address 192.168.200.4 ##Set the default remote template to a super-user set system login user remote uid 2001 class super-user ##example setting another user with Read only set system login bob class Read-only
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 if 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 "Switch_Admin" that is a member of our "SG Switch_Access" Security group.
That should give you all the information required to make a connection from the Juniper to NPS. If this helped you, please leave a like. Have any comments? leave them below and I will get back to you as soon as possible. Thanks for reading.