Как посмотреть логи радиус сервера windows

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.

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.