If you're using Microsoft NPS as a RADIUS server, it can be a pain to interpret the log files produced from the NPS service. Here are some tips to make it easier!

Log File Properties

First, go to the Accounting view, and in the Log File Properties section click Change Log File Properties.

Format

Use the format DTS Compliant. Now the logs will be in XML format, and a lot more readable for us humans.

Retention

Select to create a new log file Daily. The log files tend to be rather large, and when the files get too large, it can be too heavy to open them.

Syslog

If possible, send the NPS logs to a central syslog server. One of the solutions I'm using is to have NXLog send the logs to a Graylog server. I won't cover that setup in this blog though.

The log - what to look for

The log, in DTS format, consists of a lot of Key and Value pairs. Among all, the most interesting to extract is:

• Client-IP-Address and Client-Friendly-Name - Describing the RADIUS client. This is typically a network switch or a Wireless Lan Controller (WLC).
• Computer-Name - The RADIUS server processing the request.
• Proxy-Policy-Name - The name of the NPS Connection Request Policy
• NP-Policy-Name - The name of the NPS Network Policy
• SAM-Account-Name and Fully-Qualifed-User-Name - This is the name of the device trying to authenticate to the network; username or computer name.
• Packet-Type - This is from the RADIUS protocol (RFC 2865) telling what type of packet was sent:
  • Access-Request (1) - Request sent from the Client to the Server
  • Access-Accept (2) - Sent from the Server to the Client when authentication is successful
  • Access-Reject (3) - Sent from the Server to the Client when the authentication is rejected
  • Access-Challenge (11) - Sent from the Server to the Client
• Reason-Code - This is a reason code the NPS is using in its responses to the Clients. Normally this would be 0, which means everything went ok.

Successful authentication

A successful authentication - when using EAP - will contain a Access-Request (1), Access-Challenge (11) and a Access-Accept (2). Don't be bothered if you see multiple Access-Requests and Access-Challenges in the same authentication. This is due to the EAP messages being larger than the MTU, and thus being fragmented.

Rejected authentication

When the server rejects an authentication, it will respond with a Access-Reject (3). Now the Reason-Code will be of interest. Some examples of common codes and a short explanation is:

• 7 - The domain provided in the User-Name attribute is non-existent.
• 8 - The user in the User-Name attribute doesn't exist.
• 16 - Wrong username/password combination
• 22- EAP negotiation failed
• 34 - The user account is disabled
• 65 - The Network Access Permission setting, in the dial-in properties of the user account is set to Deny access
• 265 - The certificate provided by the client is not trusted by the server

Microsoft has a website describing all of the Reason-Codes here.

That's all for now!