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 [2025/02/07 12:42] (aktuell) – [DFN-PKI] Ralf Paffrath
@@ 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.
-<code>
-client tld1.eduroam.de {
-    type tls
-}
-client tld2.eduroam.de {
-    type tls
-}
-client tld3.eduroam.de {
-    type tls
-}
-server tld1.eduroam.de {
-    type tls
-    StatusServer on
-}
-server tld2.eduroam.de {
-    type tls
-    StatusServer on
-}
-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:
+^Name           ^
+|tld1.eduroam.de|
+|tld2.eduroam.de|
+|tld3.eduroam.de|
+==== Clients ====
 <code>
 client tld1.eduroam.de {
-    host 193.174.75.134 # alternativ bei IPv6 host 2001:638:d:c105::134
     type tls
     CertificateNameCheck Off
@@ Zeile 114: / Zeile 54: @@
 }
 client tld2.eduroam.de {
-    host 193.174.75.138 # alternativ bei IPv6 host 2001:638:d:c106::138
     type tls
     CertificateNameCheck Off
@@ Zeile 120: / Zeile 59: @@
 }
 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$/
-}
+}</code>
+==== Server ====
+<code>
 server tld1.eduroam.de {
-    host 193.174.75.134 # alternativ bei IPv6 host 2001:638:d:c105::134
     type tls
     StatusServer on
@@ Zeile 133: / Zeile 72: @@
 }
 server tld2.eduroam.de {
-    host 193.174.75.138 # alternativ bei IPv6 host 2001:638:d:c106::138
     type tls
     StatusServer on
@@ Zeile 139: / Zeile 77: @@
     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
     type tls
     StatusServer on
@@ Zeile 147: / Zeile 84: @@
 }
 </code>
+<alert>Beim Start von Radsecproxy wird ein DNS-Lookup durchgeführt. Schlägt das DNS-Lookup fehl, startet Radsecproxy nicht.</alert>
 ===== Konfiguration der Anbindung von lokalem RADIUS-Server und Access Points =====
@@ Zeile 194: / Zeile 133: @@
 ===== 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 145: @@
 }
-# 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 155: @@
 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>