SANS ISC: CSAM: Microsoft Logs - NPS and IAS (RADIUS)

• SANS Site Network
  • Current Site
  • SANS Internet Storm Center
  • Other SANS Sites Help
  • Graduate Degree Programs
  • Security Training
  • Security Certification
  • Security Awareness Training
  • Penetration Testing
  • Industrial Control Systems
  • Cyber Defense Foundations
  • DFIR
  • Software Security
  • Government OnSite Training

SANS ISC InfoSec Forums

Without a doubt, when discussing Windows logs the most common questions I get from my clients are almost about authentication, in particular about authenticating Wireless or VPN sessions using RADIUS.

Microsoft has supported RADIUS for years as IAS (Internet Authentication Service), and have changed the name to NPS (Network Policy and Access Services) in Windows Server 2008, along with adding a boatload of new features.

Where can you find NPS logs? - in a few places actually.  Many administrators will find NPS logs easiest to access in the Windows Event Viewer, where it's broken out nicely.

Most administrators will also store a text log.  If you're anything like me, using the grep, find or findstr commands are the go-to method of log access.

On to the logs themselves.  The sort of question I normally get with NPS is "why can't this user access the wireless/vpn/whatever network?", especially when other users can.  In almost all cases, the NPS Service logs will tell you exactly why, but the reason isn't always presented as easily as it could be.

For instance:

6273
Network Policy Server denied access to a user.
Contact the Network Policy Server administrator for more information.

Looking at a typical log, you'll get a generic "denied" mesage, but you'll also have the ip address of the NAS (Network Access Server), which is usually a vpn gateway, wireless controller or ap - the NAS is often the RADIUS client as well.  You'll often also have the MAC address of the AP too, or if you're running an older wireless infrastructure with no controller, the NAS will be the AP.

If it's a wireless access request, you'll also have the mac address of the calling station (which would be the workstation).

So why exactly did your user get denied access?  In the event viewer message, scroll to the very bottom, and check the Reason Code field and the text associated with it

A really common reason code is 65, especially during the initial setup of a new SSID or Policy:  "The connection attempt failed because network access permission for the user account was denied. To allow network access, enable network access permission for the user account, or, if the user account specifies that access is controlled through the matching network policy, enable network access permission for that network policy."

The easiest way to fix this one is to add a single tick-box in your radius configuration - in the network policy, in the middle of the first page, tick the box that says "Ignore User account dial-in properties"  If you don't do this, every access request will look at the account permissions to see if they have "Allow Access" enabled under their Dial-in / Network Access Permissions setting.

Of course, the other common reason code on error 6273 would be 16:

    Reason Code:            16
    Reason:                Authentication was not successful because an unknown user name or incorrect password was used.

You'll often see this one if you are doing authentication with the workstation's domain Machine Account - if a user who's machine is not in the domain selects that SSID, that account will of course not exist.

And of course, if you see dozens and hundreds of these, you might be seeing an authentication attack against your wireless system.  The common protections against this are account lockout settings, and NEVER EVER putting accounts that don't have account lockout into VPN or Wireless access groups.  The Domain account "Administrator" would be the classic example of this - it's got access to everything in the domain, and by default has the account lockout settings disabled.  "Administrator" is always the target account in both legitimate pentests and real life attacks, so you're best not to permit remote access via this account.  NPS Reason Code 36 indicates that the account in the log message has been locked out.

Especially during setup of a new SSID, you'll see accounts fail authentication when you are sure the account credentials are correct -  in that case check your policy, quite often the NPS Policy will be based on AD groups, but either the user or the machine will need to be in the right group (for instance, "Corporate Wireless").  It's very common to miss this group membership requirement on either or both of these accounts when things are first being put together, or when you are adding new users or machines to the domain.  For instance, in early September we saw a number of schools run into this as they added student accounts.

All NPS reason codes are listed here: http://technet.microsoft.com/en-us/library/dd197570.aspx

What other NPS message IDs will you commonly see in your logs?

What errors or reason codes have you seen in your system?  Please use our comment form to let us know what you've seen in your NPS logs, how the message helped you solve the problem (or not), and what your solution was.

.===============
Rob VandenBrink
Metafore