How to Configure RADIUS (NPS) Server on Windows Server

8.3K

In this article, we’ll show how to configure a RADIUS server on Windows Server 2025/2022/2019/2016. Additionally, we will cover how to configure RADIUS authentication under AD user accounts on Cisco and MikroTik network devices and wireless access points (802.1x).

What Is RADIUS and How It Works?

RADIUS (Remote Authentication in Dial-In User Service) is a network protocol that provides centralized management of authentication, authorization, and accounting (AAA), and is designed to exchange of information between a central platform and client devices.

NPS Role in Windows Server

The Network Policy Server (NPS) role implements the RADIUS server feature on the Windows Server operating system. It can be used to authenticate remote clients against the Active Directory.

Install and Configure NPS (RADIUS) on Windows Server

First, let’s install and configure the NPS (RADIUS) role on the Windows Server host. The NPS server validates credentials against AD by using the Windows security subsystem (LSASS) and LDAP queries, and then evaluates configured Network Policies locally before returning an Access-Accept/Access-Reject response to the RADIUS client.

Important. Correct time sync between NPS, DCs, and network devices is critical for certificate validation (EAP-TLS/PEAP) and Kerberos-based services in the domain environment. Keep in mind that time drift may cause authentication/TLS handshake failures.

Cisco example:

ntp server 192.168.1.10
clock timezone UTC 0

Windows check:

w32tm /query /status

Installing NPS via Server Manager

The NPS (RADIUS) role is available on all supported versions of Windows Server, including versions 2025, 2022, 2019, and 2016.

Open the Server Manager console, run the Add Roles and Features wizard > select the Network Policy and Access Services role.

Check if the NPAS role is installed on your Windows Server host:

Get-WindowsFeature -Name NPAS

After the role installation is completed, open the Network Policy Server snap-in (nps.msc) from the Server Manager > Tools menu.

Right-click on a root node of the NPS console and click Register server in Active Directory.

Confirm the new NPS server registration in Active Directory.

Note. Also, you can install NPS role and management tools using PowerShell:

Install-WindowsFeature NPAS -IncludeManagementTools

Registering NPS Server in Active Directory

Also, you can register your NPS server in Active Directory with a command:

netsh ras add registeredserver

Your NPS host will be added to the built-in domain group “RAS and IAS Servers“, which allows NPS servers to read dial-in properties and perform authorization decisions during authentication requests.

To list all authorized NPS servers in AD, run:

netsh ras show registeredserver

Next, create a new security group in the Active Directory domain (for example, RemoteCiscoUsers) and add all users who will be allowed to authenticate on Cisco routers and switches to this group.

Best practice tip. We recommend to deploy at least two NPS servers and config all RADIUS clients with primary and secondary RADIUS servers in order to avoid authentication outages during maintenance or server failures.

Adding and Managing RADIUS Clients

The next step is to add the Radius client. Radius client is the device from which your NPS can receive authentication requests. This could be a Cisco router, switch, Wi-Fi access point, etc.

Adding Cisco Devices as RADIUS Clients

Expand the RADIUS Clients and Servers > RADIUS Clients, select New.

On the Settings tab, fill the fields Friendly name, client Address (you can specify IP address or DNS name), and Shared Secret + Confirm shared password (you will use this password in the configuration of the Cisco switch/router).

In the Advanced tab, select Vendor name – Cisco.

Note. The RADIUS shared secret is still required between the network device and the NPS server. Certificates are typically used for EAP-TLS or PEAP authentication and do not replace the RADIUS shared secret. If you have a corporate Certification Authority (CA) deployed to implement PKI infrastructure, you can request a *.p12 certificate for the Radius/NPS server. Just import the certificate to the personal certification store of the Local Machine.

PowerShell Command to add RADIUS Clients

You can use the PowerShell command instead of the NPS GUI to add a new RADIUS client. In this case, you can use the New-NpsRadiusClient PowerShell cmdlet:

New-NpsRadiusClient -Address "192.168.31.1" -Name "cisco2960" -SharedSecret "Zb+kp^JUy]v\ePb-h.Q*d=weya2AY?hn+npRRp[/J7d"

After you have added a new RADIUS client, you should restart the Network Policy Server service to ensure config changes are applied immediately:

Restart-Service IAS

By default, NPS uses the following UDP ports to send and receive RADIUS traffic: 1812, 1813, 1645, and 1646. When you install the NPS role on Windows Server, rules for these ports are automatically created and enabled in Windows Defender Firewall. You can list these Windows Firewall rules using PowerShell:

Get-NetFirewallRule -DisplayGroup "Network Policy Server"

If your RADIUS client is located in a DMZ network or an external security perimeter, you must create the appropriate firewall rules on your network firewall.

Best practice. You should restrict RADIUS traffic to dedicated management VLANs/trusted infrastructure networks. You should avoid exposing RADIUS services directly to untrusted/public networks.

Common RADIUS Authentication Problems

• Time drift between client and server may cause PEAP/EAP-TLS failures
• Incorrect shared secrets lead to silent Access-Reject responses
• Missing certificate EKU “Server Authentication” breaks TLS handshake
• NPS policy mismatch can result in unexpected denies even when credentials are valid

Configure NPS Policies on the RADIUS Server

The next step is to create and configure NPS policies. These policies describe which users are allowed to authenticate remotely and their access permissions. In this example, we will associate the RADIUS client with the domain security group that determines the user privileges on CISCO devices.

Connection Request vs Network Policies

There are two types of policy on a RADIUS server:

• Connection request policies — determine which RADIUS servers should authenticate and authorize connection requests received from RADIUS clients;
• Network policies — who is authorized to connect to the network and a list of assigned privileges.

In our case, we will use only the NPS Network policies.

Creating a new NPS Network Policy

Expand the Policies > Network Policies and select New:

Specify the Policy name, the type of network access server should remain unchanged (Unspecified).

Assigning User Groups and Cisco Attributes

In the Specify conditions step, you need to add the conditions under which this RADIUS policy will be applied. Let’s add two conditions — the authorized user must be a member of a specific domain security group, and the device you want to access has a specific name. Use the Add option to create a new condition. Set the following conditions:

• Windows Group: add the RemoteCiscoUsers group)
• Client Friendly Name: Cisco_*

Note. The Client Friendly Name field may differ from the DNS name of your device. We will need it in the further steps to identify a specific network device when creating a Remote Access Policy. For example, you can use this name to specify a mask through which several different RADIUS clients are processed by a single access policy.

On the next screen, select Access Granted.

Some legacy network devices may only support PAP or SPAP authentication methods. Keep in mind that these protocols provide weak protection for user credentials and should be avoided whenever possible. In modern environments you should use PEAP, EAP-TLS, or MS-CHAPv2 instead. If PAP/SPAP must be used for compatibility reasons, you need to ensure that authentication traffic is isolated and protected within trusted management networks.

Skip the next configuration Constraints step.

In the Configure Settings section, go to the RADIUS Attributes > Standard section. Delete the existing attributes there and click the Add button.

Select Access type > All, then Service-Type > Add. Specify Others = Login.

Now add a new attribute in the RADIUS Attributes > Vendor Specific section. Under Vendor, select Cisco, and click Add. Here you need to add information about the attribute. Click Add and specify the following value:

shell: priv-lvl = 15

This value means that the user authorized by this policy will be granted a maximum (15) administrative access privileges on the Cisco device.

The last screen displays all selected NPS policy settings. Click Finish.

If you have created several network policies in the NPS console, note that they are processed from top to bottom, so the order of the policies is important. Note that NPS processes network policies in order from top to bottom. Processing stops when a policy matches the request and returns an Access-Accept/Access-Reject decision. You can change the priority of policies in the NPS console using the Processing Order value.

By default, in case no restrictive Network Policy is configured, domain users may be authenticated via NPS provided that their account and group membership satisfy policy conditions. You can check this using the Active Directory Users and Computers snap-in (dsa.msc). Open any user properties, go to the Dial-In tab, and check that the Control access through NPS Network Policy option in enabled in the Network Access Permission section.

Configuring RADIUS Authentication on Cisco Devices

Once you have created the NPS policy, you can proceed to configure your Cisco routers or switches for authentication on the newly installed RADIUS server.

Secure SSH Configuration for Cisco Switch

As it is insecure to send unencrypted user credentials over the network, you should disable the Telnet protocol on your Cisco devices. To disable Telnet and enable SSH, use the following commands in Configuration Mode on the Cisco device:

configure terminal

crypto key generate rsa modulus 2048

ip ssh version 2
ip ssh time-out 60
ip ssh authentication-retries 3

Create a local user account on your Cisco device. This account can be used for local logon in case the NPS or AD is unavailable

username cisco_local algorithm-type scrypt secret VeryStrongLocalPassword

To make the use of SSH mandatory and disable remote access using Telnet, execute the following commands:

line vty 5 15
login authentication default
transport input ssh

Testing RADIUS Connectivity

Before troubleshooting authentication problems, you should verify if the network device can reach the NPS server and that UDP port 1812 is accessible. Here is an example for Cisco:

test aaa group radius_srv_group username password legacy

On Windows run the command:

Test-NetConnection <NPS_Server_IP> -Port 1812

Cisco Catalyst RADIUS Authentication Example

Below is an example of the configuration for authorizing a Radius server for the Cisco Catalyst Switch:

# Enable AAA
aaa new-model

enable algorithm-type scrypt secret VeryStrongEnablePassword

# Configure the RADIUS server
radius server NPS01
 address ipv4 192.168.1.16 auth-port 1812 acct-port 1813
 key VeryStrongSharedSecretHere
 timeout 5
 retransmit 3

# Create a RADIUS server group
aaa group server radius radius_srv_group
 server name NPS01
 radius-server deadtime 10

# Authentication fallback to local users if RADIUS is unavailable
aaa authentication login default group radius_srv_group local
aaa authentication enable default group radius_srv_group local

# Authorization for EXEC shell access
aaa authorization exec default group radius_srv_group local
aaa authorization commands 15 default group radius_srv_group local

# Enable AAA accounting
aaa accounting exec default start-stop group radius_srv_group
aaa accounting commands 1 default start-stop group radius_srv_group
aaa accounting commands 15 default start-stop group radius_srv_group

# Specify the source interface for RADIUS traffic
ip radius source-interface vlan 10

If you have several Radius servers, add them to the group:

aaa group server radius radius_srv_group
server 192.168.1.16
server 192.168.101.16

This completes the minimum switch configuration, and you can try to check Radius authentication on your Cisco device.

Note that for privileged admin access to network devices, you should consider integrating NPS with Microsoft Entra MFA Extension/third-party MFA provider.

Security notes.

• In modern Cisco IOS versions we recommend using the radius server config mode instead of the legacy radius-server host syntax.
• You should use long randomly generated shared secrets for RADIUS authentication. Weak shared secrets may allow attackers to spoof RADIUS clients/intercept authentication traffic.
  Do not reuse the same RADIUS shared secret across multiple network devices. RADIUS shared secrets should be at least 32 characters long and generated randomly.
  Each RADIUS client should use a unique secret to reduce lateral exposure if a device config is compromised.
• Note that traditional RADIUS does not fully encrypt authentication traffic. Only user passwords are obfuscated while other packet attributes remain visible. You should deploy RADIUS only within trusted/internal networks or protect traffic additionally using IPsec/VPN tunneling.

How to Enable MikroTik (RouterOS) User Authentication via RADIUS

In this part, we will show you how to configure RADIUS authentication for VPN user connections on a MikroTik router (RouterOS based).

Note that this example uses PPTP because it is simple to demonstrate. For production deployments, we recommend using IKEv2, L2TP/IPsec, SSTP, or WireGuard instead.

Adding MikroTik as RADIUS Client in NPS

Open the Network Policy Server console (nps.msc) and create a new Radius client.

Select New RADIUS Client and configure the following settings:

• Enable this RADIUS Client;
• Friendly Name — enter the name of your MikroTik router;
• Address — specific the IP address of the MikroTik router;
• Specify your Pre-shared secret key.

Create a new Network Policy with the following settings:

• User Groups — specify the name of the domain user group that is allowed to authenticate on your MikroTik router;
• Authentication Type — MS-CHAPv2;
• Tunnel Type — Point-to-Point Tunneling Protocol (PPTP). PPTP is considered cryptographically insecure, and you should not use it in modern production environments (unless it’s required for legacy compatibility). You should prefer more secure VPN protocols (such as L2TP/IPsec, IKEv2, SSTP, or WireGuard whenever possible);
• Access Permissions — Access granted;
• In the Configure Authentication Methods window, leave only MS-CHAPv2 and allow users to change expired passwords (User can change password after it has expired option);
• Multilink and Bandwidth Allocation Protocol (BAP) – Do not allow Multilink connections;
• In the Standard section, remove Service-Type – Framed and leave only Framed-Protocol PPP;
• Encryptions — leave only the strongest encryption (MPP 128-bit) method.

Once you have created a new policy, open the Network Policy Server settings.

Leave only the following UDP ports for the RADIUS server communications:

• Authentication — 1812;
• Accounting — 1813.

Check if these UDP ports are open in Microsoft Defender Firewall Rules. If not, open them manually.

Configuring MikroTik RADIUS Connection Settings

Note that this config is provided for compatibility and demonstration purposes only. PPTP is deprecated and you should not use it in production environments.

Now you need to configure the connection settings for Windows Server RADIUS in the MikroTik configuration (we assume that PPP VPN Server is already configured on RouterOS).

Check in the PPTP server settings that only mschap2 is allowed to use for authentication.

Now we need to configure the connection to Radius NPS server. Select New Radius Server and specify the following options:

• Service: ppp;
• Address: IP address of the RADIUS server;
• Secret: pre-shared key that you specified in the network policy settings;
• Src/ Address: MikroTik IP address from which traffic will be sent to NPS;
• Authentication Port: 1812;
• Accounting Port: 1813.

Add appropriate access rules to MikroTik Firewall.

Then go to Secrets > PPP Authentication and Accounting and enable the Use Radius option.

It remains to configure a PPTP VPN connection to your MikroTik VPN on users’ computers. Users can use their Active Directory account credentials to authenticate against Mikrotik (accounts must be added to the AD group that you have specified when creating the MiktoTik Network Policy on NPS).

Note. Traditional NPS/RADIUS authentication with AD credentials does not provide multi-factor authentication (MFA) by default. For privileged admin access, you should consider integrating NPS with Microsoft Entra MFA Extension, certificate-based authentication, or third-party MFA providers.

Configure RADIUS for 802.1x Wireless Networks

The Windows Server Network Policy Server (NPS) can be used as a RADIUS server to centrally authenticate Wi-Fi clients at corporate wireless access points. The IEEE 802.1x protocol is used to authorize computers on Wi-Fi access points using a RADIUS server. This protocol provides centralized authentication of users and devices, including those on Wi-Fi networks.

NPS Setup for Wi-Fi Authentication

After installing the NPS role on Windows Server, open the NPS console. On the Start page, select RADIUS Server for 802.1X Wireless or Wired Connections.

Click Configure 802.1X to launch the setup wizard.

Select 802.1x connection type > Secure Wireless Connections.

Add all your WLAN access points as RADIUS clients (set name, IP/FQDN, shared secret).

Next select the authentication method. The Protected EAP (PEAP) will be used in this example. Note that in high-security environments, you should prefer EAP-TLS over PEAP because it provides certificate-based mutual authentication and eliminates password-based authentication risks.

Click the Configure button, then select the server certificate that will be used by clients to authenticate your RADIUS server.

In order to check if the selected certificate contains the Server Authentication EKU and that client devices trust the issuing CA, run the following command:

Get-ChildItem Cert:\LocalMachine\My

Clients use this certificate to verify the NPS identity. This can be either a self-signed certificate or one that was issued by your internal or commercial public key infrastructure (PKI). The main point is that clients should trust this certificate.

Once you have completed the NPS wizard setup, two policies will be created for you: the Connection Request Policy and the Network Policy.

Specify which user group is allowed to authenticate to RADIUS in the Network Policy settings. On the Conditions tab, add an AD group. Also, verify that the NAS port type is set to Wireless > Other or Wireless > IEEE 802.11.

Note. Unlike EAP-TTLS, the PEAP protocol only requires a server-side PKI certificate to create a secure TLS tunnel for user authentication.

Adding Wireless Access Points as RADIUS Clients

Next, configure your wireless access points to use the NPS server as the RADIUS server.

You can use a GPO to deploy wireless connection profile settings for client computers. This policy allows clients to automatically authenticate to a wireless access point using their current domain user credentials.

Create a new domain GPO and go to Computer Configuration > Policies > Windows Settings > Security Settings> Wireless Network (IEEE 802.11) Policies. Select Create a New Wireless Network Policy for Windows Vista and later.

In the policy settings, add your wireless networks (specify profile name, SSID). Enable the Connect automatically when this network is in range option.

On the Security tab, select:

• Authentication: WPA2-Enterprise
• Encryption: AES-CCMP
• Network authentication method: PEAP
• Authentication mode: User or computer authentication

Click the Properties button, then select the trusted CA certificate used for identification.

Then, click “Advanced” and enable the “Single Sign On” option. In this case, the user password that is used for authentication in Windows will also be used for authentication on a wireless access point.

After applying this policy, the Windows login screen will show the wireless network that Windows tries to connect to after the user enters their password.

Viewing NPS Event Logs in Event Viewer

To enable NPS Server Radius Authentication logging, you need to enable the Network Policy Server audit policy via the local Group Policy Editor (gpedit.msc). Go to Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Logon/Logoff > Audit Network Policy Server and check the option to audit both success and failure logon attempts.

Now you can open the Event Viewer console (eventvwr.msc), go to the Windows Logs > Security, and filter the event by the Event ID 6272.

Network Policy Server granted access to a user.

Common Event IDs (6272, 6279)

If authentication succeeds, Event ID 6272 is logged:

Network Policy Server granted access to a user.

If authentication fails, NPS usually logs Event ID 6273:

Network Policy Server denied access to a user.

If the user has entered an incorrect username and password, an event will be displayed in the Event Viewer:

Authentication failed due to a user credentials mismatch.

If the user is not a member of the correct security group, or if Network Access Permission= Deny is set in the AD user properties on the Dial-in tab, the following event will occur:

The Network Access Permission setting in the dial-in properties of the user account in Active Directory is set to Deny access….

If a user enters an incorrect password multiple times, their account will be locked out in accordance with your Account Lockout Policy in AD.

Event ID: 6279
Network Policy Server locked the user account due to repeated failed authentication attempts.

Note that Event ID 6279 is generated by NPS when it detects repeated authentication failures that result in an AD account lockout. The actual lockout is enforced by the DC and logged as Event ID 4740 in the Security log.

If you need to find all NPS authorizations events for the specific user (Richard.Doe in this example), use the next PowerShell script:

$Query = @"
<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">
      *[
        EventData[
          Data[@Name='SubjectUserName']='richard.doe'
        ]
      ]
      and
      *[
        System[
          (EventID='6272')
        ]
      ]
    </Select>
  </Query>
</QueryList>
"@

$events = Get-WinEvent -FilterXML $Query

$ipaddr = @{
    Label = "IP"
    Expression = { $_.Properties[9].Value }
}

$events |
    Select-Object $ipaddr |
    Group-Object IP |
    Format-Table Count, Name -AutoSize

Modern Identity Protection (Hybrid Environments)

In case your organization uses hybrid identity, you should complement NPS with Microsoft Entra ID protections (such as Smart Lockout and Conditional Access policies) in order to mitigate password spray and brute-force attacks beyond on-premises infrastructure.