Es gibt eine Situation, die ich in fast jedem mittelständischen Unternehmen finde, das ich mir anschaue: der First-Level-Support hat entweder viel zu wenig Rechte, um seine Arbeit zu machen, oder viel zu viele. Beides ist ein Problem, nur auf unterschiedliche Art. Zu wenig Rechte bedeutet, dass jede Kleinigkeit, ein Passwort-Reset, eine Kontoentsperrung, eine Gruppenmitgliedschaft für einen neuen Mitarbeiter, an die zweite Ebene eskaliert werden muss. Zu viele Rechte bedeutet, dass der Help Desk mit vollen Admin-Konten in der Active Directory sitzt, weil das historisch gewachsen “einfach so gemacht wurde”, und plötzlich sitzen zehn Leute mit weitreichenden Berechtigungen an vorderster Front, wo am meisten Phishing- und Social-Engineering-Versuche ankommen.
Ich hab in einem Projekt mal genau nachgezählt, wie viele Tickets im Monat reine Passwort-Resets und Kontoentsperrungen waren. Bei einem mittelgroßen Unternehmen mit ungefähr 300 Mitarbeitern waren das über 60 Prozent aller Tickets am First-Level-Support. Der Rest verteilte sich auf Softwareanfragen, Hardwareprobleme und eben Gruppenmitgliedschaften. Wenn man sich anschaut, wie viel Zeit und wie viele Eskalationen an die zweite Ebene allein durch diese simplen, sich wiederholenden Aufgaben entstehen, wird schnell klar, warum das ein Thema ist, das sich lohnt anzugehen.
Warum Standard-Delegation in Active Directory nicht reicht
Die native Antwort von Microsoft auf dieses Problem heißt Delegation von Berechtigungen in der Active Directory, also über die Delegation of Control Wizard bestimmten Gruppen erlauben, Passwörter zurückzusetzen oder Konten zu entsperren, aber eben nicht Domain-Admin-Rechte zu haben. Das funktioniert technisch, keine Frage. Aber in der Praxis stoße ich hier auf zwei wiederkehrende Probleme.
Erstens ist die Delegation in der AD granular auf OU-Ebene, aber nicht wirklich granular auf Aktions-Ebene im Sinne eines nachvollziehbaren, protokollierten Self-Service-Prozesses. Wenn ein Help-Desk-Mitarbeiter über die native AD-Verwaltungskonsole ein Passwort zurücksetzt, gibt es zwar ein Sicherheitsereignis-Log, aber keinen im Business-Sinn nachvollziehbaren Vorgang mit Ticket-Referenz, Begründung und einer für einen Auditor lesbaren Historie. Zweitens, und das ist aus meiner Sicht der größere Punkt, deckt native AD-Delegation nur On-Premises Active Directory ab. Sobald ein Unternehmen auch Entra ID Konten hat, die nicht über eine Hybrid-Synchronisierung laufen, oder wenn Konten in beiden Welten mit unterschiedlichen Prozessen verwaltet werden müssen, bricht die einheitliche Delegation auseinander.
Wie ich das Problem für au2mator gelöst hab
Als ich das erste Mal an einem Self-Service-Portal für Help Desk Mitarbeiter gearbeitet hab, war der Ausgangspunkt genau diese Beobachtung: Support-Mitarbeiter brauchen eine begrenzte Anzahl klar definierter Aktionen, nicht Admin-Rechte im Allgemeinen. Passwort zurücksetzen, Konto entsperren, MFA-Methode zurücksetzen, jemanden zu einer bestimmten Verteilerliste hinzufügen, das sind vielleicht zehn bis fünfzehn Aktionen, die neunzig Prozent des täglichen Bedarfs abdecken.
In au2mator läuft das über ein Web-Portal, in dem genau diese Aktionen als einzelne, in sich geschlossene Bausteine hinterlegt sind. Ein Help-Desk-Mitarbeiter meldet sich mit seinem eigenen, normalen Konto an, das selbst keinerlei erhöhte AD- oder Entra-Rechte hat. Er sucht den betroffenen Nutzer, wählt die Aktion aus, gibt eine Ticketnummer und kurze Begründung ein, und die Aktion wird über einen Runbook-Prozess mit einem separaten, dedizierten Service-Konto im Hintergrund ausgeführt. Der Mitarbeiter selbst hat also nie direkten Zugriff auf ein privilegiertes Konto, er triggert nur eine vordefinierte, kontrollierte Aktion.
Der Effekt ist doppelt: Auf der einen Seite bekommt der Help Desk sofortigen Self-Service-Zugriff auf genau die Aufgaben, die vorher eskaliert werden mussten, ohne dass irgendjemand persönliche Admin-Rechte braucht. Auf der anderen Seite entsteht automatisch eine saubere, durchsuchbare Historie: wer hat wann welche Aktion für welchen Nutzer mit welcher Begründung ausgeführt. Das ist genau die Art von Nachweis, die bei einem ISO-27001-Audit oder einer internen Revision gefragt wird, und die bei einer klassischen Admin-Rechte-Delegation so nicht ohne Weiteres existiert.
Wie sich das auf Eskalationen auswirkt
Bei einem Kunden, der dieses Modell eingeführt hat, ist die Zahl der an die zweite Ebene eskalierten Tickets für genau diese Standardaufgaben innerhalb weniger Wochen um etwa 70 Prozent gesunken. Das ist keine überraschende Zahl, wenn man bedenkt, dass vorher jede Kontoentsperrung, die außerhalb der begrenzten AD-Delegationsrechte des First-Level lag, automatisch weitergereicht wurde. Interessanter fand ich einen Nebeneffekt: die Reaktionszeit für Mitarbeiter, die tatsächlich schnell Hilfe brauchten, zum Beispiel bei einem gesperrten Konto am Montagmorgen, sank von im Schnitt vierzig Minuten auf unter fünf Minuten, weil der First-Level die Anfrage sofort selbst lösen konnte, statt sie in eine Warteschlange zur zweiten Ebene zu stellen.
Was ich Unternehmen empfehle, die das angehen wollen
Der pragmatischste Einstieg, den ich empfehle, ist nicht, gleich ein komplettes Self-Service-Portal für jede denkbare AD-Aktion zu bauen. Stattdessen würde ich mit den drei bis fünf Ticket-Kategorien anfangen, die tatsächlich das Gros des Volumens ausmachen, meistens sind das Passwort-Resets, Kontoentsperrungen und einfache Gruppenmitgliedschaften. Diese wenigen Aktionen sauber, kontrolliert und mit Protokollierung an den First-Level zu delegieren, bringt in aller Regel den größten Effekt für den geringsten Aufwand, bevor man sich an komplexere Szenarien wagt.
Ich schreibe hier regelmäßig über IT-Automatisierung, Azure und alles, was mir beim Bauen von au2mator so unterkommt. Wenn du Fragen zu deiner eigenen Umgebung hast, meld dich einfach.
