Local admin passwords as self-service — without tenant-wide rights for people

The situation

The permission that returns a local administrator password is tenant-wide. A scope meaning “my own devices only” simply does not exist: whoever may read it can technically read it for every device in the company. That is precisely why this application exists — it encapsulates the far-reaching permission inside a service that performs the ownership check itself.

A second documented point: the native directory log does record the retrieval, but names the application as the actor, not the person. The evidence of “who, when, why” was missing.

The specification is notably self-critical about where this sits: a break-glass route without an additional licence. Where administrator rights are needed frequently, a dedicated privilege management product would be the better primary path. That is written in the project — not as a sales point, but as an honest classification.

What the folder does not say: how the process actually worked before. Ticket, helpdesk call, or not at all — it is documented nowhere and is not reconstructed here.

The approach

A Flask application on Azure App Service. Sign-in is handled by the platform; the application reads the caller’s identity exclusively from headers injected by the server, never from browser data. Against Microsoft Graph and the database it authenticates with a managed identity — no credentials live in the application.

A retrieval works like this: the interface loads the signed-in person’s devices and checks per device, purely from metadata, whether a password is even stored, without reading it. The person picks a device and gives a reason. The server then re-resolves ownership live — the device ID sent by the browser never counts as authorisation.

Verification uses tiered signals: the assigned primary user from device management as the strong signal, or failing that a recent interactive sign-in and registered ownership in the directory. Shared devices are excluded, and a differing primary user causes a rejection. Only then does the server fetch the password. In the browser it lives briefly: copy, countdown, automatic clearing.

Where it could have gone the other way

A retrieval that cannot be logged does not happen.

In the reveal route the audit record is written before the already-fetched password goes to the browser. If that write fails, the password is discarded and the request ends with an error. The code says so in a comment: retrieved but not audited → refuse to release.

That is a real trade-off that could have gone the other way. If the audit database is unreachable, the feature stops working — even though the password was technically already in hand. Availability is sacrificed to accountability. The obvious counter-design — release it and write to the application log instead — was not chosen.

The same posture runs through the system: a directory service error causes a rejection, and an unconfigured access group locks the feature for everyone rather than opening it.

Deliberately left open, by contrast, is the fallback rule for devices with no primary user: configurable and switchable off, because per the specification the data quality of the device inventory determines the right level of strictness — and that was not known at implementation time. Deferring a decision and making it visible is a different thing from overlooking it.

The result

Around 4,400 lines across 34 files, six endpoints, three connected systems. 35 tests pass — they cover the ownership gate including its rejection cases and the group access check, and run against a built-in mock mode, so without a real tenant.

Deliberately kept manual: granting the far-reaching permission is a script that, per the documentation, should run only after governance sign-off — not as self-approval.

Marked as later phases and not built: automatic password rotation after retrieval, blocking non-compliant devices, anomaly alerting, an approval workflow. And a known gap is stated in the README: the device list only shows devices with an assigned primary user, even though the retrieval check would clear others.