Sonntag, 16. September 2007Absurditäten mit Cisco Secure ACS
Ich bin ja einer von diesen Leuten, die proprietärer (im Gegensatz zu freier, also kostenloser, quellcodeoffener) Software nicht viel abgewinnen können, was sicher zum Teil auch ideologische Gründe haben mag. Aber es gibt Erfahrungen, die lassen das auch fachlich angeraten erscheinen.
Cisco Secure ACS ist ein Produkt von Cisco, dass einen kombinierten TACACS- und RADIUS-Server sowie ein Webinterface zu Verwaltung von Benutzeraccounts beinhaltet. Ich hatte kürzlich Gelegenheit, eine größere der Absonderlichkeiten eben jenes Webinterfaces bei der Version 3.3.4.12 für Windows kennen zu lernen. Und das kam so: Alles begann mit einem lange fälligen Update von 3.1. Das funktionierte (nach dem Einlesen und dem etwas umständlichen Erhalt der richtigen Software durch Cisco) wunderbar, allerdings hatte ich übersehen, dass die Weboberfläche, die da benutzt wurde, doch ein wenig frisiert gewesen war - einige Grafiken waren ausgetauscht und einige HTML-Dateien angepasst worden, womit das Webinterface auch kundentauglich wurde. War aber kein großes Problem, die Dateien ließen sich verhältnismäßig einfach aus einem Backup rekonstruieren, und ein netter Kollege führte noch ein zwei Anpassungen durch, dann sah es aus wie zuvor. Ansonsten schien alles einwandfrei zu funktionieren. Soweit, so gut.
Einige Wochen später sprach mich jemand, der regelmäßig mit dem Webinterface arbeiten musste, darauf an, dass es seit dem Update nach wenigen Minuten oder gar Sekunden zu Verbindungsabbrüchen bzw. einem Ende der Administrationssitzung komme. Ich war erstaunt, prüfte das, und konnte es zuverlässig reproduzieren. Der ACS lauscht normalerweise auf Port 2002, wo er HTTPS akzeptiert. Loggt man sich dann ein, wählt das Webinterface dynamisch einen Port, auf dem es die Verbindungen genau dieses Clients für diese Session akzeptiert. Es gibt einen Timeout, der normalerweise eine Stunde hält - so lange sollte der ACS also auf diesem dynmisch ermittelten Port lauschen. TCPView verriet mir jedoch, dass dem nicht so war: Der für das Webinterface zuständige Prozess lief zwar weiterhin, aber nach ein oder zwei Minuten lauschte er nicht mehr auf dem Port, die Sitzung brach also in sich zusammen. Dann hiess es neu einloggen und schnell arbeiten, bevor man schon wieder ausgeloggt wurde. Das ist mindestens nervtötend, vor allem aber produktivitätsmindernd und daher nicht akzeptabel. Da Support von Cisco für das Produkt vorlag und mir genug andere Dinge einfielen, die getan werden wollten, eröffnete ich einen TAC-Case ("Technical Assistance Center", der technische Support von Cisco). Leider machte ich den Fehler, dies an einem Nachmittag nach 17:00 Uhr zu tun, womit ich bei den TAC-Engineers landete, die in einer recht ungünstigen Zeitzone saßen. Der erste Engineer hörte auf den schönen Vornamen "V." und wirkte in seinen Emails durchaus sympathisch - und er hatte mehrere Vorschläge, was man tun könnte, um das Problem einzugrenzen. Nun, eingrenzen hätte ich es auch selber können, ich hatte ja gehofft, das TAC würde womöglich ähnliche Fälle kennen und daher eine schnelle Lösung parat haben. Seine ersten Lösungsvorschläge waren dann auch nicht von Erfolg gekrönt: Java auf dem Server upgraden, ACS neu installieren. Ich tat das, auf einer Backupmaschine, allerdings war ich diesmal schlau genug, die angepasste Weboberfläche vorher wegzusichern und schnell wieder einzuspielen, so dass wenigstens die Anpassung schnell erledigt war - nur leider hatte die Aktion keinen Erfolg. Trotz großer Sorgfalt war es dem guten V. leider auch nicht möglich, das Problem zu reproduzieren, er sagte jedoch, er habe einen Bug gefunden, der auf das Problem passen könnte - er gab mir sogar einen URL. Als ich auf diesen jedoch klickte, erhielt ich nur die freundliche Mitteilung, dass dieser Bug nur für Cico-Mitarbeiter ansehbar sei und nicht für Kunden (peinlich, peinlich). Dennoch gelang es uns, auszuschließen, dass dieser Bug mit unserem Problem zu tun hätte. Schließlich schlug V. vor, das unter dem ACS laufende Windows neu zu installieren. Und das alles mit Verzögerungen von 24 Stunden zwischen Emails, weil unsere Zeitzonen etwas unglücklich zueinander passten. Aber eine Neuinstallation kam natürlich nicht in Frage, schon gar nicht einfach so auf Verdacht. Ich bat schließlich um einen neuen Engineer aus meiner eigenen Zeitzone. Den erhielt ich auch, und er (oder sie?) hörte auf den Vornamen "J.". Meine Hoffnung, nun werde allein durch die geringeren Verzögerungen bei der Kommunikation das Problem schnell und ohne allzu viel Zeitinvestition von meiner Seite gelöst, erfüllte sich jedoch nicht. Zwar antwortete J. durch eine günstigere Zeitzone schneller, aber die Ratschläge waren eher abstrus: ACS neu starten (Danke, so schlau war ich auch schon gewesen...), evtl. die Beschränkung der auswählbaren dynamischen Ports für die Admin-Sitzung herausnehmen. Funktionierte alles nicht, aber bei entstand der Verdacht, dass er das Produkt auch nicht besser kannte als ich. J. sprach über das Problem mit seinem "escalation team" - immerhin, es schien sich was zu tun. Jedoch hörte bzw. las ich zwei Tage lang nichts mehr von ihm. Am Ende dieses Zeitraums meldete sich ein dritter TAC-Engineer, ein gewisser F., und teilte mir mit, dass er nun für das Problem zuständig sei. Er bat mich um ein vollständiges Diagnoselog (zu sammeln auf eine höchst ACS-spezifische Weise) und auch darum, das ein oder andere (z.B. Neustart des ACS, dann Messen der Zeit, bis das Problem wieder auftrat). Auch bat er im ein Mitsniffen der Verbindung bei gleichzeitige Reproduzieren des Problems. Ich war zunächst etwas erstaunt, und meine Geduld näherte sich dem Ende, doch wer A sagt, musste wahrscheinlich auch B sagen. Schicksalsergeben tat ich wie mir geheißen und sandte F. diese Dateien zu, richtete ihm sogar einen Testadminaccount mit begrenztem Zugriff ein, damit er das Problem selbst überprüfen konnte. Er sei mit den Entwicklern des Produktes im Gespräch, sagte er. Es folgten einige weitere, eher wenig hilfreiche Vorschläge, wie "Downgrade des Javas auf der Workstation", oder "Anheben der MTU auf über 1500"... Ich wusste, dass das nicht helfen würde, und bat um eine Erläuterung, was das denn bitte bringen solle. Zur Antwort erhielt ich einen Anruf von einer gewissen D., die offenbar Chef oder Sündenbock für F. war. Sie sagte mir zu, dass wir direkt mit einem Entwickler auf den Server schauen würden, auch gern via "Cisco Meeting Place", einem zugegebenermaßen recht praktischen, wenn auch securitybedenklichen Webtool von Cisco zum Zugänglichmachen des Arbeitsplatzes eines Kunden. Aber nun ja, wir installieren deren closed-source-Software bei uns, dann müssen wir ihnen wohl vertrauen, sagte ich mir. Gesagt, getan. F., ein gewisser P. und ich schauten also über den Server, P. loggte sich ein, reproduzierte das Problem und war vollkommen ratlos. Aber ich war allmählich etwas skeptisch bezüglich der Fähigkeiten des TAC in dieser Sache geworden und hatte tags zuvor auf einer anderen Maschine (mit einer späteren Windows-Version als Betriebssystem) versucht, das Problem zu reproduzieren - erfolglos. Es musste also eine Lösung geben. Während F. und P. in den folgenden zwei Tagen den Eindruck zu vermitteln suchten, kompetent an dem Problem zu arbeiten, entschloss ich mich, auf dem Backup-System Den Rat von V. zu befolgen und einfach mal das Betriebssystem neu zu installieren. Dabei kam es zu einigen Windows-Ärgernissen bei dem neuen Mounten von alten SMB-Shares nach der Installation, was aber nur dazu führte, dass ich erstmal das Webinterface der Backup-Maschine nicht anpassen konnte, ansonsten liess sich alles einwandfrei importieren. Tja. Und nun ratet mal. Ja, jetzt gab es, auch nach dem Datenbankimport, keine Probleme, die Sitzung hielt so lange wie sie sollte. Ich schnaubte nur "Windows!" und machte mich daran, ein Wartungsfenster für die Reinstallation der zweiten, also der produktiven Maschine zu planen. Nebenbei konnte ich schließlich mit Hilfe eines kompetenten Kollegen mit starkem Windows-Fu das angepasste Webinterface der Backupmaschine wieder herstellen. Und endlich fiel der Groschen, denn nun zeigte der ACS wieder das ungezogene Verhalten, das der Grund für den ganzen Schlamassel gewesen war. Ich blinzelte, kicherte irre und stellte das ursprüngliche Webinterface vom Hersteller wieder her. Keine Probleme. Ich kopierte das WWW-Verzeichnis zurück: Da waren sie wieder, die Probleme. Ich kratzte mich am Kopf. In dem Verzeichnis waren ausschließlich html-Dateien, ein paar Java-Dateien und gif-Bilder. Das war doch völlig unmöglich? Ich untersuchte das also näher, benutzte zunächst die unmodifizierten HTML-Dateien und einfach nur angepasste GIF-Bilder: Und das Problem trat in dem Moment auf, wo ich andere Bilder benutzte. Ja, selbst wenn ich ein Bild nahm, mit einem Grafikprogramm editierte und es dann im gleichen Format abspeicherte, wurde ACS in der bekannten Weise unzuverlässig! Ja, ich weiss, das ist total unglaubwürdig und völlig hirnrissig. Kein Webserver darf sich für den Inhalt der Dateien (im Gegensatz vielleicht zu ihrem Datenformat) interessieren. Aber genau so verhält es sich. Die erste Lösung war also, zunächst das Standard-Webinterface von Cisco zu benutzen. Auch auf dem produktiven System löste das simple Überkopieren der GIF- und HTML-Dateien das Problem augenblicklich. Ich probierte dann noch etwas herum und fand schließlich heraus, dass man problemlos andere Grafiken benutzen kann, solange man sie nur anders nennt und die entsprechenden Einträge in den HTML-Dateien einfach nur ändert sowie die ursprünglichen GIF-Dateien im Ordner belässt. Was kann man aus dieser (vielleicht etwas zu lang geratenen) Geschichte lernen? - TAC engineers für ACS (im Gegensatz zu den normalerweise sehr kompetenten und deterministisch arbeitenden echten Netzwerkern von Cisco) nimmt man nicht, um eine Lösung zu bekommen, sondern, wenn man einen Sündenbock braucht. - proprietäre Software kann mitunter auf Arten kaputt sein, die sich selbst Cthulhu nicht in seinen Alpträumen auszumalen vermag. - Ich brauche dringend einen OSS-Radius- und TACACS-Server, der alles unterstützt, was auch der ACS kann. Leider gibt es sowas derzeit nicht... oder doch? Trackbacks
Trackback-URL für diesen Eintrag
Keine Trackbacks
|
Kalender
SucheVerwaltung des Blogs |