Is Microsoft Network Access Protection restricting the wrong users? It might be a configuration issue.
The days when employees trudged into an office and logged onto a monolithic LAN with their company-issued desktop computer are long gone. Today, all manner of network users -- including employees, customers and vendor partners -- need data center access wherever they are, via a myriad of desktops, laptops, tablets and smart devices.
But this accessibility poses a serious threat to IT administrators. Remote systems without the proper operating system patches, anti-malware tools or critical security settings can easily introduce security vulnerabilities into the corporate network.
Network Access Protection (NAP) in Windows Server 2008 R2, Windows 7 and later provides administrators with security tools to cinch security gaps and ensure the integrity of remote systems. Remote systems are inspected during the logon process and checked against a defined set of system health requirements. Systems that meet or exceed health requirements can access the network normally. Systems that fall short can get restricted access -- or be barred completely.
Although NAP has emerged as a popular technology for data center security, there are some common oversights and problems that can prevent proper health checks and logons for client computers. Let's look at several of the most frequently seen NAP problems.
The user's authentication method is not allowed
This occurs because of problems with the server-side connection request policy when client systems use 802.1x or virtual private network (VPN) enforcement. The connection request policy must be configured to override the network policy authentication settings. If the network policy authentication settings are not overridden, the company's network policy server (NPS) will reject the NAP client access requests using 802.1X and VPN connections. Access the NPS and configure the connection request policy for 802.1X and VPN connections to override the network policy authentication.
The certification authority is the wrong type
This problem usually occurs because of a mismatch between the server-side certification authority (CA) installed for NAP with Active Directory Certificate Services -- enterprise CA by default -- and the CA installed for the health Registration Authority role, which is standalone CA by default. The two CA types are incompatible. The easiest way to fix this is to reinstall the Health Registration Authority snap-in and select an appropriate authenticated or anonymous enterprise CA.
The client is incorrectly classified as non-NAP
A client computer should support Network Access Protection, but the server-side says the client is non-NAP and refuses to grant full network access. Instead, the client is forced to adhere to a non-NAP policy (if you have one). This usually happens because of a snafu on the client end; usually the NAP Agent service, the NAP enforcement client or health checks are not enabled on the client.
First, check the NAP Agent. An administrator will need to check the client computer and verify the NAP Agent is running. If not, the administrator will need to start the NAP Agent. This can be accomplished through a command line or using group policy on the client.
Second, when checking the command output from the NAP Agent, also check that the NAP enforcement client is initialized. If not, be sure to enable the enforcement client in the client computer's local settings or group policy. A common mistake is to use local policy to enable enforcement and group policy to set other NAP characteristics. This won't work.
Third, when using NAP with 802.1X or VPN enforcement, be sure to check the Protected EAP (PEAP) properties of the network connection and ensure the enable quarantine checks option is enabled.
Client access requests are ignored by the network policy server
This issue occurs when the NPS is incorrectly configured to handle Remote Authentication Dial-In User Service (RADIUS) clients. Normal NAP client access requests will create an event on the NPS. But when RADIUS clients don't perform local authorization or authentication of access requests, those clients must be specifically configured to forward connection requests. If the RADIUS clients are not forwarding connection requests -- or are forwarding requests to the wrong RADIUS server -- no connection requests will appear on the NPS. In effect, the connection request is ignored.
The best way around this problem is to access the NPS, locate the connection request policy for NAP client computers and be sure to forward requests to the proper RADIUS servers for authentication.
You cannot issue new system health authentication templates
When you try to issue a new server-side health certificate template through the certificate services console, you find the system health authentication template is not available. This is generally due to an operating system version mismatch. In order to issue a new template, the NAP CA must use the enterprise edition of Windows Server; if it is using the standard edition, it cannot issue new certificate templates. Verify the OS version and upgrade the OS to the enterprise edition if necessary to correct this issue.
Although NAP is often straightforward to install and manage, there are some common oversights -- usually on the server end -- that can cause client connection problems. With a little basic insight and some simple server configuration know-how, IT administrators can isolate and correct these basic problems in a few minutes.