Altlasten sind ein gewichtiges Thema in Entra ID: Dies betrifft in besonderem Maße Benutzer-, aber auch Computerkonten. Grund hierfür ist, dass es zu den Standardeinstellungen gehört, dass Anwender andere Personen in den Tenant einladen können, die dann ein Referenzkonto (ein sogenanntes Gastkonto) erhalten. Wird es nicht mehr benutzt, bleiben die Benutzerobjekte anschließend als verwaiste Konten zurück. Der Admin ist hierbei komplett außen vor. Ähnlich verhält es sich mit Computerkonten: In BYOD-Szenarien (Bring your own device) ist es Benutzern gestattet, mit ihren eigenen Geräten eine Anmeldung am Tenant vorzunehmen. Erneuert der User eines seiner Geräte, bleibt das bisher benutzte Geräteobjekt zurück.

Beide Beispiele sind im Sinne der Benutzererfahrung sehr komfortabel und zeitgemäß, bringen aber den Nachteil mit sich, dass sich im Laufe der Zeit mehr und mehr ungenutzte Objekte ansammeln, die höchstwahrscheinlich nicht mehr benötigt werden. Der Umgang mit Gastkonten und auch das Verwenden eigener Geräte lassen sich in Entra ID umfangreich konfigurieren. Aber was auch immer Admins diesbezüglich in ihrem Tenant pflegen, Altlasten sind immer ein Thema, das Aufmerksamkeit erfordert. Denn diese Überbleibsel sind oft überflüssig und stellen ein Sicherheitsrisiko dar. In diesem Artikel schauen wir uns Möglichkeiten an, wie sich damit umgehen lässt.

Als Erstes stellen wir dabei fest, dass Entra ID keine Mechanismen liefert, die dafür sorgen, dass nicht mehr benutzte Objekte geräuschlos entfernt werden. Sie müssen selbst ein Auge darauf werfen. Dies geht manuell und turnusmäßig, als Teil von diversen "Housekeeping"-Aktivitäten. Sie können aber auch Automatismen etablieren, die Berichte unbenutzter Objekte generieren.

Geräte sollten Sie im besten Fall über einen Lifecycle-Management-Prozess administrieren, zum Beispiel bei einem Austausch oder wenn ein Anwender ein Device als verloren meldet. Unternehmen, die ein MDM (Mobile Device Management) wie etwa Microsoft Intune einsetzen, können hierfür Policies definieren, die verschiedenartig auf nicht mehr benutzte Geräteobjekte reagieren und diese beispielsweise deaktivieren oder direkt löschen.

Doch wie ist Ihr Vorgehen ohne ein MDM? Jedes Mal, wenn ein Anwender mit seinem Gerät auf eine Microsoft-Cloudanwendung zugreift, landet der Zeitpunkt der letzten Anmeldung in einem Zeitstempel auf dem Gerät. Hiermit finden Sie leicht heraus, wann ein Gerät zuletzt im Tenant im Einsatz war. Der Weg führt über das Microsoft Entra Admin Center (MEAC) zu "Geräte" und in der Übersicht finden Sie bereits das Wichtigste rund um Geräteobjekte. In der zugehörigen Listenansicht haben Sie Filtermöglichkeiten, die unter anderem den Zeitstempel berücksichtigen, der unbenutzte Geräteobjekte ans Tageslicht befördert. Das Dashboard hat jedoch Grenzen, so kann beispielsweise lediglich ein Filter mit dem Wert "Aktivität" gesetzt sein. Möchten Sie Geräte anzeigen, die vor einem Datum online waren und gleichzeitig solche, die noch nie benutzt wurden, funktioniert dies nicht. Übrigens: Das Limit der Aufbewahrung von Protokollinformationen von maximal 30 Tagen, das Sie vielleicht aus den Anmelde- und Überwachungsprotokollen kennen, ist hier nicht gegeben. Die letzte Aktivität ist bei den Geräten und nicht in den Protokollen gespeichert.

Umfassendere Informationen zu unbenutzten Geräteobjekten liefert die PowerShell. Dabei sollten Sie die Microsoft-Hinweise [1] beachten, denn einige populäre PS-Module wie zum Beispiel "AzureAD" werden zum 30. März 2024 in den Ruhestand geschickt. Sie sollten stattdessen die Cmdlets aus den Microsoft-Graph-Modulen nutzen. Im Fall von Geräteobjekten sprechen wir hier vom Get-MgDevice-Befehl. Die gute Nachricht ist dabei, dass dieser fast die gleichen Parameter aufweist wie sein Pendant aus dem alten Modul. Der einzige wichtige Unterschied ist, dass Sie den Zeitstempel mit der letzten Aktivität nun über den Parameter "ApproximateLastSignInDateTime" auslesen.

Bevor Sie auf Microsoft Graph zugreifen können, ist es notwendig, sich wie folgt zu authentifizieren:

Nun erstellen Sie eine Ausgabe aller Geräte mit diesem Befehl:

Um die Liste so zu filtern, dass Sie nur die Geräte sehen, deren Anmeldung länger als 90 Tage zurückliegt, sieht der Befehl so aus:

Mit einer solchen Liste ausgestattet, ist es naheliegend, mit den Inhalten eine Reaktion abzuleiten. Diese kann vielfältig gestaltet sein: Möchten Sie die Geräte in einer ersten Welle deaktivieren, nutzen Sie das Cmdlet "Update-MgDevice". Eine Beschreibung aller Graph-Befehle finden Sie in der Befehlsreferenz [2].

Beabsichtigen Sie Geräteobjekte zu entfernen, ist Vorsicht geboten und Sie sollten ein paar Dinge beachten:

- Ein Geräteobjekt wird direkt entfernt und lässt sich nicht wiederherstellen. Einen Papierkorb, wie Sie ihn von Benutzerobjekten kennen, gibt es bei Geräten nicht.

- Das Azure AD speichert den BitLocker-Recovery-Key mit dem Geräteobjekt. Das Löschen betrifft also auch diesen Schlüssel.

- Haben Geräte den Status "Hybrid Azure AD joined", sind diese mit dem lokalen ADDS (Active Directory Domain Services) und Entra ID verbunden. Ein Löschen aus Entra ID hat keinen Einfluss auf den lokalen Status eines Computers.

Diese Gründe sind triftig genug, sich im Umgang mit ungenutzten Geräten eine Strategie zu überlegen. Diese kann zum Beispiel sein, in zwei Schritten zu agieren: In Schritt 1 ermitteln Sie ungenutzte Geräte eines bestimmten Zeitraums und deaktivieren die Konten. Dieser Schritt lässt sich in kurzen Abständen, zum Beispiel von drei Monaten, sinnvoll durchführen. In Schritt 2 arbeiten Sie (nach einem etwas längerem Zeitraum) die Gesamtliste der zwischenzeitlich deaktivierten Devices ab und entfernen diese. Der gesamte Prozess aus Schritt 1 und 2 lässt sich formell ausgestalten und Arbeitsschritte vorlagern, wie beispielsweise eine E-Mail an den Besitzer oder dessen Manager versenden.

Kritischer als Geräteobjekte sind verwaiste Benutzerkonten und besonders die in diesem Zusammenhang eingangs erwähnten Gastbenutzer, da diese an dem herkömmlichen Onboarding-Prozess für Useraccounts im Unternehmen vorbeimarschieren. Diese sind einfacher zu missbrauchen und sind, wenn sie in falsche Hände geraten, mit Berechtigungen und Rollen ausgestattet.

Unser Weg führt uns erneut in das Entra Admin Center und das Vorgehen ist analog wie bei den Geräteobjekten. Es ist gut geeignet, um sich vereinzelt Informationen zu Benutzern zu beschaffen – eventuell für eine Fehlersuche. "Housekeeping" wird der Admin hier aber wohl eher nicht betreiben. Auch hier ist die PowerShell das bessere Werkzeug – aber dazu gleich mehr.

Für die Anzeige der letzten Anmeldung müssen Sie die Spalte mit dem Titel "Zeitpunkt der letzten Anmeldung" in der Ansicht hinzufügen. Hierzu bemühen Sie die Schaltfläche "Ansicht verwalten", die etwas unscheinbar oben rechts im Dashboard auf ihren Einsatz wartet. Darin sollten Sie etwas stöbern, um für Sie interessante Informationen (Spalten) neben dem letzten Anmeldezeitpunkt zu finden.

Um Informationen über den letzten Anmeldezeitpunkt per Skript zu erhalten, greifen wir auch hier wieder zur PowerShell. Der Unterschied zu den Geräteinformationen ist, dass der Zeitpunkt der letzten Anmeldung nicht direkt beim Benutzerobjekt lagert, sondern unter der Haube von Entra ID. Er findet sich in einem eigenen Ressourcentyp der Graph-API namens "signInActivity". Das hat den Vorteil, dass der Aspekt des abgekündigten AzureAD-Moduls hier nicht relevant ist, da die Graph-Cmdlets von jeher die einzige Wahl waren, um an die Informationen mit dem Zeitstempel zu gelangen. Auch hier müssen Sie sich zuerst authentifizieren:

Der Befehl, der beispielsweise alle Konten mit einem letzten Anmeldedatum vor 90 Tagen erstellt, sieht dann wie folgt aus:

Im ersten Teil nutzen wir den Suchfilter, der angibt, vor welchem Zeitpunkt die letzte Anmeldung liegen muss. Alles, was danach kommt, sind die in Spalten organisierten Informationen, die Sie in der Ausgabe wünschen. Weitere Beispiele und Anschauungsmaterial finden Sie unter [3].

Eine Ausgabe am PowerShell-Prompt ist zwar schön und gut, richtig wertvoll werden die Informationen für den Administrator aber erst, wenn sie beispielsweise in Excel verfügbar sind. Dort lassen sie sich mit Kollegen teilen und natürlich filtern und sortieren. Sowohl für Geräteobjekte als auch für Benutzerkonten bieten die Ansichten des Entra Admin Centers Möglichkeiten, CSV-Dateien zu exportieren, um diese dann wiederum in Excel zu importieren.

Vorsicht ist allerdings bei den Benutzerkonten geboten: Auch wenn Sie die Spalte mit dem "Zeitpunkt der letzten Anmeldung" sehen, ist diese nicht Teil des CSV-Exports. Das liegt daran, dass beim Erstellen des CSV-Files der oben erwähnte Ressourcentyp "signInActivity" nicht abgefragt wird. Das ist schade, aber wir haben ja die PowerShell. Hier gibt es bekanntlich die Möglichkeit, über export-csv .\<Dateiname.csv> die Ausgabe in eine CSV-Textdatei zu schreiben.

An dieser Stelle sei das PowerShell-Modul "ImportExcel" [4] von Doug Finke empfohlen – einfacher lassen sich Excel-Tabellen mit Ausgaben aus der PowerShell nicht erstellen. Für die Inbetriebnahme reicht die Installation des Modules via

Danach nutzen Sie es ähnlich zum "export-csv"-Cmdlet, allerdings heißt das Kommando hier "Export-Excel". Der Befehl liefert Ihnen eine Excel-Datei, die alle Daten beinhaltet. Das Beispiel von oben, hier aber ohne Filter, sieht dann so aus:

Natürlich können Sie die Skripte bei Bedarf selbst anstoßen, aber auch Automatismen sind machbar. Hierzu bietet sich ein Automation Runbook oder eine Azure Function an, ein einfaches Beispiel liefert [5].

Zugriffsüberprüfungen (im englischen Portal "Access Reviews") sind ein Entra-ID-Mechanismus, der es gestattet, Benutzer, deren Zuordnungen in Gruppen, Rollen oder für Anwendungen turnusmäßig auf den Prüfstand zu stellen. Über einen kleinen Workflow lässt sich definieren, was mit den Ergebnissen geschehen soll: Ob ein Administrator eingreifen soll, ob die Ergebnisse der Überprüfung automatisch entfernt oder beibehalten werden oder ob nur der Report von Interesse ist.

Den Mechanismus gibt es schon längere Zeit als Teil der Identity-Governance-Tools und er ist eine wichtige Funktion im Portfolio des Zero-Trust-Werkzeugpalette von Entra. Im Mai 2022 hat Microsoft als Public Preview die Möglichkeiten erweitert, nicht benutzte Konten ("Stale Accounts") zu identifizieren und eine Reaktion zu bestimmen [6]. Zugriffsüberprüfungen lassen sich nicht für Computer anwenden und der Vorgang, ungenutzte User aus dem Tenant zu entfernen, besteht nur für Gastbenutzer. Microsoft geht hier zurecht davon aus, dass alle anderen Benutzer über einen Lebenszyklusprozess laufen. Diese Limitierung gilt nur für das Aufspüren ungenutzter Konten. Im regulären Prozess haben Zugriffsüberprüfungen alle Useraccounts im Visier.

Wir schauen uns Access Reviews an einem konkreten Beispiel an. Wir wollen ungenutzte Gastbenutzerkonten, die seit drei Monaten nicht mehr aktiv waren, automatisch löschen. Ein "Prüfer" soll das letzte Wort haben, um dies selektiv für einzelne Konten zu verhindern oder zu bejahen. Bleibt dies aus, werden die Benutzerkonten automatisch entfernt.

Sie finden die Zugriffsüberprüfungen im MEAC im Bereich "Identity Governance". Für ein Feintuning bieten sie ein breites Spektrum an Optionen, wir schauen uns hier nur die Einstellungen an, die für die Umsetzung unseres Beispiels notwendig sind. Über die Option "Neue Zugriffsüberprüfung" benennen Sie zunächst den Zielbereich. Das ist eine wichtige Angabe für den Fall, dass Sie die Funktion mit wenigen Benutzerkonten ausprobieren. Hierzu verwenden Sie eine Gruppe mit einigen Testkonten und ein solcher Test ist in einem produktiven Tenant kein Problem. Für den endgültigen Einsatz sollten Sie eine Gruppe wählen, die sämtliche Benutzerkonten beinhaltet. Dabei spart Ihnen eine dynamische Gruppe Arbeit, doch für unseren Test eignet sich auch jede andere Gruppe. Entscheidend ist, dass die Zugriffsüberprüfung nur in die Gruppe schaut und den dortigen Konten auf den Zahn fühlt. Mit der Option "Bereich" grenzen wir auf "Nur Gastbenutzer" ein. Hier besteht zudem noch die Option, über einen Zeitraum inaktive Benutzer zu betrachten. Für unser Beispiel ignorieren wir diese Einstellung.

Bei "Prüfer auswählen" entscheiden wir uns für "Ausgewählte Benutzer oder Gruppen" und selektieren das Benutzerkonto "Adele" – in unserem Beispiel die Administratorin, die eine Prüfung für einen Benutzer vornehmen darf. Wir legen bei "Wiederholung der Überprüfung" noch vierteljährlich fest, also den Zeitpunkt, zu dem der Prüfintervall aktiv wird. Ansonsten lassen wir alle Werte beim Standard, das heißt die Überprüfung ist drei Tage aktiv. Das ist der Zeitraum, in dem der Prüfer die Möglichkeit hat einzugreifen. Danach endet die Überprüfung bis zur nächsten Wiederholung in drei Monaten. Startet eine Überprüfung, erhalten Prüfer eine E-Mail mit einem Link, der zu "https://myaccess.microsoft. com" führt.

Wir sind aber noch nicht fertig, die nächste Seite "Einstellungen" beinhaltet den Kern der Überprüfung. Für unser Beispiel wählen wir bei "Ergebnisse automatisch anwenden" aus der Listbox "Zugriff entfernen". Bei der Option "Wenn Prüfer nicht reagieren" fällt unsere Wahl auf "Zugriff entfernen". Anschließend können Sie der Zugriffsüberprüfung noch einen Namen geben. Eine Zusammenfassung listet abschließend alle Aspekte auf, die unsere Überprüfung bilden.

In unserem Beispiel haben wir keinen Startzeitpunkt angegeben. Das heißt, die Überprüfung wird direkt für die Dauer von drei Tagen aktiv. In diesem Zeitraum kann jeder angegebene Prüfer durch die Ergebnisliste gehen und für einzelne Benutzer entscheiden. Vorhergehende Entscheidungen anderer Prüfer lassen sich neu treffen. Meldet sich der von uns hinterlegte Prüfer auf der "Myaccess"-Seite an, finden sich im Bereich Zugriffsüberprüfungen die Ergebnisse und die entsprechenden Entscheidungen. Im Entra Admin Center müssen Sie für Tests nicht drei Tage auf das Ergebnis warten. Stoppen Sie die Überprüfung, wird diese beendet und die Ergebnisse angewendet. In dem Fall sind deaktivierte Gastkonten das Ergebnis.

Zugriffsüberprüfungen sind mächtig. Nicht nur im Rahmen unbenutzter Gastbenutzerkonten. Es handelt sich dabei um ein wichtiges Werkzeug, das bei geschickter Planung und Einsatz dem Administrator viel Arbeit abnimmt und für ein hohes Maß an Sicherheit sorgt.

Je mehr Altlasten in einem Tenant schlummern, besonders seitens Benutzerkonten, desto größer ist die Wahrscheinlichkeit, dass ein Administrator durch etwas Unerwartetes überrascht wird. Das muss nicht zwingend eine Katatrophe sein, aber es bleibt ein schwer zu kalkulierendes Risiko. Durch die hier vorgestellten Maßnahmen können sich IT-Verantwortliche wappnen und die Wahrscheinlichkeit einer Kompromittierung durch ungenutzte Konten reduzieren. Für alte Benutzerkonten bieten sich Access Reviews an, um Altlasten seitens Gastkonten früh zu identifizieren. Alles in allem ein steht Admins vielfältiges Toolset zum Ausmisten und für mehr Sicherheit im Tenant zur Verfügung.