For those of us who manage network authentication and authorization, RADIUS is a familiar term. This protocol was introduced in the last century, and many of us from those days still remember the old-school diagrams, which surprisingly remain on the Cisco Systems website today.
RADIUS, which stands for Remote Authentication Dial-In User Service, was developed to address a specific challenge. In the past, Internet Service Providers (ISPs) had pools of dial-up connection points, and managing access to the various networks was challenging. RADIUS was the answer to managing the different types of network access from a centralized, single point of administration.
Technically, RADIUS is a protocol that enables network devices (clients) to authenticate users with a RADIUS server. The RADIUS server validates the user credentials and notifies clients whether to grant or reject network access. That simple.
While the dial-up era has been over for many years, the challenge of unifying network authentication and authorization remains, and the RADIUS protocol is still in use. Nowadays, RADIUS helps with centralized authentication, authorization, and accounting for wireless devices, authenticating switch, remote access, and virtual private network (VPN) connections.
Why use Microsoft NPS?
Microsoft Network Policy Server (NPS) is Microsoft’s implementation and extension of the RADIUS specifications. NPS allows you to manage and enforce organization-wide network access policies for connection requests.
Many RADIUS implementations store user credentials in clear text, making the server an attack vector and exposing the entire network to compromise. Hardening security and integrating these RADIUS servers with an external LDAP service requires considerable effort.
In comparison, NPS natively supports validating authentication requests with the local user accounts database (Security Accounts Manager (SAM)) and Microsoft Active Directory domain services. When NPS is part of an AD domain, it is possible to implement a single sign-on process where the same AD credentials are used for network authentication. Such an integrated solution is more secure, easier to manage, and one less set of credentials for users to remember. That’s really cool if you ask me!
Why collect Microsoft NPS/RADIUS logs?
As we already discussed, NPS is all about user authentication and authorization. We all know that authentication logs are the cornerstone of IT security, so there is no doubt that NPS/RADIUS logs should be on our collect list. These logs help us detect and respond to brute-force attacks, irregular login requests outside office hours, suspicious logins accessing critical resources, and so on. In addition, real-time security and threat management, threat-hunting, and meeting compliance mandates all require us to establish authentication logs collection and management.
You could also use NPS logs to automate network tasks. For instance, let’s say you have a wireless endpoint integrated with NPS to authenticate users and are tasked with granting IP-based network access through several firewalls as soon as the user authenticates successfully. With automatic log analysis, you can trigger a job to enable access according to the assigned IP address in the logs.
According to Microsoft, NPS creates two types of essential logs:
-
Connection logs are used primarily for auditing and troubleshooting connection attempts.
-
User accounting logs are used for connection analysis and billing purposes. Logged to a file, they also aid in security investigations because they provide a method to track a compromised user’s activity after a malicious attack.
So, how do you collect all those logs and make sense of the data?
NXLog to the rescue
NPS supports RADIUS accounting logs, such as user authentication and accounting requests, in three formats:
- IAS
-
A legacy format that writes logs in a file.
- ODBC
-
Writes logs (ODBC-compliant) in CSV format to a file.
- DTS Compliant
-
Writes logs in XML format to a file.
The IAS and DTS Compliant log formats are the most commonly used, and Microsoft recommends the latter. The newer DTS Compliant XML format consists of complex records like the following:
<Event>
<Timestamp data_type="4">12/22/2023 15:06:56.609</Timestamp>
<Computer-Name data_type="1">NAP-IAS2</Computer-Name>
<Event-Source data_type="1">IAS</Event-Source>
<Acct-Session-Id data_type="2">B3BA359F48CEDE4E9F78E5B3158F3B877E744D735B83CA01</Acct-Session-Id>
<Class data_type="1">311 1 2001:4898:b0:3007:492e:957a:d44d:7093 12/16/2009 04:32:04 145361</Class>
<MS-Extended-Quarantine-State data_type="0">0</MS-Extended-Quarantine-State>
<MS-Quarantine-State data_type="0">0</MS-Quarantine-State>
<Client-IPv6-Address data_type="5">2001:4898:b0:3007:6cc0:9514:d2ff:cdcf</Client-IPv6-Address>
<Client-Vendor data_type="0">0</Client-Vendor>
<Client-Friendly-Name data_type="1">NAP-HRA2</Client-Friendly-Name>
<Proxy-Policy-Name data_type="1">HRA</Proxy-Policy-Name>
<Provider-Type data_type="0">1</Provider-Type>
<Quarantine-Session-Id data_type="1">{9F35BAB3-CE48-4EDE-9F78-E5B3158F3B87} - 2009-12-22 23:06:53.319Z</Quarantine-Session-Id>
<Machine-Inventory data_type="1">6.1.7600 0.0 x86 Workstation</Machine-Inventory>
<Fully-Qualified-Machine-Name data_type="1">CONTOSO\CLIENT1</Fully-Qualified-Machine-Name>
<Authentication-Type data_type="0">7</Authentication-Type>
<System-Health-Result data_type="1">Windows Security Health Validator:Compliant:No Data:None[]:(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - ):(0x0 - )</System-Health-Result>
<System-Health-ResultEx data_type="1">
<SHV-Name data_type="1">Windows Security Health Validator</SHV-Name>
<Config-ID data_type="0">0</Config-ID>
<Config-Friendly-Name data_type="1"></Config-Friendly-Name>
<Health-Result data_type="1">Compliant</Health-Result>
<Extended-Isolation-State data_type="1">No Data</Extended-Isolation-State>
<Failure-Category data_type="1">None</Failure-Category>
<Failure-Category-String data_type="1"></Failure-Category-String>
<Compliance-Results data_type="1"></Compliance-Results>
</System-Health-ResultEx>
<NP-Policy-Name data_type="1">ias2-HRA-NAPSTIR-Red-Compliant</NP-Policy-Name>
<Quarantine-Update-Non-Compliant data_type="0">0</Quarantine-Update-Non-Compliant>
<Framed-Protocol data_type="0">1</Framed-Protocol>
<Service-Type data_type="0">2</Service-Type>
<Packet-Type data_type="0">2</Packet-Type>
<Reason-Code data_type="0">0</Reason-Code>
</Event>Multiline logs like the one above are relatively complex to parse with many of the log collectors on the market.
In contrast, NXLog Enterprise Edition version 6.3 and newer support collecting and parsing all three log formats with the dedicated xm_nps extension. It allows you to collect NPS logs out of the box and convert them to another log format, such as JSON:
{
"Event.Timestamp.data_type": "4",
"Event.Timestamp": "12/22/2023 15:06:56.609",
"Event.Computer-Name.data_type": "1",
"Event.Computer-Name": "NAP-IAS2",
"Event.Event-Source.data_type": "1",
"Event.Event-Source": "IAS",
"Event.Acct-Session-Id.data_type": "2",
"Event.Acct-Session-Id": "B3BA359F48CEDE4E9F78E5B3158F3B877E744D735B83CA01",
"Event.Class.data_type": "1",
// ...
"Event.Packet-Type.data_type": "0",
"Event.Packet-Type": "2",
"Event.Reason-Code.data_type": "0",
"Event.Reason-Code": "0"
}With NXLog Enterprise Edition, routing your NPS logs to a SIEM or long-term storage like Amazon S3 buckets, meeting compliance, and triggering automated network configuration and management tasks based on log data is easy. Give it a try, and get in touch with us if you need help building a solution for your use case!
