• Setting up AD, NPS, and RADIUS authentication using Windows NPS

Print Friendly, PDF & Email


This article will guide through setting up Network Policy Server (NPS) on a Windows Server along with Active Directory Domain Services (AD DS). In addition, this document will address the required parameters to successfully authenticate users to login into Arista switches and CVP using RADIUS.


  • Network Policy Server (NPS)This feature allows administrators to define policies for Network access authentication, authorization and accounting for wireless, authenticating switch, and remote access dial-up, and virtual private network (VPN) connections.
  • Active Directory Domain Services (AD DS) – This feature stores information of Users, computers, and other devices in the network such as credentials, groups, and domains. AD DS helps administrators securely manage this information and facilitates resource sharing and collaboration between users.

Lab Setup

For this lab, we have a Windows Server 2016 hosted on Vmware ESXi 6.7 with reachability to an Arista DUT and CVP, the setup would be the same for a Windows Server 2019.

Configuring Windows NPS and AD

  • Assuming that the Windows Server has been given an IP address and has reachability to other devices in the network, our next step would be to configure NPS and AD DS.
  • We can do it by clicking the windows icon on the taskbar and click on Server Manager.
  •  The next step would be to open the Server Manager and select “Add roles and features” from the dashboard or click on the “manage” > “Add roles and features”
  • That should open up a wizard as shown below, click on “Next”.
  • Select “Role-based and feature-based authentication” and click on “Next”.
  • Click on “select server from a server pool” and we should be able to see the server created with the right IP address.
  • Then we will be selecting the Roles that we would like configured, in this case, we would like to configure NPS and AD DS and hence, we would be selecting those roles.
  • Once we click “Next”, it would ask if we need to add any additional features, “Group Policy Management” and “Remote Server Administration Tools” would be selected by default and we can click “Next”.
  • The next few pages would explain about services that are being installed on the Server. Continue to click “Next” until we arrive at the page shown in the next step.
  • It would a list of all roles, role services, and features that are being installed on the Server. Once we confirm them we can click on “Install”.
  • This would complete the installation of features and would show up the features on the left side column of the Server Manager page.
  • We will also be able to view the features installed on the dashboard as green if they are successfully installed. Now, we will need to promote the Server to the Domain Controller as a post-deployment step for AD DS. This is done to make the server authoritative for an Active Directory domain.
  • By clicking on the “promote this server to a domain controller”, it would open a wizard where we can choose any of the provided options depending on the environment but in this case, we will be selecting  “Add a new forest” and will be typing in a root domain name.
  • After clicking “Next”, it would take us to the “Domain Controller options”. By default, the “Forest functional level” and “Domain functional level” should show the Windows Server version and then we would need to create a Directory Services Restore Mode (DSRM).  The DSRM is a function that is used to take the Server into maintenance mode especially during restoring backups of Active Directory. The password is critical and hence, it is recommended to change it at regular intervals. Anyone with local access can log in to the DC and reboot the device or modify or copy the Active Directory database. Once, the password is added, click “Next”.
  • Next, we can select DNS delegation but in our case, we do not have an authoritative parent zone, hence, we can proceed to click “Next”.
  • The next page would be for additional options, where we can add the NetBIOS domain name, it would automatically auto-populate based on what was added on Step 14.
  • It would then open a page to specify the path, in this case, we are using the default path as shown below to store the AD database.
  • Next, it would show us the options that were selected for Review, once reviewed we can proceed to click “Next”.
  • It would then proceed to perform a prerequisite check, once, done, it should read “All prerequisite check passed successfully”. We can proceed to click install.
    Please Note: This step will automatically reboot the server once the installation is complete.

Adding Users and Groups to AD

  • Once the server is rebooted and back up, open Server Manager and select “Active Directory Users and Computers” from the tool section on the top right corner.
  • Once we open it, we should see the AD created with the assigned domain name in step 14. Upon expanding it, we will see a folder named “Users”. It’s under this folder where we will be creating Usernames and passwords that would be authorized by NPS to log in to the switch.
    To do so we will right-click on “Users” > Select “New” > Select “User”
  • Once we double click on “User”, it should open up a wizard which you let us add first name, initials, last name, and full name for the user. In this case, we are creating a user named “artest1” and click “Next” as shown below:
  • Next, we will have to choose a strong password and you can choose any of the following options based on security policies. In this case for the purpose of the lab, I have chosen “Password never expires”.
  • Click on “Next”, review the username and password setting and click finish.
  • There we go!! we should have our user “artest1” in our AD as shown below:
  •  Now, we will need to add our user to a group. To do so we would follow the same step as step2. Right-click on “Users” > Select “New” > Select “Group”.
  •  A wizard would then open where we will need to provide a name for the group to be created. In this case, we have given the name “AristaTestGroup”.
  • Now we should see both the user and group in the active directory.
  • The Next Step, would be to associate the User to be part of the group. For this we need to right-click on the user > select “Add to a group” > it should open a box where we can type in the group name “AristaTestGroup” > click on “Check Names” (this would help validate the group name). Once this is done click “OK”.
  • To confirm that the user is part of the group, right-click on the user > properties > select “member of” tab on top and we should be able to see the group “AristaTestGroup” associated with the user “artest1”.
  • Before we continue with “OK”, another parameter would need to be checked i.e. if the user would be authenticated via NPS. To confirm, under the same window, select the “Dial-in” tab on top, and under “Network Access Permission”, confirm if the “Control access through NPS Network Policy” is selected.
  • Click on “Apply” followed by “OK”

RADIUS Server configuration

  • Click on “Server Manager” > “Tools” on the top right corner > Select “Network Policy Server”.
  • Under NPS (Local) > Standard configuration, we will be able to see two options, “RADIUS server for dial-up or VPN connection” and “RADIUS server for 802.1x Wireless or Wired connections. For this case, we will be using “RADIUS server for dial-up or VPN connections” and select “Configure VPN or Dial-up” below it.
  • Select “Dial-up Connections”and click”Next”.
  • Add “RADIUS clients” by selecting “Add” > Type in a friendly name “Aristaswitch” > type shared secret password (this would be configured as the “Key” under the switch configuration for RADIUS, so be sure to REMEMBER it!!) and click “OK”.
    If DNS is being used, be sure to click “Verify” to check if the DNS can resolve the hostname.
  • “Aristaswitch” should be seen under RADIUS clients as shown below and click “Next”.
  • Authentication methods can be left to default (MS-CHAPv2) and click “Next”.
  • Add user groups that the user is part of. To do so, click “Add” > type the group name “AristaTestGroup” > click on “Check Names” to verify the group > click “OK”.
  • We should now see “AristaTestGroups” added under Groups and click “Next”.
  • We can apply input/output IP filters, in this case, we have none and hence, we can continue to click “Next.
  • We can leave the encryption setting to default and click “Next”.
  • The Realm Name is a portion of the username which is used by the ISP to identify which connection requests to route to this server. In this case, we do not require a Realm Name and can continue to click “Next”.
  • It would state “You have successfully created the following policies and configured the following RADIUS clients”, then click on “Finish”.
  • Under “RADIUS clients and Servers” > RADIUS clients, we should be able to see the switch added successfully and enabled.

Configuring NPS policies

  • Expand Policies > right click on “Connection Request Policy” > “New”. These are set of conditions used to determine if the requests received from the RADIUS clients should be authenticated locally by the NPS or forwarded to other RADIUS servers (in this case NPS will be used as a RADIUS proxy).
  • Give it a Policy name as shown below and click “Next”. In this case, we have used “arista”.
  • Here we add conditions required by selecting “Add” > Select “Access Client IPv4 Address” > Specify IP address > OK
  • We should then see the client added to the conditions page as shown below and click “Next”
  • Here is where we specify if the authentication would occur locally or if needs to be redirected to a different RADIUS server. In this case, authentication is being done locally, hence, “Authenticate requests on this server” is selected as shown below.
  • Continue to click “Next” until we reach the “Finish” which should look like the following and click “Finish.
  • Next, we will be configuring the “Network Policies” where we specify which User/Group would be authorized and the conditions under which they can or cannot connect. To configure right click on “Network Policies” > select “New”
  • Give a Policy name, in this case, the name “Arista_Network_Policy” is given as shown below, and click “Next”
  • Here we add conditions as we did earlier in step 3 by selecting “Add” but we would select “User Groups” > type “AristaTestGroup” (Group created earlier) > click on “Check Names” to make sure the group is right > click “OK” twice and we should arrive at the following page.
  • Here we specify access permission where a user can be denied or granted access. In this case, we will be selecting “Access Granted”
  • Make sure the following Authentication Methods are selected
  • We would not need to make changes to the “Configure Contraints” page so we can click “Next” to arrive at the “Configure Settings” page. Here we would remove “Framed Protocol” by clicking on it > select remove
  •  Next, we would be changing “Service-Type” by clicking on it > select Edit > select “Others” > from the drop-down menu select “NAS Prompt” > click”OK” > click “Next”
  • We would then need to Vendor-Specific Attributes by selecting “Vendor Specific” > select “Add” > scroll down and select “Vendor-Specific” > select “Add”
  • Click on “Add” > select “Enter Vendor Code” as 30065 > select “Yes. It conforms” > select “Configure Attribute” > select “Vendor-assigned attribute number” as (all attributes will have the same number 1) > select “String” > type “shell:roles=network-admin” under “Attribute Value” > click “OK”> click “OK” again and we should see it added.
  • We will follow the same steps as above to add the other attributes. Next, we will add the privilege level, by typing “shell:priv-lvl=15” under “Attribute Value”
  • To authenticate Users in CVP, we would need to provide an additional attribute “shell:cvp-roles=network-admin” under “Attribute Value” to assign the user Network-Admin role.
  •  We should see the following added as shown below and click “OK” > click “Close”.
  • Select “Encryption” > de-select “No encryption” as we do not want our traffic from our access clients to the access servers not encrypted.
  • Click “Next and verify “Network Policy” and click “Finish.
  • Next, make sure the Network Policy is set in the right processing order. If not, you can right-click on the “Network Policy Name” > select “Move Up”.
  • Phew!!! We are finally done with the configuration on the Server Side.

Configuring the Arista Switch

  • Following are the required configurations:

* Please note: EOS local accounts are not used unless the radius server is unreachable 

arista(config)#radius-server key 0 <key> (configured in Step4 under RADIUS Server configuration)
arista(config)#radius-server host <IP address of the server) 
arista(config)#aaa authentication login default group radius local 
arista(config)#aaa authentication login console local 
arista(config)#aaa authorization exec default group radius local 
arista(config)#aaa authorization commands all default local 
arista(config)#ip radius source-interface Management1 (in this case, Management 1 is the source interface) 

If you have accounting setup, the following configurations can be used as an example: 

arista(config)#aaa accounting exec default start-stop group radius 
arista(config)#aaa accounting system default start-stop group radius 
arista(config)#aaa accounting commands all default start-stop group radius
  •  You can check on the switch side if the authentication works by running the command “show radius”. You should be able to see the message sent/received and if they were accepted or not.
arista#show radius
RADIUS server : <IP address>/1812/1813
Dynamic authorization UDP port: 3799
Messages sent: 5
Messages received: 5
Requests accepted: 5
Requests rejected: 0
Requests timeout: 0
Requests retransmitted: 0
Bad responses: 0
DNS errors: 0
CoA request received: 0
DM request received: 0
CoA ack sent: 0
DM ack sent: 0
CoA Nak sent: 0
DM Nak sent: 0
  • You can also check under “show users detail” to check if the user is authenticated correctly
arista#show users detail 
Session Username Roles TTY State Duration Auth Remote Host 
------- -------- ------------- ---- ------ --------- ------------- ------------ 
28697 artest1 network-admin vty8 E 0:08:59 group radius x.x.x.x
  • You can also take a packet capture on port 1812 as shown below
[admin@arista~]$ tcpdump -i ma1 port 1812
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on ma1, link-type EN10MB (Ethernet), capture size 262144 bytes

07:51:23.181831 74:83:ef:0b:9c:01 (oui Unknown) > 00:50:56:a2:39:ee (oui Unknown), ethertype IPv4 (0x0800), length 126: arista.45242 > ip.radius: RADIUS, Access-Request (1), id: 0xdf length: 84
07:51:23.268049 00:50:56:a2:39:ee (oui Unknown) > 74:83:ef:0b:9c:01 (oui Unknown), ethertype IPv4 (0x0800), length 257: ip.radius > arista.com.45242: RADIUS, Access-Accept (2), id: 0xdf length: 215
  • On the Windows Server end, you can look at the Event Viewer > click on “Custom Views” > click on “Server Roles” > click on “Network Policy and Access Servers” and check if the user is authenticated correctly with the right parameters or not.

Setting up CVP to authenticate users using RADIUS

* Please Note: In CVP, the cvpadmin user is always authenticated locally

  • Click on the “gear icon” on the top right corner once you log in using local user at first > select “Access Control” > select “RADIUS” under Authentication and Authorization Source > click on “Add Server” > provide an IP address, shared key as configured earlier (Step4 under RADIUS Server configuration)

  • Be sure to add the CVP IP address as a RADIUS client and under “Content Request Policies” as done earlier for the switch.
  • We can see that the user is successfully authenticated via RADIUS as shown below.
  • We can confirm the same under Event Viewer on the Windows Server.

If the issue is still seen, collect the below outputs and reach out to Arista TAC support by sending an email at support@arista.com

CLI commands:

show agent log | gzip > /mnt/flash/show-agentlog-$HOSTNAME-$(date +%d_%m.%H%M).gz
show agent qtrace | gzip > /mnt/flash/show-agentqt-$HOSTNAME-$(date +%d_%m.%H%M).gz
show logging system | gzip > /mnt/flash/show-logsys-$HOSTNAME-$(date +%d_%m.%H%M).gz 
bash tar -cvzf /mnt/flash/$HOSTNAME-tech.gz.tar /mnt/flash/schedule/tech-support/*
bash tcpdump -i <source interface for RADIUS> -w /mnt/flash/radius_auth.pcap (once you run this, initiate a login from another terminal to understand the error)

Get every new post on this blog delivered to your Inbox.

Join other followers: