For the complete documentation index, see llms.txt. This page is also available as Markdown.

Servereinstellungen

Die Servereinstellungen sind unter https://YOURNAME.radius-as-a-service.com/settings/server verfügbar

Ports & IP-Adressen

Übersicht

RADIUSaaS betreibt einen RadSec-Dienst, um seinen Nutzern eine sichere cloudbasierte Authentifizierung bereitzustellen. Darüber hinaus bietet RADIUSaaS für diejenigen Kunden, die RadSec in ihrer Netzwerkumgebung nicht nutzen können, z. B. aufgrund von Hardware- und Softwareeinschränkungen, RADIUS-Proxies an, die die Protokollkonvertierung von RADIUS zu RadSec übernehmen.

Sowohl der RadSec- als auch der RADIUS-Dienst bieten öffentliche IP-Adressen, die es Ihren Netzwerkgeräten und Diensten ermöglichen, von überall über das Internet mit unserem Dienst zu kommunizieren. Diese Dienste arbeiten auf ihren eindeutigen registrierten Ports.

RadSec / TCP

RadSec-DNS

Der DNS-Eintrag, über den der RadSec-Dienst erreicht werden kann.

Server-IP-Adressen

Dies ist die öffentliche IP-Adresse des RadSec-Dienstes.

RadSec-Ports

Dies ist der registrierte Port für RadSec: 2083

Failover & Redundanz

In Fällen, in denen Kunden höhere Redundanzstufen benötigen, können für Ihre Instanz mehrere RadSec-Endpunkte konfiguriert werden, wodurch zusätzliche IP-Adressen bereitgestellt werden. Bitte beachten Sie, dass für diesen Dienst zusätzliche Kosten anfallen.

Es ist wichtig zu beachten, dass RADIUSaaS KEIN Failover bereitstellt zwischen RadSec-Endpunkten. Stattdessen wird dieses Failover in der Regel auf Ihrer Netzwerkausrüstung implementiert, wie im folgenden Beispiel mit Meraki gezeigt.

Es wird empfohlen, Ihr Failover-Szenario mithilfe von IP-Adressen statt DNS zu konfigurieren, um eine bessere Übersicht und weniger Abhängigkeit von einem zusätzlichen Dienst (DNS) zu haben.

In dieser Konfiguration werden die beiden RadSec-IP-Adressen in der Reihenfolge ihrer Priorität aufgeführt. Wenn Meraki eine der IP-Adressen nicht erreichen kann, versucht es in der Regel noch zwei weitere Male und wechselt dann zur nächsten. Weitere Informationen zur Failover-Fähigkeit Ihres Meraki- (oder anderen) Systems entnehmen Sie bitte Ihren eigenen Unterlagen.

Anzeige mehrerer RadSec-Server in der Reihenfolge der Priorität (Meraki).

RadSec-Einstellungen

Maximale TLS-Version

Diese Einstellung steuert die maximale TLS-Version für Ihre RadSec-Schnittstelle. Die Mindestversion ist auf 1.2 festgelegt, die Standard-Maximalversion ist auf 1.3 gesetzt.

TLS 1.3 bietet mehrere Vorteile gegenüber 1.2, darunter den Mechanismus zur Authentifizierung nach dem Handshake, der das Anfordern zusätzlicher Anmeldeinformationen vor Abschluss des Handshakes ermöglicht. Dies ist wichtig für die im nächsten Abschnitt behandelten Überprüfungen der Widerrufsprüfung für RadSec-Zertifikate.

Maximale EAP-TLS-Version

Diese Einstellung steuert die maximale TLS-Version, die bei EAP verwendet wird, wenn sich Ihre Endpunkte gegenüber Ihrer RADIUSaaS-Instanz mit einem Zertifikat (EAP-TLS) oder Benutzername/Passwort-Anmeldeinformationen.

Für alle modernen Betriebssysteme ist TLS 1.3 die empfohlene Standardvorgabe. Allerdings warben bestimmte (ältere) Windows 10/11-Builds mit TLS-1.3-Unterstützung für EAP-TLS, jedoch mit einer nicht konformen Implementierung. Wenn Windows-Clients auf betroffenen Builds Verbindungsprobleme aufweisen, begrenzen Sie die ausgehandelte Protokollversion auf TLS 1.2, um eine breitere Kompatibilität zu gewährleisten.

Widerrufsprüfung für RadSec-Zertifikate

Diese Einstellung legt fest, ob für alle RadSec-Verbindungen eine Widerrufsprüfung durchgeführt werden soll. Die Methode zur Überprüfung der Widerrufsprüfung unterscheidet sich leicht von derjenigen, die für Clientauthentifizierungszertifikate verwendet wird.

Für einen ordnungsgemäßen RadSec-Betrieb stellen Netzwerkgeräte wie Access Points, Switches und VPN-Server eine TLS-geschützte Verbindung zum RadSec-Server her. RadSec-Bereitstellungen verwenden typischerweise Mutual TLS (mTLS), bei dem sich beide Peers mithilfe von X.509-Zertifikaten während des TLS-Handshakes gegenseitig authentifizieren. Die Implementierung von RADIUSaaS erzwingt mTLS.

Um die Gültigkeit und den Widerrufsstatus eines RadSec-Clientzertifikats zu bestimmen, muss das Zertifikat vom Client als Teil des TLS-Authentifizierungsprozesses vorgelegt werden. Erst nachdem das Zertifikat empfangen wurde, können Widerrufsprüfungen (z. B. über CRL oder OCSP) durchgeführt werden.

TLS 1.2

TLS 1.2 unterstützt die gegenseitige TLS-Authentifizierung während des ersten Handshakes mithilfe der CertificateRequest, Certificate, und CertificateVerify Nachrichten. Wenn die Clientauthentifizierung erforderlich und korrekt durchgesetzt wird, wird das RadSec-Clientzertifikat vor dem Aufbau der TLS-Sitzung und bevor RADIUS-Datenverkehr ausgetauscht wird vorgelegt, validiert und auf Widerruf geprüft.

TLS 1.2 erlaubt jedoch auch optionale Clientauthentifizierung und unterstützt Neuverhandlungen. Dadurch können einige RadSec-Clientimplementierungen den ersten Handshake abschließen, ohne ein Clientzertifikat vorzulegen. Dieses Verhalten ist implementierungsspezifisch und keine Einschränkung des TLS-1.2-Protokolls.

Um das oben beschriebene Verhalten zu entschärfen, wird die Widerrufsprüfung für RadSec-Zertifikate Einstellung deaktiviert, wenn die maximale TLS-Version auf 1.2 gesetzt ist. Bitte beachten Sie, dass Sie sie später manuell wieder aktivieren können.

TLS 1.3

TLS 1.3 bietet ein deterministischeres und schlankeres Modell für die gegenseitige TLS-Authentifizierung. Wenn die Clientauthentifizierung angefordert wird, wird das RadSec-Clientzertifikat als Teil des ersten Handshakes ausgetauscht und vor dem Aufbau der TLS-Verbindung validiert. Dadurch kann der RadSec-Server das Clientzertifikat, einschließlich seines Widerrufsstatus, sofort überprüfen und den Handshake fehlschlagen lassen, wenn das Zertifikat ungültig oder widerrufen ist. Dadurch ermöglicht TLS 1.3 eine strengere und besser vorhersagbare Durchsetzung der gegenseitigen TLS-Authentifizierung für RadSec-Verbindungen.

Die Widerrufsprüfung für RadSec-Zertifikate Einstellung wird automatisch aktiviert, wenn die maximale TLS-Version auf 1.3 gesetzt ist.

RADIUS / UDP

Dieser Abschnitt ist verfügbar, wenn Sie mindestens einen RADIUS-Proxy. Für jeden Proxy ist eine separate öffentliche IP-Adresse verfügbar. Die öffentlichen IP-Adressen in diesem Abschnitt unterstützen ausschließlich das RADIUS-Protokoll und lauschen daher auf den Ports 1812/1813.

Server-IP-Adressen und Standort

Geolokation des/der RADIUS-Proxys sowie der jeweiligen öffentlichen IP-Adresse(n).

Gemeinsame Geheimnisse

Das Shared Secret für den jeweiligen RADIUS-Proxy. Standardmäßig werden alle RADIUS-Proxys mit demselben Shared Secret initialisiert.

Anzeige der Änderung von Shared Secrets pro Proxy

Ports

Dieser Abschnitt zeigt die Standardports für die Dienste RADIUS-Authentifizierung (1812) und RADIUS-Abrechnung (1813) an.

Failover & Redundanz

Proxy-Redundanz

Beachten Sie, dass ein einzelner RADIUSaaS-Proxy keine Redundanz bietet. Um Redundanz sicherzustellen, richten Sie mehrere RADIUSaaS-Proxys wie beschrieben ein hier.

RadSec-Dienst-Redundanz für Proxys

Bei der Verwendung von RADIUSaaS mit mehreren RadSec-Instanzen werden Proxys automatisch so konfiguriert, dass sie sich mit allen verfügbaren RadSec-Instanzen verbinden. Ein RADIUSaaS-Proxy priorisiert die Verbindung zum nächstgelegenen regionalen RadSec-Dienst. Wenn dieser Dienst nicht verfügbar ist, wechselt er zu einem anderen verfügbaren RadSec-Dienst.

Serverzertifikate

Kunden-CA

Standardmäßig generiert RADIUSaaS ein RADIUS-Serverzertifikat das von einer Zertifizierungsstelle (CA) signiert ist, die auf unserem Dienst ausschließlich für genau diesen Zweck verfügbar ist. Wir bezeichnen sie als die Kunden-CA. Die Kunden-CA ist für jeden Kunden eindeutig.

Um Ihre Kunden-CA zu erstellen, befolgen Sie diese einfachen Schritte:

  1. Navigieren Sie zu Einstellungen > Servereinstellungen

  2. Klicken Sie auf Hinzufügen

  3. Wählen Sie Lassen Sie RaaS eine CA für Sie erstellen

  4. Klicken Sie auf Speichern

  5. Nach der Erstellung sehen Sie unter Serverzertifikate ein neues Zertifikat verfügbar

Verwenden Sie Ihr eigenes Zertifikat

Falls Sie die Kunden-CAnicht verwenden möchten, können Sie bis zu zwei Ihrer eigenen Zertifikate hochladen.

Von SCEPman ausgestelltes Serverzertifikat

Bitte befolgen Sie diese Schritte, um SCEPman Certificate Master zu nutzen und ein neues Serverzertifikat zu erzeugen:

  1. Navigieren Sie zu Ihrem SCEPman Certificate Master-Webportal.

  2. Wählen Sie links Zertifikat anfordern

  3. Wählen Sie (Web-)Server oben

  4. Wählen Sie Formular

  5. Geben Sie alle Subject Alternative Names (SANs) ein, für die das Zertifikat gültig sein soll, getrennt durch Kommas, Semikolons oder Zeilenumbrüche. Erstellen Sie ein Serverzertifikat wie beschrieben hier und geben Sie einen beliebigen FQDN an. Wir empfehlen, den SAN des Standard-Serverzertifikats anzupassen, z. B. radsec-<Ihr RADIUSaaS-Instanzname>.radius-as-a-service.com.

  6. Setzen Sie das Dateiformat für den Download auf PEM

  7. Wählen Sie Zertifikatskette einbeziehen und laden Sie das Zertifikat herunter.

  8. Stellen Sie sicher, dass sowohl Server- als auch Clientauthentifizierung für die EKU enthalten sind.

  9. Senden Sie die Anfrage zum Herunterladen des neuen Serverzertifikats ab.

Laden Sie das neue Serverzertifikat in RADIUSaaS

Um Ihr oben erstelltes Serverzertifikat hinzuzufügen, navigieren Sie zu RADIUSaaS-Instanz > Einstellungen > Servereinstellungen > Hinzufügen, dann

  1. Wählen Sie PEM- oder PKCS#12-codiertes Zertifikat (Wenn Sie in Schritt 5 PKCS#12 ausgewählt haben, enthält dies sowohl den öffentlichen als auch den privaten Schlüssel)

  2. Ziehen Sie Ihre Zertifikatsdatei per Drag & Drop hierher oder klicken Sie, um sie zu durchsuchen

  3. Geben Sie das Passwort Ihres Privaten Schlüssels

  4. Klicken Sie auf Speichern

Bitte beachten Sie: Standardmäßig stellt SCEPman Certificate Master Zertifikate aus, die 730 Tage gültig sind. Wenn Sie dies ändern möchten, lesen Sie bitte die Dokumentation.

Zertifikatsaktivierung

Da Zertifikate von Zeit zu Zeit ablaufen oder sich Ihre Präferenz hinsichtlich der zu verwendenden Zertifikate ändern kann, ist es wichtig, dass Sie das von Ihrem Server verwendete Zertifikat steuern können. Die Aktiv Spalte zeigt Ihnen das Zertifikat, das Ihr Server derzeit verwendet. Um das von Ihrem Server verwendete Zertifikat zu ändern, erweitern Sie die Zeile des Zertifikats, das Sie auswählen möchten, und klicken Sie auf Aktivieren.

Herunterladen

Um Ihr Serverzertifikat herunterzuladen, haben Sie zwei Optionen:

  1. Klicken Sie auf CA-Zertifikat herunterladen oben. Dadurch wird direkt das vertrauenswürdige Root-CA des aktuell aktiven Serverzertifikats heruntergeladen.

  2. Klicken Sie auf das Download- Symbol in der entsprechenden Zeile.

Option 2 öffnet einen Dialog, der den vollständigen Zertifikatspfad anzeigt. Das Root-Zertifikat wird immer grün markiert sein.

Anzeige des Root-Zertifikats in Grün

Bei beiden Optionen ist das heruntergeladene Root-Zertifikat in Base64 (PEM) kodiert. Falls Ihr Gerät (z. B. ein WiFi-Controller) eine binäre Kodierung (DER) benötigt, können Sie es mit OpenSSL:

Löschen

Um ein Zertifikat zu löschen, erweitern Sie die entsprechende Zeile, klicken Sie auf Löschen und bestätigen Sie Ihre Auswahl.

Zertifikatsablauf

Zertifikate laufen von Zeit zu Zeit ab. Fünf Monate bevor Ihr Zertifikat abläuft, weist Sie Ihr Dashboard durch die Anzeige eines Warnsymbols darauf hin.

Screenshot, der den Ablauf des Zertifikats zeigt

Wenn das Dreieck neben dem aktiven RADIUS-Serverzertifikat angezeigt wird, folgen Sie dieser Anleitung, um es zu aktualisieren:

Erneuerung des Serverzertifikats

Zuletzt aktualisiert

War das hilfreich?