Radsecproxy

Die Föderationsanbindung der lokalen Einrichtungen an die globale eduroam-Infrastruktur geschieht über die Föderationsproxies des Deutschen Forschungsnetzes. Hierfür wird RADIUS over TLS ( RFC6614 ) genutzt.

Als Software empfehlen wir radsecproxy. Die Software kann aus den Paketquellen installiert (z.B. bei Debian über apt install radsecproxy) oder selbst kompiliert werden. Anleitungen zum selbst kompilieren finden sich auf der Seite von radsecproxy.

Die Konfiguration geschieht dann über die Datei /etc/radsecproxy.conf

Wir haben eine Beispielkonfiguration mit den wichtigsten Elementen, die einzelnen Konfigurationsblöcke sind im Folgenden auf dieser Seite beschrieben.

Die Verbindung zum Föderationsproxy wird über TLS abgesichert. Hierfür benötigt Radsecproxy ein Zertifikat, ebenso müssen die Zertifikate der Gegenstelle überprüft werden. Da radsecproxy in der Regel unter dem User-Account radsecproxy läuft, empfiehlt es sich, einen neuen Ordner /etc/radsecproxy anzulegen, auf dem der radsecproxy-User entsprechende Leserechte besitzt.

Die CA wird vom DFN fest gesetzt. Soll die CA also gewechselt werden, muss das in Koordination mit dem DFN erfolgen.

Der DFN-Verein betreibt eine Special-Purpose-CA für die Anbindung der lokalen Radsecproxies an die Föderationsinfrastruktur. Die Beantragung von Zertifikaten dieser CA ist hier beschrieben.

Für die korrekte Funktionsweise muss das CA-Zertifikat in den entsprechenden Ordner heruntergeladen werden ( https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt ).

$> wget -O /etc/radsecproxy/eduroam-ca.pem https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt

Der TLS-Block in der radsecproxy.conf kann dann wie folgt aussehen:

tls default {
    CACertificateFile   /etc/radsecproxy/eduroam-ca.pem
    CertificateFile     /etc/radsecproxy/ihr-eduroam-ca-zertifikat.pem
    CertificateKeyFile  /etc/radsecproxy/ihr-eduroam-ca-private-key.pem
}

Die CA unterscheidet zwischen eduroam IdP und eduroam SP. Achten Sie hierbei also darauf, dass Sie bei der Beantragung das korrekte Zertifikatsprofil auswählen.

Mit der Abkündigung der DFN-PKI zu Ende 2022 muss auf die eduroam-CA umgestellt werden.

Zertifikate der DFN-PKI müssen mit dem Profil “RADIUS-Server” erstellt werden, Nur dann haben sie die benötigten Zertifikatsattribute. Die Zertifikate müssen über den PKI-Zugang Ihrer Einrichtung beantragt und genehmigt werden.

Wird ein DFN-PKI-Zertifikat für die Authentifizierung genutzt, muss auch das Server-Zertifikat von den Föderationsservern gegen die DFN-PKI (bzw. gegen das Root-Zertifikat von TeleSec) geprüft werden. Dazu kann der TLS-Block in der radsecproxy.conf so aussehen:

tls default {
    CACertificateFile   /etc/ssl/certs/T-TeleSec_GlobalRoot_Class_2.pem
    CertificateFile     /etc/radsecproxy/ihr-dfn-pki-zertifikat.pem
    CertificateKeyFile  /etc/radsecproxy/ihr-dfn-pki-private-key.pem
}

Der DFN-Verein betreibt 3 Föderationsserver mit folgenden Details:

Name
tld1.eduroam.de
tld2.eduroam.de
tld3.eduroam.de

client tld1.eduroam.de {
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
}
client tld2.eduroam.de {
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
}
client tld3.eduroam.de {
    type tls
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
}

server tld1.eduroam.de {
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
}
server tld2.eduroam.de {
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
}
server tld3.eduroam.de  {
    type tls
    StatusServer on
    CertificateNameCheck Off
    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
}

Beim Start von Radsecproxy wird ein DNS-Lookup durchgeführt. Schlägt das DNS-Lookup fehl, startet Radsecproxy nicht.

Die Anbindung der Access Points bzw. WLAN-Controller kann auf zwei verschiedene Arten erfolgen:

Sie können entweder an den RADIUS-Server angebunden werden. In diesem Fall reicht der Radsecproxy die Authentifizierungen einfach nur an den lokalen FreeRADIUS weiter und benötigt zu diesem auch eine Anbindung in beide Richtungen.

Alternativ können die APs/Controller auch direkt an den Radsecproxy angebunden werden. Dieses Setup wird bei reinen SP-Installationen empfohlen, da hier keine Erfordernis für einen RADIUS-Server gibt.

Laufen RADIUS-Server und radsecproxy auf dem selben Server, muss der RADIUS-Port von radsecproxy über die Anweisung ListenUDP <IP-Adresse des Servers>:<UDP-Port> auf einen anderen Port gesetzt werden.

Die Clients können dabei entweder einzeln mit ihrer jeweiligen IP-Adresse oder als ein ganzes Subnetz konfiguriert werden.

client 192.0.2.1 {
    type udp
    secret <shared secret>
}
client 198.51.100.0/24 {
    type udp
    secret <shared secret>
}

Der eigene RADIUS-Server kann über einen Server-Block an den Radsecproxy angebunden werden:

server ihr-radius-server {
    type udp
    host 203.0.113.1
    secret <shared secret>
}

Haben Sie mehrere RADIUS-Server, müssen Sie entsprechend mehrere Server-Blöcke anlegen.

server ihr-radius-server-1 {
    type udp
    host 203.0.113.1
    secret <shared secret>
}
server ihr-radius-server-2 {
    type udp
    host 203.0.113.2
    secret <shared secret>
}

Das Routing der verschiedenen Realms geschieht über realm-Blöcke. Hier wird für jede Realm definiert, welcher Server zuständig ist. Die angegeben Namen entsprechen hierbei den angegebenen Namen der server-Blöcke. Existieren mehrere RADIUS-Server, können im Realm-Block mehrere angegeben werden. Radsecproxy wird sie in der angegebenen Reihenfolge durchprobieren. Die Redundanz ist hier nach Hot-Standby (der nächste Server wird erst genutzt, wenn der vorherige ausfällt) und nicht im Round-Robin oder Load-Balancing.

Um die Last auf den Föderationsserver des DFN zu verringern, sollten verbreitete Fehler in der Realm-Konfiguration bereits auf dem lokalen Radsecproxy abgefangen werden. Dazu gehören z.B. Leerzeichen im Realm (z.B. am Ende, wenn Autocomplete genutzt wurde) oder 3GPP-Realms, die für SIM-Authentifizierungen im Mobilfunknetz genutzt werden. Da Radsecproxy die Realms sequenziell nach der Reihenfolge in der Konfiguration durchgeht, muss dieser Block entsprechend vor der Default-Regel stehen.

realm ihre-realm.de {
    server ihr-radius-server-1
    server ihr-radius-server-2
}

# Abfangen von typischen Fehlkonfigurationen in Clients
# (Vor dem Default-Block, da sonst die Regeln nicht ausgewertet werden.)
realm /\.$/ {
    replymessage "Misconfigured client: Realm must not end with dot."
}
realm /\.3gppnetwork.*/ {
    replymessage "Misconfigured client: 3GPP realm is not usable for eduroam."
}
realm /\s/ {
    replymessage "Misconfigured client: Realm must not contain spaces"
}
realm /^[^@]+$ {
    replymessage "Misconfigured client: Empty realm makes no sense."
}

# Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten
# Dieser Block sollte ganz am Ende der Konfiguration stehen
realm * {
    server tld1.eduroam.de
    server tld2.eduroam.de
    server tld3.eduroam.de
}

Radsecproxy

Zertifikate

eduroam-CA

DFN-PKI

Konfiguration der Föderationsserver

Clients

Server

Konfiguration der Anbindung von lokalem RADIUS-Server und Access Points

Realm-Konfiguration