Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2018/04/20 12:02] – gelöscht Ralf Paffrath
+++ de:eduroam:anleitungen:radsecproxy [2025/02/07 12:42] (aktuell) – [DFN-PKI] Ralf Paffrath
@@ Zeile 1: / Zeile 1: @@
+====== 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 ( [[https://datatracker.ietf.org/doc/html/rfc6614|RFC6614]] ) genutzt.
+Als Software empfehlen wir [[https://radsecproxy.github.io/|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 [[de:eduroam:anleitungen:radsecproxy.conf|Beispielkonfiguration]] mit den wichtigsten Elementen, die einzelnen Konfigurationsblöcke sind im Folgenden auf dieser Seite beschrieben.
+===== Zertifikate =====
+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.
+<alert>Die CA wird vom DFN fest gesetzt. Soll die CA also gewechselt werden, muss das in Koordination mit dem DFN erfolgen.</alert>
+==== eduroam-CA ====
+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 [[de:eduroam:eduroam-ca|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 ).
+<code>
+$> wget -O /etc/radsecproxy/eduroam-ca.pem https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt
+</code>
+Der TLS-Block in der ''%%radsecproxy.conf%%'' kann dann wie folgt aussehen:
+<code>
+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
+}
+</code>
+<alert>Die CA unterscheidet zwischen eduroam IdP und eduroam SP. Achten Sie hierbei also darauf, dass Sie bei der Beantragung das korrekte Zertifikatsprofil auswählen.</alert>
+===== Konfiguration der Föderationsserver =====
+Der DFN-Verein betreibt 3 Föderationsserver mit folgenden Details:
+^Name           ^
+|tld1.eduroam.de|
+|tld2.eduroam.de|
+|tld3.eduroam.de|
+==== Clients ====
+<code>
+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$/
+}</code>
+==== Server ====
+<code>
+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$/
+}
+</code>
+<alert>Beim Start von Radsecproxy wird ein DNS-Lookup durchgeführt. Schlägt das DNS-Lookup fehl, startet Radsecproxy nicht.</alert>
+===== Konfiguration der Anbindung von lokalem RADIUS-Server und Access Points =====
+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.
+<code>
+client 192.0.2.1 {
+    type udp
+    secret <shared secret>
+}
+client 198.51.100.0/24 {
+    type udp
+    secret <shared secret>
+}
+</code>
+Der eigene RADIUS-Server kann über einen Server-Block an den Radsecproxy angebunden werden:
+<code>
+server ihr-radius-server {
+    type udp
+    host 203.0.113.1
+    secret <shared secret>
+}
+</code>
+Haben Sie mehrere RADIUS-Server, müssen Sie entsprechend mehrere Server-Blöcke anlegen.
+<code>
+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>
+}
+</code>
+===== Realm-Konfiguration =====
+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.
+<code>
+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
+}
+</code>