Last updated 06/10/2020

Introduction to NPS

With Network Policy Server you can create policies to determine who can access your network and how they can connect.

NPS also includes an infrastructure to incorporate client system health checks and restrict access to systems that don’t meet minimum health requirements, such as not having up-to-date antivirus protection and the latest system and security updates installed.


Network Policy Server is Microsoft’s implementation of the RADIUS protocol, a proposed IETF standard that’s widely used to centralize authentication , authorization, and accounting to network services.

(The port values of 1812 for authentication and 1813 for accounting are RADIUS standard ports defined by the Internet Engineering Task Force (IETF) in RFCs 2865 and 2866.)

 Process and types of messages in RADIUS:
1. An access client (for example, a user on a laptop) makes a connection request to a network access server (NAS), which handles access to a network. An NAS can be, for example, a wireless access point, a VPN server, or a dial-up server. In the RADIUS infrastructure, an NAS is configured as a RADIUS client.

The term “client” can be a bit confusing. Only an NAS that’s already part of the network can be a RADIUS client. Access client devices, such as users’ desktops, laptops, or tablets that are requesting access to the network, aren’t RADIUS clients.
Also notice that the RADIUS clients configuration can vary between different vendors. For Cisco WLAN infrastructure, a wireless LAN controller is a RADIUS client, but for Ubiquiti, RADIUS client are APs.

2. The RADIUS client sends an Access-Request message, including a username/password combination or a certificate from the user, to an NPS server acting as a RADIUS server. This message can include other information about the user, such as the network address.

3. The NPS server evaluates the Access-Request message. This process can include authenticating the username and password (along with other user information) via a domain controller or client certificate.

4. The NPS server can respond with one of three types of messages:

Access-Reject—The request is rejected, and access is denied to the network or resources.
Access-Challenge—More information is requested, such as a secondary password or other access code or credential.
Access-Accept—Access is granted, and authorization is given to certain resources, based on defined network policies.

5. The connection is completed, and the NAS sends an Accounting-Request message to the NPS server to be logged. This message is sent to collect information about the user, such as his or her IP address, method of connecting to the network, and a session identifier, so that additional information that’s sent can be attributed to this user’s connection.

6. The NPS server sends an Accounting-Response message, which acknowledges that the request was received, to the NAS.

7. During the session, additional Accounting-Request messages containing information about the current session are sent. Each Accounting-Request message is acknowledged by an Accounting-Response message.

8. When the user’s connection ends, one last Accounting-Request message with information about the overall use during the session is sent. This final message is acknowledged by an Accounting-Response message.

Two main reasons you should set up an NPS architecture with RADIUS when you have different connection paths to your network.

  1. First, RADIUS centralizes control over authentication and authorization. No matter which path a user uses to access the network, a single point of contact—the NPS server acting as a RADIUS server—handles authenticating the user and determining the level of authorization.
  2. Next, standardizing on RADIUS requires all NAS devices to be RADIUS clients so that only one protocol performs authentication and authorization, and only one standard configuration process is used, regardless of the kind of device connecting to the network.


Post-installation settings:

which NASs can connect and the authentication method each one uses. NPS gives you the choice of standard or advanced configuration options. The advanced configuration option requires you to set up the components for a RADIUS server or proxy. The standard configuration has wizards to walk you through these policy settings:

Network Access Protection (NAP)—This option configures NPS as an NAP policy server (covered later in the “Configuring Network Access Protection” section).
RADIUS server for Dial-Up or VPN Connections—This option defines network policies for authenticating and authorizing connections from these RADIUS clients: dial-up or VPN network access servers.
RADIUS server for 802.1X Wireless or Wired Connections—This option defines network policies for authenticating and authorizing connections from these RADIUS clients: wireless access points and authentication switches.

Authentication methods: password based and certificate based.

Four password-based methods are supported:

• Microsoft Challenge Handshake Authentication Protocol—Microsoft Challenge Handshake Authentication Protocol (MS-CHAP) starts with a challenge-response with the access client, and then sends the username and a password with a one-way encryption (meaning the password can’t be unencrypted) to be authenticated against the stored credentials.

• Microsoft Challenge Handshake Authentication Protocol version 2—Microsoft Challenge Handshake Authentication Protocol version 2 (MS-CHAP v2) is an update to MS-CHAP with stronger security. Of the four password-based methods, it’s the preferred one.

• Challenge Handshake Authentication Protocol—Challenge Handshake Authentication Protocol (CHAP) is similar to MS-CHAP, but the password must be able to be unencrypted, making it less secure than MS-CHAP.

• Password Authentication Protocol—Password Authentication Protocol (PAP) is the least secure method. The password is sent in plaintext, and there’s no challenge and response. Because the password could be captured easily, PAP isn’t recommended.

The certificate-based authentication method is Extensible Authentication Protocol (EAP).

Certificate-based authentication is more secure than password-based methods. Depending on the method you choose, there are two authentication types. The authentication type for EAP is Transport Layer Security (TLS). Certificates and options for using them are discussed later in “Using Certificates for Authentication.”
Protected Extensible Authentication Protocol (PEAP) is a special way to encrypt a password being sent via MS-CHAP v2. With PEAP, you can check the server’s certificate, but user authentication is still done through passwords.


By default, it’s the domain where the NPS server is located. If connection requests require authentication from another domain controller, they can be sent to an NPS server acting as a RADIUS proxy, and the realm determines which server the request is routed to.

  • Lack of fault tolerance is the biggest disadvantage.
    If the one and only RADIUS server goes down, no network connection requests can be authenticated, which makes the network inaccessible to users. To eliminate this single point of failure, you can deploy multiple RADIUS servers. RADIUS clients can be configured to use a primary server and alternates, so if the primary isn’t available, the client tries the alternates in turn.
  • Server’s load.
    In a network with hundreds or thousands of requests in extremely short periods, a single RADIUS server could be overwhelmed. One solution is to use RADIUS proxies (having only one proxy reintroduces the single-point-of-failure problem) with multiple RADIUS servers. Requests received by a proxy are forwarded to a RADIUS server group, composed of one or more RADIUS servers, for handling.
    In a server group of two or more RADIUS servers, the load can be balanced based on these properties:
    Priority—Tells the NPS proxy the order of importance of this server group member when passing on requests. This setting is a non-zero integer number (such as 1, 2, 3). The lower the number, the higher the priority, so servers assigned a priority of 1 get requests first. If the Priority 1 server is unavailable, the request is sent to the Priority 2 server, and so on. Setting just the priority doesn’t result in load balancing because the lowest-priority server continues getting requests unless it becomes unavailable. However, a priority of 1 can be assigned to multiple servers, and the Weight setting can be used to force load balancing.
    Weight—Determines what percentage of connection requests are sent to a server group member when the priority is the same as other members. This setting is also a non-zero integer number between 1 and 100. For example, to distribute the load between two serv- ers evenly, you could assign each a priority of 1 and a weight of 50 so that each server gets 50% of the connection requests. The sum of all weights in the server group must be 100.
    Advanced settings—Determines whether a server group member is unavailable and whether connection requests need to be routed to another server in the group.
Certificate base authentication


For a certificate to be used for authentication, the CA must be trusted by the client or server, and to be trusted, it must have a root certificate (also called the “CA certificate”) in the Trusted Root Certification Authorities certificate store. Think of the root certificate as the master certificate for a CA. After the root certificate is installed, all other certificates from this CA are trusted automatically by the client or server. The process of requesting a certificate, having it approved, and downloading it is called “enrollment.” Clients can be enrolled automatically for some certificates in a domain. For example, if the client is a member of the same domain as the CA, the CA certificate is auto-enrolled.

Besides the root certificate, there are three other important certificate types:

• Client computer certificate—This certificate verifies a client computer’s identity to an NPS server. It’s enrolled automatically for domain members and imported manually for non-domain members.
• Server certificate—This certificate verifies a server’s identity to a client. It can be set for auto-enrollment in Active Directory.
• User certificate—This certificate can be put on a smart card to verify a user’s identity, and the smart card reader is attached to the client computer. If you’re using smart cards, you don’t auto-enroll client computer certificates.

When a certificate is presented for authentication, it must meet these three criteria for authentication to succeed:

• It must be valid (for example, hasn’t expired).

• It must be configured for the purpose it’s presented for. Eg. Certificate on a NPS server for Server Authentication, Certificate on a Workstation for Client Authentication.

• It must be issued by a trusted CA.

The Server certificate must meet these requirements:

• The subject name can’t be blank.
• The certificate is linked to a trusted root CA.
• The purpose of the certificate is Server Authentication. The object identifier for Server Authentication is
• The algorithm name is RSA, and the minimum key size is at least 2048.
• The name in the Subject line of the server certificate matches the name that is configured on the client for the connection.
• For wireless clients,If the subject alternative name (SubjectAltName) extension is used, which allows multiple servers to use the certificate, the certificate must contain the NPS server’s DNS name.

Client certificate requirements:

With either EAP-TLS or PEAP with EAP-TLS, the server accepts the client’s authentication when the certificate meets the following requirements:

  • The client certificate is issued by an enterprise certification authority (CA), or it maps to a user account or to a computer account in the Active Directory directory service.
  • The user or the computer certificate on the client chains to a trusted root CA.
  • The user or the computer certificate on the client includes the Client Authentication purpose.
  • The user or the computer certificate does not fail any one of the checks that are performed by the CryptoAPI certificate store, and the certificate passes requirements in the remote access policy.
  • The user or the computer certificate does not fail any one of the certificate object identifier checks that are specified in the Internet Authentication Service (IAS) remote access policy.
  • The 802.1x client does not use registry-based certificates that are either smart-card certificates or certificates that are protected with a password.
  • The Subject Alternative Name (SubjectAltName) extension in the certificate contains the user principal name (UPN) of the user.
  • When clients use EAP-TLS or PEAP with EAP-TLS authentication, a list of all the installed certificates is displayed in the Certificates snap-in, with the following exceptions:
    • Wireless clients do not display registry-based certificates and smart card logon certificates.
    • Wireless clients and virtual private network (VPN) clients do not display certificates that are protected with a password.
    • Certificates that do not contain the Client Authentication purpose in EKU extensions are not displayed.

You can select certificate-based authentication—EAP—when you’re setting the authentication method. EAP requires both the server and the access client to present valid certificates, which is the most secure authentication method. However, in a large organization, maintaining potentially thousands of client certificates can be a daunting administrative job, even with auto-enrollment for new access clients. Selecting PEAP as the authentication method doesn’t involve using a client certificate; instead, it uses MS-CHAP v2 for client authentication. It’s not as secure, however, as a pure certificate-based authentication method (such as EAP) because users still enter passwords, which can be guessed or stolen.

However, PEAP can be configured to require a server certificate. This method protects clients from connecting to a server that’s pretending to be the server they want to connect to, and PEAP encrypts the information it’s passing.

For a tutorial how to configure Certificate based authentication, see this post: