Network Policy Server Authorization and Authentication

People have been asking how NPS authentication actually works with certificates.

This blog describes Network Policy Server (NPS) service authentication methods when certificate is used with 802.1x implementation.

Certificate-based authentication methods

When you use EAP with a strong EAP type (such as TLS with smart cards or certificates) both the client and the server use certificates to verify their identities to each other. This process is called mutual authentication. Certificates must meet certain requirements to allow the server and the client to use them for mutual authentication.

One such requirement is that the certificate is configured with one or more purposes in EKU extensions that correlate to the certificate use. For example, a certificate used for the authentication of a client to a server must be configured with the Client Authentication purpose. Similarly, a certificate used for the authentication of a server must be configured with the Server Authentication purpose. When certificates are used for authentication, the authenticator examines the client certificate, seeking the correct purpose object identifier in EKU extensions. For example, the object identifier for the Client Authentication purpose is 1.3.6.1.5.5.7.3.2. When a certificate is used for client computer authentication, this object identifier must be present in the EKU extensions of the certificate or authentication will fail.

Understanding authentication with certificates

When a certificate is provided to a client or server computer as proof of identity, the authenticator must examine the certificate to determine its validity, whether it is configured with the purpose for which it is being used, and to find out whether the certificate was issued by a CA that the authenticator trusts.

Assuming that a certificate is configured properly and is valid, the most important aspect of the authentication process is the check by the authenticator that it trusts the CA that issued the certificate.

If the authenticator trusts the CA and the certificate is valid and configured properly according to the minimum server and client certificate requirements, authentication succeeds. If the authenticator does not trust the CA, authentication fails.

How trust is established

Windows-based computers keep certificates in a certificate store on the local computer. There is a certificate store for the Local Computer, for the Current User, and for individual Services, such as Network Connections, Automatic Updates, and Computer Browser. In each certificate store there is a folder named Trusted Root Certification Authorities that contains certificates from every CA that is trusted, whether they are public or private CAs.

To determine trust, the authenticator checks the Trusted Root Certification Authorities certificate store for either the Current User or Local Computer.

If the CA that issued the client, user, or server certificate being used for authentication has a certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator trusts the certificate. If the issuing CA does not have a CA certificate in the Trusted Root Certification Authorities certificate store on the local computer, the authenticator does not trust the certificate.

Required for EAP-TLS and PEAP-TLS

The CA certificate is enrolled automatically for domain member computers. For non-domain member computers, the certificate must be manually imported into the certificate store.

Domain member certificate enrollment

If your VPN server, NPS server, or client running Windows 2000, Windows XP, or Windows Vista is a member of a domain running Windows Server 2008 or Windows Server 2003 and AD DS, you can configure the autoenrollment of computer and user certificates. After autoenrollment is configured and enabled, all domain member computers receive computer certificates when Group Policy is next refreshed, whether the refresh is triggered manually with the gpupdate command or by logging on to the domain.

If your computer is a member of a domain where AD DS is not installed, you can install computer certificates manually by requesting them through the Certificates MMC snap-in.

Non-domain member certificate enrollment

Certificate enrollment for computers that are not domain members cannot be performed with autoenrollment. When a computer is joined to a domain, a trust is established that allows autoenrollment to occur without administrator intervention. When a computer is not joined to a domain, trust is not established and a certificate is not issued. Trust must be established using one of the following methods:

• An administrator (who is, by definition, trusted) must request a computer or user certificate using the CA Web enrollment tool.
• An administrator must save a computer or user certificate to a floppy disk and install it on the non-domain member computer. Or, when the computer is not accessible to the administrator (for example, a home computer connecting to an organization network with an L2TP/IPsec VPN connection), a domain user whom the administrator trusts can install the certificate.
  • An administrator can distribute a user certificate on a smart card (computer certificates are not distributed on smart cards).

  Many network infrastructures contain VPN and NPS servers that are not domain members. For example, a VPN server in a perimeter network might not be a domain member for security reasons. In this case, a computer certificate with the Server Authentication purpose contained in the EKU extensions must be installed on the non-domain member VPN server before it can successfully negotiate L2TP/IPsec-based VPN connections with clients. If the non-domain member VPN server is used as an endpoint for a VPN connection with another VPN server, EKU extensions must contain both the Server Authentication and Client Authentication purposes.

  Authorization

  The server running NPS performs authorization as follows:

  • NPS checks processes its network policies to find a policy that matches the connection request. If a matching policy is found, NPS either grants or denies the connection based on that policy’s configuration.
  • If both authentication and authorization are successful, NPS grants access to the network, and the user and computer can connect to network resources for which they have permissions.