Anfang des Jahres 2017 verstärkte sich bei uns das Problem, dass die Anmeldezeiten in unserem WLAN jenseits von Gut und Böse waren. Wir hatten zu diesem Zeitpunkt außerdem sechs bis sieben verschiedene SSIDs in der Luft, die uns die Airtime geklaut haben. Wir wollten eh schon länger die Anzahl der abgestrahlten SSIDs verringern und der Load-Average auf den RADIUS-Servern war auch schon bei knapp vier. Zuerst haben wir uns mit den anderen Kollegen aus dem WLAN-Team besprochen und zwei Möglichkeiten gefunden, um einmal die SSIDs zu reduzieren und neue Server zu deployen. Zum Zeitpunkt der ersten Planungen zeichnete sich zusätzlich ab, dass wir das Wurzelzertifikat unserer Server tauschen müssen, da das alte Zertifikat 2019 auslaufen würde.
Die erste Lösung, über die wir nachgedacht haben, war eine mit lediglich drei SSIDs, die ähnlich auch an anderen Universitäten eingesetzt wird. Da zwei der SSIDs das Stadt-weite KA-WLAN (eine offen, eine verschlüsselt) sind, waren wir nach unten hin mit der Anzahl begrenzt, konnten dies aber auch für uns nutzen. Da wir bisher den Gästen des KIT ein unverschlüsseltes WLAN mit Captive Portal bereitgestellt haben und das KA-WLAN dies ebenfalls, nur ohne Authentifizierung, anbietet, haben wir uns dafür entschieden, dass wir selbst gar kein unverschlüsseltes Netzwerk mehr anbieten. Als dritte SSID ist natürlich eduroam vorgegeben und diese hätten wir dann als Intranet-Zugang mitgenutzt. Dies ist möglich über die Rückgabe verschiedener VLAN-IDs je nach Login durch den RADIUS-Server (dynamic VLAN assignment). Leider ist dies aus einem einfachen Grund nichts geworden: Benutzerfreundlichkeit. Da das KIT zusätzlich zu allen Gebäuden, die auf dem Campus liegen, noch weitere Gebäude in der Stadt angemietet hat, begrenzt sich unser WLAN also nicht nur auf unseren Campus. Zusätzlich gibt es in der Stadt noch vier andere Einrichtungen, die eduroam abstrahlen. Dies stellt ein Problem dar, da Nutzer unter Umständen nicht in „unserem“ sondern in einem „fremden“ eduroam sind.
Aber warum wäre das nun schlimm, wenn die Nutzer roamen würden und im eduroam einer anderen Einrichtung wären? Der Grund steckt in einem Detail, das der normale Nutzer nicht einschätzen kann. Da wir für jedes Institut ein eigenes VLAN haben und die Institute über WLAN auf dem komplettten Campus eine SSID namens „wifi2vlan“ genutzt haben, wollten wir auch diese SSID in eduroam integrieren. Somit ist der Nutzer auf unserem Campus ins seinem Institutsnetz, an anderen Stellen aber nicht. Damit so keine Verwirrung entsteht und wir auch keine Mail bekommen mit „An stelle XY kann ich den Drucker sehen, an YZ aber nicht“ haben, wir uns für eine andere Lösung entschieden:
Wir senden vier SSIDs aus: die beiden SSIDs der Stadt, eduroam und KIT. Wir haben uns dazu entschieden eine komplett neue SSID einzuführen, damit wir die Nutzer zum Umkonfigurieren zwingen können und wir so Verwirrung uns Supportaufwand vermeiden, weil wir so eine „sanfte“ Migration erreichen können. Aus historischen Gründen gab es ein Sammelsurium als „Features“ in den alten RADIUS-Servern. Beispielsweise war es möglich sich mit und ohne Realm, mit E-Mail-Adresse, mit EMail-Alias und so weiter anzumelden. Es war bei den Accounts auch nie wirklich klar, ob es nun dieser oder jener Realm sein sollte und es war sehr übersichtlich. Im neuen WLAN kann man sich nur noch mit <kürzel>@kit.edu anmelden. Das macht die Konfiguration der Server und den Support der Nutzer sehr viel einfacher. Zusätzlich kann der User weiterhin die „wifi2vlan“-Funktion nutzen, indem er sich mit <kürzel>@<vlan-name>.w2v.kit.edu anmeldet.
Insgesamt hatten die Nutzer knapp einen Monat Zeit das neue WLAN einzurichten, bevor wir die alten SSIDs abgeschaltet haben. Weniger Glück hatten die eduroam-User. Da hier zwar die SSID gleich bleibt, aber sich die username-policy und das Wurzelzertifikat ebenfalls geändert haben, mussten sie einen „harten“ Change durchmachen. Wir haben allerdings, anders als bei der SSID „KIT“, eine Woche lange jeden Morgen eine freundliche, automatische Mail an jeden Nutzer gesendet, der sich nicht korrekt angemeldet hat. In der Mail standen Hinweise und Tips, sowie Links zu den ausführlichen Anleitungen auf unserer Webseite. Dies führte dazu, dass nachdem anfäglich ~85% der Anmeldeversuche scheiterten, es eine Woche später nur noch ~50% waren.
Ein weiterer Punkt, den wir beachten mussten, war der Zeitpunkt, zu dem wir die alten SSIDs abgeschaltet haben. Genau genommen gab es keine andere Möglichkeit als diesen einen Termin, zu dem wir eine jährlich einmalige Konstellation haben: der 30. September. Zu diesem Zeitpunkt sind so gut wie alle Mitarbeiter wieder aus dem Sommerurlaub zurück und „verpassen“ die Umstellung nicht, andererseits sind wir (vermutlich) innerhalb des Jahres nie so wenige Studenten auf dem Campus. Es ist das Ende der Prüfungsphase, die Studenten sind alle daheim und zwei Wochen später gehen die Vorlesungen wieder los. Wir wollten aber nicht bis dahin warten, weil wir dann unserem Support-Team eine riesigen Masse Erstis vorwerfen würden, die alle ihr WLAN umkonfigurieren müssen. Es passte also nur genau dieser eine Zeitpunkt.
Insgesamt ging der gesamte Change reibungslos über die Bühne und wir haben recht wenige Supportfälle gehabt, was aber auch daran lag, dass wir unseren Service Desk ausführlich informiert und unsere Anleitungen bis ins letzte Detail verbessert haben. Soviel erstmal zu unserer Umstellung. Ich werde noch ein oder zwei weitere Posts hierzu machen und die genauere Konfiguration der RADIUS-Server und die Designentscheidungen erläutern. Wenn wir unser ansible-git aufgeräumt haben und die freeradius-rolle ein eigenes git ist, werde ich auch unsere Rolle veröffentlichen.