...
If you use Radsecproxy, you should send basic statistical information about the number of logins for national and international roaming to the eduroam Operations Team. The system to do that is "F-Ticks". radsecproxy has built-in support for F-Ticks if you compiled it with the
--enable-fticks
option. If that is done, you : you simply add an option to all client { } definitions for which you know the country they are physically located in. That typically means all your connected institutions' RADIUS clients, at the national level, but excludes the international roaming top-level servers (e.g. the European Top-Level RADIUS Servers). For an institution it means all your WLAN controller connections. The client definition examples below assume that you do use F-Ticks.
...
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 } |
...