Die Geheimnisträger
Zugangsinformationen sind sensibel, ihr Management sicherheitsrelevant. Die Real-World Labs haben daher fünf Authentifizierungs-Server daraufhin untersucht, wie sie mit diesen Geheimnisen hantieren und wie sie mit einem zweiten Faktor, dem Token, fertig werden.

Von allen ernst zu nehmenden Authentifizierungsmethoden erreicht das Passwort das niedrigste Sicherheitsniveau. Um es zu stärken, ordnen Unternehmen per Regelwerk eine Mindestlänge, Verfallsdauer und Sonderzeichen an. Wer seine Anwender mit solch komplexen Zugangscodes nicht konfrontieren möchte, um auch den gewiss höheren Support-Aufwand zu vermeiden, kann ein simpel strukturiertes Passwort um einen zweiten Faktor ergänzen.
Die Industrie hat zu diesem Zweck Hardware-Token entwickelt. Erst wenn der Anwender das richtige Passwort angegeben und seinen kleinen USB-Token in den Rechner gesteckt hat, gibt ihm das Betriebssystem oder die Anwendung den Zugang frei. Solche Konzepte müssen natürlich zentral administrierbar sein und ausreichend skalieren, um den professionellen Bedürfnissen einer Firma zu entsprechen. Die Real-World Labs haben solche Access-Management-Systeme daraufhin untersucht, ob sie die auf Token basierende Authentifizierung unternehmensgerecht beherrschen.
Report-Card: Authentifizeirungs-Server
Gesucht waren Authentifizierungs-Server und Client-seitige Techniken, die die Standardidentifizierung per Anwendername und Passwort ersetzen oder ergänzen. Dazu müssen die Server mit allen gängigen LDAP-Datenbanken interagieren, seien es nun das Microsoft-Active-Directory (ADS), das E-Directory von Novell oder die Directory-Services von Sun. Zudem sollten die Systeme im Test den Aufbau eines Single-Sign-on-Konzepts in Aussicht stellen. Die Testumgebung bestand aus Windows- und Linux-Clients. Die untersuchten Lösungen mussten ihre Identifizierungsdienste sowohl für gängige kommerzielle Anwendungen als auch für eigen-entwickelte Programme bereitstellen, wobei sie primär Hardware-Token einzubinden hatten.
Nur fünf Produkte haben diese Kriterien erfüllt: der »ActivPack AAA Server 6.3« von Activcard, der »Steel-Belted Radius 4.71« (SBR) von Funk Software, der »NavisRadius 4.0« von Lucent, der «Nsure SecureLogin 3.5« von Novell sowie »SafeWord PremierAccess« von Secure Computing. Auch der Anbieter Sevan Computing hat seine Produkte zugeschickt, die rein auf Web basierenden Authentifizierungsroutinen haben diese Lösungen für den Test aber disqualifiziert. Die Angebote von Tumbleweed und Vintela haben die Testkriterien ebenfalls nicht erfüllt. RSA Security und Sun Microsystems wollten an dem Vergleich erst gar nicht teilnehmen, haben ihre Gründe aber nicht näher erläutert. Cisco, IBM, IEA Software und Micorosoft erklärten, ihre Produkte seien für diesen Test ungeeignet. Die Anbieter Extreme Networks, F5 Networks sowie Symantec wurden zu dem Vergleich nicht zugelassen, da ihre Lösungen die verlangten Spezifikationen nicht abdeckten.
Standardtreue
Alle untersuchten Produkte bis auf Novells Angebot vertrauen auf Radius als primären Authentifizierungsmechanismus, wobei sie sich eng an die ADS und LDAP binden. Novell erlaubt es dem Administrator, zwischen dem E-Directory, den ADS und jedem anderen LDAP-Verzeichnis zu wählen. Dort organisiert Nsure-Securelogin auch Radius-Zugangsattribute, die das Produkt mit externen Authenfizierungsservern abgleicht. Alle Lösungen passen die Interaktion mit den Anwendern an individuelle Bedürfnisse an. Und alle setzen strenge Policies durch, so dass ein Unternehmen seine Anforderungen recht genau umsetzen kann.
Falls der Administrator nur nach einer sicheren Authentifizierungsstruktur sucht, wird er mit jeder Lösung im Test glücklich. Signifikante Unterschiede treten auf, sobald die Produkte individuelle Skripts entwickeln, komplizierte Regelwerke abbilden und die Authentifizierungsprozesse im Detail verwalten müssen In einem Bereich treten die Unterschiede noch deutlicher hervor: Secure Computing und Activcard liefern auf Token basierende Authentifizierungssysteme, die ihre Dienste auch auf globaler Ebene abwickeln können. Lucent, Funk und Novell beherrschen zwar auch globale Authentifizierungsservices, die aber nur optional Token einbinden. Dies mag wie ein Wortspiel klingen, wird aber in den jeweiligen Lösungsansätzen klar sichtbar. Der Unterschied wird dann besonders deutlich, wenn der Administrator entscheiden muss, allen Usern oder nur privilegierten Mitarbeitern einen Token zu geben, beispielsweise kritischen Abteilungen oder Administratoren. Ein Authentifizierungssystem, das Token optional einbindet, ist weitaus flexibler darin, Anwender auch über andere Mechanismen als den Token zu identifizieren. Soll dagegen jeder Mitarbeiter auf jeden Fall ein solches Zugangsmerkmal bekommen, so ist ein rein auf Token basierendes System definitiv kostengünstiger als die allgemeinen Pendants mit optionalem Token-Support.
Vom Preis her hat Lucent das beste Angebot im Programm. Eine Single-Server-Installation für 500 simultane Anwender kostet rund 1000 Dollar, bei 2000 Mitarbeitern verlangt der Anbieter 4800 Dollar. Die Global-Authentication-Version des Steel-Belted Radius von Funk, wie sie im Test untersucht wurde, kostet dagegen schon 10000 Dollar. Der Anbieter erklärte, seine Preise rangierten von 4000 bis 20000 Dollar, wobei ein Server bis zu 20000 User in der Datenbank verkrafte.
Activcard, Novell und Secure Computing lizenzieren per User. Activcard verlangt 60 Dollar Gebühr pro Server und 43 Dollar pro Token bei 1000 Anwendern. Novell möchte 79 Dollar pro Securelogin-Nutzer. Der Preis pro Silver-Token von Secure Computing liegt bei 106,16 Dollar, ebenfalls in der 1000er-Version, wobei die Lizenz für den Server schon eingerechnet ist. Sobald die Token in einem globalen Authentifizierungsprojekt eingebunden werden sollen, wird die Kostenkalkulation komplizierter. Der Kaufpreis aus Lizenz für den Server und die Token gibt ungefähr die Implementierungskosten pro Anwendung wieder. Diese steigen natürlich mit jeder zusätzlichen Software.
Am Ende hat Navisradius von Lucent dank seiner Flexibilität überzeugt und erhält die Auszeichnung »Referenz« der Network Computing. Für ISPs und große Unternehmen entwickelt, geht das Produkt davon aus, dass jemand in der IT-Abteilung den Authentifizierungsprozess versteht. Diesen Wissensträger unterstützt der Navisradius-Server mit klugen Funktionen, Werkzeugen und einem durchdachten Interface. Wie bei allen anderen Produkten, so muss der Administrator auch bei Navisradius Zeit investieren, um das Produkt an das Netzwerk und seine Anwendungen anzupassen. Dem trägt Lucent Rechnung, indem der Hersteller seinem Kunden Integrationswerkzeuge an die Hand gibt, die diesen Prozess vereinfachen und beschleunigen. Die Funktionen der Tools liefern Skripts mit, helfen bei der Code-Generierung und der Fehleranalyse. Diese außergewöhnlichen Funktionen sind charmanterweise zu dem kleinsten Preis aller getesteten Produkte zu haben.
Wer diese Flexibilität zu Gunsten der Bedienerfreundlichkeit opfern möchte, ist mit Safeword-Premieraccess von Secure Computing gut bedient. Der Administrator kann dieses auf Token basieren-
de Authentifizierungssystem recht leicht konfigurieren und große Stückzahlen schnell und einfach an die Anwender liefern. Der Kaufpreis ist zwar recht hoch, die User-Self-Enrollment-Funktionen und die direkte Konfiguration des Servers senken jedoch Betriebskosten. Außerdem sind die Secure-Computing-Token simpel zu bedienen.
NavisRadius 4.0 von Lucent
Auf den ersten Blick wirkte dieser Server für kleine und mittelgroße Unternehmen viel zu mächtig und überladen. Es stellte sich alsbald heraus, dass der kleine Eintrittspreis und die automatischen Konfigurationswerkzeuge den Navisradius für nahezu jede Umgebung zu einer geeigneten Lösung aufwerten. Wer solide Authentifizierungsdienste sucht und auf jemanden zurückgreifen kann, der die Details solcher Prozesse lernen will oder bereits beherrscht, ist mit diesem Produkt auf einem guten Weg.
Lucent selbst versteht ihr Produkt als Radius-Entwicklungs-Plattform, auf der die Kunden eigene Authentifizierungsprogramme schaffen. Diese Dienste kombinieren Geräte wie die Token und die Anwender-Authentifizierung mit dem eigentlichen Applikationsstart und komplexen Accounting-Prozessen. Statt dies über C-Code abzuwickeln, hat Lucent zu diesem Zweck eine eigene Skriptsprache geschaffen. Die Programmierer bei Lucent selbst benutzen diese Sprache und das zugehörige Interface, um Default-Skripts zu liefern. Im Test war es leicht, die Skripts in dem Interface zu entwickeln, weil der Code nicht kompiliert werden muss.
Der »Policy Assistant« des Servers hilft dabei, die ersten Konfigurationsschritte durchzuführen und die nötigen Plug-ins einzuflechten. Lucent versteht unter Letzterem modulare Skripts, mit denen die Konfiguration für den spezifischen Einsatzfall festgezurrt wird. Das Werkzeug verhielt sich flexibel und eröffnete eine Vielzahl von Optionen, mit denen der Administrator während der Setup-Routine konfrontiert wird.
Lucent liefert eine enorme Fülle von Plug-ins mit aus. Selbst für Aufgaben, bei denen es eindeutig war, dass Anpassungs- und Entwicklungsarbeit gefordert sind, hat Lucent ein Ausgangsskript mitgeliefert, das nur noch angepasst werden musste. Das spart Zeit. So hat das Produkt im Test beispielsweise MAC-Adressen von Wireless-Adaptern importiert, um daraus Access-Control-Lists (ACLs) abzuleiten. Man findet LDAP- und SQL-Plug-ins neben Read-DNS-Pendants und Funktionen, die auf einen Programm-Flow reagieren. Parameter für das Reporting, Accounting oder die Systemleistung waren gleich mit berücksichtigt oder ließen sich leicht hinzufügen.
Die Programmierungsoptionen innerhalb der Plug-ins sind nahezu grenzenlos. Im Test wurden beispielsweise ACLs als Teil des »allow this«-Plug-ins aufgesetzt. Diese Logik ließ sich später für das »deny this«-Plug-in einfach umkehren.
Lucent geht davon aus, dass der Navisradius-Kunde bereits unternehmensweite Accounting- und Reporting-Werkzeuge einsetzt. Daher beherrscht der Navisradius viele Optionen, um seine Informationen an externe Reporting-Systeme durchzureichen, inklusive Traps, Syslog, Datenbanken oder Webseiten. Die Daten lassen sich per LDAP exportieren, wobei Lucent diese Route nicht empfiehlt.
Nach Meinung des Herstellers sind andere externe Speicher viel robuster und von anderen externen Anwendungen leichter zu erreichen. Navisradius kann Variablen auch an externe Programme oder an gesicherten C-Code exportieren, wobei diese zwei Funktionen eine Auslastungsspitze beim Prozessor verursachen. Zusätzlich protokolliert der Server selektiv bestimmte Merkmale externer Quellen. Ein eigenes Reporting-Tool hat Lucent dagegen noch nicht entwickelt, möchte dies aber in der nächsten Version nachholen.
Navisradius läuft auf Apple-Mac-OS-X, HP-UX, Windows-2003, Redhat-Linux und Sun-Solaris. Das Produkt interagiert mit Zertifikaten, um Geräte zu authentifizieren. Es akzeptiert zudem Self-Signing-Zertifikate und generiert sowohl User- als auch Server-Zertifikate.
Beim Test wurde das Setup mit dem funktionsreichen Policy-Assistant und seinem Wizard gestartet. Der Helfer zeigt zuerst eine lange Liste von Datenbank-Quellen an, gegenüber denen der Server authentifizieren kann. Alle gängigen Datenbank-Typen und Hersteller sind darin aufgeführt. Innerhalb der Datenbanktypen stehen Optionen zur Verfügung, die alle Varianten von EAP und viele andere Authentifizierungsvarianten abdecken. In einer anderen Sektion werden multiple Server für Failover- und Load-Balancing-Zwecke festgelegt. Sobald Probleme auftreten, kann der Administrator über einen Klick die Navisradius-Webseite öffnen. Sie hilft ihm mit Dokumentationen, technischen Bemerkungen und einem Plug-in-Diskussionsforum.
Bei der Entwicklung der Authentifizierungs-Skripts sind gute Testwerkzeuge unabdingbar. In diesem Bereich glänzt Lucents Produkt. Der Hersteller liefert eine gute Auswahl an Test-Tools, einen Echtzeit-Paket-Dekoder, NAS-Simulators für Lasttests sowie einen VPN-Test-Client inklusive. Die Tester haben während der Analyse einmal versäumt, den Server neu zu starten. Die im Debugger auflaufenden Fehlermeldungen haben auf diesen Umstand hingewiesen. Es traten beispielsweise auch Probleme auf, weil das Produkt die globalen Gruppen im Windows-Domain-Controller anders verstand als angenommen. Die Tester meinten, diese Gruppen wären bereits aufgesetzt, der Navisradius-Server widersprach dem. Es stellte sich heraus, dass die Maschine nicht als Teil der Domain angemeldet war. War dies nachgeholt, arbeitete der Server fehlerfrei.
Wie erwähnt, wurden zuerst die Windows-ADS und die Software-Asset-Management-Authentifizierung (SAM) eingerichtet. Im nächsten Schritt richteten die Tester beim Navisradius, wie bei allen anderen Produkten auch, die Parameter für einen Client-to-Server-VPN-Dienst. Dieser Dienst basierte auf den Remote-Access-Service (RAS) von Microsoft. Die gesamte Prozedur war einfach durchführbar. Der Radius-Server etablierte die entsprechenden Accounting-Meldungen, und die restliche Konfiguration verlief, ohne zu stocken.
Im nächsten Schritt wurde eine mehrstufige Authentifizierungsroutine entwickelt. Das Plug-in »authen-t«, das hierfür zum Einsatz kam, war nicht ganz sauber programmiert, so dass es die Authentifizierungsversuche beeinträchtigte. Um den Fehler zu finden, analysierten die Tester die Traces der Authentifizierungsversuche, isolierten das Problem, modifizierten einige wenige Parameter im Plug-in, so dass der Prozess schließlich fehlerfrei arbeitete.
Die Skriptsprache ist objektorientiert und wird jedem bekannt vorkommen, der schon mal mit C++ oder Java programmierte. Die soliden Debugging-Werkzeuge helfen bei der Entwicklung und dem Feintuning des Skriptcodes. Die Dokumentation innerhalb der Skript-Sprache ist reichhaltig und gut. Ein IT-Verantwortlicher, auch wenn er kein Programmierspezialist ist, wird sich zurechtfinden, selbst wenn er komplizierte Authentifizierungs-Routinen aufsetzen möchte.
Die Management-Konsole basiert auf Java und arbeitet nichtsdestotrotz schnell. Im Test zeigt sie die aktiven Verbindungen, Statistiken zu Verbindungsversuchen sowie die Fehlermeldungen und aktiven Datenflüsse an.
Navisradius besitzt weder eigene Token, noch eine Token-Engine, unterstützt aber die entsprechenden Produkte von Accent, RSA und Safeword. Bei anderen Token-Typen muss der Administrator entsprechende Plug-ins entwickeln und unabhängig vom gewählten Typen den Token-Authentifizierungsserver separat betreiben.
Das Plug-in für Safeword benutzt Safeword-Methoden und Libraries, die bereits standardmäßig in Navisradius eingebaut sind. Es traten allerdings überraschend Komplikationen auf. Der Navisradius hat beispielsweise ganz andere Kommunikations-Ports erwartet, als Safeword standardmäßig benutzt. Die Änderung der Ports war jedoch in fünf Klicks getan.
Safeword Premieraccess von Secure Computing
Der Hersteller nähert sich dem Thema Authentifizierung von der Token-Seite her und greift auf Partner zurück, um SSO und bestimmte andere Anwendungskonstellationen direkt zu unterstützen. Falls das Unternehmen SSO rein über einen Webserver realisieren möchte, wird Safeword alles ohne fremde Hilfe abwickeln. Für alle anderen Authentifizierungs-Prozesse, die Log-in-Skripts ohne den Weg über einen Webserver verwenden, bindet Secure Computing eine Reihe von Drittherstellern an. Auch die Synchronisation der Datenbankbestände geschieht mit Hilfe Dritter, in diesem Fall unter Beteiligung von Macware und Sun.
Premieraccess ist keine Billigpreislösung. Neben dem Lizenzpreis kommen noch versteckte Kosten für externe Produkte hinzu, sofern der Administrator deren zusätzliche Funktionen braucht. Aus diesem Grund liefert Secure Computing mit seinen Token und dem Server auch eine Reihe von Integrationskits aus, die die Drittprodukte schnell und simpel integrieren. Dies soll am Ende Entwicklungszeit und -kosten auf Kundenseite einsparen.
Wie die anderen Produkte im Test, hakt sich Premieraccess in bestehende ADS-, Radius- und LDAP-Verzeichnisse ein. Das Integrationsniveau und die Aktivierungsmethoden für ACLs variieren bei allen dreien. Falls bereits eine ADS mit Zugangsregeln und Rollen existiert, werden diese auch genutzt. Bei reinen LDAP- oder Radius-Verzeichnissen dürfen die ACLs auch auf der Premieraccess-Datenbank platziert sein. In allen Fällen jedoch können die ACLs auch Autorisierungsinformationen aufnehmen, um die Authentifizierung der Anwender zu erweitern.
Wer mehr als eine Hand voll Token an seine Mitarbeiter auszuliefern hat, weiß zu genau, dass Automatisierungsfunktionen hierfür wichtig sind. Auf diesem Gebiet wusste Premieraccess besonders zu überzeugen. Falls der Administrator im gesamten Unternehmen einen zweiten Authentifizierungsfaktor durchsetzen möchte, wird er mit dem Produkt von Secure Computing bei der Token-Implementierung Geld einsparen können. Premieraccess importiert beispielsweise Datenbankeinträge oder erlaubt es dem Administrator, Anwender einzeln herauszusuchen. Das Produkt beherrscht aber auch Self-Enrollment-Optionen auf Web-Basis.
Auf Wunsch übernimmt auch der Hersteller die Auslieferung der Token. Dabei programmiert der Anbieter die Token nach den Unternehmensvorgaben, liefert sie physisch an den Anwender und generiert eine Datenbank, die er der IT-Abteilung überstellt. Aus Sicherheitsgründen schickt er noch separat Briefe mit einer PIN-Nummer an die entsprechenden User heraus. Dieser »Automated Deployment Service« beherrscht auch noch weitere Optionen, die je nach Aufwand natürlich unterschiedlich viel kosten. Mit 10 Dollar Mehrkosten pro Token muss man schon kalkulieren.
Die Installation von Premieraccess verlief reibungslos, bis der Server den Authentifizierungsdienst für das Client-to-Server-VPN auf Basis des Microsoft-RAS-Dienstes umsetzen musste. Hier traten leider große Probleme auf beiden Seiten des Tunnels auf. Zum Glück beherrscht der Radius-Server von Secure Computing eine Reihe von Fehleranalysen. Aber selbst als die Kommunikationsverbindung hergestellt war, hat Premieraccess einige Attribute nicht an die ADS weitergereicht, so dass die Authentifizierung insgesamt fehlschlug.
Eine solche Transaktion von Parametern kann natürlich viele Arten von Informationen austauschen. Es ist aber recht ungewöhnlich, wenn eine grafisch abgewickelte Konfigurationsroutine den Anwender auf dieser Ebene mit solchen komplexen Parametern konfrontiert. Wer bei Premieraccess die Konfigurationsdatei per Editor öffnet, findet beispielsweise Strings für Cisco-Infrastrukturkomponenten oder Netzwerkparameter, die sich in dem Response-Set festlegen lassen.
Beim Test jedenfalls stellte sich heraus, dass das Microsoft-RAS-Problem auftrat, weil die IP-Adresse des RRAS (Routing und RAS) nicht per DHCP festgelegt wurde, obwohl der Server diesen Dienst tatsächlich aktiviert hatte. Auch eine Windows-2003-Maschine hatte ihre Schwierigkeiten, doch war dies ein bekanntes Problem mit der Verschlüsselung bei Microsoft-Point-to-Point (MPPE). Secure Computing erklärte zum Testzeitpunkt, dass der Hersteller heilende Patches entwickeln werde.
Der Universal-Web-Agent (UWA) läuft auf Apache und baut einen Reverse-Proxy auf, der alle Anfragen über Port 80 erhält und diese zur Applikation durchreicht. Dieser Mechanismus fügt eine zusätzliche Schutzebene ein, da beispielsweise ein IIS-Server einfach auf Anfragen von 127.0.0.1 wartet, ohne direkt an das Internet gebunden zu sein. Als Teil des Authentifizierungsprozesses generiert der UWA ein Session-Cookie und nutzt Zertifikate, die gewöhnlich an die eigene interne Certificate-Authority (CA) gekoppelt sind. Der UWA unterstützt natürlich alle standardkonformen CAs. Es waren nur einige Konfigurationseinstellungen beim Agenten und der Host-Datei des IIS-Servers notwenig, um die Webseite zu schützen. Das Ganze dauerte nicht länger als zehn Minuten.
Die Log-Einträge des Produkts umfassen vollständige Informationen zu akzeptierten und fehlgeschlagenen Authentifizierungsversuchen, administrativen Änderungen und mehr. Der Verwalter findet darin beispielsweise auch Informationen zu einzelnen Anwendern, ihren Aktionen, ihren Access-Control-Listen und Resultaten, die ihre Authentifizierungsversuche bei den jeweiligen Servern produzierten, und dem Adressbereich, aus dem sie diese Versuche initiierten. Aus diesen Daten generiert Premieraccess eine Reihe von Berichten, die eine Vielzahl von Kriterien entweder auf Anfrage oder in zeitlichen Intervallen zusammenfassend darstellen.
In drei mitgelieferten Software-Developer-Kits (SDKs) werden Skripts für Windows oder Solaris generiert, wobei die Applikationen selbst auf HP-UX, IBM-AIX, Linux, Windows oder Solaris laufen dürfen. Ein zusätzliches Authentication-SDK liefert eine Library und Beispiel-Code für Java, C und Windows-DLLs. Damit lassen sich die Authentifizierungsdienste auch an Legacy-Anwendungen koppeln. Das Administrations-SDK deckt die gleichen Funktionen ab wie die Admin-Konsole von Premieraccess. Damit lassen sich beispielsweise die Anwender-Interfaces oder die Web-Konsolen aufsetzen.
Obwohl die SDKs überzeugten, erreichen sie nicht das gleiche Niveau bei der Fehleranalyse wie Navisradius. Im Test wurden Echtzeit-Alarme und Benachrichtigungsoptionen festgelegt, damit alle Authentifizierungsaktionen des Servers zu überwachen waren. Der Server sollte zudem automatisch Alarme initiieren, sobald etwas Ungewöhnliches geschieht.
Nsure Securelogin 3.5 von Novell
Dieser Server ist recht genügsam, was seine Ansprüche an die CPU betrifft. Sein Speicherhunger ist zwar nicht klein, dafür muss man keinen Dual-Prozessor-Server aufsetzen, um die Software zu hosten. Die Installation fällt leicht, wenn der Akteur Netware-Hintergrund hat. Sie wird allerdings zu einer sperrigen Aufgabe, wenn dieses Wissen fehlt, da die Nomenklatur dann durchaus verwirrend ist.
Im Test wurde sowohl Securelogin als auch das E-Directory aufgesetzt, wobei die Installation des Verzeichnisdienstes auf einem Windows-2003-Server kinderleicht war. Wenn das Manager-Tool die im Netz aufgesetzten Applikationen und Dienste durchschaut, wird es beispielsweise automatisch den Apache-Webserver und die Java-Virtual-Mashine (JVR) mitinstallieren, sofern es nicht etwas Vergleichbares findet.
Ein Reboot garantierte, dass alle aufgesetzten Dienste ordnungsgemäß gestartet sind. Danach öffnete sich das Web-Management-Interface. Die E-Directory-Lizenz ist übrigens im Kaufpreis von Securelogin – 79 Dollar pro User – enthalten und macht somit den Wechsel zu einem solchen Verzeichnisdienst attraktiv. Sofern sich der Kunde für Securelogin entscheidet.
Novell bietet eine Vielzahl von Verzeichnis-, Authentifizierungs- und Identity-Management-Produkten an. Im Test wurde der Securelogin-Client untersucht, ein Client-seitiger Agent, der Authentifizierungs- und Autorisierungsbelange gegenüber einer Vielzahl potenzieller Backend-Server regelt.
Der Client wurde anfangs entwickelt, um Single-Sign-on (SSO) zu realisieren. Sobald Securelogin die Benutzernamen-Passwort-Kombination aufspürt, schlägt er dem Anwender daher vor, einen Wizard zu starten. Dieser erzeugt dann SSO-Informationen um das Passwort herum. Viele dieser SSO-Funktionen sind in dem Client eingebaut. So lässt sich festlegen, ob die Anwender selbst ihre eigenen Login-Infos erzeugen dürfen oder dies nur der Administrator regelt.
Es findet sich auch eine Menge vorgefertigter Login-Skripte, eigene Schemata lassen sich natürlich auch entwickeln. Um die Sicherheit zu steigern, lassen sich auf dem Client Passwortregeln einrichten und durchsetzen und auch Security-Phrases einstellen, die später für die Authentifizierung gebraucht werden. Administratoren dürfen aus einer Vielzahl von Verschlüsselungsoptionen wählen, um diese sensiblen Informationen sicher zu übertragen und zu speichern. Darunter fallen 3DES, »Novell SecretStore« innerhalb des E-Directory und die »Novell International Cryptographic Infrastructure« (NICI), ein FIPS-zertifizierter Service innerhalb des Verzeichnisdienstes.
Das »ConsoleOne«-Interface verwaltet das E-Directory. Auf Serverseite hinterließ dieses Werkzeug einen guten Eindruck, da die von ihm geschaffenen Login-Skripte fast so aussahen und sich verhielten, wie es die Tester verlangten. Einen besonderen Trick beherrscht das Konzept von Novell auch: Das Produkt gibt Passwörter an Applikationen weiter, ohne dass der Anwender selbst diese einsehen darf. Dieses Passwort lässt sich als Property an das Login koppeln oder wird in ein Skript eingebettet, wobei es für den Anwender unsichtbar bleibt, sobald er den Login initiiert.
Für ein Produkt, das selbst keine Token besitzt, beherrscht es einen durchaus sanften Token-Integrationsprozess, der vor allem die »DigiPass Token« von Vasco gut unterstützt. Die auf Token setzenden Authentifizierungsmethoden wurden mit Hilfe des Handbuchs von Vasco aufgesetzt. Die Token dieses Herstellers beherrschen als einzige alle potenziell verfügbaren Authentifizierungsverfahren, ohne dass zusätzliche Software notwendig wird. Im Gegensatz zum Token-Support der Lösungen von Lucent und Funk unterstützt Novell auch alle Backend-Systeme, die für eine Zwei-Faktor-Lösung auf Basis von Vasco notwendig sind. Securelogin kann eine Passthrough-Authentisierung auch mit anderen Token umsetzen, dafür ist jedoch größerer Integrationsaufwand erforderlich. Im Fall von Vasco reichte ein simpler Download, der Kauf zusätzliche Server- oder Client-Software oder gar neuer Lizenzen war nicht notwendig.
Steel-Belted Radius 4.71 von Funk Software
In einigen Bereichen hat dieser Server mit dem Testsieger Schritt gehalten. Während der Lucent-Server sich eher an Authentifizierungsexperten richtet, möchte der Steel-Belted Radius (SBR) es lieber Netzwerkgeneralisten erleichtern, eine starke Authentifizierung aufzusetzen. Das Handbuch erklärt beispielsweise, was Radius ist und wie es funktioniert. Falls die geplante Implementierung allerdings viele individuelle Anpassungen und Einstellungen notwendig macht, ist bei diesem Produkt Vorsicht angebracht. Sobald im Test Parameter weitgreifend verändert wurden, hat die INI-Orientierung des Servers Probleme verursacht, die sich mit den schwachen Debugging-Werkzeugen nur mühsam aufdecken ließen.
Im Test wurde die SBR-Global-Enterprise-Edition aufgesetzt. Selbst die größte Version des SBR wird über ein einfaches Benutzungs-Interface gesteuert. Zuerst haben sich die Tester mit dem lokalen Server verbunden und dann fünf Authentifizierungsmethoden ausgewählt: Native-User, NT-Domain-User, NT-Domain-Group, Windows-Domain-Group sowie Windows-Domain-User. Die meisten Funktionen in dieser Setup-Routine werden über einen einfachen Klick angesteuert und aktiviert. Die Tester fügten einen neuen RAS-Client aus einer langen Liste verfügbarer RAS-Pendants hinzu, wählten NT als Ziel und kreierten einen IP-Pool für diese Clients.
Um ein Profil anzulegen, stellt der Administrator all jene Attribute ein, die geprüft, akzeptiert oder an weitere Quellen wie einen anderen Authentifizierungsdienst oder eine Applikation weitergereicht werden. Die Liste der Optionen ähnelt stark der von Navisradius. Den großen Unterschied macht das Benutzungs-Interface aus: Es ist beispielsweise möglich, einen Nachrichtentext festzulegen, der standardmäßig bei fehlgeschlagenen Authentifizierungsversuchen erscheint, unabhängig vom Grund.
Neue Anwender werden in einem schrittweisen Prozess angelegt, angefangen beim Namen, der Domain und dem Token »SecurID«. Bei der Netzwerk-Authentifizierung traten aber einige Probleme auf, die auf die Dokumentation zurückzuführen waren. Dort stand, dass der SBR auch Geräte authentifizieren kann, die nicht auf einem Domain-Controller installiert sind. Die Fehlermeldungen des Servers informierten die Tester jedoch, dass er keine Domain-Authentifizierung durchführen könne, weil der betreffende Server nicht auf dem Domain-Controller eingerichtet sei.
Um das Problem zu lösen, hat das Werkzeug »Wintail« die Server-Logs in Echtzeit ausgelesen. Die Berichts- und Logging-Funktionen des SBR-Servers sind einfach gehalten. SBR schreibt alle Konfigurationsinformationen in eine Win-dows.txt-Datei, wobei sich Echtzeitdaten auch in Perfmon exportieren lassen. Die Tester mussten allerdings auch in die Radius.INI eingreifen, weil der SBR diese Dateien als Konfigurationsspeicher benutzt.
Es gibt eine ganze Reihe von diesen INIs, und das Handbuch liefert hilfreiche Instruktionen, wie sich diese modifizieren lassen, um den SBR an eigene Bedingungen anzupassen. Dieser Ansatz ist durchaus nachvollziehbar, aber keineswegs besonders praktikabel. Am Ende luden die Tester eine neue DLL aus dem Web, die eine bessere Fehlermeldung herausgab. Danach fügten sie Anwendergruppen aus der ADS hinzu, mussten jedoch die Zeitparameter justieren, damit beide Enden des VPN-Tunnels synchron laufen und die Authentifizierung untereinander gelingt.
Nach einem Anruf beim Funk-Support haben die Tester das Shared-Secret und die drei MPPE-Attribute entsprechend angepasst. Letztere drei sind für den ADS-Pass-through nötig, leider sind ihre Einstellungen im Handbuch ausgelassen, was der Support auch bestätigte.
Für die Token ist der Einsatz von PAP sinnvoller als CHAP. SBR unterstützt standardmäßig RSA-Token, wobei der RSA-Server im Hintergrund laufen muss. Im Test wurde daher der »RSA Ace Server« aufgesetzt, und die Integration verlief wie in der Dokumentation beschrieben.
Die mitgelieferten Plug-ins für Crypto-Card und Vasco wurden von anderen Herstellern entwickelt. Der SBR beherrscht Radius-Pass-through auch bei allen anderen, der Administrator wird aber nicht drum herum kommen, den jeweiligen Token-Server mit aufzusetzen.
Activpack AAA Server 6.3 von Activcard
Diese Lösung ist offensichtlich dafür konzipiert, mit externen Verzeichnissen und Datenbanken wie der ADS oder LDAP zu interagieren, statt eine interne Datenbank zu betreiben. Das Produkt hat ein wenig frustriert, da es einerseits eine ganze Reihe sinnvoller Funktionen beherrscht, die die Implementierung recht direkt und schnörkellos umsetzen. Andererseits sind diese Funktionen in einem Interface eingebunden, das im Vergleich zur Konkurrenz wenig durchdacht wirkt.
Im Test wurde der Server an die ADS angebunden, und schon tauchte das erste sinnvolle Feature auf: Es greift gewöhnlich ungenutzte Properties im Schema auf, um sie als Token-Element nutzbar zu machen. Der Administrator muss sein ADS-Schema also nicht erweitern, um das Produkt einzubinden. Um die Token an die Anwender zu koppeln, muss das bislang nicht verwendete Feld im LDAP-Schema mit dem Activpack-Authentication-Attribut verknüpft werden.
Die Tester gruppierten »Facsimiletelephonnumber« mit dem Activpack-Attribut »Device Serial Number«, also der Seriennummer des jeweiligen Tokens. Microsoft hat ihre ADS natürlich als erweiterbare Architektur konzipiert. Viele Administratoren sind verständlicherweise ein wenig zögerlich darin, dieses Basis-Schema zu erweitern. Wer weiß, was in der Zukunft noch kommt. Für sie ist dieser Ansatz durchaus attraktiv.
Die Basisinstallation ging schnell von der Hand, die Dokumentation dagegen verschloss sich manchmal dem einfachen Zugang. Es war schon kompliziert, ein spezielles Thema zu finden. Außerdem waren die Tester gezwungen, die Quelle eines Problems selbstständig einzuschätzen, bevor sie mit irgendwelcher Hilfe rechnen konnten.
Zum Glück ist es leicht, die Verbindung zur ADS aufzusetzen. Ein erfahrener ADS-Administrator wird kaum länger als fünf Minuten für diese Aufgabe benötigen. Als problematisch stellte sich dagegen der mehrstufige Ansatz von Activcard heraus, den der Hersteller beim Aufbau des Servers verfolgte. Auch die Terminologie, mit der der Hersteller beschreibt, was gerade vor sich geht, ist verwirrend. Zuerst erstellten die Tester den Server (eine Instanz des Authentifizierungsdienstes), dann schufen sie ein »Gate«, um Radius oder Tacacs+ zu starten. Beide Protokolle sind übrigens hauptverantwortlich für die Interaktion von Activcard und Verzeichnisdienst.
Das Gate-Setup enthält die Einstellungen für die autorisierten Remote-Clients, die Autorisierungs- und Accounting-Profil-Zuweisungen und die Selektion des Dictionary. In Letzterem sind die Methoden für ein bestimmtes Authentifizierungsverfahren abgelegt. Außerdem sind dort die Einstellungen für die gängigen Authentifizierungs- und VPN-Server von Drittherstellern gespeichert.
Ein kleines Problem trat bei den Token auf: Sie werden per Floppy-Disk aktiviert, nur hat keiner der Test-Rechner ein solches Laufwerk besessen. Es fehlte außerdem eine Self-Enrollment-Routine, so dass der Administrator die Token manuell zuweisen muss. Die »ActivPack Web Help Desk«, eine Add-on-Komponente innerhalb des Servers, erlaubt es Helpdesk-Mitarbeitern, die Authentifizierungs-Logs einzusehen, Token und PINs freizuschalten oder zu sperren, sie zu synchronisieren, oder zeitlich begrenzt gültige Passwörter festzulegen.
Der Audit-Log informierte darüber, wie sich der Activcard-Server verhielt. Der Administrator darf unterschiedliche Accounting-Systeme definieren, wobei drei Arten von Logs unterstützt werden: Audit, Accounting und Authentication. Ein einfacher Verbindungstest zu Radius initiiert eine Art Ping und bestätigte, dass der Server ordnungsgemäß arbeitete. Erst dann fügten die Tester die VPN-Parameter hinzu und aktivierten die entsprechende Authentifizierungsroutine.
Activcard identifizierte Anwender gegenüber dem Windows-2003-VPN-Server und dem »HP 2524«-Switch erfolgreich. Zusätzlich enthält der Server neben einer API für Web-Server einen Web-Acces-Agent für IIS und Sunone. Über das ebenfalls mitgelieferte Web-Self-Service-Portal können Anwender dem Administrator mitteilen, dass sie ihren Token verloren haben, er gestohlen wurde, der Token neu synchronisiert werden muss. Außerdem dürfen die Anwender dort typische sicherheitsrelevante Fragen stellen, eine Self-Enrollment-Funktion aber fehlt.
Fazit
Wem das Passwort als Zugangscode nicht mehr genügt, der wählt ein Zwei-Faktor-Authentifizierungssystem, heute typischerweise Token. Die Real-World Labs haben fünf Access-Management-Server getestet. Sie binden diese Token ein, unterstützen die vielfältigen Verfahren und binden vor allem bestehende Datenbanken, Verzeichnisdienste und Authentifizierungsmethoden an. Der gesamte Zugangsbereich lässt sich so zentral managen, wobei die Reporting- und Audit-Funktionen in Echtzeit über den Status informieren.
Navisradius von Lucent konnte dank seiner Flexibilität überzeugen und hat die Auszeichnung »Referenz« der Network Computing verdient. Das Produkt setzt aber voraus, dass jemand in der IT-Abteilung den Authentifizierungsprozess versteht. Wem die Bedienerfreundlichkeit wichtiger ist, der wird mit dem zweitplatzierten Safeword-Premieraccess von Secure Computing zufrieden sein. Das Produkt lässt sich leicht konfigurieren, und große Token-Stückzahlen sind einfach zu handhaben.
Der Securelogin 3.5 von Novell musste sich in puncto Bedienerfreundlichkeit den Vorplatzierten geschlagen geben. Der Steel-Belted Radius 4.71 von Funk Software ist ein gutes Produkt, sofern der Administrator mit den Standardeinstellungen leben kann. Will er den Server an eigene Bedürfnisse anpassen, wird er sich mit
den komplexen INI-Konfigurationen auseinandersetzen müssen. Der Activpack-AAA-Server 6.3 von Activcard hat vor allem beim Management enttäuscht, da das zuständige Interface im Vergleich zu den Mitanbietern weniger durchdacht ist. Auch dass die Self-Enrollment-Funktion fehlt, hat das Ergebnis gedrückt. [ nwc, pm ]