Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen Revision Vorhergehende Überarbeitung
Nächste Überarbeitung		 Vorhergehende Überarbeitung
de:eduroam:anleitungen:radsecproxy [2022/05/03 12:13] – Jan-Frederik Rieckersde: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%%'' 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 ===== ===== 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. 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: Der TLS-Block in der ''%%radsecproxy.conf%%'' kann dann wie folgt aussehen:
Zeile 23: Zeile 29:
 <code> <code>
 tls default { tls default {
-    CACertificateFile   /etc/radsecproxy/eduroam-ca.crt+    CACertificateFile   /etc/radsecproxy/eduroam-ca.pem
     CertificateFile     /etc/radsecproxy/ihr-eduroam-ca-zertifikat.pem     CertificateFile     /etc/radsecproxy/ihr-eduroam-ca-zertifikat.pem
     CertificateKeyFile  /etc/radsecproxy/ihr-eduroam-ca-private-key.pem     CertificateKeyFile  /etc/radsecproxy/ihr-eduroam-ca-private-key.pem
Zeile 45: Zeile 51:
 } }
 </code> </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 ===== ===== Konfiguration der Föderationsserver =====
  
Zeile 102: Zeile 94:
 <code> <code>
 client tld1.eduroam.de { 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     type tls
     CertificateNameCheck Off     CertificateNameCheck Off
Zeile 108: Zeile 102:
 } }
 client tld2.eduroam.de { 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     type tls
     CertificateNameCheck Off     CertificateNameCheck Off
Zeile 114: Zeile 110:
 } }
 client tld3.eduroam.de { 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     type tls
     CertificateNameCheck Off     CertificateNameCheck Off
Zeile 120: Zeile 118:
 } }
 server tld1.eduroam.de { 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     type tls
     StatusServer on     StatusServer on
Zeile 127: Zeile 127:
 } }
 server tld2.eduroam.de { 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     type tls
     StatusServer on     StatusServer on
Zeile 133: Zeile 135:
     MatchCertificateAttribute SubjectAltName:DNS:/^tld2\.eduroam\.de$/     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     type tls
     StatusServer on     StatusServer on
Zeile 188: Zeile 192:
 ===== Realm-Konfiguration ===== ===== 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> <code>
Zeile 196: 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 /\.$/ { realm /\.$/ {
     replymessage "Misconfigured client: Realm must not end with dot."     replymessage "Misconfigured client: Realm must not end with dot."
Zeile 214: Zeile 214:
 realm /\s/ { realm /\s/ {
     replymessage "Misconfigured client: Realm must not contain spaces"     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> </code>
  • Zuletzt geändert: vor 2 Jahren