Ab einer bestimmten Anzahl von Remote-Usern ist es notwendig, die drei Remote-Access-Disziplinen Authentifizierung, Autorisierung und Accounting zu zentralisieren. Radius-Server können das. Die Real-World Labs haben fünf dieser Plattformen untersucht.

Falls sich im Unternehmen mehr als 30 Anwender remote ins Netz einwählen, so entpuppt sich das Management der notwendigen Parameter schon als störend aufwändig. Hauptsächlich dann, wenn die User für diesen Zweck einen Mix aus privaten und öffentlichen Leitungen, Dialin, Breitband und Wireless verwenden. Alle diese Zugangsmethoden bedingen drei Disziplinen: Authentifizierung, Autorisierung und Accounting, in den berüchtigten »AAA« zusammengefasst. Sie schaffen Arbeit, sofern man diese Belange nur mit den Bordmitteln der entsprechenden Gateways abwickelt. Um eine solche heterogene, bunte Landschaft unter einen Hut zu bringen, hat die IT vor Jahren das Radius-Protokoll (Remote-Access-Dial-In-User-Service) entwickelt. Es zentralisiert die AAA-Parameter in einer Datenbank und verknüpft so externe Modem-Pools, Switches, Firewalls, VPN-Concentratoren und Access-Points an einem Ort. Also alle Zugangswege, über die externe User in das geschützte interne Netz eindringen.

Repord-Card: Radius-Server

Features: Radius-Server

Einst als Stereotyp für simple Passwort-Authentifizierung verhätschelt, hat das Radius-Protokoll dank der Wireless-Technik eine Renaissance erlebt. Denn dem Protokoll ist es gelungen, die Zugangsrechte und Accounting-Anforderungen der potenziell gefährlichen Wireless-Welt zu konzentrieren. Ein Grund mehr, kommerzielle Radius-Server einem Test in den Real-World Labs zu unterziehen. Die Produkte sollten nicht nur die Active-Directory von Microsoft oder Token wie den «SecurID« von RSA einklinken. Das ist inzwischen nahezu Standard. Sie sollten zusätzlich mehrere externe Network-Access-Server (NAS) berücksichtigen, seien es Dialup-Server, VPN-Concentratoren, WLAN-Access-Points oder Firewalls. Cisco, Funk Software, Iea Software, Interlink Networks und Lucent haben sich bereit erklärt, ihre Radius-Server unter diesen Bedingungen testen zu lassen. Der Anbieter Vircom lehnte ab, weil er zum Testzeitpunkt seine Lösung komplett überarbeitete. Die Appliance von Xperience Technologies war für den Test nicht qualifiziert, weil sie die Token von RSA nicht unterstützte. Secure Computing ihrerseits hat eine Teilnahme einfach abgelehnt.

Standard-Standards

Bei einem solch in die Jahre gekommenen Protokoll darf man davon ausgehen, dass sich jedes Produkt an die Bestimmungen hält. Dies ist auch der Fall, sowohl bei Radius als auch dem Extensible-Authentication-Protocol (EAP). Die Lösungen mussten auch offenlegen, welche Authentifizierungsmechanismen sie beherrschen und wie sie mit anderen Datenbanken interagieren. Der Interoperabilitätstest untersuchte, wie effizient und sauber die Radius-Server mit verschiedenen Radius-Clients kommunizierten. Dazu gehörten Access-Points, VPNs und Dialin-Server. Die Konfiguration hat der Test anhand folgender Kriterien bewertet: Wie leicht und schnell lassen sich Gruppen- und Anwenderprofile schaffen, und wie flexibel lassen sich die darin beschriebenen Attribute modifizieren? Auch die Sicherheit spielte eine große Rolle. Die Radius-Server mussten zeigen, wie sie den Datentransfer mit den NAS-Systemen integer gestalten. In den meisten Fällen endete es damit, dass die Produkte SSL-Zertifikate einsetzten. Nur Funk und Interlink gingen einen Schritt weiter, indem sie Shared-Secrets auf mehrere Server verteilten und so die Vertraulichkeit der Daten sicherten. Bei Interlink sind Shared-Secrets für die Remote-Konfiguration sogar obligatorisch.

Natürlich greifen Sicherheitsfunktionen und Policies nur dann, wenn man sie gescheit verwalten kann. Dazu wurden die unterschiedlichen Regelsätze analysiert, welche die Radius-Server verbindlich durchsetzen. Der Test legte großen Wert darauf, wie die Produkte zeitabhängige Regelsätze für einzelne Anwender, Gruppen und Rollen organisierten. Alle Lösungen bis auf »Steel-Belted Radius« von Funk haben diese Art der Zugangskontrolle umgesetzt. Ferner mussten die Server zeigen, ob sie Zeitkontingente pflegen können. Darüber steuert der Administrator, wie lange ein User, eine Gruppe oder eine Rolle auf das Netz zugreifen darf. Nur Lucent und Cisco haben diese »Time-Quotas« zum Testzeitpunkt unterstützt. Alle Produkte konnten die Zugriffsrechte abhängig von simultanen Logons auf Anwender- und Applikationsebene einschränken.

Die meisten Systeme im Test haben eine SQL-Datenbank betrieben, um darin die Anwenderprofile abzulegen und per ODBC oder JDBC aufzurufen. Die Integration der Datenbanktechnik ist immens wichtig, um die beim Billing und Accounting entstehenden Datenmassen skalierbar zu organisieren. Außerdem, wie sinnvoll wären all diese Informationen, wenn man sie nicht standardisiert bearbeiten sowie ex- und importieren könnte? Der Test hat auch die mitgelieferten Management-Werkzeuge unter die Lupe genommen. Bewertet wurde, wie die Tools Informationen darstellen, wie dynamisch diese Statusdaten sind und welche verschiedenen Funktionen verfügbar sind, um diese Daten zu modifizieren.

Neben diesen Basisdisziplinen hat auch die Interaktion mit Netzwerk-Managamentsystemen den Ausschlag gegeben. Hierbei hat der Test unter anderem den inhaltlichen Wert von E-Mail-Alarmen begutachtet. Diese Meldungen ließen sich recht sanft in den Servern von Cisco und IEA Software einrichten, ganz im Gegensatz zu Lucents Produkt.

Auch ihre Zertifikatsfunktionen haben die Radius-Server offenbaren müssen. Mit ihnen weisen die Produkte Profilen signierte Zertifikate zu. Lucent, Cisco, Funk und Interlink haben diesen Testlauf anstandslos bestanden. VoIP-Accounting-Fähigkeiten waren dünn gesät. Nur Cisco und IEA Software beherrschten diese Disziplin.

Bei dem Preismodell der Produkte wirkte sich aus, wie die Radius-Server eingesetzt werden. Lucent beispielsweise hat ein alternatives Preisschema für den Fall definiert, dass ihr Server hauptsächlich Wireless-Wolken bedient. Dieses flexible Preismodell, gekoppelt mit der Standardtreue des Produkts, hat Lucent die Auszeichnung »Referenz« der Network Computing eingebracht. Wie die Report-Card zeigt, liegen der Erst- und der Letztplatzierte einen halben Punkt auseinander. Egal, welche Anforderungen man hat, keines dieser Produkte wird enttäuschen.

NavisRadius Authentication Server 4.3.9 von Lucent

Dieser Server nimmt die AAA-Anforderungen in Unternehmen ausgewogen in Angriff. Der Navisradius hat als einziger im Test eine JDBC-Schnittstelle geliefert, mit der er sich an die SQL-Datenbank koppelt. Das Management dieses Pakets, bestehend aus einer Sybase-Datenbank und dem JDBC-Plugin, war mit dem mitgelieferten »Server Management Tool« (SMT) simpel. Und der auf Formen setzende «PolicyAssistant« hat die Serverkonfiguration ausgeklügelt abgewickelt. In älteren Versionen musste man für solche Zwecke noch auf die pedantisch anmutende »PolicyFlow AAA«-Programmiersprache zurückgreifen. Dank seiner Java-Wurzeln läuft das SMT-Tool auf mehreren Plattformen. Um den Server darüber remote zu managen, muss man das Tool separat installieren. Sofern auf dem Client Java 2 läuft, arbeitet das Remote-Management fehlerfrei. Die Benutzungsschnittstelle von SMT funktionierte gut. Außerdem traten die für Java typischen Verzögerungen kaum in Erscheinung.

Die Sprache des Policyflow ist Segen und Fluch zugleich. Sie ist keine echte Programmiersprache wie C++ oder Java, sondern mehr ein Skripting-Toolkit, mit dem man auf die verschiedenen Prozessschritte und Instanzen in diesem Radius-Server zugreift. Diese Schritte legen fest, wie der Server auf Anfragen reagiert, Informationen aus den User-Einträgen sammelt, dekodiert und so weiter. Falls man genügend Zeit hat, sich mit den Nuancen der Sprache auseinanderzusetzen, kann man das Produkt recht genau an eigene Ansprüche anpassen. Im Test jedenfalls entpuppte sich die Sprache als unerbittlich und nachtragend. Ein einziges falsch gesetztes Attribut, und man wird Stunden für die Fehlersuche investieren müssen. Die Tester haben daraus gelernt: Spiele mit den Plugins und Methoden nur dann herum, wenn du ein großes Problem lösen musst. Denn SMT bietet von sich aus schon genügend Flexibilität, um die Standard-Radius-Variablen zu konfigurieren.

Statt sich nur gegenüber einer auf Text basierenden Anwenderliste oder lokalen Datenbank zu authentifizieren, liefert Navisradius auch Proxies für Windows-Active-Directory/NT-Domains, Unix/etc/passwd, Kerberos, Novell-Directory, externe Datenbanken wie Oracle und MySQL, LDAP-Server und zahlreiche Hardtoken-Authentifizierungssysteme wie SecurID, Defender, Safeword und Vasco. Obwohl der Server aus sich heraus die NDS und die Windows-AD nicht unterstützt, kann er die dortigen Einträge per LDAP auslesen, nachdem er sich in diesen Directories selbst als User mit Administratorlevel einrichtete. Überrascht hat, dass der Navisradius das Verfahren TACACS+ nicht beherrscht – ein AAA-Protokoll, das anstelle von UDP auf TCP setzt und gern zu administrativen Zwecken benutzt wird.

Das Produkt braucht Java 2, weil es auf die flexible und erweiterbare Java-Policyflow-Plugin-Architektur aufsetzt. Beeindruckt hat, wie der Server die Autorisierungsaspekte von Radius von den Disziplinen Authentifizierung und Accounting trennte. Der Universal-State-Server (USS) beispielsweise protokollierte alle Sessions, die der Server aktuell organisierte. Auf diese Weise erleichtert er Autorisierungsentscheidungen, die auf Countern in der internen Netzwerksession-Datenbank basieren. Im Test wurde diese Funktion aufgegriffen, um Grenzwerte für Concurrent-Logons auf Anwendernamen-Ebene zu setzen. Außerdem hat dieses Feature erlaubt, die Login-Zahl auf einer spezifischen Ressource einzuschränken.

Die Anwenderkonfiguration mit dem »Access Manager«-Tool kann einfach ausfallen, wenn man die Authentifizierung ohne spezifische Autorisierungsattribute abwickelt. Oder komplex, wenn man Access-Control-Lists mit mehreren Authentifierungsquellen und Anwenderprofilen definiert. Die Profile lassen sich entweder für jeden Anwender einzeln oder als Templates ausformulieren, die dann jedem User zugewiesen werden.

Navisradius verwaltet im Gegensatz zu Cisco und Funk keine IP-Adresspools, um darüber das Remote-Access-Management zu konsolidieren. Diese Funktion ist extrem hilfreich. Wenn der Radius-Server aus einem von ihm verwalteten Pool IP-Adressen zuweist, kann er beispielsweise bestimmte Adressen an individuelle Anwender binden und den Zugang abhängig von der aktuell verfügbaren Adressmenge dynamisch regeln. Lucent erklärte, diese Funktion sei in ihrem Tool »IP Manager« eingebettet, das sich in Navisradius integriert. Der Server kann immerhin Anwendern IP-Adressen zuweisen, sofern diese entweder in dem Anwenderprofil oder Template als Framed-IP-Address-Radius-Attribut eingetragen sind. Navisradius spricht außerdem über ein Plugin mit externen DHCP-Servern, um mit deren Hilfe Anwendern, die sich gerade authentifizieren wollen, dynamisch Adressen zuzuweisen.

Es traten einige Störungen auf, als sich Clients im Test gegenüber einem AD ausweisen mussten. Vor allem traten die Probleme nach dem Upgrade auf Navisradius Version 4.3.2 auf. Der Server selbst hat einen Anwender erfolgreich gegenüber dem AD authentifiziert, Policyflow dagegen scheiterte daran, diesen gültigen User zu autorisieren. Selbst dann noch, als das Tool frisch auf den Radius-Server installiert wurde. Es blieb nichts anderes übrig, als die Maschine herunterzufahren und neu zu starten. Es war offensichtlich, dass beim Update die Registry-Einträge nicht aktualisiert wurden. Das anpassbare Realtime-Log-Feature und die eingebauten Test-Clients des Produkts halfen dabei, dieses Problem unter Beihilfe von Lucent zu lösen.

Die Flexibilität des Loggings und des Echtzeit-Trackings von Navisradius ist erstklassig. Die bloße Menge der Logging-Typen und -ebenen ist überwältigend. Die dazugehörigen Regeln und Log-Rotationsfunktionen machen das Ganze ausgezeichnet managebar. Wie alle Server im Test hat Navisradius Standardereignisse wie accept, reject, discard protokolliert. Der Administrator darf mehrere Log-Output-Quellen definieren, die der Server als Kanäle oder »Channels« interpretiert. Dazu zählen Syslog, SNMP-Traps, SQL-Datenbanken, E-Mail, Pager und Files.

Zu Berichtszwecken greift der Server auf die Stärken von Java zurück. Das geschmackvolle Tortendiagramm lieferte einen hervorragenden Überblick des gesamten Serverstatus. Diese Anzeige ist viel schneller zu erfassen als die bloßen Zahlendaten von Cisco oder Iea. Der Leistungsmonitor zeichnet Anfragen sowie akzeptierte und abgewiesene Versuche in einer Skala an. Diese Skala stellt die letzten 200 Ereignisse in einem leicht zu lesenden Zeilengraphen dar. Die sichtbare Aktualisierung der Daten funktionierte vor dem Hintergrund, dass es sich ja um eine auf Java basierende Konsole handelte, außerordentlich gut.

Navisradius lieferte eine Menge guter Extrafunktionen. Der Server dekodiert Radius-Pakete in Echtzeit, so dass man sein aktuelles Verhalten recht gut nachvollziehen kann. Diese Funktion war besonders hilfreich, um die falsch konfigurierten Regeln in der Policyflow-Kette zu isolieren. Da der Server SNMP versteht, lässt er sich gut extern überwachen. Navisradius unterstützt hierbei nur Read-Zugriffe. Ebenfalls als nützlich erwiesen sich die E-Mail-Alarme, obwohl sie alles andere als leicht zu konfigurieren waren. Dazu muss man auf ein Policyflow-Skript zurückgreifen. Abgerundet wird das Produkt von seinem Preismodell, das auf der Anzahl und dem Typen der zu unterstützenden Clients basiert.

Steel-Belted Radius 4.5 von Funk Software

Dieser Radius-Server unterscheidet sich schon dank seines Fokus von den anderen Produkten. Er möchte das WLAN-Segment sichern und unterstützt EAP wie kein anderer im Test. Die Benutzungsschnittstelle ist zwar simpel strukturiert, dafür aber auch funktional. Obwohl der Steel-Belted in filigranen Kontrollbelangen nicht an den Navisradius heranreicht, ist er doch ein rundum gelungener, funktionsreicher Radius-Server.

Funk hat die Unternehmensversion des Produkts für Windows-2000 eingesandt. Der »Steel-Belted Radius 4.5« (SBR) hat seine Mitkonkurrenz in Sachen Integration, Interoperabilität sowie bei der Unterstützung von Authentifizierungsmechanismen und Backend-Quellen überboten. So konnte sich der SBR nahtlos in das Testfeld eingliedern. Er hat anstandslos mit dem AD und dem ACE/Server interagiert. Außerdem besitzt er eine ausgearbeitete Bibliothek, in der er herstellerspezifische NAS-Attribute organisiert.

Die Installation und Inbetriebnahme des Servers waren problemlos. Eine kleine Störung überraschte beim ersten Start des Servers. Die Maschine verlangte, dass sein NT-Netlogon-Dienst gestartet werde. Um sich gegenüber einer Windows-Domain auszuweisen, muss der Server Mitglied jener Domain sein.

Es war beeindruckend, wie sich der SBR in die Domain einfügte. Der Server konnte individuelle User entweder über ihr Profil in der ursprünglichen Datenbank oder über ihr Gruppenprofil authentifizieren. Die Definition der Profile und externen NAS-Geräte verlief intuitiv und flexibel. Der Test legte Profile fest, in denen Prüf- und Antwort-Attribute eingetragen waren. Diese Profile wurden dann den Anwendern in ihrer ursprünglichen Datenbank zugewiesen.

Die Enterprise-Version des SBR beherrscht zahlreiche Authentifizierungsmechanismen, darunter fehlen aber einige Draft-EAP-Typen wie das Subscriber-Identify-Modell (SIM). Der Anbieter erklärte, dies werde in SBR-Version 4.7 nachgeholt. Der Server zapft eine große Gruppe von Backend-Authentifizierungsquellen an, ausgenommen Kerberos. In die NDS findet er auch nur per LDAP-Interface Eingang. Der SBR läuft als Dienst auf Windows-Maschinen und wird durch eine auf der Win32-API basierende Management-Anwendung gesteuert.

Dieses Tool gefiel im Test, weil es benutzerfreundlich und leicht zu bedienen war. Man muss sich im Gegensatz zu Lucent und Cisco nicht tief in die Menü- und Options-Kategorien stürzen, um den Server einzustellen. Und die gelieferten Kategorien waren leicht verständlich. Im Test wurden beispielsweise alle Tunnel-relevanten Authentifierungsbelange für VPNs und Firewalls eingerichtet, ohne uns mit den gewöhnlich komplexen Security-Schnittstellen zu konfrontieren. Die Tunnel setzen Restriktionen anhand von Attributen durch. Dazu gehören unter anderem die NAS-IP-Adresse, NAS-Typ, Zahl simultaner Verbindungen pro Tunnel und die Station-ID. Wie bei den anderen Produkten mussten die fortschrittlichen Funktionen wie die EAP-Definitionen mit einem Text-File eingerichtet werden. Die Folge: Der Server musste neu starten, um die Änderungen zu aktivieren.

Das LDAP-Configuration-Interface (LCI) von Funk wusste zu gefallen. Es verwaltet den SBR mit Hilfe von LDAP-Befehlen. Das LDAP-Schema ist fixiert, weil LCI als Brücke zwischen den Befehlen und der internen Datenbank fungiert. Die LCI-Schnittstelle hat den SBR auch an die externe LDAP-Datenbank gekoppelt. Dies erleichtert die Bindung an die Windows-Domaine, sofern SBR auf einer Workgroup-Maschine läuft.

Zu unserer Freude verwaltete SBR IP-Adresspools. Im Test wurde mit der Datei »radius.ini« durchgesetzt, dass der Pool exklusiv auf mehrere Ressourcen aufgeteilt wird, damit Adressüberlappungen über Netzwerkobjekte hinweg ausgeschlossen bleiben. Da der SBR Adressräume fest an NAS-Geräte bindet, ließ sich die Autorisierung der Clients von den Netzwerk-Ressourcen abhängig machen.

Die Administration des Servers war simpel. Um ihn remote zu verwalten, muss jedem Remote-Computer, der für diese Aufgabe vorgesehen ist, die Win32-Server-Configuration-API aufgespielt werden. Alternativ kann SPV auch auf einem Terminal-Server laufen und wird dann über die Client-Terminal-Dienste für Remote-Management angesteuert. Im Gegensatz zu Cisco und Interlink, deren Produkte sich per Browser konfigurieren lassen. Funk versprach, einen auf Web basierenden Installer in Version 5.0 nachzurüsten.

SBR hat als einziger Server im Test auf Usern basierendes Accounting für EAP-TTLS (EAP-Tunneled-Transport-Layered-Security) im Anonymous-Modus unterstützt. EAP-TTLS und EAP-PEAP (EAP-Protected-EAP) nutzen anonyme Benutzernamen, um Tunnel aufzubauen und alle darin transferierten Daten zu kodieren. Die meisten Radius-Server können aus diesen Sitzungen keine Daten extrahieren, weil die User-Credentials verborgen sind.

SBR unterstützt keine Time-Quotas und tageszeitabhängigen Restriktionen, erkennt einige zeitabhängige Regeln aber an. Der Administrator darf Session-Time-Outs und Concurrent-Logon-Grenzen erheben, die er als Attribute in individuelle User- und Gruppenprofile einträgt. SBR liefert aber keine Audit-Logs, um dies zu konfigurieren oder zu administrieren. Dadurch ist es eher schwierig, Änderungen in diesem Bereich zu protokollieren und Fehler zu beseitigen. Die Tiefe der Logs reicht soweit, dass der Server bei jeder Transaktion beispielsweise den Grund für die Ablehnung aufzeichnet. Neben den klassischen Informationen, wie viele Anfragen er annahm etc, versteht sich.

Besonders gelungen ist eine andere Berichtsfunktion. Der SBR koppelt seine eigenen Statistiken mit dem Windows-Performance-Monitor. Diese konsolidierten Statusdaten zeigten auf einen Blick alle Aspekte der Ressourcenauslastung auf dem Server. Das Management-Interface betreibt auch Echtzeit-Counter für den generellen Server-Zustand. Die Session-Tabelle im Display erwies sich ebenfalls als hilfreiches Reporting-Tool. Man kann mit ihr herausfinden, wie der Server vielzählige Sessions handhabt.

Die Extra-Funktionen des SBRs waren enttäuschend. Der Server unterstützt kein SNMP. Außerdem hat der Hersteller bislang keine explizite Option eingerichtet, mit der der SBR mit DHCP kommunizieren kann. Daher konnte der Server auch keine Adresse aus einem vordefinierten IP-Raum auf Basis des Anwenderprofils, des NAS-Systems oder anderer identifizierbarer Merkmale zuweisen.

RAD-Series 6.1.2 von Interlink Networks

Diese Maschine setzte im Test als einzige auf Linux auf. Mit ihrer Leistung von 1900 Transaktionen bei der Authentifizierung und dem Accounting gegenüber einem AD etablierte sie in einer eigenen Liga. Der Hersteller hat auch seinen »Secure XS Server« zugeschickt. Er erfüllte aber die Testanforderungen nicht und wurde daher auch nicht untersucht.

Der RAD hat gut funktioniert, beim Security- und Policy-Management aber schlecht ausgesehen. Auch die Reporting- und Präsentationsfunktionen des Systems enttäuschten. Die Installation und Konfiguration waren dagegen leicht, vor allem im Vergleich zu dem auf Open-Source basierenden »FreeRADIUS«-Server. Sie ähnelte der von Navisradius und SBR, mit der Ausnahme, dass sie per Text abgewickelt wird. Zudem muss der Administrator ein Shared-Secret zwischen dem Server-Manager, den Client-Maschinen und dem RAD-Server einrichten, will er das System remote verwalten. Die anderen Produkte griffen auf SSL-Zertifikate zurück, um die Kommunikation zu sichern. Neben der Befehlszeile und Telnet ließ sich die Box auch per Browser verwalten. Beeindruckt hat, dass der RAD auch per SNMP-Workstation administriert werden konnte.

Es fiel schwer, den Radius-Server an das AD zu koppeln. Dazu mussten das »authfile« editiert und einige LDAP-Skripte definiert werden. Gelegentlich hat der Server nach einem Neustart das »authfile« in neuem Format abgelegt, so dass er den Inhalt der Datei nicht mehr analysieren konnte. Interlink erklärte den Fehler damit, dass im Test diese Datei mit zwei verschiedenen Werkzeugen editiert wurde. Mal mit dem Text-Editor, dann mit dem »Configuration Manager«. Der RAD-Server besitzt immerhin die Fähigkeit, das Management-Interface so zu verriegeln, dass es nur eine einzige administrative Session im ganzen Netz akzeptiert.

Der Server beherrscht kein TACACS+, dafür aber eine ganze Reihe anderer Authentifizierungsquellen, wobei er diese meist per LDAP anzapft. Dazu gehören beispielsweise SecurID und Kerberos. Die User-Konfiguration legt Rechte für Anwender sowie Ressourcen im Netz fest. Die skalierbare »ProLDAP«-Repository, die mit RAD-Server ausgeliefert wird, erlaubt es, komplexe Policy-Definitionen zu setzen, Check und Deny-Listen inklusive.

Überraschend war, dass die RAD-Serie die Zwei-Phasen-TTLS-Authentifizierung beherrscht, die sie sogar auf das PEAP-Verfahren ausdehnt. Jede Session authentifiziert sich auf diese Weise gegenüber zwei Anwenderprofilen: Das erste, um den Tunnel aufzusetzen, das zweite, um den Anwender zu identifizieren.

Die »Attribute Pruning«-Funktion des Servers wusste zu gefallen. Sie erlaubt es dem Server, irrelevante Attribute in seiner Antwort an einen NAS-Server zu löschen. Auf diese Weise verhindert er, dass er überflüssige Informationen übermittelt, die ein Dritter abfangen und für feindliche Aktionen missbrauchen könnte. Die RAD-Serie unterstützt tageszeitabhängige Regeln recht solide, versteht aber keinen Algorithmus, mit dem sie Zeitkontingente umsetzen könnte. Interlink erklärte, dass diese Funktion bald in das Software-Development-Kit eingebettet werde.

Der RAD-Server hat leider keine reichhaltigen Statistiken zum Serverstatus geliefert. Es fehlt die wichtige Echtzeit-Anzeige, in der man sofort sehen kann, was aktuell geschieht. Gerade beim Troubleshooting wäre sie extrem hilfreich. Immerhin protokollierte der Server die Sessionzahl und führte auf, wer sich in welche Ressource für wie lange eingeloggt hat. Leider zeigt die RAD-Maschine im Gegensatz zur SBR nicht an, welche Sessions insgesamt über multiple Radius-Proxies hinweg aktiv sind. Im Test konnte das Server-Manager-Interface aber jede beliebige Anwendersession stoppen.

Secure Access Control Server 3.2 von Cisco

Dieser Radius-Server ist robust. Er beherrscht zahlreiche Funktionen, seine Leistung ist erstklassig. In eine reine Cisco-Umgebung integriert er sich nahtlos. Der Secure-Access-Control-Server (ACS) ist aber nicht flexibel. Zu allererst war es nicht möglich, die Authentifizierungs- und Accounting-Ports zu rekonfigurieren. Sie sind an die UDP-Nummern 1645, 1646, 1812 sowie 1813 gefesselt. Falls aus irgendwelchen Gründen diese Ports bereits belegt sind, wird der ACS keine Anfrage beantworten.

Der ACS-Server hat wie erwartet Anwender gegenüber zahlreichen ID-Datenbanken authentifiziert und speziell TACACS+ gut beherrscht. Gute Neuigkeiten für Anwender, die gern auf wichtige Infrastruktur-Elemente zugreifen möchten. Leider konnte das System weder Kerberos noch EAP-TTLS einflechten. Dafür unterstützt der ACS eine Unmenge an Token-Authentifizierungssystemen: Safeword, Passgo, Cryptocard, Avtivcard, Vaso und SecurID.

Dank seiner Herkunft hat das System hervorragend mit NAS-Systemen interagiert. Der Server konnte Access-Control-Lists (ACLs) an ein Cisco-NAS-Gerät exportieren und so den Zugang für Anwender in das Netzwerk feinstufig kontrollieren. Dies funktioniert aber nur bei Cisco-Lösungen und macht daher die Herstellerbindung noch enger.

Im Test wurde der ACS per Browser verwaltet, wobei SSL den Datenaustausch sinnvollerweise kodierte. Von allen getesteten Benutzungsoberflächen war der Cisco-Ansatz am schnellsten nachvollziehbar. Jede Interface-Sektion enthält eine genaue Beschreibung aller Optionen, die man auf dieser Funktionsebene konfigurieren kann. Die Web-Schnittstelle greift so tief in das System ein, dass sie jeden Aspekt des Radius-Servers steuern kann. Im Test musste daher kein einziges Mal auf den Texteditor oder die Befehlszeile zurückgegriffen werden.

Ein Anwender kann sich gegenüber mehreren ID-Datenbanken simultan authentifizieren, wobei der ACS Anfragen an externe Datenbanken zwischenspeicherte. Im Default steuerte der Server auch, wie viele Anwender in einer Gruppe sich simultan einwählen dürfen. Dies geschah über den IP-Adresspool, den der ACS auf die Gruppen aufteilt. Im Umkehrschluss bedeutete dies aber auch, dass der Server sich nicht an den lokalen DHCP-Server koppelt und dessen Funktionen außen vor lässt.

Die Security- und Policy-Management-Funktionen des ACS-Servers sind erstklassig. Nur der ACS und der Navisradius haben Zeitkontingente und tageszeitabhängige Restriktionen für Anwender und Gruppen durchgesetzt. Im Test ließen sich diese Regeln recht einfach konfigurieren. Es wurden beispielsweise Grenzwerte für die Verbindungsdauer und fehlgeschlagene Login-Versuche festlegt. Auch unterschiedliche Passwörter abhängig vom verwendeten Frontend-Authentifizierungsmechanismus waren einstellbar. Nur der ACS erlaubte es den Anwender, ihre Zugangspasswörter in der lokalen ACS-Datenbank über den Browser zu ändern.

Die Berichtsfunktionen dagegen konnten nicht überzeugen. Cisco empfiehlt seinen Kunden, zu diesem Zweck auf Tools von Drittherstellern zurückzugreifen. Die gesammelten Logs konnte der ACS per CSV-Datei exportieren, wobei er die Einträge nach Ereignistyp sortierte. Ein Bericht wusste immerhin zu gefallen. In dem »administrative audit« zeichnete der ACS alle Aktionen auf, die bei einem Login mit Administratorrechten geschehen. Darin waren beispielsweise alle Konfigurations- und Policy-Änderungen aufgeführt. Auch das Tool »CSMon« hat nützliche Daten geliefert. Es protokollierte den Status des Servers. Der Administrator kann darin Gegenmaßnahmen festlegen, die ein frei definierbares Ereignis auslöst.

Pluspunkte hat der ACS gesammelt, weil er als Pionier VoIP unterstützt. Die VoIP-User-Konfiguration legt kein Passwort fest. Das VoIP-Accounting und –logging ist außerdem von anderen Account-Logs getrennt. Dies hilft dabei, zwischen VoIP-Anwender zu differenzieren und ihren Netzzugang abhängig von ihrem Bedarf zu regeln.

Info

So testete Network Computing

Die Radius-Server wurden auf einem Dell-»PowerEdge 2450«-Rechner mit 1 GByte Hauptspeicher, 25 GByte großen SCSI-Platten und zwei 993-MHz-Pentium-Prozessoren aufgespielt. Als Betriebssystem nutzten wir Windows-2000-Server mit Service-Pack 4 und Linux 7.3

Wir richteten die Server so ein, dass sie mit mehreren Radius-Clients sprechen mussten. Darunter der »VPN 3000 Concentrator« von Cisco, der Access-Point »Aironet 1100«, auch von Cisco, sowie der Access-Point »AP-600« von Proxim. Wir benutzten zudem kommerzielle Radius-Testwerkzeuge wie den »NAS Simulator« und das Radius-Last-Tool von Evolynx. Dieses hat vielzählige Radius-Anfragen generiert. Die Testwerkzeuge gaben uns die nötige Flexibilität, um die Server-Kapazität zu untersuchen.

Die Leistung hing tatsächlich davon ab, auf welcher Plattform die Server liefen. Da die Radius-Server auf dezidierten Maschinen arbeiteten, konnten wir ihre Grenzen so richtig ausloten. Wir jagten die CPU-Auslastung auf zwischen 90 bis 95 Prozent hoch, um in dieser Stresssituation beurteilen zu können, wie viele Anfragen die Server abweisen mussten. Danach fügten wir mehrere Anwender einer Session hinzu, um zu sehen, wie effizient die Datenbank der Server User-Profile organisiert. Natürlich gab es Leistungsunterschiede, sobald die Radius-Server per Proxy externe Datenbanken befragen mussten. Hier wirkte die Performance der externen Systeme ein.

Wir simulierten mit den Testwerkzeugen fünf simultane Anfragen. Darin alternierten fünf legale und zwei illegale User. Damit wir die Ergebnisse miteinander vergleichen konnten, mussten sich alle diese Anwender gegenüber dem AD authentifizieren. Radiusnt von IEA, der ACS von Cisco und der Navisradius von Lucent verkrafteten 170 Anfragen pro Sekunde. Der Steel-Belted-Server von Funk verdaute sogar 320. Interlink hat gar unglaubliche 1900 Anfragen in der Sekunde abgewickelt. Diese herausragenden Resultate verdankt das System seiner Linux-Plattform. Leistung allein sollte aber nicht die wichtigste Entscheidungsgrundlage sein. Denn im Schnitt wird ein Server kaum mehr als 120 Anfragen pro Sekunde erledigen müssen. Alle Server im Test haben diese Marke souverän überboten.

Wir verifizierten, ob die Server die Radius-Spezifikationen RFC2865 und RFC2869 und die EAP-Definition RFC2716 einhalten. Wir untersuchten auch, wie gut die Server die »Advisory CA-2002-06« umsetzen. Hierin sind Denial-of-Service-Attacken beschrieben.

Schließlich analysierten wir, wie gut die Produkte den Wünschen von IT-Abteilungen in Unternehmen gerecht werden. Die Server mussten dabei zeigen, ob sie mehr zu bieten haben, als der Radius-Standard vorgibt.

RadiusNT 5.0 von Iea Software

Dieser Server ist Bestandteil der »Emerald Management Suite« von Iea Software. Die Standard-,Professional- und Enterprise-Version kostete nur einen Bruchteil dessen, was die anderen Radius-Server-Hersteller verlangten. Im Test wurde die funktionsreiche Enterprise-Version untersucht. Sie unterstützt die LDAP-Authentifizierung und Token-Cards der größeren Dritthersteller. Die Installation verlief nahezu problemlos. Der »RadiusNT« ist allerdings eng an die »Emerald UI« gebunden, weshalb man die Emerald-SQL-Datenbank aufsetzen muss. Nichtsdestotrotz konnte sich der Server über sein ODBC-Interface an weitere externe Quellen koppeln, darunter Oracle, Sybase, MySQL und PostgresSQL.

Verwaltet wurde die Maschine mit einem auf Web basierenden Konfigurationswerkzeug, dessen Oberfläche aber teilweise unverständlich war. Es dauert eine ganze Weile, bis gewisse serverrelevante Attribute gefunden und eingestellt waren. Dem Radiusnt wird ein Client-Test-Tool beigelegt, mit dem sich die Servereinstellungen testen lassen. Außerdem ließ sich der Server per Befehlszeile in einem Debugging-Modus starten. In diesem Modus fiel es weitaus leichter, den Grund für fehlgeschlagene Authentifizierungsversuche zu isolieren. Bei den Authentifizierungsmechanismen kam der Server den Testern leider nicht soweit entgegen. Es fehlt der Support für auf Zertifikate basierende Mechanismen wie TLS und TTLS. PEAP dagegen war angemessen abgedeckt.

Die Zeitkontingente hat der Radiusnt im Test dagegen hervorragend durchgesetzt. Jedes Mal, wenn sich jemand einloggte, wurde die entsprechende Dauer vom Zeitbudget des entsprechenden Anwenders abgebucht. Zudem informierte der Server die Anwender in seiner Authentifizierungsantwort, wie viel Zeit ihnen noch bleibt. Auf diese Weise verhinderte er, dass die User ihr Budget überstrapazierten.

Die Berichte und das Logging waren kein Lichtblick. Falls der Server sich per ODBC-Interface an eine SQL-Datenbank koppelt, so darf man immerhin die Accounting-Logs anpassen und eigene Queries definieren. Das VoIP-Accounting überzeugte. Der Server konnte sich außerdem an andere VoIP-Accounting-Datenbanken koppeln. Iea Software erklärte, dass der VoIP-Support primär dazu genutzt werde, Calling-Card-Dienste abzubilden. In dem Fall wird der Radiusnt-Server an eine Billing-Plattform angebunden.

Die Maschine beherrscht SNMP. Im Test exportierte das Protokoll Informationen über den aktuellen Status des Servers. Um die Sicherheit zu erhöhen, erkannte Radiusnt duplizierte Authentifizierungsanfragen. Zudem setzte er SSL-Zertifikate ein, mit denen er die Integrität der Daten bei LDAP-Transfers sicherstellte.

Fazit

Wie die Report-Card zeigt, liegen der Erst- und Letztplatzierte gerade einmal einen halben Punkt auseinander. Keiner der fünf getesteten Radius-Server wird daher in einem Radius-Projekt enttäuschen.

Den besten Eindruck im Test machte der Navisradius-Server von Lucent. Er hat einen ausgewogenen Ansatz gewählt und mit seinen Management- und Konfigurationsoptionen überzeugt. Den letzten Ausschlag gab das flexible Preismodell, das sich an dem Einsatzfall orientiert. Damit hat sich der Navisradius von Lucent die Auszeichnung »Referenz« der Network Computing erworben. Der Steel-Belted-Radius-Server von Funk liegt nur knapp auf dem zweiten Platz, weil er den Zugriff der Anwender weniger feinstufig regelt. Er unterstützt unter anderem keine Zeitkontingente. Der drittplatzierte RAD-Server von Interlink Networks hat im Test mit 1900 Transaktionen die größte Leistung geboten, im Management-Bereich aber Schwächen gezeigt. Man muss hierfür teilweise komplizierte Skripte einsetzen. Der Secure-Access-Control-Server von Cisco eignet sich vorzüglich für Cisco-Umgebungen, ist in anderen Einsatzfällen aber nicht flexibel genug. Sein vierter Platz ist durch seine schwachen Report-Funktionen und fehlendem DHCP-Support begründet. Auf dem fünften Platz liegt der Radiusnt-Server von Iea Software. Im Test hat er die komplizierteste, weil nicht eingängige Management-Oberfläche geliefert. Er unterstützt weder TLS noch TTLS wie die anderen. Auch im Reporting konnte dieser Radius-Server nicht überzeugen. [ nwc, pm ]