Entra ID-Konfigurationen: Wie Du Deine Geräteverwaltung absicherst & Risiken minimierst!
Aaron Siller - Jetzt lesen!
Der ultimative Microsoft Entra ID Guide
Mit dem Microsoft Entra ID zum professionellen Identity & Access Management in Deinem Microsoft 365 Tenant.
Lade jetzt kostenlos meinen ultimativen Entra ID-Leitfaden zur sicheren Konfiguration und Optimierung herunter.
Mein Erstgespräch ist kostenlos und unverbindlich
Einstieg ins Microsoft Entra ID
Entra ID schnell einrichten
Da Microsoft Entra ID als Cloud-Identity-Lösung verfügbar ist, kann dieses IAM-System schnell und effizient in deiner Microsoft 365 Umgebung bereitgestellt werden.
Zentrale Verwaltung aller Identity-Funktionen
Richtlinien, Einstellungen und die Aktivierung von Entra ID-Features werden über das Microsoft Entra Admin Center zentral gesteuert. Mitunter haben wir hier auch Verbindungen zu anderen Microsoft 365 Diensten
Sicherheit mit Microsoft Entra ID
Durch die Nutzung von Conditional Access Richtlinien und der Entra ID Identity Protection kann das Sicherheits-Niveau zentral gesteuert, überwacht und vergleichsweise schnell verbessert werden.
Die Cloud-basierte Identity-Lösung Microsoft Entra ID bietet einen umfassenden Funktionsumfang. In diesem Guide gebe ich sowohl Einsteigern als auch Profis einen tieferen Einblick in die Funktionsweise und den (sicheren) Einsatz vom Microsoft Entra ID.
Microsoft Entra ID Schulungen
Mit einer professionellen Microsoft Entra ID Schulung von mir erhältst Du das notwendige Wissen, um im Do-It-Yourself-Modus Dein Entra ID zu verwalten.
Microsoft Entra ID Beratung
Brauchst du Beratung und Support bei der Einführung, Einrichtung und Feinabstimmung von Microsoft Entra ID in deinem Unternehmen? Auch hierbei stehe ich Dir gerne jederzeit zur Seite!
Überblick zu Entra ID
Der Funktionsumfang und die generelle Arbeitsweise werden in den folgenden Artikeln zu Microsoft Entra ID gezeigt.
Entra ID – Erweiterte Conditional Access Richtlinien einrichten
Aaron Siller - Jetzt lesen!
Entra ID – Endlich die Join-Typen verstehen!
Aaron Siller - Jetzt lesen!
Aufbau einer hybriden Identitätsinfrastruktur
Zu Beginn einer jeden Planung zur Implementierung vom Microsoft Entra ID in einer bestehenden IT-Umgebung ist es essenziell, sich mit den grundlegenden Konzepten der hybriden Identitätsinfrastruktur auseinanderzusetzen. Dabei stellen sich zentrale Fragen:
- Welche Topologien und Konfigurationsmöglichkeiten sind gegeben?
- Wie viele Mandanten müssen verknüpft werden?
- Was soll synchronisiert werden und welche Attribute sind relevant?
Ein klassisches Einstiegsszenario bildet die Anbindung eines lokalen Active Directory an einen einzelnen Microsoft-365-Mandanten über das Entra ID Connect. Dieser Agent wird auf einem lokalen Server installiert und synchronisiert lokale Identitäten in die Cloud. Dabei ist zu beachten, dass Microsoft Entra ID und das Azure-Portal denselben Identitätsverwaltungsdienst nutzen – unabhängig davon, ob es sich um eine Microsoft-365-Subscription oder ein separates Azure-Abonnement handelt.
Vorsicht bei der Expressinstallation!
Die Expressinstallation von Entra ID Connect synchronisiert das vollständige lokale Verzeichnis ohne manuelle Selektion. Dies birgt erhebliche Risiken: Auch Servicekonten, gelöschte Benutzer oder administrative User können somit in die Cloud synchronisiert werden. In der Praxis empfiehlt sich daher eine gezielte Auswahl synchronisierter Objekte durch organisatorische Einheiten (OUs) , Attributs- oder Gruppenfilter. Lokale Administratoren sollten niemals mit Cloud-Administrationskonten synchronisiert werden – eine klare Trennung der Zuständigkeiten ist essenziell.
Hinweis: Das bevorzugte Synchronisierungsmodell bei hybrider Anbindung ist die Kennworthashsynchronisierung. Dabei verwenden Benutzer dasselbe Passwort sowohl lokal als auch in der Cloud – jedoch erfolgt keine direkte Authentifizierung über den lokalen Domain Controller, sondern über die in die Cloud synchronisierten Hashwerte.
Kapitel
Synchronisierungsserver, Staging und Fallback-Konzepte
In hybriden Identitätsinfrastrukturen mit Microsoft Entra ID ist die Art der Synchronisation zwischen lokaler Umgebung und Cloud-Diensten von zentraler Bedeutung. Eine typische Fehlannahme besteht darin, mehrere aktive Synchronisierungsserver gleichzeitig auf eine einzige Entra ID-Instanz (somit einen Microsoft 365 Tenant) synchronisieren zu lassen – diese Konfiguration funktioniert nicht und führt zu Konflikten. Stattdessen funktioniert der Einsatz eines sogenannten Staging Servers als Fallback-Lösung.
Der Staging Server bezieht Änderungen aus dem lokalen AD und der Cloud mit einem Versatz zum Aktiven, exportiert diese jedoch nicht. Er fungiert als passiver Spiegel und bei Ausfall der primären Synchronisierungsinstanz aktiviert.
Hinweis: Bei der Kennworthashsynchronisierung ist ein "sofortiger Zusammenbruch" bei Ausfall der Synchronisierung nicht zu erwarten, da Benutzer sich weiterhin anmelden können – der Hash ist bereits in der Cloud gespeichert. Problematisch wird es erst bei Änderungen an Benutzerobjekten wie Namens- oder Kennwortänderungen. Anders verhält es sich bei der Pass-through Authentication oder klassichen Single Sign-On: Hier ist ein funktionierender Synchronisierungsserver - somit eine auch eine Redundanz -zwingend erforderlich, da die Authentifizierung über Kerberos-Tickets erfolgt.
Der Staging Server hat laut Microsoft eine Synchronisationsverzögerung von etwa 60 Sekunden im Vergleich zur aktiven Instanz. Wichtig: Er wird nicht automatisch aktiviert, sondern muss manuell aus dem passiven Modus überführt werden. Dies setzt voraus, dass Administratoren den Ausfall zeitnah erkennen – Monitoringlösungen wie PRTG oder der Connected Health-Dienst können hier unterstützen.
Wichtige Überlegungen für Deine Notfallplanung:
Screenshot zur Aktivierung des Staging Modus
Vorbereitung des lokalen Verzeichnisses und Identitätsbereinigung
Die Synchronisierung mehrerer Gesamtstrukturen (Forests) mit einem zentralen Entra ID Mandanten ist grundsätzlich möglich.
Eine entscheidende Voraussetzung ist jedoch die eindeutige Identifizierbarkeit aller Benutzerobjekte. In historisch gewachsenen IT-Infrastrukturen (schonmal gehört, oder?) wurden Benutzerattribute wie SMTP-Adressen oder UPNs häufig mehrfach vergeben – während dies lokal unproblematisch sein mag, führt es bei der Cloud-Synchronisation regelmäßig zu Konflikten.
Vor der erstmaligen Einrichtung vom Entra ID Connect ist eine umfassende Bereinigung des lokalen Active Directory unerlässlich. Dies betrifft veraltete, ungenutzte oder fehlerhaft konfigurierte Benutzer- und Objektinformationen. Viele Unternehmen besitzen kein durchgehend gepflegtes Active Directory – sei es aufgrund historischer Entwicklungen oder fehlender Ressourcen. Diese Ausgangslage stellt jedoch keine unüberwindbare Hürde dar, sofern systematische Vorbereitungsmaßnahmen getroffen werden.
Ein unverzichtbares Werkzeug für diese Aufgabe ist „IDFix", das gezielt Inkonsistenzen aufspürt: doppelte UPNs, fehlerhafte SMTP-Adressen und andere potenzielle Synchronisierungshindernisse. Das Tool scannt das gesamte Verzeichnis und erstellt einen detaillierten Bericht über alle gefundenen Probleme. Erst wenn die Konsistenz und Eindeutigkeit aller Objekte sichergestellt ist, sollte mit der eigentlichen Konfiguration von Entra ID Connect begonnen werden.
Die systematische Bereinigung des lokalen Verzeichnisses bildet somit das Fundament für eine stabile und wartungsarme Synchronisierung. Wird dieser Schritt ausgelassen oder nur oberflächlich durchgeführt, resultieren daraus nachgelagerte Probleme und ein erhöhter Administrationsaufwand. Die empfohlene Vorgehensweise lautet daher: erst das lokale Verzeichnis in einen konsistenten Zustand bringen, dann die Synchronisierung mit Entra ID einrichten – nur so lässt sich eine reibungslose hybride Identitätsinfrastruktur aufbauen.
Kapitel
Standardkonten, Namenskonventionen und Absicherung administrativer Benutzer
In Microsoft Entra ID-Umgebungen basiert die Kontenstruktur in der Regel auf einem definierten Standardmodell. Die meisten Benutzer verfügen über ein eigenes Konto, mit dem sie aktiv arbeiten. Deren Benutzer - unser administrativer Benutzerobjekt - kann dabei mit einem primären Postfach sowie mehreren sekundären SMTP-Adressen ausgestattet sein.
Eine Lizenzierung ist für die reine Synchronisation des Kontos mit Microsoft Entra ID zunächst nicht erforderlich - erst die Bereitstellung von Microsoft 365 Services erfordert eine Lizenz. Wird keine benutzerdefinierte Domäne zugewiesen, so erhält das Objekt automatisch eine standardisierte „.onmicrosoft.com“-Adresse. Diese wird jedem Tenant bei der Registrierung mitgegeben und ist daher in der Praxis weit verbreitet. Jedes Benutzerkonto besitzt folglich neben der eigentlichen Domäne stets auch eine „.onmicrosoft.com“-Alias-Adresse.
Adminkonten und deren Benennung
Auch bei administrativen Konten finden wir häufig ein konsistentes Namensschema – beispielsweise durch Anhänge wie „-adm“ oder ähnliche Muster:
Diese Vorgehensweise birgt allerdings Risiken. Sollte es im Rahmen eines Sicherheitsvorfalls zu einem erfolgreichen Angriff auf die Entra ID-Instanz kommen, zählt die Identifikation privilegierter Konten zu den ersten Maßnahmen eines potenziellen Angreifers. Ein leicht durchschaubares Namensschema begünstigt dabei die gezielte Kompromittierung administrativer Zugänge.
Weitere Empfehlung zur Absicherung Deiner administrativen Identitäten
Phishingresistente MFA als Grundschutz
Administrative Konten sollten grundsätzlich durch eine moderne und vor allem phishingresistente Multi-Faktor-Authentifizierung (MFA) geschützt werden. Klassische Verfahren wie SMS-Codes oder App-basierte Bestätigungen (z. B. über Microsoft Authenticator) gelten heute als nicht mehr ausreichend sicher, da sie potenziell durch sogenannte MFA-Bypass-Techniken kompromittiert werden können.
Die Realität von MFA-Bypass-Angriffen
Ein konkreter Fall aus dem Jahr 2023 zeigt die Gefahr: Ein Benutzer gibt seine Anmeldedaten ein, erhält die MFA-Abfrage – bestätigt diese jedoch nicht. Dennoch kann durch die erzeugte Session- oder Cookie-ID ein Angreifer, sofern keine weiteren Schutzmechanismen aktiv sind, einen eigenen zweiten Faktor registrieren und sich erfolgreich am Konto anmelden. Die eigentliche MFA-Prüfung wird somit umgangen, obwohl sie aktiviert war. Der wirksamste Schutz gegen solche Angriffe sind phishingresistente MFA-Methoden, wie etwa FIDO2-Keys oder zertifikatsbasierte Anmeldeverfahren.
Verschleierung administrativer Konten
Die administrative Kontenstruktur sollte grundlegend überdacht werden. Viele setzen noch auf einfache Benennungsschemata wie [email protected] – das macht es jedoch für potenzielle Angreifer leicht, privilegierte Konten zu identifizieren. Eine Möglichkeit ist die Anonymisierung administrativer Logins durch kryptische Kombinationen aus Buchstaben und Zahlen ([email protected]). Dies erfordert allerdings eine konsequente Umsetzung im gesamten Verzeichnis.
Alternative Naming-Konzepte
Eine alternative Herangehensweise wäre, administrative Konten zwar mit Klarnamen zu versehen, aber diese intern mit nicht offensichtlichen Namen zu kombinieren – z. B. aus „Aaron ADM" wird „Maximilian Mundt". Für das IT-Team nachvollziehbar, für externe Beobachter jedoch schwer zuzuordnen. Wichtig ist, dass diese Maßnahmen immer Teil eines umfassenden Sicherheitskonzepts sind, das u. a. auch Privileged Identity Management (PIM) und Conditional Access berücksichtigt.
Breaking Glass Accounts als Notfalllösung
Ein Breaking Glass Account muss vollständig von allen automatisierten Richtlinien und Schutzmechanismen ausgenommen sein – keine Conditional Access Policies, kein PIM, keine Session Controls.
Der Fokus liegt auf garantierter Zugänglichkeit im Notfall. Gleichzeitig gelten verschärfte Anforderungen:
Ein komplexes Passwort mit mindestens 16 Zeichen sowie ein phishingresistenter zweiter Faktor sind verpflichtend.
Die Sicherheitsanforderungen für Breaking Glass Accounts haben sich in den letzten Jahren fundamental gewandelt – von simplen Notfallkonten ohne MFA zu hochsicheren, aber dennoch verlässlich zugänglichen Emergency-Access-Lösungen.
Interessanter Fakt: FIDO2-Keys basieren auf Public-Key-Kryptographie und sind immun gegen Phishing-Angriffe, da sie nur mit der registrierten Website kommunizieren. Ein Angreifer auf einer gefälschten Seite erhält selbst bei physischem Zugriff auf den Key keine verwertbaren Anmeldedaten – die kryptographische Bindung an die echte Domain macht dies technisch unmöglich.
Breaking Glass Accounts – Früher vs. Heute
Die Sicherheitsanforderungen für Breaking Glass Accounts haben sich in den letzten Jahren fundamental gewandelt – von simplen Notfallkonten ohne MFA zu hochsicheren, aber dennoch verlässlich zugänglichen Emergency-Access-Lösungen.
Von Shared Accounts zu personalisierten Adminkonten
Ein häufig diskutiertes Thema ist die Verwendung von Shared Admin-Konten, bei denen mehrere Personen denselben administrativen Login nutzen. Diese früher übliche Praxis ist aus heutiger Sicht nicht mehr empfehlenswert, da sie die Nachvollziehbarkeit und Verantwortlichkeit massiv einschränkt. Moderne Sicherheits- und Compliance-Anforderungen setzen auf personalisierte, klar zuordenbare Konten mit entsprechender Protokollierung – auch und gerade im Admin-Bereich.
Phishingresistente MFA als neuer Standard für Deine Admins
Auch auf die Gefahr hin, dass ich mich wiederhole: Für reguläre Admin-Konten gilt ebenfalls: MFA ist Pflicht – und zwar möglichst phishingresistent. Während für Daily-Admin-Konten oft noch auf App-basiertes Number Matching zurückgegriffen wird, um den Alltag vermeintlich praktikabel zu halten, sollte bei privilegierten Notfallkonten keine Kompromisslösung mehr zum Einsatz kommen.
Breaking Glass Accounts müssen dabei vollständig von Conditional Access Policies und PIM ausgenommen bleiben, um ihre Verfügbarkeit im Notfall zu garantieren. Diese Balance zwischen Sicherheit und Verfügbarkeit erfordert zusätzliche Kontrollmechanismen wie regelmäßige Tests, lückenlose Dokumentation und detaillierte Zugriffsprotokolle.
Schrittweise Modernisierung als pragmatischer Weg
Insbesondere bei kleinen und mittelständischen Unternehmen ist die vollständige Umsetzung dieser Maßnahmen schwierig realisierbar. Budgetäre, personelle und organisatorische Rahmenbedingungen führen oft zu priorisierten Umsetzungsplänen. Dennoch sollte eine schrittweise Modernisierung der Kontostrukturen und Absicherungsmechanismen erfolgen – nicht zuletzt im Hinblick auf steigende regulatorische Anforderungen und eine zunehmend aggressivere Bedrohungslage. Best Practices umfassen dabei neutrale Benennungen, den Verzicht auf Shared Accounts, die konsequente Nutzung phishingresistenter MFA, klar definierte Breaking Glass Accounts sowie eine zentrale Dokumentation aller administrativen Konten bei gleichzeitiger Reduzierung ihrer Sichtbarkeit in öffentlichen Verzeichnissen. Denken wir auch an die Verwendung eins Just-In-Time-Zugriffs.
Kapitel
Verwaltung und Kontrolle von Gastbenutzern
Ein weiteres zentrales Thema, das du nicht vernachlässigen solltest, ist der Umgang mit Gastbenutzern. Über das Admin Center gehst du zurerst auf Alle anzeigen und anschließend auf Identität. Nach dem Ladeprozesse kann nun Benutzer und dann Alle Benutzer ausgewählt werden. Hier kannst du gezielt nach Gastkonten filtern, indem du unter dem Reiter Filter den Benutzertyp „Gast“ auswählst. In einer Beispielumgebung mit 110 Benutzern und 65 Gästen ergibt sich ein fast ausgeglichenes Verhältnis – ein möglicher Indikator für veraltete oder nicht mehr benötigte Gastzugänge.
Die eigentliche Herausforderung liegt darin, zu erkennen, welche Gastbenutzer noch Zugriff benötigen und welche Zugriffe verwaist sind. In einer idealen Umgebung erfolgt dies durch einen klaren On- und Offboarding-Prozess. In der Praxis sieht es jedoch oft anders aus: Jeder interne Benutzer darf Gäste einladen, was langfristig zu einer unübersichtlichen Zugriffslage führt.
Zwei Möglichkeiten stehen dir zur Verfügung, um den Zugriff zu prüfen:
Access Reviews
Über Entra ID P2 oder Governance kannst du mithilfe von Access Reviews automatisiert prüfen lassen, ob ein Gastzugriff noch notwendig ist.
Last-Login-Day via PowerShell / Graph API analysieren
Falls dir keine Entra ID P2 Lizenz zur Verfügung steht, kannst du auch über PowerShell oder die Microsoft Graph API prüfen, wann sich ein Benutzer zuletzt authentifiziert hat. Das ist ein guter Indikator dafür, ob der Zugriff noch benötigt wird. Benutzer, die sich in den letzten 90 Tagen nicht angemeldet haben, sind potenzielle Kandidaten für den Entzug von Rechten.
Access Reviews: Automatische Überprüfung
Das Entra ID Portal bietet unter dem Pfad Identity Governance → Access Reviews eine strukturierte und teils automatisierbare Oberfläche. Dort kannst du über „New Access Review“ gezielt definieren, welche Ressourcen und Benutzerverhältnisse geprüft werden sollen. Das sind auf der ersten Ebene ist das Microsoft Teams + Gruppen und auf der zweiten Ebene SharePoint und OneDrive. Da die meisten externen Benutzer über Teams eingebunden werden, empfiehlt es sich, genau hier mit der Validierung zu beginnen.
Bei der Auswahl kannst du entweder einzelne Gruppen gezielt prüfen oder eine globale Überprüfung aller Gruppen mit externen Mitgliedern aktivieren – z. B. über die Option „All Microsoft 365 Groups with Guest Users“. Dabei kann ausgewählt werden, ob alle internen Benutzer, oder nur die der Gastkonten in den Fokus genommen werden sollen.
Im nächsten Schritt legst du fest, wer die Bewertung durchführen soll. Hier stehen dir mehrere Optionen zur Verfügung: der jeweilige Gruppenbesitzer, der Benutzer selbst oder Gruppen, der Manager (gemäß Attribut im Benutzerobjekt).
In der Praxis hat sich meist die Verantwortung beim Gruppenbesitzer bewährt, vor allem im Kontext von Microsoft Teams. Wichtig: Eine Microsoft 365-Gruppe – und damit ein Team – sollte immer mindestens zwei Besitzer haben, um den Self-Service-Gedanke zu gewährleisten und die IT-Administration zu entlasten. Sollte es keinen Gruppenbesitzer geben, kannst du zusätzlich sogenannte Fallback Reviewer definieren. Diese springen dann für die Bestätigung ein.
Ein weiterer Konfigurationspunkt ist die Review recurrence. Du kannst hier zwischen wöchentlich, monatlich, quartalsweise, halbjährlich oder jährlich wählen. Hier muss entschieden werden, wie oft der besitzer reviewen soll, ob seine Benutzer noch benötigt werden oder nicht. Vorsicht vor der Aussage, dass der Kunde genau weiß, wann welche Gastzugriffe benötigt werden. Dies ist Meistens nicht der Fall. In der Praxis ist eine halbjährliche Überprüfung (semi-annually) ein sinnvoller Rhythmus, da er einerseits regelmäßig genug ist, um Relevanz zu behalten, und andererseits nicht zu viel administrativen Aufwand erzeugt.
Wichtig zu wissen: Die Funktionalität rund um Access Reviews ist wohl die einfachste Möglichkeit zur automatischen Bewertung von Gastzugriffen, erfordert jedoch auch eine Entra ID P2-Lizenz.
Microsoft 365 - DSGVO Compliance & Hardening Check
Nutzen Sie direkt meine Expertise aus hunderten erfolgreicher Projekte für den Intensiv-Check und Handlungsempfehlungen.
Damit die DSGVO-Compliance und Microsoft Security Ihres Unternehmens keine Glückssache ist.
Damit die DSGVO-Compliance und Microsoft Security Ihres Unternehmens keine Glückssache ist.
Kapitel
Gruppenverwaltung, Berechtigungen und Lifecycle Management in Microsoft Entra ID
Als nächstes geht es um die zentrale Verwaltung von Gruppen in Microsoft Entra ID. Beginne zunächst mit einem Blick in den Bereich „Gruppen“ > „Übersicht“ im Microsoft Entra Admin Center. Dort erhältst du eine kompakte Aufstellung, wie viele Gruppen aktuell im Tenant existieren – unterteilt in Sicherheitsgruppen, Microsoft 365 Gruppen sowie dynamische Gruppen. Diese Übersicht ist dabei hilfreich, um das aktuelle Gruppenkonstrukt besser einschätzen zu können. Ein besonderer Fokus liegt auf den beiden Optionen in den Gruppeneinstellungen unter „Allgemein“:
Beide Einstellungen sollten aus administrativer Sicht auf „Nein“ gesetzt werden. Warum? In der Praxis ist es sinnvoll, wenn ausschließlich IT-Verantwortliche Gruppen erstellen, zur Gewährleistung einheitlicher Standards. Beachte: Das Deaktivieren der M365-Gruppenerstellung verhindert noch nicht automatisch, dass Nutzer Teams anlegen können – dies betrifft nur die Gruppenanlage direkt
Teams-Besitzer und deren Bedeutung
Im nächsten Schritt wechselst du in das Microsoft 365 Admin Center und dort in den Bereich Teams → In der Teamsübersicht wieder auf Teams → Teams verwalten. Nun erscheint eine Auflistung der verschiedenen Teams. Achte hier besonders auf die Spalte „Besitzer“. Es zeigt sich häufig, dass viele Teams nur einen Besitzer haben. Im Sinne vom Self-Service-Gedanke ist es allerdings empfehlenswert, dass jedes Team mindestens zwei Besitzer hat. Außerdem solltest du den Umfang der aktiven Teams prüfen. Wenn du z. B. 156 Teams bei 264 Benutzern findest, lohnt sich eine kritische Prüfung: Welche davon sind überhaupt noch aktiv und notwendig?
Um dem Einhalt zu geben ist es wichtig zu entscheiden, wer darf Teams anlegen, aber auch sich Gedanken darüber zu machen, wie du mit dem Lifecycle Management umgehst.
Lifecycle Management aktivieren
Ein besonders effektives Werkzeug zur automatisierten Pflege deiner Gruppen- und Teamstruktur ist das Lifecycle Management in Entra ID, das dir ab der Entra ID P1 Lizenz zur Verfügung steht. Du findest die entsprechende Funktion unter „Einstellungen“ > „Ablaufdatum“. Mit dieser Funktion kannst du definieren, wie lange ein Microsoft 365 Team (bzw. die zugrundeliegende Gruppe) aktiv bleiben darf, ohne dass eine Benutzeraktivität erfolgt. Eine Aktivität kann sein:
Sobald innerhalb der definierten Lebensdauer (z. B. 365 Tage) keine Aktivität erfolgt, wird der TeamBesitzer automatisch 30, 15 und 1 Tag vor Ablauf per E-Mail gewarnt und kann die Gruppe auf Knopfdruck verlängern. Reagiert er nicht, wird das Team gelöscht – kann aber innerhalb von 30 Tagen wiederhergestellt werden.
Diese Funktion hilft nicht nur, ungenutzte Altlasten zu identifizieren und zu bereinigen, sondern auch sensible Informationen besser abzusichern. Das Ablaufdatum auf 1 Jahr einzustellen, ist dafür eine gute Empfehlung.
Hinweis: Nicht jeder User braucht eine P1 Lizenz. Es reicht hier aus, dass nur eine P1 Lizenz vorhanden ist, um das technisch bereit zu stellen. Allerdings ist das für die Gruppen nicht mehr lizenkonform. Microsoft hat die Prüfung der Lizenzen in den letzten Jahren stark runtergefahren, es kann trotzdem zu einer Nachlizenzierung kommen
Kapitel
Geräteverwaltung im Microsoft Entra ID – Best Practices und Konfiguration
Im nächsten Schritt wechselst du im Microsoft Entra Admin Center in den Bereich „Geräte“ und klickst anschließend auf „Übersicht“, um dir einen Überblick über die aktuell registrierten Geräte im Tenant zu verschaffen.
Hast du zum Beispiel etwa 509 Geräte bei rund 100 aktiven Benutzerkonten ist dies eine Zahl, die auf den ersten Blick recht hoch erscheint. Rechnet man jedoch mit durchschnittlich zwei Geräten pro Benutzer, käme man auf etwa 200–250 Geräte.
Terminalserver und weitere gemeinsam genutzte Systeme, können diese Zahl jedoch schnell deutlich nach oben treiben.
Wichtig ist hier: Die alleinige Anzahl an Geräten ist nicht entscheidend – vielmehr zählt, wie du die Registrierung und Verwaltung dieser Geräte kontrollierst und absicherst. Um das zu steuern, wechselst du links in den Bereich „Geräteeinstellungen“.
Der erste zentrale Punkt dort lautet: „Benutzer können Geräte mit Microsoft Entra verknüpfen“. Ein Klick auf das kleine (i) neben dem Eintrag zeigt dir wichtige Details. „Select the user and groups that are allowed to join devices to Microsoft Entra. This setting is applicable to Microsoft Entra Join and MacOS devices. This setting does not apply to Microsoft Entra hybrid joined devices, joined VMS and autopilot devices. (...)“
n dieser Einstellung geht es darum, ob ich als User mein Gerät selbst joinen kann – nicht jedoch hybridjoined Devices, Azure VMs oder Autopilot-Geräte. Das bedeutet: Aktivierst du diese Funktion für alle Benutzer, kann jeder Mitarbeitende eigenständig Geräte mit dem Tenant verknüpfen – etwa über die Anmeldung in Teams, Office oder Drittanbieter-Apps. Ein User sollte nicht die Möglichkeit besitzen, seine Geräte selbst zu joinen. Stichwort: BYOD. Viele Unternehmen gehen von BYOD weg, da es mehr Arbeit hinter sich birgt, als es potenziellen Mehrwert bietet.
Solche ungewollten Registrierungen führen zu einer aufgeblähten Geräteverwaltung, die kaum kontrollierbar ist. Deshalb solltest du in Erwägung ziehen, diese Option auf „Keine“ oder zumindest „Ausgewählte Benutzergruppen“ zu setzen. Will ein Benutzer dann dennoch ein Gerät registrieren, kann er sich an dich als Administrator wenden, und du kannst die Freigabe temporär aktivieren.
Dieses Vorgehen erhöht die Kontrolle erheblich und reduziert Risiken – insbesondere im Kontext von BYODSzenarien (Bring Your Own Device), die zunehmend kritisch betrachtet werden.
Multifaktor-Authentifizierung zum Registrieren oder Beitreten von Geräten
Auch hier lautet die Empfehlung: Setze den Wert auf „Nein“. Microsoft selbst weist in der Beschreibung darauf hin, dass dieser Mechanismus durch bedingten Zugriff (Conditional Access) besser gesteuert werden kann. Die Geräteeinstellungen sind tenantweit gültig, da sie Legacy-Einstellungen sind und bieten daher nur eingeschränkte Steuerung. Über Conditional Access kannst du hingegen deutlich flexibler und sicherer arbeiten
Maximale Anzahl von Geräten pro Benutzer
Hier kannst du zwischen 5, 10, 15, 20 (empfohlen), 50 und 100 wählen. Früher war der MicrosoftStandardwert auf 50 Geräten pro Benutzer. Inzwischen hat Microsoft selbst diesen Wert auf 20 reduziert und gibt dies auch als Empfehlung an. Realistisch betrachtet ist das jedoch immer noch sehr großzügig bemessen. Die wenigsten Benutzer benötigen mehr als drei Geräte, die auf ihren Namen registriert sind. Meine Empfehlung: Setze den Wert auf fünf. Sollte ein User bereits 5 Geräte regisriert haben, kann er dieser auch weiterhin nutzen, er kann dann nur kein weiteres Gerät registrieren.
Wichtig: Diese Grenze betrifft nicht die Anzahl der Geräte, an denen sich ein Benutzer anmeldet, sondern jene, die explizit auf seinen Namen registriert sind – also als primärer Benutzer im Entra ID eingetragen sind. Eine Anmeldung auf Poolgeräten oder Terminalservern ist davon nicht betroffen.
Kapitel
Gerätebereinigung und automatisierte Entfernung veralteter Objekte
Ein oft unterschätzter, aber enorm wichtiger Aspekt in der Entra ID Verwaltung ist der Umgang mit veralteten Geräten. In der Geräteübersicht im Microsoft Entra Admin Center kannst du schnell feststellen, wie viele Geräte sich im Tenant befinden und wann diese zuletzt aktiv waren.
Wenn du über das Menü „Geräte > Übersicht“ navigierst, wirst du unter anderem einen Bereich finden, der explizit „Veraltete Geräte“ listet. Die Definition hierfür lautet:
Geräte, die sich seit über sechs Monaten nicht mehr synchronisiert oder gemeldet haben.
Ein solcher Zeitraum sollte – je nach Anwendungsfall – mit Vorsicht betrachtet werden. Du solltest daher nicht pauschal alle, als „veraltet“ markierten Geräte löschen. Stattdessen ist es empfehlenswert, diese Liste zunächst vorsichtig zu filtern und zu bewerten. Nutze sie als Indikator für eine anschließende Analyse und spreche ggf. mit betroffenen Teams oder Benutzergruppen, bevor du Entscheidungen über die Entfernung triffst.
Es gibt auch noch eine alternative Methode zur Verwaltung. Ein praktischer Ansatz ist hier die Nutzung eines PowerShell-Skripts, das automatisiert Geräte entfernt, die sich seit einer bestimmten Anzahl von Tagen nicht mehr gemeldet haben. Dieses Skript ist unter dem Begriff „Automated Stale Device Removal“ bekannt.
Mit dem Skript lässt sich flexibel definieren, welche Geräte zu entfernen sind – zum Beispiel alle, die seit 30, 60, 90 oder 120 Tagen keine Rückmeldung mehr geliefert haben. Das Tool liefert dir eine schnelle, skalierbare Möglichkeit, die Geräteverwaltung effizient zu automatisieren – insbesondere dann, wenn du vorher eine saubere Bestandsaufnahme durchgeführt hast.
Den Blogartikel mit Skript findest Du von mir übrigens auch hier.
Entra ID Joined
Entra ID Joined Geräte sind vollständig in Entra ID eingebunden und typischerweise firmeneigene Geräte, die zentral verwaltet werden – ideal für Cloud-native Organisationen ohne lokale Domäne. Der Benutzer meldet sich direkt mit seinem Entra ID-Konto an, wodurch alle Richtlinien, wie Intune-Compliance oder Conditional Access, sofort greifen.
Entra ID Hybrid Joined
Entra ID Hybrid Joined Geräte sind in einer lokalen Active Directory-Domäne eingebunden und gleichzeitig mit Entra ID verbunden – diese Konfiguration ist typisch für Unternehmen im Übergang zur Cloud. Sie erlaubt es, bestehende Gruppenrichtlinien weiterzuverwenden, während Cloud-Features wie Single Sign-On und Conditional Access genutzt werden.
Entra ID Registered
Entra ID Registered Geräte gehören meist dem Benutzer selbst (z. B. Smartphones oder private Notebooks) und sind nicht domänengebunden, sondern lediglich über das Benutzerkonto bei Entra ID registriert. Sie ermöglichen eingeschränkten Zugriff auf Unternehmensressourcen und werden oft im Rahmen von BYOD-Szenarien verwendet.
Kapitel
Kontrolle über Benutzereinwilligungen und App-Berechtigungen
Weiter geht es mit dem Umgang mit Benutzerberechtigungen und der Verwaltung von Einwilligungen bei Applikationen. Um diese Einstellungen zu prüfen, navigierst du im Microsoft Entra Admin Center zu „Anwendungen“ > „Unternehmensanwendungen“ und anschließend auf der linken Seite zu „Einwilligung und Berechtigungen“.
Die dort restriktivste Option ist „Benutzereinwilligung nicht zulassen. Für alle Apps ist ein Administrator erforderlich.“. Damit erreichst du, dass Benutzer bei der Nutzung oder Installation neuer Applikationen, eine Genehmigungsanfrage an einen globalen Administrator senden müssen.
Ein Konto mit der Rolle des Globalen Administratoren muss sich dann als nächstes gegenüber der Applikation authentifizieren und diese freischalten.
Der Nutzer sieht dann wie rechts im Screenshot eine Meldung in der Oberfläche mit dem Hinweis „Permission Request“ – eine Anforderungsmaske, die klar signalisiert: Nur ein globaler Administrator kann diesen Zugriff genehmigen. Dadurch wird automatisch verhindert, dass Applikationen ohne dein Wissen tiefgreifende Rechte im Tenant erhalten. Besonders bei OAuth-basierten Cloud-Anwendungen ist das entscheidend, da über entsprechende Berechtigungen Zugriff auf E-Mail-Inhalte, Kalender, Kontakte oder sogar auf alle Dateien im OneDrive oder SharePoint erfolgen kann.
So sehen die Konfigurationsoptionen zur Einwilligung und Berechtigung im Entra ID aus:
Im weiteren Verlauf dieses Schritts solltest du dir nun die Übersicht der bereits registrierten Unternehmensanwendungen ansehen. Navigiere dazu zu „Unternehmensanwendungen“ > „Übersicht“. Dort siehst du alle Applikationen, die in deinem Tenant im Einsatz sind – unabhängig davon, ob sie aktiv verwendet werden oder lediglich registriert wurden. Nimm dir Zeit und gehe die Liste durch. Häufig fallen hier bereits verdächtige oder unerwartete Applikationen auf.
Es tauchen zum Beispiel Anwendungen wie „Miro“, „Awork“ oder auch „Samsung Mail“ auf. Letztere wurde wahrscheinlich durch die Nutzung eines mobilen Endgeräts mit vorinstallierter Samsung-Mail-App autorisiert. Solche Einträge sind zwar nicht per se verdächtig, sollten aber im Rahmen eines vollständigen Überblicks dokumentiert und bewertet werden
Mache nun weiter mit dem Aufruf der jeweiligen Anwendung und navigiere zunächst zum Abschnitt „Besitzer“. Hier kannst du feststellen, ob überhaupt ein Besitzer für die Applikation eingetragen ist. Ist das nicht der Fall, gehst du weiter auf „Benutzer und Gruppen“, um zu prüfen, ob die App aktuell noch mit einem Benutzerkonto verknüpft ist. Falls keine Benutzer mehr zugeordnet sind oder die hinterlegte Person nicht mehr aktiv ist, könnte das bereits ein Hinweis darauf sein, dass die Anwendung obsolet ist.
Im nächsten Schritt öffnest du den Bereich Aktivitäten und anschließend „Anmeldeprotokolle“. Um eine aussagekräftige Auswertung zu erhalten, filterst du hier idealerweise nach dem Zeitraum „Letzter Monat“. Wenn keine Anmeldungen im definierten Zeitraum erfolgt sind, ist es sehr wahrscheinlich, dass die Applikation aktuell nicht mehr genutzt wird.
Klicke auf Eigenschaften und nun hast du zwei Optionen: Entweder du löschst die Anwendung sofort, oder du deaktivierst zunächst die Anmeldung zur App. Sollte sich nach der Deaktivierung ein Benutzer melden und auf die Applikation zugreifen wollen, kann der Zugriff jederzeit wieder aktiviert werden. Meldet sich hingegen niemand, lässt sich die App zu einem späteren Zeitpunkt endgültig entfernen. Wichtig ist, vor dem Löschen in Zweifelsfällen Rücksprache mit dem betroffenen Benutzer zu halten.
Dieses Vorgehen lässt sich systematisch auf alle Anwendungen im Tenant anwenden. Im Beispiel wurde unter anderem „Samsung Mail“ geprüft – eine Anwendung, die oft durch mobile Endgeräte registriert wird. Bei solchen Apps empfiehlt es sich, neben der Prüfung der Anmeldeaktivitäten auch über den Einsatz von App-Schutzrichtlinien in Intune nachzudenken. Mit diesen Richtlinien lassen sich Sicherheitsmaßnahmen wie das Unterbinden von Screenshots oder das Kopieren von Inhalten aus geschäftlichen Apps umsetzen. Voraussetzung dafür ist allerdings, dass die entsprechenden Geräte über Intune verwaltet werden.
Durch diesen strukturierten Prüfprozess und die Anpassung der Benutzereinwilligungsrichtlinien stellst du sicher, dass keine unkontrollierten Applikationen im Hintergrund mitlaufen und gleichzeitig neue Registrierungen nur unter administrativer Kontrolle erfolgen. So reduzierst du effektiv potenzielle Sicherheitsrisiken und behältst die Kontrolle über deinen Applikationsbestand.
Kapitel
Externe Identitäten und Zusammenarbeit sicher steuern
Ein zentraler Aspekt in der Verwaltung von Microsoft Entra ID ist der kontrollierte Umgang mit externen Identitäten – insbesondere im Kontext der Gasteinladung. Du beginnst die Konfiguration im Entra Admin Center unter „Externe Identitäten“, indem du zunächst zur Übersicht navigierst. Dort findest du den Punkt „Einstellungen für externe Zusammenarbeit“. Der oberste Punkt Gastbenutzerzugriff wurde bereits in einem früheren Kapitel im Zusammenhang mit Benutzereinstellungen kurz angeschnitten wurde.
Der nächste Punkt beantwortet folgende Frage: Wer darf überhaupt externe Benutzer einladen? Standardmäßig erlaubt Microsoft, dass Mitglieder, Gastbenutzer mit Mitgliederrechten sowie Benutzer mit bestimmten Administratorrollen neue Gäste hinzufügen dürfen. Diese Voreinstellung ist in vielen Organisationen problematisch, da sie unkontrolliert zu einer wachsenden Zahl externer Konten führen kann – häufig ohne sinnvolle Dokumentation oder Überprüfung.
Als IT-Administrator solltest du daher in Betracht ziehen, diesen Prozess zu zentralisieren. Idealerweise führst du einen strukturierten Onboarding-Prozess ein, in dem ausschließlich autorisierte Administratoren oder ausgewählte Personengruppen – etwa Projektleiter – berechtigt sind, externe Gäste einzuladen. So behältst du die Kontrolle über alle externen Identitäten im Tenant und kannst gleichzeitig sicherstellen, dass jede Einladung dokumentiert, gerechtfertigt und revisionssicher ist.
Die Empfehlung lautete: Entwickle in Abstimmung mit dem Endkunden klare Richtlinien, wer Gäste einladen darf und unter welchen Voraussetzungen. Das betrifft nicht nur technische Einstellungen, sondern auch betriebliche Absprachen und Kommunikationsprozesse mit betroffenen Abteilungen.
Den Punkt Einstellungen für das Verlassen von externen Benutzer sollte auf „Ja“ eingestellt sein. Ein weiterer Punkt ist die Einschränkung von Einladungen nach Domänen. Standardmäßig erlaubt Microsoft, dass Einladungen an beliebige externe Domänen gesendet werden können. Hier bietet dir Entra ID die Option, nur Einladungen an vorher freigegebene Domänen zuzulassen. Sobald eine bestimmte Domäne freigegeben ist, dürfen Benutzer mit einer E-Mail-Adresse aus dieser Domäne eingeladen werden. Alle anderen Anfragen würden abgelehnt.
In vielen Unternehmen übersteigt die Anzahl der Gastbenutzer oft 50% aller Identitäten im System – wie im Beispiel mit 65 Gästen bei 110 Gesamtbenutzern. Diese "Schattenidentitäten" entstehen, weil jeder interne Mitarbeiter eigenständig Gäste einladen kann, aber niemand sie wieder entfernt. Das Resultat: Ein erhebliches Sicherheitsrisiko durch vergessene externe Zugänge, die oft jahrelang unbemerkt bestehen bleiben.
Kapitel
Mandantenübergreifende Zugriffseinstellungen
Navigiere zunächst im Microsoft Entra Admin Center zum Punkt Einstellungen für externe Zusammenarbeit und öffne dort die mandantenübergreifenden Zugriffseinstellungen. Diese Funktion ist eines der zentralen Werkzeuge, um externe Identitäten in deinem Tenant sicher zu verwalten. Klicke dann auf Standardeinstellungen, um die allgemeinen Richtlinien für alle anderen Microsoft-Tenants zu konfigurieren.
Einstellungen für den eingehenden Datenverkehr
Zunächst werfen wir einen Blick auf die eingehenden Zugriffseinstellungen. Diese bestimmen, ob externe Benutzer aus anderen Microsoft-Tenants überhaupt Zugriff auf Ressourcen deines Tenants erhalten dürfen. In kritischen Situationen – etwa bei Auffälligkeiten oder Sicherheitsvorfällen – kannst du hier den Zugriff sofort blockieren und sämtliche externe Zugriffe unterbinden. Diese Maßnahme ist eine Art Notbremse, mit der sich ein potenzielles Eindringen externer Benutzer schnell unterbrechen lässt.
Einstellungen für den ausgehenden Datenverkehr
Anschließend solltest du auch die ausgehenden Zugriffseinstellungen unter die Lupe nehmen. Diese regeln, ob und unter welchen Bedingungen deine Benutzer von anderen Tenants eingeladen werden dürfen. Oft liegt der Fokus auf der Frage: Wen darf ich einladen? – mindestens genauso wichtig ist jedoch die Gegenrichtung: Wer von meinen Usern darf überhaupt von anderen eingeladen werden?
Standardmäßig ist es so eingestellt, dass jeder Benutzer von externen Organisationen eingeladen werden kann. Doch genau hier setzt eine wichtige Überlegung an: In vielen Unternehmen ist es nicht notwendig, dass sämtliche Benutzer Einladungen von außen annehmen können. Eine sinnvolle Maßnahme wäre, den Zugriff nur bestimmten Benutzergruppen zu gestatten. Du kannst eine dedizierte Sicherheitsgruppe anlegen und in den Richtlinien unter „Zugriff zulassen für bestimmte Benutzer oder Gruppen“ genau diese Gruppe angeben. So sorgst du dafür, dass nur Mitglieder dieser Gruppe Einladungen von außen annehmen dürfen.
Microsoft 365 hat sich über die Jahre von einem geschlossenen zu einem sehr offenen System entwickelt – während früher Funktionen standardmäßig deaktiviert waren und aktiv eingeschaltet werden mussten, sind heute viele Features von Anfang an aktiviert, was erhöhte Aufmerksamkeit der Administratoren erfordert.
Kapitel
Identity Protection und Sicherheitsbewertung
Starte dafür im Microsoft Entra Admin Center im Bereich Identitätsschutz. Der volle Zugriff kann nur mit einer Entra ID P2 Lizenzierung genutzt werden. Jedoch stehen bei den anderen Lizenzierungen die Berichte zur Verfügung. Die Identity Protection ist ein KI-gesteuerter Mechanismus. Dieser Mechanismus erkennt von wo aus sich User anmelden, von welchen Geräten, wie häufig sich User anmelden, ob es fehlerhafte Anmeldungen gab und kategorisiert, und validiert diese dann.
Um die Berichte einzusehen, klicke unter Berichte auf riskante Anmeldungen. Wähle im Datumsfilter den Zeitraum „Letzter Monat“, um dir einen Überblick darüber zu verschaffen, ob im vergangenen Monat verdächtige oder anomale Anmeldeversuche registriert wurden. Mit einer P2 Lizenz erhältst du automatische Warnung. Hast du diese nicht ist es wichtig, dir einen internen Reminder zu setzen – etwa wöchentlich oder mindestens zweiwöchentlich –, um diesen Bereich manuell zu überprüfen. Ein monatlicher Check wäre an dieser Stelle eher zu spät, wenn es um präventive Sicherheit geht.
Besonders relevant ist hier auch der Bericht über riskante Benutzer. Dieser zeigt dir Konten, bei denen in der Vergangenheit verdächtige Anmeldeaktivitäten festgestellt wurden. Öffne dafür den gleichnamigen Punkt und wähle einen Benutzer aus. Dort findest du unter „Letzte riskante Anmeldungen“ einen Einblick, ob und wann Auffälligkeiten vorlagen. Sollten alte Anmeldungen vorliegen empfiehlt es sich in solchen Fällen, die Anmeldung als sicher zu bestätigen, um keine unnötigen Blockierungen im System aufrechtzuerhalten – vorausgesetzt, der Benutzer ist legitim bekannt.
Risikoanalysen verstehen und nutzen
Im Anschluss kannst du einen Blick auf die Identitätssicherheitsbewertung werfen. Diese findest du ebenfalls im Bereich Identitätsschutz. Den Microsoft Defender findest du im Microsoft 365Admin Center → Sicherheit. Im Microsoft Defender Portal unter Gefährdungsverwaltung → Sicherheitsbewertung findest du Maßnahmen, die du im Tenant konfigurieren solltest, um das Sicherheitsniveau von deinem Tenant hochzustufen.
Neben einem gewissen „Gamification-Effekt“ bietet er dir eine sehr detaillierte Liste von Maßnahmen, die du umsetzen kannst, um dein Sicherheitsniveau zu erhöhen. Klicke im Defender Portal auf Empfohlene Maßnahmen, um eine Übersicht dieser Konfigurationsvorschläge zu erhalten. Hier kannst du einmal durchgehen, welche Maßnahmen für dich in Frage kommen und welche nicht.
Beachte jedoch: Viele der Maßnahmen bauen direkt auf Microsoft 365 Services auf, etwa Defender for Identity, Defender for Endpoint, Defender for Office 365 oder Microsoft Defender for Cloud Apps. Wenn du alternative Sicherheitslösungen im Einsatz hast – zum Beispiel von Drittherstellern – ist der Score nur bedingt aussagekräftig. Das kann zu Irritationen führen, da dir dann potenziell niedrige Scores angezeigt werden, obwohl du technisch längst abgesichert bist.
Das Schema mit der Bewertung
Zurück im Entra ID: Die dortige Identitätssicherheitsbewertung ist von dem Microsoft Secure Score abgekapselt. Ein Wert im 90% Bereich ist sehr gut. Nutze diese Bewertung als Orientierungshilfe und prüfe, ob einzelne Empfehlungen für deinen Tenant sinnvoll sind – oder ob du das Risiko bewusst akzeptierst, weil du bereits andere Schutzmechanismen etabliert hast.
Entra ID-Konfigurationen: Wie Du Deine Geräteverwaltung absicherst & Risiken minimierst!
Entra ID – Erweiterte Conditional Access Richtlinien einrichten
Entra ID – Endlich die Join-Typen verstehen!
Seite [tcb_pagination_current_page] von [tcb_pagination_total_pages]
Antworten auf häufig gestellte Fragen zu Microsoft Entra ID
Das ist im Grunde dasselbe Ding! Microsoft hat Azure Active Directory einfach in Microsoft Entra ID umbenannt. Du wirst aber noch häufig beide Begriffe sehen, weil die Umbenennung noch nicht überall durchgezogen wurde – sogar die Installationsdatei heißt noch "AzureADConnect.msi".
Jein. Du brauchst mindestens einen Server mit Windows Server 2016 oder neuer, auf dem Entra ID Connect läuft. Der braucht aber nur 4 GB RAM – also keine Rakete. Wichtig: Nur ein Server darf aktiv synchronisieren, aber du kannst einen zweiten als Staging Server für Notfälle einrichten.
Standardmäßig alle 30 Minuten. Das reicht für die meisten Szenarien völlig aus. Wenn du's eilig hast, kannst du über PowerShell einen Delta-Sync manuell anstoßen: Start-ADSyncSyncCycle -PolicyType Delta
Das ist dein Notfall-Admin-Account für den worst case – wenn alle anderen Zugänge nicht mehr funktionieren. Der muss von allen Richtlinien ausgenommen sein, ein mega-sicheres Passwort (mindestens 16 Zeichen) haben und trotzdem mit phishingresistenter MFA geschützt sein. Denk dran: Das ist deine letzte Rettung!
Standardmäßig ja – und das ist oft ein Problem! Du solltest das über die Einstellungen für externe Zusammenarbeit einschränken. Am besten legst du fest, dass nur bestimmte Personen (z.B. Projektleiter) Gäste einladen dürfen. So behältst du den Überblick.
Setz die maximale Anzahl von Geräten pro User runter (5 statt 20), deaktiviere "Benutzer können Geräte mit Microsoft Entra verknüpfen" und nutze Registry Keys oder Intune-Richtlinien. Wichtig: Bei der Office-Anmeldung ist standardmäßig ein Haken gesetzt, der das Gerät registriert – den müssen User manuell entfernen!
Check erstmal, wer sich in den letzten 90 Tagen nicht mehr angemeldet hat – das geht per PowerShell oder Graph API. Mit Access Reviews (ab P2 Lizenz) kannst du das sogar automatisieren: Alle 6 Monate werden Teambesitzer gefragt, ob ihre Gäste noch benötigt werden.
Nein, bloß nicht! Die Express-Installation synchronisiert alles ungefiltert – inklusive Servicekonten, gelöschter User und technischer Objekte. Nimm immer "Customize" und wähle gezielt aus, was synchronisiert werden soll.
Für die meisten: Password Hash Sync! Das ist einfach, zuverlässig und funktioniert auch wenn dein lokales Netzwerk mal ausfällt. PTA ist komplexer und ADFS braucht mindestens 4 zusätzliche Server – das lohnt sich nur bei speziellen Compliance-Anforderungen.
Microsoft sagt standardmäßig alle 90 Tage – das ist viel zu lang! Stell das über Conditional Access auf 7 Tage runter. So reduzierst du das Risiko, falls mal eine Session-ID geklaut wird. Ausnahme: Service-Konten für Konferenzräume oder Teams-Telefone.
Absolut! Das ist deine wichtigste Waffe gegen Angriffe. Fang mit den Basics an: Blockiere Zugriffe aus Ländern wo du keine Mitarbeiter hast, erzwinge MFA für alle User und blockiere Legacy Authentication. Das allein macht deinen Tenant schon deutlich sicherer.
Mit Lifecycle Management (ab P1 Lizenz) werden inaktive Teams automatisch gelöscht. Nach 365 Tagen ohne Aktivität bekommt der Besitzer Warnmails und kann verlängern. Reagiert keiner, wird's gelöscht – kann aber 30 Tage lang wiederhergestellt werden.
Geh ins Entra Admin Center → Unternehmensanwendungen. Da siehst du alles, was User so installiert haben – oft auch Überraschungen wie "Samsung Mail" oder "Miro". Check die Anmeldeprotokolle: Keine Logins im letzten Monat? Weg damit!
.local Domains sind nicht internet-routbar und führen dazu, dass User in der Cloud automatisch eine @onmicrosoft.com Adresse bekommen. Das ist unpraktisch für Teams und Exchange. Nutze immer eine echte, registrierte Domain für deine UPNs!
Nutze das "What-If" Tool im Conditional Access Bereich! Da kannst du simulieren, welche Richtlinien für welchen User unter welchen Bedingungen greifen würden. Und ganz wichtig: Schließ immer einen Breaking Glass Account von allen Richtlinien aus, damit du im Notfall noch reinkommst!
Dr. Oliver Diedrich
"Seit 2022 hält Aaron Siller iX-Workshops zu verschiedenen Themen der Microsoft-Welt für die heise Academy ab. Seine große Expertise in den Themen "Mobile Device Management mit Microsoft Intune", "Planung, Konfiguration und Verwaltung von MS Teams" und "Administration von Microsoft 365 Copilot" führt regelmäßig zu ausverkauften Workshops und hervorragenden Teilnehmerbewertungen. Wir sind sehr froh, Herrn Siller als Referenten gewonnen zu haben."
Chefredakteur iX
Video Referenz Florian Weide
Video Referenz Iris Becker
Video Referenz Andreas
Video Referenz Neomi Weber
Lassen Sie uns sprechen!
siller.consulting GmbH - Zum Maria-Hauptschacht 68, 52477 Alsdorf - Copyright 2025
