Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2023/01/04 10:46] – Hinweis auf Reihenfolge der Realm-Blöcke Jan-Frederik Rieckers
+++ de:eduroam:anleitungen:radsecproxy [2026/03/24 12:04] (aktuell) – Jan-Frederik Rieckers
@@ Zeile 13: / Zeile 13: @@
 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>
+<alert>Es muss zwingend ein Zertifikat aus der eduroam-CA verwendet werden. Zertifikate aus TCS (Harica) oder anderen Quellen akzeptieren wir nicht.</alert>
 ==== eduroam-CA ====
@@ Zeile 36: / Zeile 36: @@
 <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 ====
-<alert>Mit der Abkündigung der DFN-PKI zu Ende 2022 muss auf die eduroam-CA umgestellt werden.</alert>
-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:
-<code>
-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
-}
-</code>
-==== TCS (Sectigo) ====
-<alert>Da wir aktuell auf die eduroam CA umstellen, werden wir grundsätzlich keine Umstellungen von DFN-PKI auf TCS vornehmen. Wenn Sie bereits TCS nutzen, können Sie dies weiter tun, bis die TCS-Konfiguration von uns abgekündigt wird. Sie erhalten dabei im Voraus eine Nachricht von uns.</alert>
-Zertifikate von Sectigo können aktuell auch für die Föderationsverbindung genutzt werden. Auch hier müssen Sie über den TCS-Zugang Ihrer Einrichtung ein Zertifkat erstellen.
-Wird TCS genutzt, senden auch die Föderationsserver ein TCS-Zertifikat, sodass hier der TLS-Block wie folgt aussehen sollte:
-<code>
-tls default {
-    CACertificateFile   /etc/ssl/certs/Comodo_AAA_Services_root.pem
-    CertificateFile     /etc/radsecproxy/ihr-tcs-zertifikat.pem
-    CertificateKeyFile  /etc/radsecproxy/ihr-tcs-private-key.pem
-}
-</code>
 ===== Konfiguration der Föderationsserver =====
-Der DFN betreibt 3 Föderationsserver mit folgenden Details:
+Der DFN-Verein betreibt 3 Föderationsserver mit folgenden Details:
-^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 |
-Die DNS-Namen lösen dabei nur auf die IPv4-Adresse auf.
-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.
+^ FQDN ^ IPv4 ^ IPv6 ^
+|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 |193.174.75.142 | 2001:638:d:c108:26::1 |
+==== Clients ====
 <code>
 client tld1.eduroam.de {
@@ Zeile 88: / Zeile 56: @@
 client tld3.eduroam.de {
     type tls
-}
+}</code>
+==== Server ====
+<code>
 server tld1.eduroam.de {
     type tls
@@ Zeile 97: / Zeile 67: @@
     StatusServer on
 }
-server tld3.eduroam.de {
+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>
-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:
+<alert>Beim Start von Radsecproxy wird ein DNS-Lookup durchgeführt. Schlägt das DNS-Lookup fehl, startet Radsecproxy nicht.
+Um unabhängig von DNS zu sein, kann die IP-Adresse statisch eingetragen werden, allerdings muss dann auch der Zertifikats-Namens-Check angepasst werden.
+</alert>
+Der folgende Code-Schnipsel ist ein Beispiel für die Konfiguration mit IP-Adresse. (Erfordert radsecproxy Version 1.10 oder höher)
 <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
+    host 193.174.75.134
     type tls
-    StatusServer on
+    ServerName tld1.eduroam.de
-    CertificateNameCheck Off
+    StatusServer On
-    MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
 }
-server tld2.eduroam.de {
+client tld1.eduroam.de {
-    host 193.174.75.138 # alternativ bei IPv6 host 2001:638:d:c106::138
+    host 193.174.75.134
     type tls
-    StatusServer on
+    ServerName tld1.eduroam.de
-    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>
@@ Zeile 194: / Zeile 140: @@
 ===== 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 mehrere angegeben werden. Radsecproxy wird sie in der angegebenen Reihenfolge durchprobieren.
+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>
@@ Zeile 202: / Zeile 152: @@
 }
-# Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten
+# Abfangen von typischen Fehlkonfigurationen in Clients
-# Dieser Block sollte ganz am Ende der Konfiguration stehen
+# (Vor dem Default-Block, da sonst die Regeln nicht ausgewertet werden.)
-realm * {
-    server tld1.eduroam.de
-    server tld2.eduroam.de
-    server tld3.eduroam.de
-}
-</code>
-Um die Last auf den Föderationsserver des DFN zu verringern, können Sie verbreitete Fehler in der Realm-Konfiguration bereits auf Ihrem Radsecproxy abfangen.
-Da Radsecproxy die Realms sequenziell nach der Reihenfolge in der Konfiguration durchgeht, muss dieser Block entsprechend vor der Default-Regel stehen.
-<code>
 realm /\.$/ {
     replymessage "Misconfigured client: Realm must not end with dot."
@@ Zeile 224: / Zeile 162: @@
 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>