CSAM: Microsoft Logs - NPS and IAS (RADIUS)

Published: 2013-10-15
Last Updated: 2013-10-15 18:20:24 UTC
by Rob VandenBrink (Version: 1)
0 comment(s)

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:

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?

A RADIUS message was received from the invalid RADIUS client IP address a.b.c.d.

Especially when setting up a new Wireless Controller, VPN server or whatever, you'll see this.  In the NPS config, this device needs to be added as an NPS client.

If you are using NPS to authenticate administrative access to switches, routers or the like, you might see this if you've added a new switch (or whatever), but have missed the NPS client config step.

Network Policy Server granted access to a user.
Hopefully you see lots of these - successful authentication messages.
Network Policy Server granted full access to a user because the host met the defined health policy.
This one is generally tied to 6272 - after the authentication succeeds, the health policy within NPS must be satisfied before you are granted access.

Network Policy Server discarded the request for a user.

This message text doesn't correctly reflect the situation. Message 6274 is generally means that This condition occurs when NPS discards accounting requests because the RADIUS accounting request message sent by the RADIUS client does not match what NPS is expecting.

A LDAP connection with domain controller DC0x.mydomain.com for domain MYDOMAIN is established.
You'll see this one crop up occasionaly - it's just NPS "checking in" with it's domain controllers.  If it's a quiet system, you might see this followed immediately by an authentication request

Domain controller S-HOF-DC3.mscu.com for domain MSCU is not responsive. NPS switches to other DCs.
Oops - look like there's a problem with one of the domain controllers.  You'll often see this one on Patch Tuesdays, when servers reboot after patching.
There is no domain controller available for domain MNP

This one is also often seen on Patch Tuesdays, either when the NPS server reloads, and the service might have come up before the network, or if all DC's are in the process of rebooting.

If this comes up in other situations, you might have a more serious problem on the NPS server or on the network.


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

Keywords: CSAM 2013
0 comment(s)


Diary Archives