A logging level of 3 is the default and recommended log level. Radsecproxy will then log successful and failed authentications on one line each. The log destination is the local syslog destination.
| Code Block |
|---|
LogLevel 3
LogDestination x-syslog:///LOG_LOCAL0
|
| ||
radsecproxy features a semi-automatic prevention of routing loops for RADIUS connections. If you define a client and server block (see below) and give them the same descriptive name, the proxy will prevent proxying from the client to that same server. Turn this feature on with:
|
This section defines which TLS certificates should be used by default. This installation of radsecproxy always uses the same certificates, so this is the only TLS section. CACertificatePath contains the eduroam-accredited CA certificates with filenames in the OpenSSL hash form. The parameters below need to be adapted to point to your server certificate in PEM format, the private key for this certificate and the password for this private key if needed, respectively. If no password is needed for the private key, you can comment this line (precede it with a # sign). The option CRLCheck validates certificates against the Certificate Revocation List (CRL) of the CAs. It requires a valid CRL in place, or else the certificate validation will fail. Therefore, it is important to regularly update the CRLs by re-downloading them as described above.
Right now, checking CRLs is discouraged due to a pending bug in OpenSSL regarding CRL reloading.
| Code Block |
|---|
tls defaultClient { CACertificatePath /etc/radsecproxy/certs/ca/ CertificateFile /etc/radsecproxy/certs/CERT_PEM__ CertificateKeyFile /etc/radsecproxy/certs/CERT_KEY__ CertificateKeyPassword __CERT_PASS__ policyOID .1.3.6.1.4.1.25178.3.1.1 # CRLCheck On } tls defaultServer { CACertificatePath /etc/radsecproxy/certs/ca/ CertificateFile /etc/radsecproxy/certs/CERT_PEM__ CertificateKeyFile /etc/radsecproxy/certs/CERT_KEY__ CertificateKeyPassword __CERT_PASS__ policyOID .1.3.6.1.4.1.25178.3.1.2 # CRLCheck On } |
The following section deletes attributes from RADIUS requests that convey VLAN assignment information. If VLAN information is sent inadvertently, it can cause a degraded or non-existent service for the end user because he might be put into the wrong VLAN. Connected service providers should filter this attribute on their own. Connected Identity Providers should not send this attribute at all. Checking for the existence of these attributes on your server is just an optional additional safety layer. If you do have a roaming use for cross-institution VLAN assignment, you may want to delete this stanza. |
| Code Block |
|---|
rewrite defaultClient {
removeAttribute 64
removeAttribute 65
removeAttribute 81
}
|
...