Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2018/02/19 15:01] – [Einbindung des eigenen WLANs / SP-Teil] Steffen Klemer
+++ de:eduroam:anleitungen:radsecproxy [2023/06/27 17:30] (aktuell) – TCS-Konfiguration entfernt Jan-Frederik Rieckers
@@ Zeile 1: / Zeile 1: @@
-====== Leitfaden Einrichtung Radsecproxy für dfn eduroam ======
+====== 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.
-Die Verbindung zwischen DFN eduroam-Server und den Einrichtungen erfolgt
+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.
-via radsec-Protokoll (RFC 6614). Eine Möglichkeit hierfür ist das
-Programm [[https://software.nordu.net/radsecproxy/|radsecproxy]], das auch bereits in einigen Linux
-Distributionen zu finden ist. Da es nur wenige Anforderungen hat, ist
-aber auch das Selbst-Kompilieren meist ohne großen Aufwand möglich.
-Es läuft momentan nur in Unix-Umgebungen, ist aber ressourcensparend genug, dass es problemlos in einer VM betrieben werden kann.
+Die Konfiguration geschieht dann über die Datei ''%%/etc/radsecproxy.conf%%''
-===== Einbindung des eigenen WLANs / SP-Teil =====
+Wir haben eine [[de:eduroam:anleitungen:radsecproxy.conf|Beispielkonfiguration]] mit den wichtigsten Elementen, die einzelnen Konfigurationsblöcke sind im Folgenden auf dieser Seite beschrieben.
-Es gibt 2 Möglichkeiten für den SP-Betrieb:
+===== Zertifikate =====
-) Das lokale WLAN spricht mit dem RSP:
+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.
-<code>
+<alert>Die CA wird vom DFN fest gesetzt. Soll die CA also gewechselt werden, muss das in Koordination mit dem DFN erfolgen.</alert>
-WLAN-Controller ----- RSP --------------- DFN
-                       |
-                       |
-                       | (nur Anfragen für eigenen @REALM)
-RADIUS-Server ---------+
-</code>
-Vorteil:
+==== eduroam-CA ====
-  - Alle Anfragen von Gästen und die allermeisten 'unsauberen' Pakete werden vom RSP bearbeitet und entweder direkt verworfen oder zum DFN geschickt. Beim  ggf. im internen Netz stehenden RADIUS-Server landen nur relevante Anfragen.
-  - Der RSP leitet auch 'übergroße' EAP-Pakete sauber und korrekt zum DFN, was einige Probleme mit Roaming-Gästen verhindert.
+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.
-) Das lokale WLAN spricht mit dem RADIUS-Server:
+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>
-WLAN-Controller --- RADIUS-Server --- RSP -------- DFN
+$> wget -O /etc/radsecproxy/eduroam-ca.pem https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt
 </code>
-Vorteil:
+Der TLS-Block in der ''%%radsecproxy.conf%%'' kann dann wie folgt aussehen:
-  - ggf. bereits bestehende Struktur muss nicht verändert werden; es wird nur der RSP zwischen RADIUS-Server und DFN gesetzt.
-  - Eine Übergabe von Attributen (zB [[de:eduroam:witzetippsundtricks|Client-spezifische VLANs]]) vom RADIUS-Server vom WLAN-Controller ist einfacher möglich.
-===== Distributionen =====
+<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>
+==== DFN-PKI ====
-Für Ubuntu 16.04. bietet es sich an, zunächst das Paket von [[https://files.dfn.de/index.php/s/LPjdpDXlHEoXlaF]]
+<alert>Mit der Abkündigung der DFN-PKI zu Ende 2022 muss auf die eduroam-CA umgestellt werden.</alert>
-zu verwenden, da hier ein größeres Problem im Zusammenspiel mit
-neueren Linux-Kerneln geschlossen wurde.
+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.
-Bei Debian sind die Distri-eigenen Pakete eine gute Wahl.
+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:
-Andere Distributionen und Betriebssysteme funktionieren auch wunderbar
-und können gerne eingesetzt werden. Wir können wegen fehlender
-Personaldecke im Moment jedoch keine tiefgreifende Hilfe dabei leisten.
-===== Bsp-Config =====
-Zunächst benötigen Sie ein Zertifikat der DFN PKI im .pem-Format sowie den zugehörigen Schlüssel und Zwischen-Zertifikate. Wie Sie diese erhalten, ist in [[de:eduroam:anleitungen:zertifikate]] beschrieben.
-Eine sehr einfache Konfiguration könnte so aussehen:
 <code>
-# Bsp-Config für den radsecproxy
+tls default {
-# 2017-11-30 klemer ät dfn.de
+    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
+}
+</code>
+===== Konfiguration der Föderationsserver =====
-# Falls der radsecproxy auf dem selben Host wie ein radius-Server
+Der DFN betreibt 3 Föderationsserver mit folgenden Details:
-# läuft, muss hier ein anderer Port gewählt werden
-listenUDP		*:1812
-# listenTLS *:2083 ist default, muss nicht gesetzt werden
+^Name           ^IPv4-Adresse  ^IPv6-Adresse        ^
+|tld1.eduroam.de|193.174.75.134|2001:638:d:c105::134|
+|tld2.eduroam.de|193.174.75.138|2001:638:d:c106::138|
+|tld3.eduroam.de|194.95.245.98 |2001:638:d:c104::98 |
-# debug-Logging; im Produktivbetrieb eher auf Stufe 3
+Die DNS-Namen lösen dabei nur auf die IPv4-Adresse auf.
-LogLevel		5
-# ggf. via syslog-Protokoll zu einem zentralen
+Eine einfache Konfiguration definiert nun die folgenden Server- und Client-Blöcke: (Bei einfachen Service-Provider-Konfigurationen können die Client-Blöcke weggelassen werden.
-# Syslog-Server schicken
-# zunächst aber in eine lokale Datei.
-# Log-Rotation nicht vergessen, damit das Dateisystem nicht
-# überquillt!
-LogDestination		file:///var/log/radsecproxy.log
+<code>
+client tld1.eduroam.de {
+    type tls
+}
+client tld2.eduroam.de {
+    type tls
+}
+client tld3.eduroam.de {
+    type tls
+}
+server tld1.eduroam.de {
+    type tls
+    StatusServer on
+}
+server tld2.eduroam.de {
+    type tls
+    StatusServer on
+}
+server tld3.eduroam.de {
+    type tls
+    StatusServer on
+}
+</code>
+<alert> Achtung: Bei dieser Konfiguration wird beim Start von Radsecproxy ein DNS-Lookup durchgeführt. Schlägt das DNS-Lookup fehl, startet Radsecproxy nicht.</alert>
-# Funktioniert nur, wenn Client und Server den selben Namen haben
+Um die IP-Adresse festzuschreiben und dadurch nicht von DNS abhängig zu sein kann eine alternative Konfiguration genutzt werden. Diese muss genutzt werden, wenn die Anbindung an die Föderationsproxies über IPv6 geschehen soll. Hierbei muss allerdings die Überprüfung des Zertifikatsnamens manuell angepasst werden:
-# (hier: tld1 bzw. tld2)
-LoopPrevention		on
+<code>
+client tld1.eduroam.de {
+    host 193.174.75.134
+    # alternativ bei IPv6
+    #host 2001:638:d:c105::134
+    type tls
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
+}
+client tld2.eduroam.de {
+    host 193.174.75.138
+    # alternativ bei IPv6
+    #host 2001:638:d:c106::138
+    type tls
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
+}
+client tld3.eduroam.de {
+    host 194.95.245.98
+    # alternativ bei IPv6
+    #host 2001:638:d:c104::98
+    type tls
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
+}
+server tld1.eduroam.de {
+    host 193.174.75.134
+    # alternativ bei IPv6
+    #host 2001:638:d:c105::134
+    type tls
+    StatusServer on
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
+}
+server tld2.eduroam.de {
+    host 193.174.75.138
+    # alternativ bei IPv6
+    #host 2001:638:d:c106::138
+    type tls
+    StatusServer on
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
+}
+server tld3.eduroam.de  {
+    host 194.95.245.98
+    # alternativ bei IPv6
+    #host 2001:638:d:c104::98
+    type tls
+    StatusServer on
+    CertificateNameCheck Off
+    MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
+}
+</code>
+===== Konfiguration der Anbindung von lokalem RADIUS-Server und Access Points =====
-# die Zertifikate...
+Die Anbindung der Access Points bzw. WLAN-Controller kann auf zwei verschiedene Arten erfolgen:
-tls default {
-    # enthaelt beide(!) Telekom-Zertifikate:
-    # subject= /C=DE/O=T-Systems Enterprise Services GmbH/OU=T-Systems Trust Center/CN=T-TeleSec GlobalRoot Class 2
-    # und Subject: C=DE, O=Deutsche Telekom AG, OU=T-TeleSec Trust Center, CN=Deutsche Telekom Root CA 2
-    CACertificateFile /etc/radsecproxy/certs/telekom-zertifikate.pem
+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.
-    # Das Server-Zertifikat muss die 'Client'-Eigenschaft haben. Das erreicht man in der DFN-PKI zB dadurch, dass
+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.
-    # beim Antrag bei 'Typ' Radius-Server statts des voreingestellten 'Webserver' ausgewählt wird.
-    # enthält (in dieser Reihenfolge!)
+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.
-    #  - Serverzertifikat
-    #  - Erstes Intermediate (meist s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Global Issuing CA)
-    #  - Zweites Intermediate (meist s:/C=DE/O=Verein zur Foerderung eines Deutschen Forschungsnetzes e. V./OU=DFN-PKI/CN=DFN-Verein Certification Authority 2)
-    CertificateFile	 /etc/radsecproxy/certs/server.pem
+Die Clients können dabei entweder einzeln mit ihrer jeweiligen IP-Adresse oder als ein ganzes Subnetz konfiguriert werden.
-    # enthält den Server-Key
+<code>
-    CertificateKeyFile /etc/radsecproxy/certs/server.key
+client 192.0.2.1 {
+    type udp
+    secret <shared secret>
 }
+client 198.51.100.0/24 {
+    type udp
-# ENTWEDER:  Falls das WLAN direkt am radsecproxy angeschlossen sein soll:
+    secret <shared secret>
-client wlan-controler-or-access-points {
-  host <ip-address-or-net>
-  type udp
-  secret dievoegel
 }
+</code>
+Der eigene RADIUS-Server kann über einen Server-Block an den Radsecproxy angebunden werden:
-# ODER: Falls das WLAN am Radius-Server hängt und dieser den radsecproxy
+<code>
-#        befragt
+server ihr-radius-server {
-client local-radius-server {
+    type udp
-  host <ip-address-or-net>
+    host 203.0.113.1
-  type udp
+    secret <shared secret>
-  secret fliegenum
 }
+</code>
+Haben Sie mehrere RADIUS-Server, müssen Sie entsprechend mehrere Server-Blöcke anlegen.
-# Fuer lokale Tests
+<code>
-client localtest {
+server ihr-radius-server-1 {
-  host 127.0.0.1
+    type udp
-  type udp
+    host 203.0.113.1
-  secret mitternacht
+    secret <shared secret>
 }
+server ihr-radius-server-2 {
+    type udp
-# Die beiden DFN radsec-Server als Clients, für Anfragen
+    host 203.0.113.2
-# eigener User auf Reisen
+    secret <shared secret>
-# (Abschnitt entfällt bei reinen SP)
-client tld1 {
-  host 193.174.75.134
-  type tls
-  certificatenamecheck off
-  matchCertificateAttribute CN:/^(radius1\.dfn|tld1\.eduroam)\.de$/
-}
-client tld2 {
-  host 193.174.75.138
-  type tls
-  certificatenamecheck off
-  matchCertificateAttribute CN:/^(radius2\.dfn|tld2\.eduroam)\.de$/
 }
+</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>
-# Der lokale RADIUS-Server für die Authentifizierung des eigenen
+realm ihre-realm.de {
-# Realm
+    server ihr-radius-server-1
-server radius-server1 {
+    server ihr-radius-server-2
-  host <ip-address>
-  type udp
-  secret deradler
 }
-# ggf. ein zweiter lokaler RADIUS-Server
+# Abfangen von typischen Fehlkonfigurationen in Clients
-server radius-server2 {
+# (Vor dem Default-Block, da sonst die Regeln nicht ausgewertet werden.)
-      host <ip-address>
+realm /\.$/ {
-      type udp
+    replymessage "Misconfigured client: Realm must not end with dot."
-      secret istgelandet
 }
+realm /\.3gppnetwork.*/ {
-# Die beiden DFN-Radsec-Server für die Weiterleitung der Anfragen
+    replymessage "Misconfigured client: 3GPP realm is not usable for eduroam."
-# fremder User am eigenen Standort
-server tld1 {
-     host 193.174.75.134
-     type tls
-     certificatenamecheck off
-     matchCertificateAttribute CN:/^(radius1\.dfn|tld1\.eduroam)\.de$/
-     StatusServer on
 }
-server tld2 {
+realm /\s/ {
-     host 193.174.75.138
+    replymessage "Misconfigured client: Realm must not contain spaces"
-     type tls
-     certificatenamecheck off
-     matchCertificateAttribute CN:/^(radius2\.dfn|tld2\.eduroam)\.de$/
-     StatusServer on
 }
+# Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten
-# hier den eigenen Realm eintragen
+# Dieser Block sollte ganz am Ende der Konfiguration stehen
-# (Abschnitt entfällt bei reinen SP)
-realm ihr-realm-hier.de {
-        server radius-server1
-        server radius-server2
-}
-# alles andere geht zum DFN
 realm * {
- server tld1
+    server tld1.eduroam.de
- server tld2
+    server tld2.eduroam.de
+    server tld3.eduroam.de
 }
 </code>
-==== Fehlermeldung bzgl. eduPKI ====
-Sollten Sie alles aufgesetzt haben und erhalten nun eine Fehlermeldung, dass sich der radsecproxy nicht dem DFN Server verbinden will, weil dieser ein Zertifikat der **eduPKI** ausliefert, so ist dies **völlig normal**. Bis Sie den kommenden Punkt __weiter zu erledigen__ nicht abgearbeitet haben, //kann// es nicht funktionieren.
-Vgl. auch unser [[de:eduroam:admins:FAQ|Admin-FAQ]] .
-==== Weiter zu erledigen ====
-Nach der Einrichtung des radsecproxy [[https://www.dfn.de/kontakt/|benötigt der DFN folgende Informationen]]:
-  * IP-Adresse des radsecproxy-Servers
-  * 'CN' des Zertifikats, das der RSP bekommen wird