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 [2023/06/02 14:08] – Update zur Umstellung TCS Jan-Frederik Rieckers
@@ Zeile 53: / Zeile 53: @@
 ==== 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>
+<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, müssen Sie bis zum 27.06.2023 auf die eduroam CA umstellen.</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:
@@ Zeile 108: / Zeile 106: @@
 <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 114: / Zeile 114: @@
 }
 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 120: / Zeile 122: @@
 }
 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 126: / Zeile 130: @@
 }
 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 133: / Zeile 139: @@
 }
 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 139: / Zeile 147: @@
     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 194: / Zeile 204: @@
 ===== 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 216: @@
 }
-# 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 226: @@
 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>