Lokale Admin-Passwörter im Self-Service — ohne mandantenweite Rechte für Menschen

Ausgangslage

Die Berechtigung, die ein lokales Administrator-Passwort zurückgibt, gilt mandantenweit. Einen Berechtigungsumfang „nur eigene Geräte“ gibt es schlicht nicht: Wer lesen darf, darf es technisch für jedes Gerät im Unternehmen. Genau dafür existiert diese Anwendung — sie kapselt die weitreichende Berechtigung in einem Dienst, der die Eigentümerprüfung selbst übernimmt.

Zweiter dokumentierter Punkt: Das native Verzeichnisprotokoll hält den Abruf zwar fest, weist aber die Anwendung als Handelnden aus, nicht den Menschen. Der Nachweis „wer, wann, warum“ fehlte.

Bemerkenswert selbstkritisch ordnet die Spezifikation das Portal ein: als Break-Glass-Weg ohne Zusatzlizenz. Bei häufigem Admin-Bedarf wäre ein spezialisiertes Produkt der bessere Hauptweg. Das steht so im Projekt — nicht als Verkaufsargument, sondern als Einordnung.

Was der Ordner nicht sagt: wie der Ablauf vorher konkret aussah. Ticket, Helpdesk-Anruf oder gar nicht — das ist nirgends dokumentiert und wird hier nicht rekonstruiert.

Ansatz

Eine Flask-Anwendung auf Azure App Service. Die Anmeldung übernimmt die plattformseitige Authentifizierung; die Identität des Aufrufers liest die Anwendung ausschließlich aus den vom Server eingefügten Kopfzeilen, nie aus Browserdaten. Gegenüber Microsoft Graph und der Datenbank authentisiert sie sich über eine verwaltete Identität — es liegen keine Zugangsdaten in der Anwendung.

Ablauf eines Abrufs: Die Oberfläche lädt die Geräte der angemeldeten Person und prüft je Gerät rein über Metadaten, ob überhaupt ein Passwort gesichert ist, ohne es zu lesen. Die Person wählt ein Gerät und gibt einen Grund an. Der Server löst die Eigentümerschaft daraufhin neu und live auf — die vom Browser geschickte Geräte-ID gilt nie als Berechtigung.

Geprüft wird mit gestaffelten Signalen: der zugewiesene Hauptbenutzer aus der Geräteverwaltung als starkes Signal, ersatzweise eine kürzliche interaktive Anmeldung und eingetragene Besitzerschaft im Verzeichnis. Geteilte Geräte sind ausgeschlossen, ein abweichender Hauptbenutzer führt zur Ablehnung. Erst danach holt der Server das Passwort. Im Browser lebt es kurz: kopieren, Countdown, automatisches Löschen.

Der Punkt, an dem es anders hätte laufen können

Ein Abruf, der nicht protokolliert werden kann, findet nicht statt.

In der Abruf-Route wird der Protokolleintrag geschrieben, bevor das bereits geholte Passwort an den Browser geht. Schlägt das Schreiben fehl, wird das Passwort verworfen und die Anfrage mit einem Fehler beendet. Im Code steht das als Kommentar: abgerufen, aber nicht protokolliert → Herausgabe verweigern.

Das ist eine echte Abwägung, die anders hätte ausgehen können. Ist die Protokolldatenbank nicht erreichbar, funktioniert die Funktion nicht mehr — obwohl das Passwort technisch schon vorlag. Verfügbarkeit wird der Nachweisbarkeit geopfert. Der naheliegende Gegenentwurf — herausgeben und ersatzweise ins Anwendungsprotokoll schreiben — wurde nicht gewählt.

Dieselbe Haltung durchzieht das System: Ein Fehler beim Verzeichnisdienst führt zur Ablehnung, eine nicht konfigurierte Zugriffsgruppe sperrt die Funktion für alle, statt sie zu öffnen.

Bewusst offen gelassen wurde dagegen die Ersatzregel für Geräte ohne Hauptbenutzer: abschaltbar konfiguriert, weil laut Spezifikation die Datenqualität im Gerätebestand über die richtige Strenge entscheidet — und die war zum Umsetzungszeitpunkt nicht bekannt. Eine Entscheidung vertagen und das sichtbar machen ist etwas anderes, als sie zu übersehen.

Ergebnis

Rund 4.400 Zeilen in 34 Dateien, sechs Endpunkte, drei angebundene Systeme. 35 Tests laufen grün — sie decken den Eigentümer-Gate samt Ablehnungsfällen und den Gruppenzugriff ab und laufen gegen einen eingebauten Mock-Modus, also ohne echten Mandanten.

Bewusst manuell geblieben: Die Vergabe der weitreichenden Berechtigung ist ein Skript, das laut Dokumentation ausdrücklich nur nach Governance-Freigabe laufen soll — nicht im Selbstgenehmigungsverfahren.

Als spätere Ausbaustufen ausgewiesen und nicht umgesetzt: automatischer Passwortwechsel nach dem Abruf, Blockade nicht regelkonformer Geräte, Auffälligkeitsalarme, Freigabe-Workflow. Und eine bekannte Lücke steht im README: Die Geräteliste zeigt nur Geräte mit zugewiesenem Hauptbenutzer, obwohl die Prüfung beim Abruf auch andere freigeben würde.