Leistungen Vorgehen Insights Ressourcen Kontakt Beratung anfragen
Home / Ressourcen / M365 Admin-Kontoschutz

M365 Admin-Kontoschutz – Implementierungsanleitung

Schritt-für-Schritt Anleitung zum Schutz vor Administrator-Kontoübernahme im M365 Tenant

Microsoft Entra ID P2 5 Empfehlungen Conditional Access Zero Trust
Fortschritt 0 von 38 Schritten erledigt
1
Vorbereitung & Voraussetzungen prüfen
Einmalig ▶
Alle folgenden Maßnahmen setzen bestimmte Lizenzen und Rollen voraus. Bitte vor dem Start sicherstellen dass alles vorhanden ist.
2
PIM – Privileged Identity Management aktivieren
Kernmaßnahme ▶
PIM macht permanente Admin-Rollen zu zeitlich begrenzten, genehmigungspflichtigen Rollen. Das ist die wirksamste Einzelmaßnahme gegen dauerhaft exponierte Adminkonten. Ein kompromittiertes Konto erhält damit keine permanente Admin-Macht.
PIM aktivieren und Rollen umstellen
entra.microsoft.com → Identity Governance → Privileged Identity Management → Microsoft Entra roles
Im linken Menü Privileged Identity Management öffnen. Falls PIM noch nicht aktiviert ist, erscheint eine Schaltfläche Discover your privileged roles – diese anklicken um PIM für den Tenant zu aktivieren.
Unter Microsoft Entra roles → Roles die Rolle Global Administrator auswählen. Alle Konten die dort als Active (permanent) aufgeführt sind, auf Eligible umstellen: auf den Benutzer klicken → Remove assignment → danach über Add assignments → Eligible wieder hinzufügen.
Dasselbe für weitere sensible Rollen wiederholen: Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator.
In den Role settings der Global Administrator-Rolle folgende Einstellungen setzen: Maximale Aktivierungsdauer 4 Stunden, Aktivierung erfordert MFA, Aktivierung erfordert Begründung (Justification), optional: Aktivierung erfordert Genehmigung durch einen zweiten Admin.
Unter Alerts sicherstellen dass der Alert "Roles don't require MFA for activation" und "Global Administrators are being used" aktiviert sind. Diese senden E-Mail-Benachrichtigungen bei verdächtiger Nutzung.
Wichtig: Stellt sicher dass mindestens ein Break-Glass-Konto (Notfallzugangskonto) als permanenter Global Administrator verbleibt – aber ohne PIM-Pflicht. Dieses Konto darf nur für echte Notfälle verwendet werden, muss ein sehr starkes Passwort haben und sollte mit FIDO2 gesichert sein. Dokumentiert es sicher offline.
PIM-Zugriff testen
Meldet euch mit einem der umgestellten Adminkonten an und navigiert zu My roles in PIM. Die Global Administrator-Rolle sollte nun unter Eligible roles erscheinen – nicht mehr unter Active roles.
Klickt auf Activate, gebt eine Begründung ein, bestätigt MFA und prüft ob die Aktivierung erfolgreich ist und nach der gesetzten Zeit automatisch endet.
3
PAW – Privileged Access Workstation einrichten
Kernmaßnahme ▶
Eine PAW ist ein dediziertes Gerät ausschließlich für administrative Aufgaben. Administrative Aktionen werden nie von normalen Arbeitsgeräten aus durchgeführt. Dadurch ist das Admingerät vom üblichen Bedrohungspfad (Browser, E-Mail, Downloads) isoliert.
Gerät vorbereiten und härten
Ein dediziertes Gerät (physisch oder VM) für administrative Tätigkeiten bereitstellen. Dieses Gerät wird ausschließlich für M365-Administration verwendet – keine E-Mails, kein Surfen, keine Office-Dokumente aus unbekannten Quellen.
Windows 11 sauber installieren und vollständig patchen. BitLocker verschlüsseln, Secure Boot und TPM 2.0 aktivieren.
Gerät in Microsoft Intune einschreiben: Einstellungen → Konten → Auf Schul- oder Geschäftskonto zugreifen → Verbinden → mit dem Tenant verbinden. Alternativ: Autopilot-Profil für PAW anlegen.
In Intune eine dedizierte Device Compliance Policy für das PAW anlegen (Intune → Devices → Compliance policies): BitLocker erforderlich, Secure Boot erforderlich, aktuelle Betriebssystemversion, Defender aktiv. Das Gerät muss als Compliant markiert sein.
In Intune eine Configuration Profile für das PAW anlegen die folgendes durchsetzt: AppLocker oder Windows Defender Application Control (WDAC) – nur signierte/erlaubte Anwendungen starten, keine Installation von Software ohne Admin-Freigabe, Anschlussbeschränkungen (USB außer FIDO2-Key sperren via Intune Device Restrictions).
Das Gerät einer eigenen Entra ID-Gruppe (PAW-Devices) zuweisen – diese Gruppe wird später in den Conditional Access Policies und Device Filters referenziert.
Wenn kein separates physisches Gerät beschafft werden kann, ist eine strikte Trennung über separate Browserprofile (dediziertes Edge-Profil nur für Admin, kein normales Surfen in diesem Profil) ein erster Schritt – ist aber kein Ersatz für eine echte PAW.
4
Named Locations & eingeschränkter Admin-Zugriff
Kernmaßnahme ▶
Named Locations definieren vertrauenswürdige Netzwerke (IP-Adressen oder Länder). Eine Conditional Access Policy blockiert dann Admin-Logins aus allen nicht definierten Standorten – ein Angreifer mit gestohlenem Passwort aus einem anderen Land oder Netzwerk kommt nicht herein.
Named Location anlegen
entra.microsoft.com → Protection → Conditional Access → Named locations
Unter Named locations auf + IP ranges location klicken. Name vergeben, z.B. Vertrauenswürdige Büro-Netzwerke. Die Option Mark as trusted location aktivieren.
Alle öffentlichen IP-Adressen der Unternehmensstandorte (Büro-Internetanschlüsse) im CIDR-Format eintragen (z.B. 203.0.113.0/24). Abfragen welche IPs eure Firewalls nach außen verwenden – beim IT-Dienstleister oder Netzwerkadmin erfragen.
Optional: Zusätzlich eine Countries location anlegen (Erlaubte Länder), die nur DE, AT, CH, NL, BE enthält – als zusätzliche Schicht falls keine festen IPs vorhanden sind.
Speichern und die erstellte Named Location notieren – sie wird in der folgenden CAP referenziert.
Conditional Access Policy: Admin-Zugriff auf Named Locations beschränken
entra.microsoft.com → Protection → Conditional Access → Policies → + New policy
Neue Policy anlegen, Name: Admin Login nur aus vertrauenswürdigen Standorten.
Unter Users: Select users and groups → Directory roles → alle administrativen Rollen auswählen (Global Administrator, Privileged Role Administrator, Security Administrator, Exchange Administrator, SharePoint Administrator, Billing Administrator, Helpdesk Administrator).
Unter Target resources: All cloud apps auswählen (Admin-Tools umfassen viele Apps – besser alle schützen).
Unter Conditions → Locations: Configure: Yes → Exclude: Selected locations → eure Named Location (Vertrauenswürdige Büro-Netzwerke) auswählen. Damit greift die Policy für alle Standorte außer den bekannten.
Unter Access controls → Grant: Block access auswählen. Admin-Logins außerhalb bekannter Standorte werden vollständig blockiert.
Policy zunächst auf Report-only setzen. 24–48 Stunden beobachten ob legitime Admin-Logins fälschlicherweise geblockt würden. Erst dann auf On schalten.
Bevor ihr diese Policy auf "On" schaltet: Sicherstellen dass das Break-Glass-Konto aus Schritt 2 von dieser Policy ausgenommen ist (unter Users → Exclude → Users → Break-Glass-Konto eintragen). Sonst sperrt ihr euch bei einem IP-Wechsel selbst aus.
5
Managed Device mit Device Filters in Conditional Access
Kernmaßnahme ▶
Diese CAP erzwingt dass Administratoren sich ausschließlich von Intune-verwalteten, konformen Geräten anmelden können. Ein Angreifer mit gestohlenem Passwort – auch mit MFA-Code – kann sich nicht von einem unbekannten Gerät einloggen. Device Filters erlauben dabei eine sehr granulare Steuerung (z.B. nur explizit gekennzeichnete PAW-Geräte).
Gerätegruppe und -filter vorbereiten
Sicherstellen dass das PAW-Gerät aus Schritt 3 in Intune als Compliant gilt und der Entra-Gruppe PAW-Devices zugeordnet ist.
Optional: Eine Geräteerweiterung in Entra konfigurieren. Navigiert zu Entra ID → Devices → All devices, das PAW-Gerät öffnen und unter Properties ein Extension Attribute setzen (z.B. extensionAttribute1 = PAW). Dieses Attribut kann im Device Filter referenziert werden.
CAP anlegen: Admin-Zugriff nur von Managed & Compliant Devices
entra.microsoft.com → Protection → Conditional Access → Policies → + New policy
Neue Policy anlegen, Name: Admin nur von Managed Compliant Device.
Unter Users: Alle administrativen Rollen wie in Schritt 4 auswählen. Break-Glass-Konto unter Exclude eintragen.
Unter Target resources: All cloud apps.
Unter Conditions → Filter for devices: Configure: Yes, Mode: Exclude filtered devices from policy. Im Filter-Ausdruck präzise Bedingungen setzen:

Einfache Variante (nur Compliant-Geräte erlauben):
Device Filter Ausdruck 
device.isCompliant -eq True
Erweiterte Variante (nur explizite PAW-Geräte über Extension Attribute):
Device Filter Ausdruck (PAW-Attribut) 
device.isCompliant -eq True -and device.extensionAttribute1 -eq "PAW"
Unter Access controls → Grant: Block access. Geräte die den Filter nicht erfüllen werden blockiert.
Policy auf Report-only setzen, 48h beobachten, dann auf On schalten. Testlogin vom PAW-Gerät und von einem privaten Gerät durchführen und Ergebnis prüfen.
Device Filters sind mächtiger als die einfache "Require compliant device"-Einstellung unter Grant, weil sie komplexe logische Ausdrücke über Geräteeigenschaften (Betriebssystem, Join-Typ, eigene Attribute) erlauben.
6
FIDO2-Sicherheitsschlüssel für Administratoren einrichten
Kernmaßnahme ▶
FIDO2-Hardwarekeys (z.B. YubiKey) sind phishing-resistente Authentifizierungsmittel. Anders als TOTP-Codes oder SMS können FIDO2-Tokens nicht durch Phishing abgefangen werden – der Key kommuniziert kryptografisch direkt mit dem echten Dienst. Für Adminkonten ist dies der Goldstandard.
FIDO2 Authentifizierungsmethode aktivieren
entra.microsoft.com → Protection → Authentication methods → Policies
Unter Authentication methods → Policies die Methode FIDO2 security key auswählen und auf Enable stellen.
Unter Target: zunächst nur die Gruppe der Administratoren auswählen (z.B. eine Entra-Gruppe M365-Admins). Nicht auf alle Benutzer ausrollen bis der Prozess erprobt ist.
Optional aber empfohlen: Unter Configure die Einstellung "Enforce attestation" aktivieren – dadurch werden nur Keys akzeptiert die sich mit einem Herstellerzertifikat ausweisen können (verhindert Fake-Keys). Unterstützte Key-Modelle ggf. auf YubiKey-AAGUIDs einschränken.
Speichern.
FIDO2-Key für Administratorkonten registrieren
myaccount.microsoft.com → Security info → + Add sign-in method
Jeder Administrator ruft myaccount.microsoft.com auf und navigiert zu Security info. Auf + Add sign-in method klicken und Security key wählen.
Den FIDO2-Key in einen USB-Port stecken (oder NFC antippen). Dem Assistenten folgen: PIN für den Key vergeben (merken!), Taste auf dem Key drücken um die Registrierung zu bestätigen.
Einen zweiten FIDO2-Key als Backup registrieren – für den Fall dass der erste Key verloren geht. Beide Keys sicher aufbewahren (nicht gemeinsam lagern).
Login testen: Browser neu starten, entra.microsoft.com aufrufen, bei der Anmeldemethode Sign in with a security key wählen, Key einstecken und PIN + Taste bestätigen.
CAP: Phishing-resistente MFA für Admin erzwingen
entra.microsoft.com → Protection → Conditional Access → Policies → + New policy
Neue Policy anlegen, Name: Admin muss FIDO2 oder Windows Hello verwenden.
Unter Users: alle administrativen Rollen auswählen. Break-Glass-Konto ausschließen (dieses sollte aber ebenfalls mit FIDO2 gesichert sein).
Unter Target resources: All cloud apps.
Unter Access controls → Grant: Require authentication strength wählen → Phishing-resistant MFA auswählen. Diese vordefinierte Stärke-Richtlinie akzeptiert nur FIDO2, Windows Hello for Business und certificate-based auth – keine SMS, keine TOTP-Codes.
Policy auf Report-only setzen bis alle Admins ihren FIDO2-Key registriert haben. Danach auf On schalten.
Schaltet die CAP erst auf "On" wenn alle betroffenen Administratorkonten einen FIDO2-Key registriert haben. Sonst sperrt ihr Admins aus die noch keinen Key haben. Prüft über Entra → Users → Authentication methods welche Accounts bereits einen Security Key eingetragen haben.
7
Gesamtvalidierung & laufender Betrieb
Abschluss ▶
Nach Implementierung aller Maßnahmen sollte eine Gesamtüberprüfung stattfinden um sicherzustellen dass alle Schutzschichten greifen und sich gegenseitig verstärken.
Abschlusstest: Admin-Login-Szenarien durchspielen
Negativtest – Angriffsszenario simulieren: Versucht von einem unbekannten Gerät (Privathandy, fremder PC) und aus einem unbekannten Netzwerk (Mobilfunk) mit Admin-Zugangsdaten einzuloggen → Ergebnis muss Blocked sein.
Positivtest – Legitimer Admin-Zugriff: Vom PAW-Gerät aus dem Büronetzwerk mit FIDO2-Key einloggen und PIM-Rolle aktivieren → alles muss reibungslos funktionieren.
PIM-Audit: Unter PIM → Audit history prüfen dass alle Rollenaktivierungen korrekt protokolliert werden und Begründungen eingetragen sind.
Conditional Access – Was-wäre-wenn: In Conditional Access → What If Szenarien durchspielen: Admin-Benutzer + unbekannte IP + unbekanntes Gerät → welche Policies greifen? Sicherstellen dass alle relevanten Policies als Applied angezeigt werden.
Break-Glass-Konto testen: Einmal im Quartal das Break-Glass-Konto in einer kontrollierten Situation testen um sicherzustellen dass es im Ernstfall noch funktioniert. Login protokollieren.
Empfehlungen für den laufenden Betrieb
Monatlich: PIM Audit-Log prüfen – wer hat welche Rollen wann aktiviert? Auffälligkeiten (ungewöhnliche Uhrzeiten, unbekannte Begründungen) nachverfolgen.
Vierteljährlich: Access Review in PIM einrichten (Identity Governance → Access reviews) – automatisierte Überprüfung ob alle Eligible-Zuweisungen noch aktuell und berechtigt sind.
Jährlich: FIDO2-Keys auf Firmware-Updates prüfen (Herstellerseite), Key-Inventar aktualisieren, verlorene Keys sofort aus Entra löschen (Security info → Remove).
Bei Ausscheiden eines Administrators: FIDO2-Keys des Kontos sofort löschen, PIM-Eligible-Zuweisung entfernen, Konto deaktivieren – in dieser Reihenfolge.