not logged in | [Login]

Quick Links

Always use radiusd -X when debugging!

Logging in an eduroam environment

Running an eduroam service will generally mean there is a requirement for logging the users of the service. National education networks will also likely require that logs are kept of who is using the network. This means that logs must be kept of both authentication and accounting requests (and likely DHCP as well).

The easiest and most basic method of log keeping will be to record, in some form or another, every packet that is received or sent by the server. This is what is done by the basic eduroam guide and, while fulfilling the requirements, is not necessarily the most efficient.

EAP has many round trips, and keeping a record of all of these packets is generally unnecessary. However it is also not acceptable to just record Access-Accept or Access-Reject packets and their contents. They will generally not include attributes such as Calling-Station-Id, and will also not log authentication attempts that do not fully complete.

Therefore at least the following should be logged, each with an accurate timestamp:

  • Initial authentication request, with

    • User-Name (outer)
    • Calling-Station-Id
    • NAS-IP-Address

  • When sending an Access-Accept reply

    • Packet-Type ("Accept")
    • User-Name (outer)
    • User-Name (inner)
    • Calling-Station-Id
    • Operator-Name
    • Chargeable-User-Identity
    • NAS-IP-Address

  • When sending an Access-Reject reply

    • Packet-Type ("Reject")
    • Reason for rejection (Module-Failure-Message)
    • User-Name (outer)
    • User-Name (inner)
    • Calling-Station-Id
    • Operator-Name
    • Chargeable-User-Identity
    • NAS-IP-Address

Logging the initial EAP request

The &session-state: list can be used to determine whether the incoming request is the first in an EAP transaction, as on the first packet the list will be empty. Update the list at the same time to ensure that it is not empty on the next round; we can use Tmp-String-1 to note the type of log record.

Make these changes in the default server (raddb/sites-enabled/default).

authorize {
    if (!&session-state:) {
        update session-state {
            &Tmp-String-1 := "request"
        }
        linelog
    }
    ...
}

Recording the inner User-Name

To log the inner User-Name, it needs to be copied from the inner-tunnel to the outer. In raddb/sites-enabled/inner-tunnel, update post-auth:

server inner-tunnel {
    post-auth {
        ...
        update outer.session-state {
            &User-Name := &User-Name
        }

        Post-Auth-Type REJECT {
            ...
            update outer.session-state {
                &User-Name := &User-Name
            }
        }
    }
}

Logging Accept or Reject

Once again in the outer server, update the post-auth section to log the reply with the required attributes.

server default {
    post-auth {
        ...
        update session-state {
            &Tmp-String-1 := "accept"
        }
        linelog

        Post-Auth-Type REJECT {
            ...
            update session-state {
                &Tmp-String-1 := "reject"
            }
            linelog
        }
    }
}

Configuring logging

The examples above use the linelog module as an example, but in reality many different logging methods could be used in the same place. An example linelog configuration could be something like

linelog {
    filename = /path/to/log/file
    permissions = 0600
    reference = "messages.%{session-state:Tmp-String-1}"
    messages {
        request = "%T request %{User-Name} %{Calling-Station-Id} ..."
        accept = "%T accept %{User-Name} %{session-state:User-Name} %{Calling-Station-Id} ..."
        reject = "%T reject %{User-Name} %{session-state:User-Name} %{Calling-Station-Id} ..."
    }
}