Unterschiede
Hier werden die Unterschiede zwischen zwei Versionen angezeigt.
Beide Seiten der vorigen Revision Vorhergehende Überarbeitung Nächste Überarbeitung | Vorhergehende ÜberarbeitungLetzte ÜberarbeitungBeide Seiten der Revision | ||
de:eduroam:anleitungen:radsecproxy [2018/03/20 10:21] – [Bsp-Config] Ralf Paffrath | de:eduroam:anleitungen:radsecproxy [2023/06/02 14:08] – Update zur Umstellung TCS Jan-Frederik Rieckers | ||
---|---|---|---|
Zeile 1: | Zeile 1: | ||
- | ====== | + | ====== Radsecproxy ====== |
+ | Die Föderationsanbindung der lokalen Einrichtungen an die globale eduroam-Infrastruktur geschieht über die Föderationsproxies des Deutschen Forschungsnetzes. Hierfür wird RADIUS over TLS ( [[https:// | ||
- | Die Verbindung zwischen DFN eduroam-Server und den Einrichtungen erfolgt | + | Als Software empfehlen wir [[https://radsecproxy.github.io/ |
- | via RadSec-Protokoll (RFC 6614). Eine Möglichkeit hierfür ist das | + | |
- | Programm | + | |
- | Distributionen zu finden ist. Da es nur wenige Anforderungen hat, ist | + | |
- | aber auch das Selbst-Kompilieren meist ohne großen Aufwand möglich. | + | |
- | Es läuft momentan nur in Unix-Umgebungen, | + | Die Konfiguration geschieht dann über die Datei '' |
- | ===== Einbindung des eigenen WLANs / SP-Teil ===== | + | Wir haben eine [[de: |
- | Es gibt 2 Möglichkeiten für den SP-Betrieb: | + | ===== Zertifikate ===== |
- | === 1) Das lokale WLAN spricht mit dem RSP: === | + | Die Verbindung zum Föderationsproxy wird über TLS abgesichert. Hierfür benötigt Radsecproxy ein Zertifikat, ebenso müssen die Zertifikate der Gegenstelle überprüft werden. Da radsecproxy in der Regel unter dem User-Account '' |
- | < | + | |
- | | AAA |-| BBB |-| CCC |AAA=WLAN-Controller|BBB=radsecproxy|CCC=DFN | + | |
- | | | | | | !@4 | | | + | |
- | | | | DDD | | | + | |
- | | | | | | ! | | | + | |
- | | EEE |-@8| ' | + | |
- | </diagram> | + | |
- | + | ||
- | /* sah mal so aus: | + | |
- | < | + | |
- | WLAN-Controller ----- RSP --------------- DFN | + | |
- | | | + | |
- | | | + | |
- | | (nur Anfragen für eigenen @REALM) | + | |
- | RADIUS-Server ---------+ | + | |
- | </ | + | |
- | */ | + | |
+ | < | ||
- | **Vorteil**: | + | ==== eduroam-CA ==== |
- | | + | |
- | - Der RSP leitet auch ' | + | |
- | + | 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: | |
- | === 2) Das lokale WLAN spricht mit dem RADIUS-Server: === | + | |
- | < | + | Für die korrekte Funktionsweise muss das CA-Zertifikat in den entsprechenden Ordner heruntergeladen werden ( https:// |
- | | AAA |-| EEE |-| BBB |-| CCC |AAA=WLAN-Controller|EEE=RADIUS-Server|BBB=radsecproxy|CCC=DFN | + | |
- | </diagram> | + | |
- | /* | ||
< | < | ||
- | WLAN-Controller | + | $> wget -O / |
</ | </ | ||
- | */ | ||
+ | Der TLS-Block in der '' | ||
- | **Vorteil**: | + | < |
- | - ggf. bereits bestehende Struktur muss nicht verändert werden; es wird nur der RSP zwischen RADIUS-Server und DFN gesetzt. | + | tls default { |
- | - Eine Übergabe von Attributen (zB [[de:eduroam: | + | CACertificateFile |
+ | CertificateFile | ||
+ | | ||
+ | } | ||
+ | </ | ||
+ | < | ||
- | ===== Distributionen ===== | + | ==== DFN-PKI |
+ | < | ||
- | Für Ubuntu 16.04. bietet es sich an, zunächst das Paket von [[https:// | + | 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. |
- | zu verwenden, da hier ein größeres Problem im Zusammenspiel mit | + | |
- | neueren Linux-Kerneln geschlossen wurde. | + | |
+ | 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 '' | ||
- | Bei Debian sind die Distri-eigenen Pakete eine gute Wahl. | + | < |
+ | tls default { | ||
+ | CACertificateFile | ||
+ | CertificateFile | ||
+ | CertificateKeyFile | ||
+ | } | ||
+ | </ | ||
+ | ==== TCS (Sectigo) ==== | ||
- | Andere Distributionen und Betriebssysteme funktionieren auch wunderbar | + | < |
- | und können gerne eingesetzt | + | |
- | Personaldecke im Moment jedoch | + | |
- | ===== Bsp-Config ===== | + | Wird TCS genutzt, senden auch die Föderationsserver ein TCS-Zertifikat, sodass hier der TLS-Block wie folgt aussehen sollte: |
- | Zunächst benötigen Sie ein Zertifikat der DFN PKI im .pem-Format sowie den zugehörigen Schlüssel und Zwischen-Zertifikate. Wie Sie diese erhalten, ist in [[de: | + | <code> |
- | + | ||
- | + | ||
- | Eine sehr einfache Konfiguration könnte so aussehen: | + | |
- | + | ||
- | <file bash radsecproxy.conf> | + | |
- | # Bsp-Config für den radsecproxy | + | |
- | # 2017-11-30 klemer ät dfn.de | + | |
- | + | ||
- | + | ||
- | # Falls der radsecproxy auf dem selben Host wie ein radius-Server | + | |
- | # läuft, muss hier ein anderer Port gewählt werden | + | |
- | listenUDP *: | + | |
- | + | ||
- | # listenTLS *:2083 ist default, muss nicht gesetzt werden | + | |
- | + | ||
- | # debug-Logging; | + | |
- | LogLevel 5 | + | |
- | + | ||
- | # ggf. via syslog-Protokoll zu einem zentralen | + | |
- | # Syslog-Server schicken | + | |
- | # zunächst aber in eine lokale Datei. | + | |
- | # Log-Rotation nicht vergessen, damit das Dateisystem nicht | + | |
- | # überquillt! | + | |
- | LogDestination file:/// | + | |
- | + | ||
- | + | ||
- | # Funktioniert nur, wenn Client und Server den selben Namen haben | + | |
- | # (hier: tld1 bzw. tld2) | + | |
- | LoopPrevention on | + | |
- | + | ||
- | + | ||
- | # die Zertifikate... | + | |
tls default { | tls default { | ||
- | | + | |
- | | + | |
- | | + | |
- | CACertificateFile | + | } |
+ | </ | ||
+ | ===== Konfiguration der Föderationsserver ===== | ||
+ | Der DFN betreibt 3 Föderationsserver mit folgenden Details: | ||
- | # Das Server-Zertifikat muss die ' | + | ^Name ^IPv4-Adresse |
- | # beim Antrag bei ' | + | |tld1.eduroam.de|193.174.75.134|2001: |
+ | |tld2.eduroam.de|193.174.75.138|2001: | ||
+ | |tld3.eduroam.de|194.95.245.98 |2001: | ||
- | # enthält (in dieser Reihenfolge!) | + | Die DNS-Namen lösen dabei nur auf die IPv4-Adresse auf. |
- | # | + | |
- | # | + | |
- | # - Zweites Intermediate (meist s:/ | + | |
- | CertificateFile / | + | Eine einfache Konfiguration definiert nun die folgenden Server- und Client-Blöcke: |
- | # enthält den Server-Key | + | < |
- | | + | client tld1.eduroam.de { |
+ | type tls | ||
} | } | ||
- | + | client | |
- | + | type tls | |
- | # ENTWEDER: | + | |
- | client | + | |
- | host < | + | |
- | | + | |
- | secret dievoegel | + | |
} | } | ||
- | + | client | |
- | # ODER: Falls das WLAN am Radius-Server hängt und dieser den radsecproxy | + | type tls |
- | # befragt | + | |
- | client | + | |
- | host < | + | |
- | | + | |
- | secret fliegenum | + | |
} | } | ||
- | + | server tld1.eduroam.de { | |
- | # Fuer lokale Tests | + | type tls |
- | client localtest { | + | |
- | host 127.0.0.1 | + | |
- | type udp | + | |
- | | + | |
} | } | ||
+ | server tld2.eduroam.de { | ||
+ | type tls | ||
+ | StatusServer on | ||
+ | } | ||
+ | server tld3.eduroam.de { | ||
+ | type tls | ||
+ | StatusServer on | ||
+ | } | ||
+ | </ | ||
+ | < | ||
+ | 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: | ||
- | # Die beiden DFN RadSec Client' | + | < |
- | # im Roaming-Fall an die Server in den Einrichtungen geschickt. | + | client tld1.eduroam.de { |
- | # IP-Adresse und CN kann beim DFN in Berlin erfragt werden | + | host 193.174.75.134 |
- | # (Abschnitt entfällt | + | # alternativ |
- | client tld1 { | + | #host 2001: |
- | | + | type tls |
- | type tls | + | |
- | | + | |
- | | + | |
} | } | ||
- | client tld2 { | + | client tld2.eduroam.de |
- | host < | + | host 193.174.75.138 |
- | type tls | + | # alternativ bei IPv6 |
- | | + | #host 2001: |
- | | + | |
+ | | ||
+ | | ||
} | } | ||
+ | client tld3.eduroam.de { | ||
+ | host 194.95.245.98 | ||
+ | # alternativ bei IPv6 | ||
+ | #host 2001: | ||
+ | type tls | ||
+ | CertificateNameCheck Off | ||
+ | MatchCertificateAttribute SubjectAltName: | ||
+ | } | ||
+ | server tld1.eduroam.de { | ||
+ | host 193.174.75.134 | ||
+ | # alternativ bei IPv6 | ||
+ | #host 2001: | ||
+ | type tls | ||
+ | StatusServer on | ||
+ | CertificateNameCheck Off | ||
+ | MatchCertificateAttribute SubjectAltName: | ||
+ | } | ||
+ | server tld2.eduroam.de { | ||
+ | host 193.174.75.138 | ||
+ | # alternativ bei IPv6 | ||
+ | #host 2001: | ||
+ | type tls | ||
+ | StatusServer on | ||
+ | CertificateNameCheck Off | ||
+ | MatchCertificateAttribute SubjectAltName: | ||
+ | } | ||
+ | server tld3.eduroam.de | ||
+ | host 194.95.245.98 | ||
+ | # alternativ bei IPv6 | ||
+ | #host 2001: | ||
+ | type tls | ||
+ | StatusServer on | ||
+ | CertificateNameCheck Off | ||
+ | MatchCertificateAttribute SubjectAltName: | ||
+ | } | ||
+ | </ | ||
+ | ===== Konfiguration der Anbindung von lokalem RADIUS-Server und Access Points ===== | ||
+ | Die Anbindung der Access Points bzw. WLAN-Controller kann auf zwei verschiedene Arten erfolgen: | ||
+ | Sie können entweder an den RADIUS-Server angebunden werden. In diesem Fall reicht der Radsecproxy die Authentifizierungen einfach nur an den lokalen FreeRADIUS weiter und benötigt zu diesem auch eine Anbindung in beide Richtungen. | ||
+ | Alternativ können die APs/ | ||
- | # Der lokale | + | Laufen |
- | # Realm | + | |
- | server radius-server1 { | + | |
- | host <ip-address> | + | |
- | type udp | + | |
- | secret deradler | + | |
- | } | + | |
- | # ggf. ein zweiter lokaler RADIUS-Server | + | Die Clients können dabei entweder einzeln mit ihrer jeweiligen IP-Adresse oder als ein ganzes Subnetz konfiguriert werden. |
- | server radius-server2 { | + | |
- | host < | + | |
- | type udp | + | |
- | secret istgelandet | + | |
- | } | + | |
- | # Die beiden RadSec Server für die Weiterleitung der Anfragen | + | < |
- | # der eduroam Gäste am eigenen Standort. | + | client 192.0.2.1 { |
- | # IP-Adressen sowie CN's (CommonName) können beim DFN erfragt werden. | + | type udp |
- | server tld1 { | + | |
- | host < | + | |
- | type tls | + | |
- | certificatenamecheck off | + | |
- | | + | |
- | | + | |
} | } | ||
- | server tld2 { | + | client 198.51.100.0/ |
- | host < | + | type udp |
- | type tls | + | |
- | certificatenamecheck off | + | |
- | | + | |
- | | + | |
} | } | ||
+ | </ | ||
+ | Der eigene RADIUS-Server kann über einen Server-Block an den Radsecproxy angebunden werden: | ||
- | + | < | |
- | # hier den eigenen Realm eintragen | + | server |
- | # (Abschnitt entfällt bei reinen SP) | + | type udp |
- | realm ihr-realm-hier.de | + | host 203.0.113.1 |
- | | + | secret <shared secret> |
- | | + | |
} | } | ||
+ | </ | ||
+ | Haben Sie mehrere RADIUS-Server, | ||
- | # alles andere geht zum DFN | + | < |
- | realm * { | + | server ihr-radius-server-1 |
- | server tld1 | + | type udp |
- | server tld2 | + | host 203.0.113.1 |
+ | secret <shared secret> | ||
} | } | ||
+ | server ihr-radius-server-2 { | ||
+ | type udp | ||
+ | host 203.0.113.2 | ||
+ | secret <shared secret> | ||
+ | } | ||
+ | </ | ||
+ | ===== Realm-Konfiguration ===== | ||
- | </ | + | Das Routing der verschiedenen Realms geschieht über '' |
+ | 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, | ||
+ | Da Radsecproxy die Realms sequenziell nach der Reihenfolge in der Konfiguration durchgeht, muss dieser Block entsprechend vor der Default-Regel stehen. | ||
- | ===== Fehlermeldung bzgl. eduPKI ===== | + | < |
+ | realm ihre-realm.de { | ||
+ | server ihr-radius-server-1 | ||
+ | server ihr-radius-server-2 | ||
+ | } | ||
- | Sollten Sie alles aufgesetzt haben und erhalten nun eine Fehlermeldung, dass sich der radsecproxy | + | # Abfangen von typischen Fehlkonfigurationen in Clients |
+ | # (Vor dem Default-Block, da sonst die Regeln | ||
+ | realm /\.$/ { | ||
+ | replymessage " | ||
+ | } | ||
+ | realm /\.3gppnetwork.*/ { | ||
+ | replymessage " | ||
+ | } | ||
+ | realm /\s/ { | ||
+ | replymessage " | ||
+ | } | ||
- | Vgl. auch unser [[de:eduroam: | + | # Default-Regel: Alles unbekannte zu den DFN-Servern weiterleiten |
- | + | # Dieser Block sollte ganz am Ende der Konfiguration stehen | |
- | + | realm * { | |
- | + | | |
- | ===== Weiter zu erledigen ===== | + | |
- | + | | |
- | Nach der Einrichtung des radsecproxy [[https:// | + | } |
- | * IP-Adresse des radsecproxy-Servers | + | </ |
- | * ' | + |