Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2023/02/24 08:20] – [Realm-Konfiguration] Ralf Paffrath
+++ de:eduroam:anleitungen:radsecproxy [2023/06/27 17:30] (aktuell) – TCS-Konfiguration entfernt Jan-Frederik Rieckers
@@ Zeile 51: / 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 107: / Zeile 93: @@
 <code>
-client tld1 {
+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
     MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
 }
-client tld2 {
+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
     MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
 }
-client tld3 {
+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
     MatchCertificateAttribute SubjectAltName:DNS:/^tld3\.eduroam\.de$/
 }
-server tld1 {
+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 132: / Zeile 126: @@
     MatchCertificateAttribute SubjectAltName:DNS:/^tld1\.eduroam\.de$/
 }
-server tld2 {
+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 135: @@
     MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/
 }
-server tld3  {
+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 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 202: / Zeile 204: @@
 }
-# 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
-    server tld2
-    server tld3
-}
-</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 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>