Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- de:eduroam:anleitungen:radsecproxy [2022/04/19 11:12] – Neue Anleitungsseite Radsecproxy Jan-Frederik Rieckers
+++ de:eduroam:anleitungen:radsecproxy [2023/06/02 14:08] – Update zur Umstellung TCS 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 17: / Zeile 19: @@
 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.
-Für die korrekte Funktionsweise muss das CA-Zertifikat in den entsprechenden Ordner heruntergeladen werden ( https://pki.pca.dfn.de/eduroam-ca/pub/cacert/cacert.crt ).
+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>
+$> wget -O /etc/radsecproxy/eduroam-ca.pem https://pki.pca.dfn.de/eduroam-ca/pub/cacert/chain.txt
+</code>
 Der TLS-Block in der ''%%radsecproxy.conf%%'' kann dann wie folgt aussehen:
@@ Zeile 23: / Zeile 29: @@
 <code>
 tls default {
-    CACertificateFile   /etc/radsecproxy/eduroam-ca.crt
+    CACertificateFile   /etc/radsecproxy/eduroam-ca.pem
     CertificateFile     /etc/radsecproxy/ihr-eduroam-ca-zertifikat.pem
     CertificateKeyFile  /etc/radsecproxy/ihr-eduroam-ca-private-key.pem
@@ Zeile 47: / 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 71: / Zeile 75: @@
 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 Server-Blöcke weggelassen werden.
+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.
 <code>
@@ Zeile 102: / 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 108: / 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 114: / 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 120: / 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 127: / 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 133: / 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 188: / 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 196: / Zeile 216: @@
 }
-# 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 214: / 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>