Troubleshooting the Authentication Infrastructure

If you have multiple wireless APs and are unable to authenticate with any of them, you might have a problem with your authentication infrastructure, which consists of your NPS servers, PKI, and Active Directory accounts. In this section we examine common issues with NPS authentication and authorization, and validation of certificate- and password-based authentications.

Troubleshooting NPS Authentication and Authorization

To troubleshoot the most common issues with NPS authentication and authorization, verify the following:

• That the wireless AP can reach the NPS servers: To test this, try to ping the IP address of the wireless AP's interface on the wired network from each of the NPS servers. Additionally, ensure that IPsec policies, IP packet filters, and other mechanisms that restrict network traffic are not preventing the exchange of RADIUS messages between the wireless AP and its configured NPS servers. RADIUS traffic to the NPS servers uses a source IPv4 or IPv6 address of the wireless AP, a destination IPv4 or IPv6 address of the NPS server, and a UDP destination port of 1812 for authentication messages and UDP destination port 1813 for accounting messages. RADIUS traffic from the NPS servers uses a source IPv4 or IPv6 address of the NPS server, a destination IPv4 or IPv6 address of the wireless AP, and a UDP source port of 1812 for authentication messages and UDP source port 1813 for accounting messages. These examples assume that you are using the RADIUS UDP ports defined in RFC 2865 and 2866 for RADIUS authentication and accounting traffic.
• That each NPS server/wireless AP pair is configured with a common RADIUS shared secret: Each NPS server/wireless AP pair is not necessarily required to use a unique RADIUS shared secret, but it must use the same value for the RADIUS shared secret for the members of the pair. For example, when you copy the NPS configuration from one NPS server to another, verify all of the shared secret pairs between the NPS servers and the wireless APs.
• That the NPS servers can reach a global catalog server and an Active Directory domain controller: The NPS server uses a global catalog server to resolve the user principal name (UPN) of the computer or user certificate or the MS-CHAP v2 account name to the distinguished name of the corresponding account in Active Directory. The NPS server uses an Active Directory domain controller to validate the credentials of the computer and user account and obtain account properties to evaluate authorization.
• That the computer accounts of the NPS servers are members of the RAS and IAS Servers security group for the appropriate domains Adding the NPS server computer accounts to the RAS and IAS Servers security group for the appropriate domains is normally done during the initial configuration of the NPS server. To add the NPS server computer account to the appropriate domains, you can run the netsh nps add registeredserver command.
• That there are no configured restrictions blocking access: Ensure that the user or computer account is not locked out, expired, or disabled or that the time the connection is being made corresponds to the permitted logon hours.
• That the user account has not been locked out by remote access account lockout: Remote access account lockout is an authentication counting and lockout mechanism designed to prevent an online dictionary attack against a user's password. If remote access account lockout is enabled, you can reset account lockout for the account by deleting the
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemoteAccess\Paramete rs\AccountLockout\DomainName:AccountName registry value on the NPS server.
• That the connection is authorized: For authorization, the parameters of the connection attempt must:
  • Match all the conditions of at least one network policy. If there is no matching policy, all wireless authentication requests are rejected.
  • Be granted network access permission through the user account (set to Allow Access), or if the user account has the Control Access Through NPS Network Policy option selected, the network access permission of the first matching network policy must be set to Grant Access.
  • Match all the settings of the profile. Verify that the authentication settings of the profile have EAP-TLS or PEAP-MS-CHAP v2 enabled and properly configured.
  • Match all the settings of the dial-in properties of the user or computer account. To obtain the name of the network policy that rejected the connection attempt, ensure that NPS event logging is enabled for rejected authentication attempts, and use the Event Viewer to view the events that have the Source of NPS and Event ID set to 2. In the text of the event message, look for the network policy name in the Proxy-Policy-Name or Policy-Name field.
• That you have not changed the mode of your domain from mixed mode to native mode: If you have just changed your Active Directory domain from mixed mode to native mode, NPS servers can no longer authenticate valid connection requests. You must restart every domain controller in the domain for the change to replicate.