Vom Ticket-Ping-Pong zur Lösung: Incident Management bei komplexen Logins

Im oben genannten Artikel ging es um die zunehmende Zersplitterung moderner IT-Prozesslandschaften. An Beispielen wurde deutlich, wie Anwender heute im Dickicht aus isolierten Fachbereichs-Silos und starren Security-Vorgaben verloren gehen. Wer eigentlich nur einen Server benötigt, muss sich oft unfreiwillig als IT-Architekt beweisen und komplexe Abhängigkeiten zwischen Firewall, Netzwerk und Berechtigungen selbst bewältigen.

Diese Fragmentierung blockiert die Handlungsfähigkeit und zeigt: Isolierte Standard-Prozesse reichen nicht mehr aus. Es bedarf nutzerzentrierter, abteilungsübergreifender Workflows, die diese Komplexität im Hintergrund auflösen.

Dies sollte allerdings nicht nur für Tickets bei Applikationen und Infrastrukturen gelten, sondern auch innerhalb von Troubleshooting-Prozessen.

Das Problem

Tickets oder Störungsmeldungen werden aus Sicht des Anwenders meistens so erstellt, dass das konkrete Problem sichtbar wird. Dabei ist nicht vorauszusetzen, dass entsprechendes technisches Wissen vorhanden ist. Der Anwender kann und sollte keine Hinweise auf Lösungen liefern. Trotzdem kann dies dazu führen, dass ein Beispiel genannt wird, welches in der weiteren Bearbeitung des Tickets als Hauptproblem gesehen wird. Somit wird aus einem größeren Problem ein spezielles, das dadurch eventuell komplett falsch zugewiesen wird.

Ein Beispiel aus der Praxis

Das Thema Multi-Faktor-Authentisierung ist in diesem Zusammenhang komplex. Ein einfaches „Ich kann mich nicht mehr anmelden“ kann keine vollständige Fehlerbeschreibung sein. Oft hat ein Unternehmen mehrere Möglichkeiten der Multi-Faktor-Authentisierung. Diese variieren vom Hardwaretoken über Softwaretoken, Smartcards bis hin zu spezifischen Authentisierungs-Apps. All diese vOptionen können darüber hinaus auch noch mit verschiedensten Verzeichnisdiensten gekoppelt sein. Hier kann es eine Bandbreite von internen Active Directories über separate oder applikationsspezifische LDAP-Verzeichnisse bis hin zu lokalen Konten auf RADIUS-Servern oder anderen Authentisierungsservern geben. Auch die Anbindung der jeweiligen Authentisierungslösung an einen Verzeichnisdienst kann variieren. Zum Beispiel kann eine Applikation einen Hardware- oder Software-Token direkt gegen einen RSA-SecurID-Server prüfen, oder sie nutzt – vor allem für die weiterführende Rechtevergabe – einen RADIUS-Server als erste Kommunikationsinstanz, der den Token gegen den RSA-SecurID-Server prüft und anschließend den Zugriff auf die Applikation autorisiert.

Es wird für Anwender unübersichtlich, wenn ein Unternehmen für verschiedenste Anwendungen nur eine Teilmenge der im Unternehmen verfügbaren MFA-Methoden zur Verfügung stellt. Nachfolgend nur eine Auswahl, die uns täglich bei Kunden begegnet:

• Microsoft 365 SSO
  • Microsoft Authenticator App (passwortlose Authentisierung)
  • Smartcard mit PIN (Benutzerzertifikat)
• Access Gateway
  • RSA-Hardware- oder Software-Token (Benutzername + PIN + Tokencode + AD-Kennwort)
    • Anmeldung zur Applikation über AD und RADIUS-Server (RSA-SecurID-Server)
  • Smartcard mit PIN (Benutzerzertifikat)
• VPN-Gateway
  • LDAP (abweichendes Konto von AD) + interner TOTP Service mit beliebiger App
  • RSA-Hardware- oder Software-Token (Benutzername + PIN + Tokencode + AD-Kennwort)
    • Anmeldung zur Applikation über AD und RSA-SecurID-Server ohne RADIUS
  • RSA-Hardware-Token (lokaler Benutzer + PIN + Tokencode + Computerzertifikat)

Im Fehlerfall sollte ein Anwender schon konkret beschreiben, welche Art von Authentisierungsverfahren unter Benutzung welcher Faktoren nicht funktioniert. Dabei kann es sein, dass ein Verfahren mit Applikation 1 funktioniert, mit Applikation 2 jedoch nicht. Dies muss nicht zwangsläufig an der Applikation selbst liegen.

Wo liegt der Fehler?

Der Anwender kann nur feststellen, dass die Anmeldung an einer oder mehreren Applikationen mit dem Anmeldeverfahren seiner Wahl nicht funktioniert. Die Kombination der möglichen Verfahren und deren technischen Hintergründe muss der Anwender nicht verstehen.

Um die Fehlersuche zu vereinfachen, sollte es in einer IT-Landschaft nur wenige Varianten der sicheren Authentisierung geben, zum Beispiel eine gängige Variante und eine für Spezialfälle, in denen diese nicht umsetzbar ist. In der Praxis sieht es leider oft anders aus: Eine Vielfalt von Anmeldeverfahren und -techniken fügt sich in eine ebenso komplexe Organisationsstruktur ein. IT-Dienstleistungen werden durch verschiedene Unterabteilungen und deren Dienstleister erbracht. Hier sollten wenige unternehmensweite Standards gelten und nicht abteilungsspezifische Lösungen.

Darüber hinaus sollten die für das Incident Management Zuständigen und vor allem der 1st-Level-Support eine Übersicht über alle Anmeldevarianten haben und wissen, welche Applikation welche Anmeldemechanismen verwendet. Das setzt eine unternehmensweite Knowledge Base voraus, die Applikationsverantwortliche aktuell halten.

Prozesse und Anleitungen für Anwender sollten verständlich beschrieben und auch aktuell sein. Es darf nicht vorkommen, dass eine veröffentlichte Anleitung nicht mehr dem Stand der Technik entspricht. Zum Beispiel kann eine beschriebene Variante des Onboardings nicht funktionieren, wenn der enthaltene Link von einem Smartphone aus nicht direkt geöffnet werden kann, weil das genutzte Verfahren von aktuellen mobilen Betriebssystemen nicht mehr unterstützt wird.

Sind die drei Bedingungen – wenige, dafür standardisierte technische Verfahren, ein informierter 1st-Level-Support und aktuelle verständliche Anleitungen für Nutzer – nicht allesamt erfüllt, werden aus eigentlichen Standard-Incidents schnell individuelle, nutzerspezifische Probleme, denen sich ein kompetenter 3rd-Level-Support widmen muss. Und so kommt es, dass entsprechende Tickets zwischen einzelnen Abteilungen monatelang hin und her gehen. Gerade wenn es weder an der Applikation noch am MFA-Server noch an Berechtigungen liegt, sondern an einem System dazwischen, dessen Anbindung den vorherigen drei Support-Einheiten möglicherweise nicht oder nur teilweise bekannt ist (z.B. dem RADIUS-Server).

Hinzu kommt, dass die Dokumentation innerhalb des Ticketsystems in jedem Schritt so detailgetreu wie möglich sein sollte, damit nicht mehrfach dieselben Lösungsversuche mit dem Anwender durchgespielt werden und jeweils zum selben negativen Ergebnis kommen.

Lösungsmöglichkeit

Um auf die anfangs beschriebene Lösungsmöglichkeit aus dem vorherigen Artikel zurückzukommen, ist dieser für das Incident Management bei Applikationen mit komplexen Anmeldeverfahren etwas anzupassen.

Insbesondere IT-Anmeldeverfahren brauchen:

• unternehmensweite Standardisierung
• gut beschriebene Prozesse
• verständliche und aktuelle Anwenderdokumentation
• gezielte Troubleshooting-Prozesse und kein Fingerpointing zwischen Abteilungen
• im Einzelfall: Weiterleitung an Troubleshooting-Experten, um die Wartezeit der Anwender zu verkürzen

Weiterhin gilt: „Es darf nicht dazu führen, dass der Anwender Detailwissen über die IT-Architektur des Unternehmens braucht” oder IT-interne Verfahren und Abhängigkeiten kennen muss, um zuständige Personen auf die richtige Fährte zu setzen.

Diese Grundsätze sind jeder Person mit IT-Service-Erfahrung vertraut, doch es ist an der Zeit, sie wieder allen ins Gedächtnis zu rufen.

Fazit

Je komplexer die IT-Landschaft durch neue Dienstleister, Applikationen und Verfahren wird, desto kritischer sind aktuelle Dokumentationen und lösungsoptimierte Prozesse. Nur so lässt sich das Supportaufkommen langfristig bewältigen.

Verweise

[1] „Zersplitterte Prozesslandschaft – von Herausforderungen im IT-Dienstleister-Wirrwarr“, Sebastian Matzigkeit, ComConsult GmbH, Mai 2025, abgerufen unter: [https://www.comconsult.com/zersplitterte-prozesslandschaft-von-herausforderungen-im-it-dienstleister-wirrwarr/]