Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2022/05/09 14:05] – Und ein Copy-Paste-Fehler. Jan-Frederik Rieckers
+++ de:eduroam:anleitungen:radsecproxy [2023/06/27 17:30] (aktuell) – TCS-Konfiguration entfernt Jan-Frederik Rieckers
@@ Zeile 6: / Zeile 6: @@
 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 =====
@@ Zeile 49: / Zeile 51: @@
 }
 </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 =====
@@ Zeile 106: / Zeile 94: @@
 <code>
 client tld1.eduroam.de {
-    host 193.174.75.134 # alternativ bei IPv6 host 2001:638:d:c105::134
+    host 193.174.75.134
+    # alternativ bei IPv6
+    #host 2001:638:d:c105::134
     type tls
     CertificateNameCheck Off
@@ Zeile 112: / Zeile 102: @@
 }
 client tld2.eduroam.de {
-    host 193.174.75.138 # alternativ bei IPv6 host 2001:638:d:c106::138
+    host 193.174.75.138
+    # alternativ bei IPv6
+    #host 2001:638:d:c106::138
     type tls
     CertificateNameCheck Off
@@ Zeile 118: / Zeile 110: @@
 }
 client tld3.eduroam.de {
-    host 194.95.245.98 # alternativ bei IPv6 host 2001:638:d:c104::98
+    host 194.95.245.98
+    # alternativ bei IPv6
+    #host 2001:638:d:c104::98
     type tls
     CertificateNameCheck Off
@@ Zeile 124: / Zeile 118: @@
 }
 server tld1.eduroam.de {
-    host 193.174.75.134 # alternativ bei IPv6 host 2001:638:d:c105::134
+    host 193.174.75.134
+    # alternativ bei IPv6
+    #host 2001:638:d:c105::134
     type tls
     StatusServer on
@@ Zeile 131: / Zeile 127: @@
 }
 server tld2.eduroam.de {
-    host 193.174.75.138 # alternativ bei IPv6 host 2001:638:d:c106::138
+    host 193.174.75.138
+    # alternativ bei IPv6
+    #host 2001:638:d:c106::138
     type tls
     StatusServer on
@@ Zeile 137: / Zeile 135: @@
     MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
 }
-server tld3.eduroam.de {
+server tld3.eduroam.de  {
-    host 194.95.245.98 # alternativ bei IPv6 host 2001:638:d:c104::98
+    host 194.95.245.98
+    # alternativ bei IPv6
+    #host 2001:638:d:c104::98
     type tls
     StatusServer on
@@ Zeile 192: / Zeile 192: @@
 ===== 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 200: / Zeile 204: @@
 }
-# Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten
+# Abfangen von typischen Fehlkonfigurationen in Clients
-realm * {
+# (Vor dem Default-Block, da sonst die Regeln nicht ausgewertet werden.)
-    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:
-<code>
 realm /\.$/ {
     replymessage "Misconfigured client: Realm must not end with dot."
@@ Zeile 218: / Zeile 214: @@
 realm /\s/ {
     replymessage "Misconfigured client: Realm must not contain spaces"
+}
+# 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>