Weiterleitung

Die Konfiguration der Weiterleitung erfolgt über RADIUS > Server > Erweiterte Einstellungen > Weiterleitung





Bei den "mehrschichtigen" EAP-Protokollen wie TTLS oder PEAP kann die eigentliche "innere" Authentifizierung auf einem separaten RADIUS-Server erfolgen. Das ermöglicht z. B. die Weiterverwendung eines existierenden RADIUS-Servers, der nur die Benutzertabellen bereitstellt, selbst aber nicht EAP(/TLS)-fähig ist. Der TLS/TTLS/PEAP-Tunnel wird in diesem Fall vom LCOS-RADIUS-Server verwaltet.

Die Konfiguration von solchen mehrschichtigen Protokollen ist Teil einer allgemeinen Methode zur Weiterleitung von RADIUS-Anfragen, mit der ein LCOS-RADIUS-Server auch als RADIUS-Proxy verwendet werden kann. Die Weiterleitung von Anfragen bzw. die Proxy-Funktion basieren auf dem Konzept der "Realms". Ein Realm ist eine Zeichenkette, welche die Gültigkeit einer Reihe von Benutzerkonten definiert. Das Gerät betrachtet die folgenden Bestandteile eines Benutzernamens als Realm:

Mail-Domain
user@company.com; company.com bildet den Realm und ist durch ein @-Zeichen vom Benutzernamen getrennt.
MS-Computerauthentisierung
company\user; company bildet den Realm und ist durch einen Backslash ("\") vom Benutzernamen getrennt. Diese Authentifizierung ist z. B. bei einem Windows-Login gebräuchlich.
MS-Domain
host/user.company.com; Beginnt der Benutzername mit dem String host/ und enthält der restliche Name mindestens einen Punkt, dann betrachtet das Gerät alles hinter dem ersten Punkt als Realm (in diesem Fall also company.com).

Der Realm kann als Hinweis auf den RADIUS-Server verstanden werden, auf dem das Benutzerkonto verwaltet wird. Vor dem Durchsuchen der Benutzertabelle auf dem RADIUS-Server wird der Realm wieder entfernt. Mit der Nutzung von Realms können ganze Netzwerke, die untereinander als vertrauenswürdig gelten, die RADIUS-Server in den Partner-Netzen nutzen und so auch zwischen den Netzen wechselnde Benutzer authentifizieren. Der LCOS-RADIUS-Server speichert die verbundenen RADIUS-Server mit Angabe des zugehörigen Realms in einer Weiterleitungs-Tabelle. Diese Tabelle wird nach dem – in Verbindung mit dem Benutzernamen übermittelten – Realm durchsucht. Wenn keine Übereinstimmung gefunden wird, wird die Anfrage mit einem Access Reject beantwortet. Ein leerer Realm wird als lokale Anfrage gewertet, d. h. der LCOS-RADIUS-Server durchsucht seine eigenen Benutzer-Tabellen und erzeugt daraus die entsprechende Antwort.

Zur Unterstützung der Realm-Verarbeitung verwendet der LCOS-RADIUS-Server zwei spezielle Realms:

Standard-Realm
Dieser Realm wird verwendet, wenn ein Realm übermittelt wird, für den kein expliziter Weiterleitungs-Server definiert ist. Für den Standard-Realm selbst muss in der Weiterleitungs-Tabelle allerdings ein entsprechender Eintrag angelegt werden.
Leerer Realm
Dieser Realm wird verwendet, wenn kein Realm, sondern nur der Benutzername übermittelt wird.

Im Default-Zustand enthält die Weiterleitungs-Tabelle keine Einträge, der Standard- und der Leere Realm sind leer. Das bedeutet das alle Anfragen als lokale Anfragen behandelt werden und ggf. übermittelte Realms werden ignoriert. Um den LCOS-RADIUS-Server als reinen Weiterleitungs-Server bzw. RADIUS-Proxy zu verwenden, müssen der Standard- und der Leere Realm auf einen Wert gesetzt werden, für den in der Weiterleitungs-Tabelle ein entsprechender Server definiert ist.

Bitte beachten Sie, dass die Weiterleitung von RADIUS-Anfragen den übermittelten Benutzernamen nicht verändert – es wird weder ein Realm hinzugefügt, noch verändert oder abgeschnitten. Der Server, an den die Anfrage weitergeleitet wird, muss nicht der letzte der Weiterleitungs-Kette sein, und er benötigt möglicherweise den Realm selbst für eine korrekte Weiterleitung. Nur der RADIUS-Server, der letztlich die Anfrage bearbeitet, löst den Realm aus dem Benutzernamen und durchsucht erst dann die Tabellen mit den Benutzerkonten. Dementsprechend löst der LCOS-RADIUS-Server den Realm vom Benutzernamen, wenn die Anfragen lokal verarbeitet werden.

Zur Verarbeitung von getunnelten EAP-Anfragen im Zusammenhang mit TTLS und PEAP wird ein spezieller EAP-Tunnel-Server verwendet – auch in Form eines Realms. Wählen Sie hier einen Realm, der nicht mit anderen verwendeten Realms in Konflikt steht. Wenn kein EAP-Tunnel-Server angegeben ist, leitet der LCOS-RADIUS-Server Anfragen an sich selbst weiter, was bedeutet, dass sowohl die innere als auch die äußere EAP-Authentifizierung vom LCOS-RADIUS-Server selbst bearbeitet werden.

Richten Sie ggfs. die Weiterleitungs-Server ein.





Realm
Zeichenkette, mit der das Weiterleitungs-Ziel identifiziert wird.
Backup-Profil
Alternativer Weiterleitungs-Server, an den Anfragen weitergeleitet werden, wenn der erste Weiterleitungs-Server nicht erreichbar ist.
Authentifizierungs-Server bzw. Accounting-Server
Für die beiden möglichen RADIUS-Anwendungen Zugangsverwaltung (Access) und Abrechnung (Accounting) können Sie hier Parameter konfigurieren, damit der Router entsprechende RADIUS-Anfragen an einen externen RADIUS-Server weiterleiten kann. Soll keine Weiterleitungsfunktionalität für die Zugangsverwaltung oder Abrechnung genutzt werden, so lassen Sie das entsprechende Adressfeld leer.
Server-Adresse
IP-Adresse des RADIUS-Servers, an den die Anfrage weitergeleitet werden soll.
Port
Für den Port muss die gleiche Port-Nummer eingestellt werden, die im entsprechenden RADIUS-Server konfiguriert ist. Das ist im Allgemeinen 1812 für Zugangsverwaltung (Access) und 1813 für Abrechnung (Accounting).
Attributwerte
Hier können sie RADIUS-Attribute mit benutzerdefinierten Werten versehen. Die einzelnen Namen-Werte-Paare müssen der Form <Name>=<Wert> entsprechen und sind durch Semikola voneinander getrennt. <Name> identifiziert dabei das RADIUS-Attribut durch seinen Namen oder seine Nummer. Die zugehörigen Attributnamen finden Sie in den entsprechenden RADIUS RFCs. Attributsnamen können abgekürzt werden, solange die Bezeichner eindeutig sind. Da die Anzahl der Zeichen begrenzt ist, lässt sich der Name abkürzen. Das Kürzel muss dabei eindeutig sein. Beispiele:
  • NAS-Port=1234 ist nicht erlaubt, da das Attribut nicht eindeutig ist (NAS-Port, NAS-Port-Id oder NAS-Port-Type).
  • NAS-Id=ABCD ist erlaubt, da das Attribut eindeutig ist (NAS-Identifier).
Als Attribut-Wert ist die Angabe von Namen oder RFC-konformen Nummern möglich. Für das Gerät sind die Angaben Service-Type=Framed und Service-Type=2 identisch. Die Angabe eines Wertes in Anführungszeichen ("<Wert>") ist möglich, um Sonderzeichen wie Leerzeichen, Semikolon oder Gleichheitszeichen mit angeben zu können. Das Anführungszeichen innerhalb des Wertes erhält einen umgekehrten Schrägstrich vorangestellt (\"), der umgekehrte Schrägstrich ebenfalls (\\). Zusätzlich ist es möglich eine Reihe von Platzhalter einzusetzen:
  • %n – wird ersetzt durch den konfigurierten Gerätenamen.
  • %e – wird ersetzt mit der Seriennummer des Gerätes, wie man sie aus dem sysinfo des Gerätes kennt.
  • %% – wird ersetzt durch ein einzelnes %-Zeichen.
  • %{name} – wird ersetzt durch den ursprünglichen Wert des entsprechenden RADIUS-Attributes. Etwaige Neu / Um-Definitionen innerhalb dieser Attributsliste werden nicht beachtet! Der Bezeichner kann gekürzt werden, solange er eindeutig bleibt.
Schlüssel (Secret)
Der Schlüssel (Secret) muss ebenfalls mit dem im RADIUS-Server konfigurierten übereinstimmen, damit die Authentifizierung dieses Routers gegenüber dem angesprochenen RADIUS-Server funktioniert.
Absende-Adresse
Hier können Sie optional eine Absendeadresse konfigurieren, die statt der ansonsten automatisch für die Zieladresse gewählten Absendeadresse verwendet wird.
Protokoll
Protokoll für die Kommunikation zwischen dem internen RADIUS-Server und dem Weiterleitungs-Server.

www.lancom-systems.de

LANCOM Systems GmbH | A Rohde & Schwarz Company | Adenauerstr. 20/B2 | 52146 Würselen | Deutschland | E‑Mail info@lancom.de

LANCOM Logo