Windows radius server logs

What is a RADIUS event log?

A RADIUS server is responsible for Authorization and Accounting
in addition to its primary role of Authentication, hence its alternate name: “AAA
server”. Given the importance of these tasks, it should come as no surprise that a RADIUS server
is typically configured to log and store a record of all the requests it receives.

RADIUS event logs may be used for:

• Compliance audits
• Troubleshooting authentication issues
• Troubleshooting VPN issues
• Tracking use
• Tracking users
• Tracking devices

And more! RADIUS event logs are a powerful tool for managing your 802.1x network and users.

What information is included in a RADIUS Log?

The data contained within a RADIUS event log varies from RADIUS to RADIUS, but there are some
common fields that you’re likely to find no matter your RADIUS provider.

• Date
• Time
• Name
• Client Type
• Record Type
• Authentication Type

RADIUS vendors with a robust management and reporting suite, like our own SecureW2 Cloud RADIUS,
have the ability to add and remove data fields from event logs. Custom RADIUS event logs can be
particularly useful for compliance audits.

In addition to event logs for authentication and authorization requests, RADIUS servers usually
also log other event types like server startups, shutdowns, or interruptions of service. These
make up a small fraction of the overall logs, but are particularly useful for investigating
outages and the like.

How to view FreeRADIUS logs

FreeRADIUS is an open source framework for implementing your own DIY RADIUS. It requires a lot of
technical expertise and hardware (or cloud server space) to configure and maintain, but it’s
powerful and infinitely customizable. 

During the configuration process for a FreeRADIUS
server, admins are required to
designate a folder for RADIUS event log output. FreeRADIUS doesn’t do anything with the logs,
however, so you’ll need to manually process the raw data to a more human readable form if you plan
to make extensive use of the logs.

How to view NPS logs

NPS is Microsoft’s pseudo-RADIUS that has seen widespread adoption due to its tight integration
with the rest of the Microsoft environment. In particular, it plays well with Active Directory
(AD), which is the IdP of choice for many organizations.

Viewing event logs generated by an NPS RADIUS is easy, if a little unintuitive. Rather than
finding them in NPS, check the Windows Event Viewer (another system that’s part of the larger
Windows Server package). 

However, neither AD nor NPS have truly made the leap to the cloud. There are workarounds that
allow you to use them in a limited capacity, but organizations that are using cloud directories
like Google, Azure, or Okta should not use stopgap measures for network security. Limited support
and antiquated systems leave your network vulnerable.. 

The best RADIUS event logging solution

Instead, use a built-for-cloud RADIUS like the aptly-named SecureW2 Cloud RADIUS. Not only has it
been engineered for the ground up for cloud authentication, it also has an incredibly
simple-yet-powerful management interface with unprecedented power over RADIUS event logging.

Картинка с сайта: windoro.ru

Unlike our competitors, our cloud PKI isn’t simply a layered directory with some added bells and
whistles. It’s a full-featured PKI security suite that can integrate into your existing network
infrastructure or be used as a turnkey solution.

But wait, there’s more! It comes with the industry’s #1 rated 802.1x onboarding software. So not
only can you easily view RADIUS events, but you can easily see device connectivity issues and
certificate enrollment status all in one place. No longer do admins need to manually scour through
logs, everything needed to troubleshoot issues is available in our easy to use Cloud Management
Portal.

Our Cloud RADIUS is powered by the Dynamic Policy Engine – a network access control solution that
allows the RADIUS to interface directly with any cloud directory to confirm authorization
requests. Instead of relying on insecure credentials or static certificates, you can make
real-time policy decisions based on user attributes stored in the directory.

We have affordable solutions for organizations of every size. Check out our
pricing page here.

The «log» section of the radiusd.conf file is where the primary logging configuration for the FreeRADIUS server is located.

log {
    destination = files
    file = ${logdir}/radius.log
#   requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log
    syslog_facility = daemon
    stripped_names = no
    auth = no
    auth_badpass = no
    auth_goodpass = no
#   msg_goodpass = ""
#   msg_badpass = ""
}

Log Destination

Destination for log messages. This can be one of the following values:

• files — log to «file», as defined below.
• syslog — send log messages to syslog (see also the «syslog_facility» below).
• stdout — log to standard output.
• stderr — log to standard error.

Note that the command-line debugging option «-X» overrides this option, and forces all logging to go to stdout.

Default:

destination = files

Log File Location

If the destination == «files», then the logging messages for the server are appended to the tail of this file. Again, note that if the server is running in debugging mode, this file is NOT used.

Default:

file = ${logdir}/radius.log

Requests Log

If this configuration parameter is set, then log messages for a request go to this file. This is a log file per request, once the server has accepted the request as being from a valid client. Messages that are not associated with a request still go to radius.log defined above.

Note that not all log messages in the server core have been updated to use this new internal API. As a result, some messages will still go to radius.log. Patches are welcome to fix this behavior.

The file name is expanded dynamically. You should ONLY user server-side attributes for the filename, i.e. things you control. Using this feature MAY also slow down the server substantially, especially if you do things like SQL calls as part of the expansion of the filename.

The name of the log file should use attributes that don’t change over the lifetime of a request, such as User-Name,
Virtual-Server or Packet-Src-IP-Address. Otherwise, the log messages will be distributed over multiple files.

Default (disabled):

requests = ${logdir}/radiusd-%{%{Virtual-Server}:-DEFAULT}-%Y%m%d.log

Syslog Facility

This option determines which syslog facility to use, if destination == «syslog» The exact values permitted here are OS-dependent.

Default:

syslog_facility = daemon

Log User-Name Attribute

Log the full User-Name attribute, as it was found in the request. The allowed values are: {no, yes}

Default:

stripped_names = no

Log Authentication Requests

Log authentication requests to the log file. The allowed values are: {no, yes}

Default:

auth = no

Log Passwords

Log passwords with the authentication requests.

• auth_badpass — logs password if it’s rejected
• auth_goodpass — logs password if it’s correct

The allowed values are: {no, yes}

Default:

auth_badpass = no
auth_goodpass = no

Log Additional Text

Log additional text at the end of the «Login OK» messages. For these to work, the «auth» and «auth_goodpass» or «auth_badpass» configurations above have to be set to «yes».

The strings below are dynamically expanded, which means that you can put anything you want in them. However, note that this expansion can be slow, and can negatively impact server performance.

Default (disabled):

msg_goodpass = ""
msg_badpass = ""

Log Additional Debug Information

Logging can also be enabled for an individual request by a special dynamic expansion macro: %{debug: #}, where # is the debug level for this request (1, 2, 3, etc.). For example:

...
update control {
       Tmp-String-0 = "%{debug:1}"
}
...

The attribute that the value is assigned to is unimportant, and should be a «throw-away» attribute with no side effects.

For example, in the «authorize» section:

if ("%{User-Name}" == "juliasmith") {
        update control {
             Tmp-String-0 = "%{debug:3}"
        }
}

The server log file records RADIUS events, such as server startup or shutdown or user authentication or rejection, as a series of messages in an ASCII text file. Each line of the server log file identifies the date and time of the RADIUS event, followed by event details. You can open the current log file while RADIUS is running.

Log RotationLog Rotation

Log rotation prevents RADIUS server logs from growing indefinitely. You can rotate RADIUS server log files by date or size:

• By default, RADIUS server log files are rotated daily with a filename extension that specifies the year, month, and day. You can rotate log files daily, weekly, or monthly.

  The current log file is named radius.log, and rotated log files are named radius.log-YYYYMMDD, where YYYYMMDD specifies the date. For example:

  -rw——- 1 rsaadmin rsaadmin 120 Dec 3 00:36 radius.log-20201203

  -rw——- 1 rsaadmin rsaadmin 3613 Dec 4 00:37 radius.log

• To rotate log files by size, instead of date, use the size parameter in the radiusd file to specify a maximum size for a server log file. By default, the size parameter is commented out and set to 0.

  The current log file is named radius.log, and rotated log files are named radius.log.n, where n is 1, 2, 3, and so forth. For example, the most recent rotated log file is named radius.log.1. When radius.log reaches the maxium size, a new radius.log file is created, the current radius.log file is rotated and renamed radius.log.1, and the previous radius.log.1 file is renamed radius.log.2.

  The size option is mutually exclusive with the time interval options (daily, weekly, or monthly). If you specify the size option after you specify time criteria, then log files are rotated without regard for the last rotation time. The last specified option takes precedence.

Use SSH to configure RSA RADIUS log rotation in the /etc/logrotate.d/radiusd file. For instructions, see the RSA Authentication Manager RADIUS Reference Guide.

Debugging LevelDebugging Level

By default, RSA RADIUS debugging is turned off. You can enable additional logging to obtain useful information for troubleshooting. Change the debug_level to 1 or 2, depending upon how much information you want to log:

debug_level=0

Entering any invalid value, such as 3, resets the debug_level to the default value of 0.

Note: Do not change the «suppress_secrets = yes» configuration. Changing this value to «no» would log the user passcode and the client shared secret in plain text at log level 1 and 2.

RSA RADIUS debugging is configured by editing the radiusd.conf file in the Operations Console. For instructions, see Edit RADIUS Server Files.

When Network Policy Server (NPS) is configured as a RADIUS server, it performs authentication, authorization, and accounting for connection requests received from configured RADIUS clients.

If authentication and authorizations are successful, users and computers are granted access to the network resources for which they have permissions.

So far the theory …

I did not get any event logs though ?

So I checked the NPS properties on the newly configured NPS server, and all looked OK ?

I also checked the accounting log settings, and not problems here as well ?

Картинка с сайта: audministrator.wordpress.com

I restarted the NPS service and even the server but no success ?

Solution :

So Google was here to help.

Open the cmd with admin privileges and run this command

auditpol /get /subcategory:"Network Policy Server"

Next run this cmd.

auditpol /set /subcategory:"Network Policy Server" /success:enable /failure:enable

And check if it shows this result :

Try to log on to the VPN and see if the event logs start appearing.

Картинка с сайта: audministrator.wordpress.com

Which is did in my case

Enjoy !

This entry was posted on Thursday, November 19th, 2020 at 3:49 pm and is filed under Uncategorized. You can follow any responses to this entry through the RSS 2.0 feed.
You can leave a response, or trackback from your own site.

RADIUS servers are often called AAA (authentication, authorization and accounting) servers because they perform each of those three functions. Accounting – which refers to the process of tracking events as they occur – is something a RADIUS server achieves by generating event logs.

RADIUS logs contain detailed information on the clients accessing your network. Checking here should be one of your first steps when determining what the cause of network connectivity issues is – or when you suspect unauthorized network access. In this blog, we’ll show you exactly where to find RADIUS event logs, and why they’re important.

What are RADIUS Event Logs?

RADIUS servers can be configured to perform event logging, an in-depth record of events related to connection requests from RADIUS clients. These event logs can vary in detail, but they will often show things such as the device, OS, user, whether the authentication was successful or failed, and error messages related to the authentication attempt.

Logs can be generated every time a RADIUS client attempts to authenticate to your network or VPN. They’re a great starting point for determining the root cause of Wi-Fi connectivity issues, or for meeting compliance requirements from auditing or regulatory authorities.

RADIUS Event Log Use Cases

Keeping event logs and regularly auditing them is necessary for modern cybersecurity. RADIUS event logs can be and are used for a variety of purposes, including the following:

• Compliance audits
• Troubleshooting authentication issues
• Troubleshooting Wi-Fi and VPN connectivity problems
• Tracking the devices accessing your network
• SIEM or Syslog alarms

Basically, event logs can be used anytime you need to troubleshoot connection issues for a particular user or device. They can also be imported to any Security Information and Event Management (SIEM) software you use, so you can be alerted right away when connection issues arise. In this way, they can potentially serve as the basis for the first notice you receive when there are problems with authentication to your network.

Finding Logs from Different RADIUS Servers

Network Policy Server (NPS) Logs

Картинка с сайта: www.securew2.com

Network Policy Server (NPS) is Microsoft’s implementation of RADIUS. Network Policy Server logs can be viewed using Windows Server Manager or Windows Event Viewer UI (another system, part of the larger Windows Server package). You must decide whether you want to log RADIUS client authentication and accounting information to text log files stored on the local computer or to a SQL Server database on either the local computer or a remote computer. Like with other RADIUS servers, NPS event logs contain authentication results and the reason for any failed authentication attempts.

NPS is only suitable as an addition to an existing Windows Server in most environments. Its logs may not be as detailed as other RADIUS server logs, sometimes missing accurate reasons for connection failures like when users type in wrong passwords.

NPS and Active Directory (AD) are generally tied to on-premise infrastructure, as well. This means that NPS may not be a suitable choice for organizations looking for cloud-based identity management and access control solutions, such as Azure AD (Microsoft Entra ID) or similar.

FreeRADIUS Logs

FreeRADIUS is an open-source RADIUS server free for download and use. It can run on Unix-based platforms.

Картинка с сайта: www.securew2.com

By default, Free RADIUS stores accounting information in /var/log/freeradius of the Unix platform, but accessing these logs takes some technical expertise.

Where Do I Find Cloud RADIUS Event Logs?

Картинка с сайта: www.securew2.com

Cloud RADIUS, unlike an NPS server, is a managed and cloud-based platform that can be configured and deployed to any location. It also captures detailed logs for every network connection request and provides extensive information in addition to ACCESS_ACCEPT and ACCESS_REJECT responses.

This information can be easily found in the SecureW2 management portal by navigating to Data & Management, then selecting the RADIUS Events option.

Cloud RADIUS Event Log Fields and Meanings

Cloud RADIUS event logs were designed to provide administrators a clear snapshot of each authentication attempt. As such, we’ve incorporated numerous fields in them, including the following:

⦁ Region – Origin of the connection request.
⦁ Timestamp – Recorded time of the connection request.
⦁ Identity – Username used during the authentication.
⦁ Subject/Common Name – Name of the user using the certificate or token.
⦁ User Principal Name – Email ID of the user trying to connect to the network.
⦁ Device – Information related to the device such as a serial number.
⦁ Certificate serial – Serial number of the device’s certificate trying to connect to the network.
⦁ MAC Address – Media Access Control Address of the device trying to connect to the network.
⦁ Client Public IP – IPv4 address of the device, needed for the network to reach the device.
⦁ Operating System – Software that supports the device trying to connect to the network.
⦁ User Role – The user role designated by the administrator that the user belongs to.
⦁ Network Policy – This shows the network policy that applies to the user.
⦁ RADIUS Reply – Status of the RADIUS Authentication (ACCESS_ACCEPT/ACCESS_REJECT)
⦁ Error Message – If applicable, the reason why the remote access authentication attempt failed.

Cloud RADIUS Event Log Search Filters

Картинка с сайта: www.securew2.com

RADIUS logs are a great tool for troubleshooting when you start getting reports that users can’t connect to your network. Granular search filters make it simpler to access them, which is why Cloud RADIUS includes a range of search settings.

Narrow your search by checking a specific user, for example, when only a single person is experiencing connectivity issues. You can also search by operating system, MAC address, and more.

Detailed and Easily Accessible Logs with Cloud RADIUS

Картинка с сайта: www.securew2.com

Event logs serve many purposes: they can be your first line of defense when an unauthorized party accesses your network, they can help you rapidly pinpoint the root cause of network connectivity problems, and they may be required for compliance reasons. Being able to quickly access and read RADIUS records is crucial.

Cloud RADIUS event logs streamline this process. Every authentication attempt is recorded in a detailed entry that provides administrators enhanced visibility. Additionally, granular search filters make it a simple matter to find the exact entry you need when you need it. Organizations using SecureW2’s Cloud RADIUS can not only view events from the management portal, but also export data to a SIEM provider to trigger an alarm and have notifications on the occurrence of connectivity issues.

We have affordable solutions for organizations of every size. Check out our pricing page here.