In dieser zweiteiligen Serie schauen wir uns die wichtigsten Authentifizierungsmethoden in Microsoft Entra ID an – ihre Voraussetzungen und vor allem die kritischen Abhängigkeiten. Part 1 legt die Grundlagen: Wir klären, welche Methoden es gibt, wofür sie verwendet werden können (primäre Anmeldung, MFA, SSPR), und warum selbst bei einer vollständig passwortlosen Strategie bestimmte „Fallback-Methoden“ unverzichtbar bleiben.

Überblick: Welche Authentifizierungsmethoden gibt es?

Microsoft Entra ID unterstützt mittlerweile eine beachtliche Anzahl an Authentifizierungsmethoden. Die folgende Tabelle zeigt die wichtigsten und ihre Einsatzmöglichkeiten:

Legende:

• Primäre Anmeldung: Methode kann anstelle eines Passworts zum Einloggen verwendet werden
• Zweiter Faktor (MFA): Methode kann zusätzlich zum Passwort eingesetzt werden
• SSPR: Methode kann zur Self-Service Password Reset genutzt werden

Schon in dieser Übersicht zeigt sich die erste wichtige Erkenntnis: Nicht jede Methode kann für alle Zwecke verwendet werden. Besonders auffällig: Die modernsten und sichersten Methoden (Windows Hello, FIDO2, Authenticator passwortlos) sind nicht für SSPR verwendbar. Das hat weitreichende Konsequenzen für deine Planung – dazu später mehr.

Kurzer Hinweis zu QR Code: Die QR Code Authentifizierung ist eine spezialisierte Methode für Frontline Worker (z.B. im Einzelhandel oder der Produktion) auf gemeinsam genutzten mobilen Geräten. Ein QR Code wird mit einer PIN kombiniert und dient als Single-Factor Authentifizierung. Diese Methode funktioniert nur auf iOS/Android-Geräten und sollte nur für spezifische Benutzergruppen aktiviert werden, nicht organisationsweit. Sie ist nicht für MFA oder SSPR geeignet und sollte durch Conditional Access Policies zusätzlich abgesichert werden.

Die drei Kategorien: Primäre Anmeldung, MFA und SSPR

Um die Abhängigkeiten zu verstehen, müssen wir zunächst die drei Einsatzbereiche auseinanderhalten:

Primäre Anmeldung (First Factor)

Die primäre Anmeldung ist das, womit sich ein Benutzer zuerst identifiziert. Klassisch ist das das Passwort, aber moderne Methoden wie Windows Hello, FIDO2 oder Authenticator (passwortlos) können das Passwort komplett ersetzen.

Wichtig zu wissen: Passwortlose Methoden wie FIDO2 oder Windows Hello erfüllen bereits von sich aus MFA-Anforderungen, weil sie zwei Faktoren kombinieren:

• Etwas, das man hat: Das Gerät, der Sicherheitsschlüssel
• Etwas, das man weiß oder ist: PIN oder Biometrie (Fingerabdruck, Gesichtserkennung)

Sicherheitshinweis zu Windows Hello for Business: Obwohl sowohl PIN als auch Biometrie unterstützt werden, solltest du im Produktivbetrieb Biometrie (Fingerabdruck oder Gesichtserkennung) bevorzugen. Die PIN ist anfällig für Shoulder Surfing – ein Kollege oder Angreifer könnte die PIN-Eingabe beobachten und bei Zugriff auf das Gerät (z.B. unbeaufsichtigter Arbeitsplatz) diese nutzen. Biometrische Merkmale kann man nicht einfach ausspähen. Die PIN sollte nur als Fallback dienen, wenn biometrische Hardware nicht verfügbar ist.

Multi-Faktor-Authentifizierung (MFA)

MFA bedeutet: Zusätzlich zur primären Anmeldung (meist Passwort) ist ein zweiter Faktor erforderlich. Das kennst du wahrscheinlich zur Genüge:

• SMS-Code oder Telefonanruf
• Authenticator-App (Push-Benachrichtigung oder OTP-Code)
• Hardware OATH-Token

Microsoft unterscheidet dabei zwischen:

• Klassische MFA: SMS, Anruf, OTP – diese Methoden sind anfällig für Phishing-Angriffe
• Phishing-resistente MFA: Windows Hello, FIDO2, Zertifikate – diese Methoden können nicht per Remote-Phishing abgefangen werden

Microsoft empfiehlt eindeutig phishing-resistente Methoden, besonders für Admins und den Zugriff auf sensible Ressourcen. Und das aus gutem Grund – die Angriffe werden immer raffinierter.

Self-Service Password Reset (SSPR)

SSPR ermöglicht es Benutzern, ihr vergessenes Passwort selbst zurückzusetzen, ohne den Helpdesk anzurufen. Dafür muss sich der Benutzer mit registrierten Methoden verifizieren.

Und hier kommt der Haken: Nicht alle Authentifizierungsmethoden können für SSPR verwendet werden. Besonders die modernsten passwortlosen Methoden (Windows Hello, FIDO2, Authenticator passwortlos) sind nicht für SSPR verfügbar. Das ist eine der kritischsten Einschränkungen im Entra ID Authentifizierungssystem und führt oft zu Verwirrung bei der Planung.

SSPR im Detail: Welche Methoden funktionieren?

Microsoft dokumentiert in den offiziellen Learn-Artikeln nicht explizit, warum bestimmte Methoden nicht für SSPR unterstützt werden. Die Dokumentation listet lediglich auf, welche Methoden zugelassen sind. Hier die Übersicht:

Für SSPR zugelassen:

• Microsoft Authenticator (Push-Benachrichtigungen oder Code)
• Hardware/Software OATH-Token
• SMS-Code
• Sprachanruf
• E-Mail OTP

Nicht für SSPR zugelassen:

• Windows Hello for Business
• FIDO2-Sicherheitsschlüssel
• Authenticator (passwortlos/Passkey)
• QR Code

Sicherheitsbedenken bei E-Mail als SSPR-Methode

E-Mail als SSPR-Methode ist technisch möglich, aber es gibt wichtige Punkte zu beachten:

Warum geschäftliche E-Mail-Adressen nicht funktionieren: Geschäftliche E-Mail-Adressen (z.B. benutzer@firma.de) sind selbst über Entra ID geschützt. Wenn ein Benutzer sein Entra ID Passwort vergessen hat, kann er auch nicht auf seine geschäftliche E-Mail zugreifen – ein klassischer Zirkelschluss. Deshalb kommen für SSPR nur private E-Mail-Adressen in Frage (Gmail, Outlook.com, Yahoo, etc.).

Das Problem mit privaten E-Mail-Adressen: Private E-Mail-Adressen liegen außerhalb deiner Kontrolle.

• Schwächere Sicherheit: Private E-Mail-Accounts haben oft schwächere Passwörter und keine MFA aktiviert
• Keine Kontrolle: Du hast keine Möglichkeit, Sicherheitsrichtlinien durchzusetzen
• Account-Übernahme-Risiko: Private Mailaccounts sind ein beliebtes Angriffsziel und oft leichter zu kompromittieren
• Kein Monitoring: Du kannst nicht erkennen, wenn der private Account übernommen wurde

Worst-Case-Szenario: Ein Angreifer übernimmt den privaten Gmail-Account eines Benutzers. Wenn E-Mail die einzige SSPR-Methode ist, kann er das Entra ID Passwort zurücksetzen und sich Zugriff auf alle Unternehmensressourcen verschaffen. Nicht gut.

Meine Empfehlung basierend auf SSPR-Konfiguration:

• Bei zwei erforderlichen SSPR-Methoden: E-Mail kann aktiviert bleiben. Ein kompromittierter E-Mail-Account alleine reicht nicht aus – der Angreifer benötigt zusätzlich Zugriff auf die zweite Methode (z.B. Telefon oder Authenticator-App). Die Kombination aus Telefonnummer + E-Mail oder Authenticator + E-Mail ist akzeptabel.
• Bei nur einer erforderlichen SSPR-Methode: E-Mail sollte aus Sicherheitsgründen deaktiviert werden. Das Risiko ist zu hoch. Besser: Telefonnummer oder Authenticator-App als einzige Methode.

Kritische Abhängigkeiten zwischen Authentifizierungsmethoden

Jetzt kommen wir zum Kern der Sache. Die folgenden drei Abhängigkeiten sind entscheidend dafür, dass deine Authentifizierungsstrategie auch in der Praxis funktioniert:

Abhängigkeit #1: Passwortlose Methoden benötigen Fallback für SSPR

Stell dir folgendes Szenario vor:

• Ein Unternehmen führt Windows Hello for Business ein
• Benutzer melden sich fortan nur noch mit PIN oder Fingerabdruck an
• Das AD-Passwort wird nicht mehr im Alltag verwendet

Problem: Was passiert, wenn der Benutzer das (nicht mehr genutzte) Passwort vergisst oder aus irgendeinem Grund zurücksetzen muss?

Da Windows Hello nicht für SSPR verwendet werden kann, benötigt der Benutzer eine alternative Methode zur Verifikation. Ohne registrierte SSPR-Methode (z.B. Telefonnummer oder E-Mail) gibt’s nur einen Weg: Anruf beim Helpdesk. Und das nervt beide Seiten.

Deshalb die goldene Regel:

Selbst bei vollständig passwortloser Strategie muss jeder Benutzer mindestens eine SSPR-fähige Methode registriert haben – typischerweise eine Telefonnummer oder alternative E-Mail-Adresse.

Microsoft empfiehlt standardmäßig, dass Benutzer mindestens zwei Methoden für SSPR registrieren. Das erhöht die Ausfallsicherheit – wenn das Telefon mal verloren geht, gibt’s immer noch eine Alternative.

Abhängigkeit #2: Windows Hello und FIDO2 benötigen initiale MFA

Die zweite wichtige Abhängigkeit betrifft das Onboarding von passwortlosen Methoden:

Windows Hello for Business und FIDO2-Schlüssel können nicht „einfach so“ eingerichtet werden. Zur Registrierung dieser Methoden verlangt Microsoft eine vorherige MFA-Überprüfung.

Warum ist das so?

Sicherheit. Wenn jemand einfach einen FIDO2-Schlüssel zu einem Account hinzufügen könnte, ohne sich stark zu authentifizieren, könnte ein Angreifer einen Schlüssel zum gehackten Account hinzufügen und hätte dauerhaften Zugang. Das will man vermeiden.

Der typische Ablauf beim Einrichten von Windows Hello:

1. Benutzer meldet sich mit Passwort an seinem Gerät an
2. Windows fordert zur Einrichtung von Hello auf
3. Azure AD verlangt eine MFA-Überprüfung (z.B. Push an Authenticator-App oder SMS-Code)
4. Nach erfolgreicher MFA wird das Hello-Schlüsselpaar erstellt und im TPM gespeichert
5. Ab jetzt kann sich der Benutzer mit Hello anmelden

Dasselbe gilt für FIDO2-Schlüssel:

1. Benutzer meldet sich im Portal „Meine Sicherheitsinformationen“ an
2. Wählt „Sicherheitsschlüssel hinzufügen“
3. Azure AD verlangt MFA-Überprüfung
4. Nach erfolgreicher MFA kann der Schlüssel registriert werden

Die Abhängigkeit:

Vor der Einführung von Windows Hello oder FIDO2 muss sichergestellt sein, dass Benutzer bereits eine MFA-Methode registriert haben (z.B. Authenticator-App oder SMS).

Für neue Benutzer, die noch keine MFA-Methode haben, gibt es zwei Lösungen:

• Combined Security Info Registration: Beim ersten Login werden Benutzer aufgefordert, MFA-Methoden zu registrieren
• Temporary Access Pass (TAP): Ein Administrator erstellt einen zeitlich begrenzten Einmalcode, mit dem der Benutzer sich anmelden und direkt passwortlose Methoden einrichten kann (dazu später mehr in Part 2)

Abhängigkeit #3: Authenticator-App alleine reicht oft nicht aus

Die Microsoft Authenticator App ist vielseitig: Sie kann für MFA (Push/Code) und für SSPR verwendet werden. Klingt nach einer Komplettlösung, oder? Nicht ganz.

Warum Authenticator alleine problematisch sein kann

Szenario 1: Geräteverlust

Ein Benutzer hat nur die Authenticator-App registriert, keine andere Methode. Das Smartphone geht verloren oder wird zurückgesetzt.

• Der Benutzer kann sich nicht mehr anmelden (keine MFA)
• Der Benutzer kann auch kein Passwort zurücksetzen (keine SSPR-Methode)
• Ergebnis: Helpdesk muss ran

Szenario 2: SSPR-Policy mit zwei Methoden

Microsoft empfiehlt (und viele Unternehmen konfigurieren das so), dass SSPR mindestens zwei verschiedene Methoden erfordert. Die Authenticator-App zählt dabei als eine Methode, egal ob Push oder Code verwendet wird.

Das bedeutet: Auch wenn die Authenticator-App technisch für SSPR funktioniert, benötigt der Benutzer eine zweite Methode – typischerweise Telefon oder E-Mail.

Mobilnummer als Abhängigkeit für Authenticator

Es gibt noch eine weitere Abhängigkeit: Für bestimmte Features der Authenticator-App (z.B. passwortlose Telefonanmeldung) kann Microsoft verlangen, dass eine Telefonnummer hinterlegt ist, um die Identität des Benutzers zusätzlich zu verifizieren.

Best Practice:

Auch wenn die Authenticator-App die Hauptmethode ist, sollten Benutzer mindestens eine alternative Methode registriert haben – idealerweise Telefonnummer oder E-Mail als Fallback.

Abhängigkeitsdiagramm: Was braucht was?

Hier nochmal die wichtigsten Abhängigkeiten auf einen Blick:

Phishing-Resistenz: Die wichtige Unterscheidung

Microsoft kategorisiert Authentifizierungsmethoden nach ihrer Widerstandsfähigkeit gegen Phishing-Angriffe. Das ist nicht nur Marketing – die Unterschiede sind in der Praxis erheblich:

Phishing-anfällige Methoden

• Passwort: Kann auf gefälschten Login-Seiten abgefangen werden
• SMS / Anruf: Code kann vom Benutzer auf Phishing-Seite eingegeben werden
• Authenticator Push: Trotz Number Matching kann ein überzeugender Angriff Benutzer zur Bestätigung verleiten
• OTP-Codes: Können in Echtzeit auf gefälschter Seite abgefangen und verwendet werden

Phishing-resistente Methoden

• Windows Hello for Business: Privater Schlüssel verlässt nie das TPM, kein übertragbares Geheimnis
• FIDO2-Sicherheitsschlüssel: Der Schlüssel ist an die echte Domain gebunden (z.B. login.microsoft.com). Selbst wenn ein Angreifer eine täuschend echte Phishing-Seite erstellt (z.B. login-micros0ft.com mit einer Null statt O), wird der FIDO2-Schlüssel keine Anmeldung durchführen, da die Domain nicht übereinstimmt. Der Benutzer kann sich nur auf der echten Website anmelden.
• Authenticator (passwortlos / Passkey): Gerätgebundener Schlüssel mit Kryptographie
• Zertifikat-basierte Authentifizierung: Asymmetrische Kryptographie, Smartcard

Microsoft sagt es ziemlich klar:

„Microsoft recommends using phishing-resistant authentication methods such as Windows Hello for Business, passkeys (FIDO2) and FIDO2 security keys, or certificate-based authentication (CBA) because they provide the most secure sign-in experience.“

Microsoft Learn: Authentication Methods Overview

Für die Planung bedeutet das: Für hochprivilegierte Accounts (Administratoren) und den Zugriff auf sensitive Ressourcen solltest du ausschließlich phishing-resistente Methoden zulassen. Für normale Benutzer bietet bereits die Kombination Passwort + MFA deutlich mehr Sicherheit als ein reines Passwort, aber mittelfristig sind passwortlose Verfahren sowohl sicherer als auch benutzerfreundlicher.

System Preferred MFA: Automatische Auswahl der sichersten Methode

Mit System Preferred MFA bietet Microsoft die Möglichkeit, automatisch die sicherste verfügbare Authentifizierungsmethode aus den registrierten Methoden eines Benutzers auszuwählen.

Statt dass der Benutzer bei jeder MFA-Aufforderung zwischen SMS, Authenticator-Push oder anderen Methoden wählen muss, entscheidet das System basierend auf einer Microsoft-definierten Sicherheitshierarchie.

Der Vorteil: Benutzer verwenden automatisch die sicherste Methode, ohne sich Gedanken machen zu müssen. Das vereinfacht den Rollout moderner Methoden erheblich – du kannst neue Methoden ausrollen, ohne dass Benutzer manuell umstellen müssen.

Hinweis: Die Konfiguration und praktische Implementierung von System Preferred MFA behandeln wir in Part 2 dieser Serie.

Hybrid-Umgebungen: Zusätzliche Überlegungen

In Hybrid-Umgebungen (lokales Active Directory synchronisiert mit Entra ID) kommen weitere Abhängigkeiten hinzu:

Windows Hello for Business in Hybrid

Windows Hello for Business funktioniert auch in Hybrid-Umgebungen (lokales Active Directory + Entra ID). Die Einrichtung ist allerdings komplexer und erfordert spezifische Voraussetzungen.

Wichtig für diesen Artikel: In Hybrid-Szenarien gelten dieselben Abhängigkeiten wie in reinen Cloud-Umgebungen:

• Benutzer benötigen eine vorhandene MFA-Methode zur Einrichtung von Hello
• Benutzer benötigen eine SSPR-fähige Methode (Telefon/E-Mail) als Fallback
• TPM 2.0 auf Client-Geräten wird dringend empfohlen

Hinweis: Eine detaillierte Anleitung zu Windows Hello for Business mit Cloud Kerberos Trust für Hybrid-Umgebungen findest du in meiner separaten Artikelserie: Windows Hello for Business SSO mit Cloud Kerberos Trust

FIDO2 für Windows-Login in Hybrid

FIDO2-Schlüssel können auch für den Windows-Login auf Hybrid-Joined Geräten verwendet werden, benötigen aber zusätzliche Konfiguration:

• Azure AD Hybrid Authentication Management PowerShell-Modul
• Domain Controller mit aktuellen Patches
• Intune Policy oder GPO zur Aktivierung des FIDO2-Logins
• Konfiguration für Kerberos-Ticket-Ausstellung über Azure AD

Ohne diese Konfiguration kann sich der Benutzer zwar mit dem FIDO2-Schlüssel an Azure AD anmelden, erhält aber keine Kerberos-Tickets für On-Premises Ressourcen (Fileshares, interne Webseiten etc.). Das führt dann zu Verwirrung beim Benutzer – „Ich bin doch angemeldet, warum kann ich nicht auf das Laufwerk zugreifen?“

Minimalsets: Was braucht ein Benutzer mindestens?

Basierend auf den Abhängigkeiten können wir Minimalsets definieren. Diese sind wichtig für die Planung, aber in Part 2 gehen wir noch viel detaillierter darauf ein:

Minimalset für klassische MFA

• Passwort (primäre Anmeldung)
• Authenticator-App oder SMS/Anruf (zweiter Faktor)
• Zweite SSPR-Methode (z.B. Telefon, wenn Authenticator die erste ist)

Minimalset für passwortlose Strategie (Windows Hello)

• Passwort (technisch vorhanden, aber nicht mehr im Alltag genutzt)
• Authenticator-App oder SMS (für initiales Hello-Setup und als MFA-Fallback)
• Windows Hello for Business (primäre Anmeldemethode)
• Telefonnummer oder E-Mail (für SSPR, da Hello nicht dafür nutzbar)

Empfohlenes Set für maximale Flexibilität

• Windows Hello (primär am eigenen Gerät)
• FIDO2-Sicherheitsschlüssel (Backup, für fremde Geräte)
• Authenticator-App (für mobile Anmeldungen, als Fallback)
• Telefonnummer (für SSPR und Notfälle)
• Passwort (vorhanden, aber nur für Legacy-Szenarien)

Diese Kombination deckt die meisten Szenarien ab und bietet mehrere Fallback-Optionen bei Geräteverlust oder technischen Problemen. Mehr dazu in Part 2.

Häufige Missverständnisse und Stolpersteine

„Passwortlos bedeutet, das Passwort wird gelöscht“

Realität: Das Passwort existiert weiterhin im Active Directory / Entra ID, wird aber nicht mehr aktiv verwendet. Es dient als Fallback für Systeme, die moderne Authentifizierung noch nicht unterstützen. Und davon gibt’s mehr, als man denkt.

„Mit FIDO2 brauche ich keine andere Methode“

Realität: Du benötigst mindestens eine SSPR-fähige Methode (Telefon/E-Mail), da FIDO2 nicht für Self-Service Password Reset verwendet werden kann. Außerdem brauchst du eine MFA-Methode, um den FIDO2-Schlüssel überhaupt erst registrieren zu können. Das ist ein Henne-Ei-Problem, das viele erst beim Rollout bemerken.

„SMS ist genauso sicher wie Authenticator“

Realität: SMS ist anfälliger für SIM-Swapping-Angriffe und Phishing. Die Authenticator-App ist deutlich sicherer, besonders mit Number Matching. Für hochsensible Bereiche sollten nur phishing-resistente Methoden (FIDO2, Hello) zugelassen werden. SMS ist besser als nichts, aber definitiv nicht die erste Wahl.

Stolperstein: Legacy-Authentifizierung

Selbst wenn du modernste MFA-Methoden einführst, können veraltete Protokolle (IMAP, POP3, SMTP Basic Auth) diese komplett umgehen. Solche Legacy-Authentifizierungen senden oft nur Benutzername + Passwort und ignorieren MFA komplett.

Die Lösung: Legacy-Authentifizierung muss via Conditional Access oder Security Defaults blockiert werden, sonst bleibt ein riesiges Sicherheitsloch bestehen. Das wird oft vergessen und ist dann die Hintertür für Angreifer.

Zusammenfassung und Ausblick

Die wichtigsten Erkenntnisse aus Part 1 auf einen Blick:

1. Nicht alle Methoden können für alle Zwecke verwendet werden – besonders die Einschränkung bei SSPR ist kritisch und muss bei der Planung berücksichtigt werden
2. Passwortlose Methoden haben Abhängigkeiten zu klassischen Methoden – sowohl beim Onboarding (MFA erforderlich) als auch als Fallback (SSPR)
3. Selbst bei passwortloser Strategie braucht jeder Benutzer eine SSPR-fähige Methode (Telefon oder E-Mail) – das ist keine optionale Empfehlung, sondern Pflicht
4. Phishing-resistente Methoden sollten der Standard sein, besonders für Administratoren und sensitive Bereiche – die Angriffe werden nicht einfacher
5. Minimalsets sind wichtig, aber mehr Redundanz erhöht die Ausfallsicherheit und reduziert Helpdesk-Anfragen

Wie geht es weiter?

In Part 2 dieser Serie wird’s praktisch: Wir schauen uns detailliert an, welche Kombinationen von Authentifizierungsmethoden für verschiedene Szenarien empfohlen werden (Admins, Office-Mitarbeiter, Remote-Worker, Frontline Worker etc.). Außerdem behandeln wir Best Practices für den Rollout, häufige Fehler aus der Praxis und geben dir konkrete Empfehlungen, wie du die Minimalsets in deiner Umgebung umsetzt.

Referenzen

• Microsoft Entra Authentication Overview – Microsoft Learn
• Passkeys (FIDO2) authentication method in Microsoft Entra ID – Microsoft Learn
• Get started with a phishing-resistant passwordless authentication deployment – Microsoft Learn
• Microsoft Authenticator authentication method – Microsoft Learn
• QR code authentication method in Microsoft Entra ID – Microsoft Learn
• How self-service password reset works in Microsoft Entra ID – Microsoft Learn
• Prepare users to provision and use Windows Hello for Business – Microsoft Learn

Der Beitrag Authentifizierungsmethoden in Microsoft Entra ID – Part 1: Grundlagen und Abhängigkeiten erschien zuerst auf M365 Blog - Julian Stabentheiner.

Willkommen in der Welt der Microsoft Entra ID Registration Campaign – einem Feature, das eigentlich hilfreich sein soll, aber bei Hardware Token Usern zu einem echten Praxisproblem wird. In diesem Artikel zeige ich dir, warum das passiert und wie du es mit wenigen Handgriffen lösen kannst.

Was ist die Microsoft Authenticator Registration Campaign?

Die Registration Campaign ist ein „Nudging-Mechanismus“ in Microsoft Entra ID, der User während des normalen Sign-In-Prozesses dazu auffordert, Microsoft Authenticator einzurichten. Das Ganze läuft so ab:

1. User meldet sich normal an
2. Führt MFA wie gewohnt durch (z.B. mit SMS, Hardware Token, oder einer anderen Methode)
3. Nach erfolgreicher MFA erscheint ein Prompt zur Einrichtung von Microsoft Authenticator
4. User kann den Einrichtungsprozess durchlaufen oder „Skip for now“ wählen

Die Idee dahinter ist gut: Microsoft möchte die Adoption von Authenticator Push Notifications erhöhen, da diese sicherer und benutzerfreundlicher sind als SMS oder Anrufe. Die Campaign zielt dabei spezifisch auf Push Notifications ab – nicht auf TOTP-Codes im Authenticator.

Konfiguration der Registration Campaign

Als Administrator kannst du die Campaign granular steuern:

• Scoping: Du kannst festlegen, welche User oder Gruppen zur Registrierung aufgefordert werden sollen (Include) und welche ausgenommen werden (Exclude)
• Snooze-Verhalten: Du kannst konfigurieren, wie oft User den Prompt „wegklicken“ können (0-14 Tage pro Snooze, unlimited oder limited snoozes)
• Erzwingung: Nach einer bestimmten Anzahl von Snoozes kann die Registrierung verpflichtend werden

Wichtig zu verstehen: Die Campaign prüft nur eine einzige Bedingung – hat der User Microsoft Authenticator Push Notifications eingerichtet? Wenn nein, wird der Prompt angezeigt. Welche anderen MFA-Methoden der User bereits hat, spielt dabei keine Rolle.

Hardware TOTP Token in Entra ID

Hardware TOTP (Time-based One-Time Password) Token – auch OATH Hardware Token genannt – sind physische Geräte, die alle 30 oder 60 Sekunden einen neuen sechsstelligen Code generieren. In Microsoft Entra ID sind sie eine vollwertige MFA-Methode und stehen in der System-Preferred MFA Hierarchie an Position 5 (TOTP).

Die Hierarchie sieht so aus:

1. Temporary Access Pass (TAP)
2. Passkey (FIDO2)
3. External authentication methods
4. Microsoft Authenticator notifications
5. Time-based one-time password (TOTP) ← Hardware OATH Token
6. Telefon (SMS/Anruf)
7. Certificate-based authentication

Typische Einsatzszenarien

Hardware TOTP Token werden in der Regel bewusst eingesetzt für:

• User ohne Smartphone: Mitarbeiter in Produktionsumgebungen, Lager, oder Bereiche mit Smartphone-Verbot
• Hohe Sicherheitsanforderungen: Privilegierte Accounts oder regulierte Industrien
• Datenschutz-Bedenken: User, die keine privaten Geräte für geschäftliche Zwecke nutzen möchten
• Backup-Methode: Als Fallback für Authenticator oder FIDO2

In all diesen Fällen ist die Entscheidung für Hardware-Token eine bewusste organisatorische Wahl – und genau hier entsteht das Problem mit der Registration Campaign.

Das Problem: Warum werden Hardware Token User „belästigt“?

Jetzt kommen wir zum Kern des Problems. Stell dir vor:

• Du hast einem User ein Hardware TOTP Token zugewiesen
• Der User nutzt dieses Token erfolgreich für MFA
• Die Registration Campaign ist für „All users“ aktiviert

Was passiert?

Der User wird bei jedem Sign-In nach der MFA-Eingabe (mit seinem Hardware Token!) zur Installation von Microsoft Authenticator aufgefordert. Er kann „Skip for now“ wählen, aber nach der konfigurierten Snooze-Zeit (z.B. 1 Tag) kommt der Prompt wieder. Und wieder. Und wieder.

Falls du „Limited snoozes“ konfiguriert hast (z.B. maximal 3x snoozen), wird nach dem dritten Snooze die Authenticator-Registrierung verpflichtend – selbst wenn der User ein vollständig funktionales Hardware Token hat!

Warum ignoriert die Campaign das Hardware Token?

Die Antwort liegt in der Funktionsweise der Registration Campaign. Sie prüft ausschließlich, ob der User Microsoft Authenticator Push Notifications eingerichtet hat. Das ist die einzige Bedingung.

Die Campaign fragt nicht:

• Hat der User bereits andere sichere MFA-Methoden wie Hardware TOTP?
• Ist der User bereits mit sicheren Authentifizierungsmethoden ausgestattet?
• Wurde dem User bewusst eine alternative Methode zugewiesen?

In der offiziellen Microsoft Learn FAQ wird das explizit bestätigt:

„Will a user who signs in with a 3rd party authenticator app see the nudge?“
Yes. If a user is enabled for the registration campaign and doesn’t have Microsoft Authenticator set up for push notifications, the user is nudged to set up Authenticator.

Das gleiche gilt für Hardware TOTP Token: Die Campaign sieht sie nicht als Grund, den User vom Authenticator-Prompt zu verschonen.

Warum ist das problematisch?

Auf den ersten Blick könnte man sagen: „Na und? Der User kann doch einfach snoozen.“ Aber in der Praxis entstehen mehrere Probleme:

1. Organisatorischer Konflikt

Wenn du als Organisation bewusst Hardware Token ausrollst – sei es aus Sicherheits-, Datenschutz- oder praktischen Gründen – dann möchtest du, dass diese User das Token nutzen. Die Registration Campaign unterläuft diese Entscheidung, indem sie die User ständig zur Authenticator-Installation drängt.

Das kann zu Verwirrung führen: „Warum soll ich Authenticator installieren, wenn ich doch ein Token bekommen habe?“

2. Schlechte User Experience

User mit Hardware Token haben bereits eine sehr sichere MFA-Methode (Position 5 in der System-Preferred Hierarchie – höher als SMS!). Sie müssen aber:

• Bei jedem MFA-Prompt nach dem Snooze-Intervall den Authenticator-Prompt sehen
• Wiederholt auf „Skip for now“ klicken
• Im schlimmsten Fall (limited snoozes) nach 3x snoozen zur Registrierung gezwungen werden

Das ist nicht nur nervig, sondern untergräbt auch das Vertrauen in die von IT-Abteilung bereitgestellte Lösung.

3. System-Preferred MFA hilft nicht

Man könnte denken: „Aber Hardware TOTP ist doch Teil der System-Preferred MFA – sollte das nicht automatisch funktionieren?“ Leider nein.

System-Preferred MFA bestimmt nur, welche Methode beim MFA-Prompt bevorzugt wird (also während der eigentlichen Authentifizierung). Die Registration Campaign läuft aber nach dem MFA-Prompt als separater Schritt. System-Preferred MFA kann den Authenticator-Registrierungs-Prompt nicht verhindern.

4. Hardware Token wird nach Authenticator-Einrichtung „nutzlos“

Hier wird es besonders problematisch: Angenommen, ein User ist von der ständigen Registration Campaign so genervt, dass er den Microsoft Authenticator doch einrichtet – in der Hoffnung, endlich Ruhe zu haben.

Was passiert dann?

Durch die System-Preferred MFA Hierarchie wird der User ab diesem Zeitpunkt immer zur Authentifizierung mit dem Authenticator aufgefordert. Denn Microsoft Authenticator Push Notifications stehen auf Position 4 in der Hierarchie, während TOTP auf Position 5 steht. Das System bevorzugt automatisch die höher priorisierte Methode.

Das Ergebnis:

• Der User wird nun standardmäßig zur Authenticator-Push-Notification aufgefordert
• Das Hardware Token liegt nutzlos herum
• Der User fragt sich: „Warum habe ich überhaupt ein Token bekommen, wenn ich es nie nutzen kann?“
• Die organisatorische Entscheidung für Hardware Token wurde komplett untergraben

Besonders ärgerlich: Viele User, die Hardware Token erhalten haben, können den Authenticator aus gutem Grund nicht nutzen (kein Smartphone, Datenschutzbedenken, Sicherheitsrichtlinien). Sie werden praktisch gezwungen, eine Methode einzurichten, die sie nicht verwenden können oder sollen – nur um die Campaign-Prompts loszuwerden.

Selbst wenn der User das Hardware Token weiterhin nutzen möchte, muss er bei jedem MFA-Prompt aktiv auf „Use another method“ klicken und dann das Token auswählen. Das ist genau das Gegenteil dessen, was du als Administrator mit der Hardware Token-Bereitstellung erreichen wolltest.

Die Lösung: Hardware Token User ausschließen

Die gute Nachricht: Die Lösung ist einfach und elegant. Du musst lediglich deine Hardware Token User von der Registration Campaign ausschließen. Microsoft bietet dafür group-based exclusions an, die genau für solche Szenarien gedacht sind.

Schritt 1: Security Group für Hardware Token User

Erstelle eine Security Group (z.B. „MFA-HardwareTokenUsers“ oder „Exclude-AuthenticatorCampaign“) und füge alle User hinzu, die Hardware TOTP Token nutzen.

Wichtiger Hinweis: Dynamische Gruppen basierend auf „hat Hardware OATH Token“ sind leider nicht möglich, da es keine entsprechenden User-Attribute gibt, die in Dynamic Group Queries verwendet werden können. Du musst die Gruppe also manuell pflegen.

Alternative: Falls du viele Hardware Token User hast, kannst du ein Azure Functions Script schreiben, das über die Graph API prüft, welche User Hardware OATH Token haben, und die Gruppenmitgliedschaft automatisch aktualisiert. Das ist allerdings optional – für die meisten Umgebungen reicht die manuelle Pflege aus.

Schritt 2: Gruppe von Registration Campaign ausschließen

Jetzt schließt du die Gruppe von der Registration Campaign aus.

Via Entra Admin Center

1. Melde dich als Authentication Policy Administrator (oder höher) im Entra Admin Center an
2. Navigiere zu Entra ID → Authentication methods → Registration campaign
3. Bei „Excluded users and groups“ klicke auf „Add users and groups“
4. Füge deine Hardware Token Gruppe hinzu
5. Klicke auf Save

Wichtig: Wenn ein User sowohl in einer Include- als auch in einer Exclude-Gruppe ist, hat Exclude Vorrang. Der User wird nicht zur Registrierung aufgefordert.

Schritt 3: Verifizierung

Um zu testen, ob der Ausschluss funktioniert:

1. Melde dich als Test-User an, der in der ausgeschlossenen Gruppe ist
2. Führe MFA mit dem Hardware Token durch
3. Nach erfolgreicher MFA sollte kein Authenticator-Registrierungs-Prompt erscheinen

Falls der Prompt weiterhin erscheint, überprüfe:

• Ist der User tatsächlich Mitglied der Exclude-Gruppe?
• Wurde die Policy gespeichert/aktualisiert?
• Warte ggf. einige Minuten für die Replikation der Policy-Änderung

Alternative Ansätze

Neben der group-based exclusion gibt es noch einige alternative Ansätze, je nachdem wie deine Umgebung aussieht:

Granulares Include statt Exclude

Statt „All users“ mit Exclusions kannst du die Campaign nur auf spezifische Gruppen anwenden:

• Gruppe: „MFA-SMS-Users“ (User, die nur SMS/Voice haben)
• Gruppe: „MFA-ThirdPartyOTP-Users“ (User mit Third-Party Authenticator Apps)

Vorteil: Mehr Kontrolle, keine User werden versehentlich geprompted

Nachteil: Mehr administrativer Aufwand, neue User müssen aktiv zugewiesen werden

Unlimited Snoozes aktivieren

Wenn du die Campaign generell beibehalten möchtest, aber User nicht zwingen willst:

• Setze „Limited number of snoozes“ auf Disabled
• User können unbegrenzt snoozen und die Registrierung vermeiden

Vorteil: Flexibler für alle User

Nachteil: User sehen weiterhin den Prompt (schlechte UX für Hardware Token User)

ging für User, die tatsächlich von Authenticator profitieren würden (z.B. SMS-User)

Best Practices

Basierend auf den Erkenntnissen aus der Praxis hier einige Empfehlungen:

1. Proaktiv ausschließen: Schließe Hardware Token User vor der Aktivierung der Registration Campaign aus, nicht erst nachdem User sich beschweren.
2. Gruppenpflege etablieren: Etabliere einen Prozess zur Pflege der Exclusion-Gruppe. Wenn ein neuer User ein Hardware Token erhält, sollte er automatisch (oder zeitnah) zur Gruppe hinzugefügt werden.
3. Kommunikation: Informiere deine User über die Gründe für Hardware Token vs. Authenticator. Transparenz erhöht die Akzeptanz.
4. Monitoring: Nutze die Authentication Methods Activity Reports in Entra ID, um die tatsächliche Nutzung zu überwachen. So siehst du, ob deine Strategie aufgeht.
5. Policy-Alignment: Stelle sicher, dass deine Authentication Methods Policy Hardware OATH für die entsprechenden Gruppen aktiviert hat und die Token ordnungsgemäß registriert sind.
6. Backup-Methoden: Auch wenn Hardware Token die primäre Methode ist, sollten User idealerweise eine Backup-Methode registriert haben (z.B. Telefonnummer für SMS als Notfall-Fallback).

Fazit

Die Microsoft Entra ID Registration Campaign ist ein nützliches Feature, um die Adoption von Microsoft Authenticator Push Notifications zu fördern. Allerdings berücksichtigt sie nicht, ob User bereits andere sichere MFA-Methoden wie Hardware TOTP Token nutzen.

Das führt zu einem Praxisproblem: User mit Hardware Token werden ständig zur Authenticator-Installation aufgefordert, obwohl sie bereits eine sichere und bewusst gewählte MFA-Methode haben. Oft auch aus dem Grund, dass sie den Authenticator gar nicht nutzen können. Das sorgt für Verwirrung, schlechte User Experience und untergräbt organisatorische Entscheidungen.

Die Lösung ist einfach: Group-based exclusion. Erstelle eine Security Group für deine Hardware Token User und schließe diese von der Registration Campaign aus. Das verhindert den Prompt und ermöglicht deinen Usern, die bereitgestellte Hardware-Lösung ohne Ablenkung zu nutzen.

Ausblick: Ab März 2026 wird die Registration Campaign für Tenants mit aktivierten Synced Passkeys auf Passkeys statt nur Microsoft Authenticator abzielen. Das könnte das Verhalten leicht ändern, aber die grundsätzliche Empfehlung zur group-based exclusion für Hardware Token User bleibt bestehen.

Meine Empfehlung: Nutze die group-based exclusion proaktiv als Standard-Konfiguration für alle Hardware Token Deployments. Deine User werden es dir danken!

Referenzen und weiterführende Informationen

Alle Informationen in diesem Artikel basieren auf der offiziellen Microsoft Learn Dokumentation. Hier findest du die wichtigsten Quellen:

• How to run a registration campaign to set up Microsoft Authenticator
• OATH tokens authentication method
• How to manage OATH tokens in Microsoft Entra ID (Preview)
• System-preferred multifactor authentication (MFA)
• Manage authentication methods for Microsoft Entra multifactor authentication
• How to migrate to the Authentication methods policy

Der Beitrag Microsoft Entra ID Registration Campaign und Hardware TOTP – Ein Konflikt in der Praxis erschien zuerst auf M365 Blog - Julian Stabentheiner.

Voraussetzungen

Bevor wir mit der Konfiguration starten, solltest du sicherstellen, dass deine Umgebung die folgenden Voraussetzungen erfüllt:

• Client-Betriebssystem: Windows 10 oder Windows 11 mit Pro/Enterprise Edition
• Geräte: (Hybrid) Azure AD joined Geräte
• Active Directory: Domain und Forest Functional Level mindestens Windows Server 2008 R2
• Domain Controller: Read-Write Domain Controller (RWDC) in jedem Active Directory-Standort erforderlich – RODC reicht nicht aus
• Entra ID Connect: Bereits implementiert und funktionsfähig
• Berechtigungen: Globaler Administrator für Entra ID sowie Domänen-Administrator für das lokale Active Directory
• Netzwerk: Konnektivität zwischen Clients und Domain Controllern
• TLS 1.2: Aktiviert auf dem Verwaltungssystem

Wichtige Einschränkung: Benutzer, die Mitglieder von privilegierten integrierten Sicherheitsgruppen sind (z.B. Domain Admins, Enterprise Admins), können Cloud Kerberos Trust nicht verwenden. Dies ist eine Sicherheitsmaßnahme, um potenzielle Angriffsvektoren von Microsoft Entra ID zum lokalen Active Directory zu verhindern. OnPrem Admin-Konten sollten allerdings grundsätzlich nicht mit Entra ID Accounts synchronisiert werden.

Konfiguration und Einrichtung

Die Einrichtung ist erfreulich unkompliziert und besteht im Wesentlichen aus drei Hauptschritten: der Aktivierung des Microsoft Entra Kerberos Servers, der Bereitstellung der entsprechenden Intune-Policy und der abschließenden Validierung. Damit ist Cloud Kerberos Trust deutlich einfacher zu implementieren als die älteren Key Trust oder Certificate Trust Methoden.

Schritt 1: Microsoft Entra Kerberos aktivieren

Der erste Schritt besteht darin, Microsoft Entra Kerberos zu aktivieren. Dieses fungiert als Read-Only Domain Controller (RODC) in deinem lokalen Active Directory und ermöglicht die Ausstellung von Kerberos-Tickets basierend auf der Cloud-Authentifizierung.

PowerShell-Modul installieren

Zunächst benötigst du das PowerShell-Modul AzureADHybridAuthenticationManagement. Öffne eine PowerShell-Sitzung mit Administratorrechten und führe folgenden Befehl aus:

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

Falls noch nicht geschehen, stelle sicher, dass TLS 1.2 aktiviert ist:

[Net.ServicePointManager]::SecurityProtocol = [Net.ServicePointManager]::SecurityProtocol -bor [Net.SecurityProtocolType]::Tls12

Kerberos Server konfigurieren

Nach der Installation des Moduls kannst du den Microsoft Entra Kerberos Server einrichten. Führe die folgenden Befehle aus – am besten vom Entra ID Connect Server aus:

$domain = $env:USERDNSDOMAIN
$userPrincipalName = "admin@deintenant.onmicrosoft.com"
$domainCred = Get-Credential

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName -DomainCredential $domainCred

Du wirst aufgefordert, dich mit deinen Domänen-Administrator-Anmeldeinformationen und anschließend mit deinen Entra ID Anmeldeinformationen zu authentifizieren. Der Befehl erstellt ein RODC-Objekt in deinem Active Directory sowie ein entsprechendes krbtgt-Konto.

Wichtiger Hinweis: Das krbtgt-Konto ist standardmäßig deaktiviert – das ist beabsichtigt und korrekt so. Es dient lediglich als Platzhalter für die Cloud-basierte Kerberos-Ticketausstellung.

Konfiguration verifizieren

Um zu überprüfen, ob die Einrichtung erfolgreich war, führe folgenden Befehl aus:

Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $userPrincipalName

Du solltest nun die Details des Microsoft Entra Kerberos Servers sehen, einschließlich der Domain, des Cloud-Objekts und des Erstellungsdatums. Zusätzlich kannst du in deinem Active Directory unter den Domain Controllers das neue RODC-Objekt mit dem Namen „AzureADKerberos“ finden.

Schritt 2: Intune-Policy konfigurieren

Der zweite Schritt besteht darin, Windows Hello for Business mit Cloud Kerberos Trust über eine Intune-Policy auf den Geräten zu aktivieren. Hierfür verwenden wir den Settings Catalog in Microsoft Intune.

Settings Catalog Policy erstellen

1. Öffne das Microsoft Intune Admin Center (https://intune.microsoft.com)
2. Navigiere zu Devices → Configuration profiles
3. Klicke auf Create profile
4. Wähle als Platform Windows 10 and later
5. Wähle als Profile type Settings catalog
6. Vergib einen aussagekräftigen Namen wie „Windows Hello for Business – Cloud Kerberos Trust“

Erforderliche Einstellungen hinzufügen

Sofern nicht schon geschehen, muss Windows Hello for Business (WhfB) aktiviert werden. Hier einmal im Schnelldurchlauf:

Im Settings Catalog suchst du nach „Windows Hello for Business“ und fügst die folgenden Einstellungen hinzu:

1. Use Windows Hello for Business (Device)
   • Setze diese Einstellung auf Enabled
2. Use Cloud Trust For On Premises Auth
   • Setze diese Einstellung auf Enabled
3. Use a hardware security device (Optional, aber empfohlen)
   • Setze diese Einstellung auf Enabled oder Required
   • Erzwingt die Verwendung von TPM (Trusted Platform Module) für zusätzliche Sicherheit

Hinweis: Die Bezeichnungen der Einstellungen haben sich im Laufe der Zeit geändert. In älteren Portal-Versionen hießen sie „Use Passport for Work“ und „Use Cloud Trust For On Prem Auth“. Die Funktionalität ist jedoch identisch.

Policy zuweisen

Weise die Policy den gewünschten Benutzer- oder Gerätegruppen zu. Nach der Zuweisung wird die Policy beim nächsten Check-in der Geräte ausgerollt.

Schritt 3: Testing und Validierung

Nachdem beide Konfigurationsschritte abgeschlossen sind, ist es Zeit, die Implementierung zu testen und zu validieren.

Policy-Anwendung überprüfen

Auf einem Client-Gerät kannst du im Event Viewer unter Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider → Admin nach der Event ID 358 suchen. Dieses Event bestätigt, dass die Policy erfolgreich angewendet wurde.

Alternativ kannst du in der Registry unter HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork prüfen, ob der Wert UseCloudTrustForOnPremAuth auf 1 gesetzt ist.

DSREGCMD zur Validierung nutzen

Das wichtigste Tool zur Validierung ist DSREGCMD. Öffne eine Eingabeaufforderung und führe folgende Befehle aus:

DSREGCMD /REFRESHPRT
DSREGCMD /STATUS

In der Ausgabe solltest du im Abschnitt SSO State folgende Werte sehen:

AzureAdPrt : YES
AzureAdPrtUpdateTime : [Zeitstempel]
AzureAdPrtExpiryTime : [Zeitstempel]
CloudTgt : YES
OnPremTgt : YES

Wenn sowohl CloudTgt als auch OnPremTgt auf YES stehen, funktioniert Cloud Kerberos Trust einwandfrei. Das Cloud TGT wird von Entra ID ausgestellt, während das On-Premises TGT vom lokalen Domain Controller bereitgestellt wird.

Kerberos-Tickets überprüfen

Mit dem Befehl klist cloud_debug kannst du zusätzlich die Details der Kerberos-Tickets einsehen und überprüfen, ob sowohl Cloud- als auch On-Premises-Tickets vorhanden sind.

Troubleshooting: Häufige Probleme und Lösungen

Trotz der einfachen Implementierung kann es zu einigen typischen Problemen kommen. Hier sind die häufigsten Herausforderungen und deren Lösungen:

CloudTgt zeigt NO

Problem: Das Cloud TGT wird nicht ausgestellt.
Lösung: Führe DSREGCMD /REFRESHPRT aus, um das Primary Refresh Token manuell zu aktualisieren. Dadurch wird ein neues Cloud TGT von Entra ID angefordert.

OnPremTgt zeigt NO

Problem: Das On-Premises TGT wird nicht ausgestellt.
Lösung:

• Überprüfe, ob die Policy korrekt angewendet wurde (Event ID 358)
• Stelle sicher, dass das Gerät die Mindestanforderungen erfüllt (Windows 10 oder Windows 11)
• Prüfe die Netzwerkkonnektivität zum Domain Controller
• Verifiziere, dass der Microsoft Entra Kerberos Server korrekt im Active Directory registriert ist

Policy wird nicht angewendet

Problem: Die Intune-Policy scheint nicht anzukommen.
Lösung:

• Bestätige, dass beide erforderlichen Einstellungen im Settings Catalog vorhanden sind
• Überprüfe die Gruppenzuweisungen
• Warte auf den nächsten Check-in oder erzwinge eine Synchronisation über das Intune-Portal
• Prüfe im Intune-Portal unter Device Configuration, ob Konflikte mit anderen Policies bestehen

Fehler „Operation not supported“ beim Set-AzureADKerberosServer

Problem: Der PowerShell-Befehl schlägt mit einer Fehlermeldung fehl.
Lösung:

• Führe den Befehl vom Entra ID Connect Server aus, nicht direkt vom Domain Controller
• Stelle sicher, dass du über die erforderlichen Administratorrechte verfügst
• Bei Child Domains verwende dedizierte Domänen-Administrator-Anmeldeinformationen für die jeweilige Domain

Certificate Trust wird statt Cloud Kerberos Trust verwendet

Problem: Trotz korrekter Konfiguration wird Certificate Trust statt Cloud Kerberos Trust verwendet.
Lösung:

• Kritisch: Wenn die Einstellung „Use certificate for on-premises authentication“ aktiviert ist, hat Certificate Trust Priorität vor Cloud Kerberos Trust
• Diese Einstellung muss auf Not configured gesetzt sein
• Prüfe sowohl Intune-Policies als auch Group Policies auf diese Einstellung
• Nach der Änderung: Gerät neu starten und Windows Hello neu registrieren

Zusammenfassung und Ausblick

Cloud Kerberos Trust bietet eine elegante und moderne Lösung für Single Sign-On in hybriden Umgebungen. Die Implementierung ist im Vergleich zu älteren Trust-Methoden deutlich vereinfacht:

• Keine PKI erforderlich – im Gegensatz zu Certificate Trust
• Keine Synchronisierungsverzögerungen – im Gegensatz zu Key Trust
• Minimaler Konfigurationsaufwand – nur drei Hauptschritte notwendig
• Native Cloud-Integration – nahtlose Integration mit Entra ID und Intune

Mit der Aktivierung von Microsoft Entra Kerberos und der Bereitstellung der entsprechenden Intune-Policy hast du die Grundlage für eine sichere, passwortlose Authentifizierung gelegt, die sowohl Cloud- als auch On-Premises-Ressourcen abdeckt.

In Teil 3 dieser Serie (folgt) werden wir uns mit erweiterten Szenarien und Best Practices beschäftigen, einschließlich Multi-Forest-Umgebungen, Monitoring und Reporting sowie der Migration von bestehenden Trust-Modellen zu Cloud Kerberos Trust.

Hast du Fragen oder Anregungen zu diesem Artikel? Schreib mir gerne in den Kommentaren!

Referenzen und weiterführende Links

Dieser Artikel basiert auf den offiziellen Microsoft Learn Dokumentationen:

• Windows Hello for Business cloud Kerberos trust deployment guide – Offizielle Deployment-Anleitung von Microsoft
• Introduction to Microsoft Entra Kerberos – Technische Details zu Microsoft Entra Kerberos
• Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune – Intune-Konfigurationsanleitung
• Plan a Windows Hello for Business Deployment – Planungsleitfaden für Windows Hello for Business

Der Beitrag Windows Hello for Business SSO – Cloud Kerberos Trust – Part 2 erschien zuerst auf M365 Blog - Julian Stabentheiner.

Deprecation-Warnung für klassische MDM-Updates

Apple hat in einem Video¹ der WWDC 2025 angekündigt, dass die 26er-Versionen von iOS/iPadOS und macOS nicht mehr per MDM-Updaterichtlinien verwaltet werden können. Auch Microsoft weist in einem Artikel² darauf hin. Deshalb ist ein Wechsel auf die hier beschriebenen DDM-Richtlinien zwingend notwendig, wenn man ab Herbst weiterhin Updates für die Geräte mit Intune verwalten will.

Herkömmliche MDM-Updatepolicy

Mit der alten Möglichkeit, dem Updatemanagement über MDM-Richtlinien, ist man sehr beschränkt gewesen. Man konnte nur einen bestimmten Updatezeitraum definieren und welche Version installiert werden soll. Updates konnten bis zu 30 Tage zurückgestellt werden und das war es dann eigentlich schon. Was dabei fehlt: die Flexibilität für den Nutzer.

Vergleich zwischen DDM und klassischem MDM-Updateverfahren

Beim traditionellen Mobile Device Management (MDM) melden sich Geräte regelmäßig beim Management-Server (z. B. Intune), um neue Richtlinien oder Befehle abzurufen. Dieses ständige Abfragen („Polling“) erzeugt eine gewisse Verzögerung und belastet Server sowie Geräte.

Im Gegensatz dazu ermöglicht das moderne Declarative Device Management (DDM) eine deutlich autonomere Steuerung: Geräte erhalten deklarative Richtlinien, die das gewünschte Verhalten klar definieren. Anschließend setzen sie diese selbstständig und unmittelbar um, ohne ständiges Nachfragen beim Server.

In der nachfolgenden Tabelle habe ich die Unterschiede zwischen DDM und MDM Updatemanagement dargestellt.

Feature	DDM Managed Software Update	Herkömmliche MDM-Updatepolicy
Unterstützt iOS/iPadOS	ab 17.0	(ältere Versionen)
Unterstützt macOS	ab 14.0	nur ab macOS 12 mit eingeschränkten Optionen
Spezifisches Targetging (Version/Build)	möglich	überwiegend unflexibel
Deadline Enforcement	erzwingbare Updates	keine zwingende Deadline
Verweis-URL / Info-Links	Details-URL möglich	nicht vorhanden
Sichtbarkeit des Updates kontrollierbar	über integrierte Verzögerungen (Deferrals)	über Einstellungen, aber mit geringer Priorität
Priorität gegenüber anderen Policys	DDM hat Vorrang, blockiert MDM-Policies	je nach Konfiguration, aber weniger deterministisch

Best-Practices für macOS & iOS Updatemanagement via DDM

Die Updaterichtlinien sind weitestgehend gleich bei iOS und macOS, mit ein paar Besonderheiten bei den Deferral-Zeiten. Diese kann bei macOS für Major-, Minor- und System-Updates einzeln gesteuert werden. Das ermöglicht einem, Security-Updates (Minor-Updates) automatisiert deutlich früher für den User freizugeben. Major-Updates sollen z.B. möglichst spät bzw. von der IT-Abteilung gesteuert freigegeben werden. Folgende Wünsche erfüllt mein Best-Practices-Ansatz:

• Automatische Freigabe von Minor-Versionen
  • Minor-Updates (Sicherheitsupdates, Bugfixes, Stabilitätsverbesserungen) werden spätestens 7 Tage nach Veröffentlichung automatisch für Nutzer bereitgestellt.
  • Vorteil: Balance aus Aktualität und Stabilität.
• Zeitverzögerte Freigabe von Major-Versionen
  • Neue Major-Versionen (z. B. iOS 19, macOS 26) werden standardmäßig möglichst spät freigegeben, sofern nicht explizit früher von der IT freigegeben.
  • Vorteil: Umfangreiche Tests und Risikominimierung bei großen Updates und Möglichkeit des Überspringens der x.0-Version.
• Forcierte Installation zu einer definierten Deadline
  • Kritische oder festgelegte Versionen können per DDM zu einer verbindlichen Frist erzwungen werden, um Compliance und Sicherheit zu gewährleisten.
  • Vorteil: Schnellstmögliches Durchpatchen bei sicherheitsrelevanten Updates.
• Flexible Update-Installation durch Nutzer
  • Nutzer erhalten bis zur definierten Deadline maximale Flexibilität, um das Update zu einem günstigen Zeitpunkt selbst zu installieren.
  • Vorteil: Hohe Nutzerakzeptanz und minimale Arbeitsunterbrechungen.
• Pilotgruppen vor breitem Rollout
  • Neue Updates werden zuerst in Pilotgruppen getestet, um mögliche Probleme frühzeitig zu erkennen und zu beheben.

TL;DR Infobox

Für die Ungeduldigen hier kurz und knapp die empfohlene DDM-Konfiguration für produktive Apple-Geräte (ab iOS 17 / macOS 14):

• Minor Updates Deferral: automatische Freigabe nach 7 Tagen
• Major Updates Deferral: verzögerte Freigabe, z. B. 90 Tage
• Zielversion: definiert über „Target OS Version“ (z. B. 15.6)
• Deadline: erzwungene Installation per „Target Date“ (z. B. 05.08.2025, 19:00 Uhr)
• Flexibilität: Nutzer:innen können das Update bis zur Deadline manuell starten
• Rollbacks und Sicherheitsreaktionen (RSR): aktiviert
• Automatic Actions: Alle auf AlwaysOn stellen
• Beta Enrollment: Mit AlwaysOff deaktivieren

Allgemeine Updatesettings

Zunächst erstelle ich eine Settings Catalog Richtlinie für die allgemeinen Updateeinstellungen für alle Clients. Diese dienen dazu, bestimmte Einstellungen fest einzuschalten, damit der User diese auch nicht deaktivieren kann.

• Allow Standard User OS Updates: Allowed
  → Wichtig, sofern die macOS-User keine Adminrechte haben (unbedingt empfohlen!)
• Automatic Actions (AlwaysOn bedeutet, dass der User diese Einstellung nicht deaktivieren kann)
  • Download: AlwaysOn
    → Updates werden automatisch heruntergeladen, sobald sie verfügbar sind.
  • Install OS Updates: AlwaysOn
    → Betriebssystem-Updates werden automatisch installiert, ohne dass der Nutzer aktiv werden muss.
  • Install Security Update: AlwaysOn
    → Sicherheitsupdates werden automatisch installiert
• Program Enrollment: AlwaysOff
  → Die Teilnahme an Beta-Programmen (z. B. iOS Public Beta) ist deaktiviert. Das verhindert instabile Pre-Release-Versionen in der Unternehmensumgebung.
• Rapid Security Response (RSR)
  • Enable: Enabled
    → Schnelle Sicherheitsmaßnahmen (RSR) werden unterstützt. Apple kann so kritische Sicherheitslücken ohne vollständiges OS-Update schließen.
  • Enable Rollback: Enabled
    → Bei Problemen mit RSR-Updates ist ein Rückgängigmachen (Rollback) möglich – erhöht die Betriebssicherheit.
• Notifications: Enabled
  → Nutzer erhalten Benachrichtigungen über verfügbare Updates, Deadlines oder erforderliche Installationen. Wird dieser Punkt auf Disabled gesetzt, erhält der User erst eine Minute vor der Installation eine Benachrichtigung. Kann sinnvoll für unbeaufsichtigte Shared Devices sein.

Achtung bei Assignment Filtern

Bei DDM-Policies werden Assignment-Filter nicht unterstützt. Teilweise funktioniert es zwar trotzdem, aber bei User-Assignments funktioniert es definitiv nicht! Das musste ich nach einigem Troubleshooting selbst feststellen.

Quelle: https://learn.microsoft.com/en-us/intune/intune-service/protect/managed-software-updates-ios-macos#configure-the-automatic-ddm-software-updates-policy

Zusammenspiel der Updatesettings & Ablauf

Ein Punkt hat mich ziemlich viel Arbeit gekostet. Und zwar das Zusammenspiel der Deferrals & Target OS Version herauszufinden. Es ist in den Dokumentationen von Apple und Microsoft nicht genau ersichtlich, wie sich was bedingt. Dazu habe ich zahlreiche Tests durchgeführt, um dies zu erarbeiten. Im Wesentlichen sind die im nachfolgenden Screenshot abgebildeten Settings wichtig. An einem Beispiel möchte ich diese erklären und erstelle dafür eine separate Policy, damit ich diese jeweils für eine Pilot- und Broad-Gruppe separat einstellen kann. Das ist aber Geschmackssache und nicht zwingend so umzusetzen.

Wir gehen von den nachfolgenden Daten aus: Die macOS-Version 15.6 ist am 29.07. erschienen. Am 01.08. werden die Settings Target OS Version (15.6) und Target Date Time (5.8.2025 19:00:00) gesetzt.

Hinweis zur Zeitzone:
Bei klassischen MDM-Updateeinstellungen wurde die Uhrzeit für Installationen stets in einer festen Zeitzone definiert. In Umgebungen mit Clients über mehrere Zeitzonen hinweg führte das dazu, dass mehrere Update-Richtlinien gepflegt werden mussten, um Installationen zuverlässig außerhalb der lokalen Arbeitszeiten auszuführen.

Mit DDM entfällt diese Komplexität: Die konfigurierte Zeit gilt immer in der lokalen Zeitzone des Geräts. Das vereinfacht das Richtlinien-Management erheblich, insbesondere in globalen oder verteilten Organisationen.

Bis zum 1.08. wird dem User in den Updatesettings angezeigt, dass die Version 15.5 die neueste von der IT-Abteilung freigegebene Version ist. Er kann also keine neuere Version als 15.5 installieren. Ab dem Zeitpunkt des Setzens von Target OS Version und Target Date Time passiert Folgendes: Die eingestellte Deferral-Zeit von 7 Tagen für die Minor-Version wird ignoriert und dem User wird das Update 15.6 in den Updatesettings angeboten. Je nach sonstiger Konfiguration wird es auch bereits im Hintergrund heruntergeladen und installiert. Die Benachrichtigungen für den User folgen dem nachfolgenden Schema. Die Benachrichtigungen für den User werden dabei immer häufiger und „penetranter“ um den User vor dem automatischen Neustart zum Update anzuregen. Bei weniger als 14 Tagen erhält der User täglich eine Benachrichtigung. 24 Stunden vor Deadline wird die Meldung selbst bei aktiver „Nicht stören“ Funktion angezeigt.

Eine Stunde vor Erreichen der Target Date Time erhält der User die Information darüber, dass ein Update installiert werden muss. Diese Meldung erscheint erneut 30, 10 und 1 Minute vor Erreichen der Zeit. Dann läuft ein Countdown, der nicht abgebrochen werden kann. Um spätestens 19 Uhr am 5.8. startet das System automatisch neu und installiert das Update selbstständig.

Am nächsten Tag kann die IT-Abteilung die Version in der Compliance-Richtlinie auf 15.6 erhöhen, um ausgeschaltete Geräte ab diesem Zeitpunkt für Conditional Access am Zugriff auf Unternehmensressourcen zu hindern, bis das Update installiert ist. Ein Client, welcher nach Erreichen der Frist gestartet wird, hat von da an genau eine Stunde Zeit, das Update zu installieren, und startet dann ebenfalls automatisch neu.

Was passiert ohne gesetzte Target OS Version und Target Date Time?

Wird die IT-Abteilung nicht aktiv, so wird 7 Tage nach Release der Minor-Version das Update erstmalig dem Client angeboten. Sind automatische Updates konfiguriert, wird das Update ebenfalls automatisch installiert, aber ohne erzwungenen Neustart. Der User wird dann regelmäßig über den nötigen Neustart informiert und muss zum Abschließen des Updates den Client neustarten. Man hat also ein gewisses Fallback implementiert, um Sicherheitsupdates notfalls als Self-Service für den User freizugeben.

Gleiches gilt, wenn vom letzten Update noch alte Werte gesetzt sind, also zum Beispiel Version 15.5 zum 1. Mai um 19 Uhr, gesetzt ist. Das Setting muss also nicht entfernt werden und sollte es auch nicht. Denn neu in Betrieb genommene Geräte werden so innerhalb einer Stunde nach der Installation auf die dort definierte Version hochgezogen.

Was ist mit der Enforce Latest-Einstellung?

Wer sich bereits mit dem Updatemanagement per DDM beschäftigt hat, wird sich nun fragen, wieso man nicht einfach die Enforce Latest Einstellung nutzt? Natürlich ist das auch eine Option, vor allem für kleinere Firmen mit wenigen Geräten und ohne eigene IT-Abteilung. Aber diese Möglichkeit hat für mich (aktuell) einen großen Nachteil: Wird eine neue Major-Version von Apple veröffentlicht, dann wird auch dieses Update nach Erreichen der Delay in Days Einstellung sofort installiert. Nicht selten ist es vorgekommen, dass die x.0-Versionen einige Fehler enthalten haben, und erst ab der x.1-Version das Update empfehlenswert war. Man muss sich also entscheiden, ob man Minor-Updates möglichst schnell, oder Major-Updates möglichst spät installiert haben will.

Aktuell können keine gesonderten Zeiten für Major- & Minor-Versionen eingestellt werden. Deswegen benutze ich dieses Setting nicht, sondern baue auf Interaktion der IT-Abteilung. Sofern Apple bzw. Microsoft dies implementiert und die Target OS Version und Target Date Time dieses Setting überschreibt, wäre es eine echte Alternative zu den Deferrals.

In Summe ergeben sich folgende drei Policys, die im Zusammenspiel einwandfrei funktionieren und mit kleinen Anpassungen auch für iOS genutzt werden können.

Fazit

Mit Declarative Device Management (DDM) via Microsoft Intune lässt sich das Update-Management für iOS 17+ und macOS 14+ deutlich effizienter und skalierbarer gestalten. DDM ermöglicht es, Geräte autonom Updates nach definierten Regeln durchzuführen – von der automatischen Freigabe von Minor‑Updates (z. B. 7 Tage nach Release) über verzögerte Major‑Rollouts (z. B. 90‑Tage Deferral) bis hin zur forcierten Installation zur Deadline.

Der kombinierte Ansatz aus Flexibilität für Endnutzer und Kontrolle für die IT führt zu hoher Akzeptanz und verringerter manueller Steuerung. Meldungen und Statusreports der Geräte geben unmittelbare Transparenz über den Compliance‑Status.

Im Vergleich zum traditionellen MDM‑Updateverfahren bietet DDM deutlich präzisere Steuerung, niedrigere Infrastrukturbelastung, bessere Skalierbarkeit und ein stabileres Nutzererlebnis.

Für Unternehmen mit klaren Sicherheits- und Compliance-Anforderungen ist DDM der empfohlene Standard – DDM-Policies haben Priorität vor älteren MDM-Richtlinien, sodass eine konsistente und konfliktfreie Umsetzung gewährleistet ist.

1. https://developer.apple.com/videos/play/wwdc2025/258/ ︎
2. https://techcommunity.microsoft.com/blog/intunecustomersuccess/support-tip-move-to-declarative-device-management-for-apple-software-updates/4432177 ︎

Der Beitrag macOS & iOS Updates mit Intune per DDM effizient verwalten erschien zuerst auf M365 Blog - Julian Stabentheiner.

Es gibt natürlich auch Compliance-Richtlinien für andere Betriebssysteme, ich beziehe mich hier aber auf die Möglichkeiten unter Windows.

Dieser Artikel ist im Dezember 2024 mit der zu dem Zeitpunkt aktuellen Intune Version erstellt worden.

Wie funktioniert eine Custom Compliance-Richtlinie?

In den Einstellungen einer Compliance-Richtlinie ist dir sicher schon einmal der Punkt Custom Compliance aufgefallen. Genau diesen benötigen wir. Mit der Custom Compliance-Richtlinie haben wir die Möglichkeit, mittels PowerShell-Script alles Mögliche am Client auswerten zu können, um diese Daten für die Bewertung der Gerätecompliance zu verwenden.

Dafür müssen wir zwei Dateien vorbereiten. Einmal eine PowerShell-Datei, die uns die benötigten Daten direkt auf dem Client ausliest und diese dann an Intune liefert. Die zweite Datei ist eine JSON-Datei, die der Compliance-Richtlinie mitteilt, wie die Compliance zu bewerten ist. Konkret möchte ich in diesem Beispiel die BIOS-Version auslesen und unterhalb einer bestimmten Version das Gerät als NICHT compliant markieren.

PowerShell-Script zur Datenerfassung

Das folgende PowerShell-Script ermittelt die Informationen über das Gerät selbst und die BIOS-Version. Auch habe ich ein Beispiel zur Erkennung von installierter Software eingefügt. So kann man das Gerät als nicht compliant taggen, sofern z.B. die Software Steam installiert ist.
Zusätzlich werden die Informationen über den TPM abgefragt, welche ich in diesem Beispiel aber nicht weiter auswerten werde.

$WMI_ComputerSystem = Get-WMIObject -class Win32_ComputerSystem
$WMI_BIOS = Get-WMIObject -class Win32_BIOS 
$TPM = Get-Tpm

#App Detection
$InstalledSoftware = Get-ChildItem "HKLM:\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall"
if ($InstalledSoftware -like "*Steam*") {
    $steam = "Detected"
}
else {
    $steam = "Not Detected"
}

$hash = @{ Manufacturer = $WMI_ComputerSystem.Manufacturer; BiosVersion = $WMI_BIOS.SMBIOSBIOSVersion; TPMChipPresent = $TPM.TPMPresent; Steam = $steam}
return $hash | ConvertTo-Json -Compress

Nach dem Abrufen der Informationen wird ein Hash gebildet, der anschließend ins JSON-Format konvertiert wird, um diese Informationen an Intune zu liefern. Die Daten in der $hash Variable sehen dann wie folgt aus:

PS C:\Windows\system32> $hash

Name                           Value
----                           -----
TPMChipPresent                 True
Steam                          Not Detected
Manufacturer                   Dell Inc.
BiosVersion                    1.17.0

Nach der Konvertierung zu JSON erhalten wir Folgendes:

{"TPMChipPresent":true,"Steam":"Not Detected","Manufacturer":"Dell Inc.","BiosVersion":"1.17.0"}

Anschließend müssen wir das fertige Script im Intune als Compliance Discovery Script hinzufügen. Dies tun wir im Intune admin center unter Home > Endpoint Security > Device Compliance > Scripts > Add > Windows 10 and later

Nachdem wir dem Script einen Namen gegeben haben, können wir den Inhalt der PowerShell-Datei hinzufügen.

Definition der Custom Compliance

Die eigentliche Auswertung der Custom Compliance-Richtlinie wird über ein JSON File definiert. Für dieses Beispiel habe ich folgende Konfiguration erstellt, welche ich nachfolgend erläutern werde:

{
"Rules":[ 
    { 
       "SettingName":"BiosVersion",
       "Operator":"GreaterEquals",
       "DataType":"Version",
       "Operand":"1.19.0",
       "MoreInfoUrl":"https://stabentheiner.de",
       "RemediationStrings":[ 
          { 
             "Language":"en_US",
             "Title":"BIOS Version needs to be upgraded to at least 1.19.0. Value discovered was {ActualValue}.",
             "Description": "BIOS must be updated. Please refer to the link above"
          },
          {
             "Language":"de_DE",
             "Title":"BIOS-Version muss auf mindestens 1.19.0 aktualisiert werden. Der erkannte Wert lautet {ActualValue}.",
             "Description": "BIOS muss aktualisiert werden. Bitte beziehen Sie sich auf den obigen Link"
          }
       ]
    },
    {
       "SettingName":"Manufacturer",
       "Operator":"IsEquals",
       "DataType":"String",
       "Operand":"Dell Inc.",
       "MoreInfoUrl":"https://stabentheiner.de",
       "RemediationStrings":[ 
          { 
             "Language": "en_US",
             "Title": "Only Dell devices are supported.",
             "Description": "You are not currently using a Dell device."
          },
          {
             "Language": "de_DE",
             "Title": "Nur Dell-Geräte werden unterstützt.",
             "Description": "Sie verwenden derzeit kein Dell-Gerät."
          }
       ]
    },
    { 
       "SettingName":"Steam",
       "Operator":"IsEquals",
       "DataType":"String",
       "Operand":"Not Detected",
       "MoreInfoUrl":"https://stabentheiner.de",
       "RemediationStrings":[ 
          { 
             "Language": "en_US",
             "Title": "Unsupported Application Detected",
             "Description": "Steam has been detected on your device. Please uninstall this software to meet the compliance requirements."
          },
          {
            "Language": "de_DE",
            "Title": "Nicht unterstützte Anwendung erkannt",
            "Description": "Steam wurde auf Ihrem Gerät erkannt. Bitte deinstallieren Sie diese Software um die Compliance Anforderungen zu erfüllen."
         }
       ]
    }
 ]
}

Es werden drei Variablen überprüft und dafür wird jeweils eine Regel erstellt. Regeln sind grundsätzlich so aufgebaut, dass zunächst das zu überprüfende Setting per SettingName definiert wird. Für die erste Regel lautet der Wert BiosVersion. Wir erinnern uns: Über das Detection Script wurde eine Variable mit diesem Namen geliefert. Danach habe ich den Operator GreaterEquals gewählt, denn ich möchte nicht nur auf eine genaue Bios Version prüfen, sondern eine Mindestversion voraussetzen. Durch das Setzen des DataType auf Version kann ich so den Operand auf 1.19.0 setzen, und alle BIOS-Versionen, welche mindestens der 1.19.0 entsprechen, würden ein positives Ergebnis zurückmelden. Also auch 1.21.1, jedoch nicht 1.9.0, da diese kleiner ist. Hätte man den DataType auf String gesetzt, ginge das nicht.

Die MoreInfoUrl kann dafür genutzt werden, um dem User eine Information bereitzustellen, wie er z.B. sein BIOS updaten kann, damit da Gerät wieder Compliant ist.

Zuletzt kann über die RemediationStrings eine Information an den User zurückgegeben werden, sofern die Prüfung negativ ausfällt. Man kann zusätzlich mehrere Sprachen definieren, sollte man Betriebssysteme mit unterschiedlichen Sprachen im Unternehmen einsetzen.

Was die zweite und dritte Regel macht, sollte nun selbsterklärend sein.

Anlegen der Custom Compliance-Richtlinie

Jetzt kann die eigentliche Compliance-Richtlinie angelegt werden. Diese erstellen wir unter Devices > Compliance > Create Policy

Wir geben der Policy einen zur gewählten Namensgebung passenden Namen und wechseln in den Konfigurationsblock Custom Compliance.

Dort wählen wir das Discovery Script aus und laden anschließend die eben erstellte JSON-Datei mit den Compliance-Settings hoch.

Abschließend wählen wir noch den Scope aus. Ich habe in diesem Fall All Devices gewählt, aber zusätzlich einen Filter für das Gerätemodell ausgewählt, bei dem ich genau diese Compliance Version prüfen möchte und diesen per Include einbezogen.

Die Actions for noncompliance sind individuell wie bei allen Compliance-Richtlinien zu wählen.

Auswertung der Compliance-Richtlinie

Schauen wir uns nun die Auswertung der Richtlinie an. In diesem Beispiel ist erst einer der Rechner als Compliant markiert. Dieser hat bereits die geforderte Version 1.19.0 installiert. Die Geräte, welche als Not compliant markiert sind, haben noch eine ältere BIOS-Version installiert. Und alle Geräte, welche im Status Not applicable stehen haben, entsprechen nicht dem Filter für die Modellnummer.

Die Version in der JSON-Datei kann so nach jedem BIOS-Release angepasst werden, um die BIOS-Version als Voraussetzung für einen positiven Compliance-Status zu verwenden.

Praxistipps

Eine Compliance-Richtlinie mit verschiedenen Prüfungen in nur einer Policy zu verpacken, wird in der Praxis eher nicht so gut funktionieren. Ich würde die Prüfung auf die BIOS Version in eine eigene Policy packen, um flexibler mit der Zuweisung zu sein und bei einer Änderung an zum Beispiel der App Detection nicht mehrere Policys anpassen zu müssen. Deshalb gilt es immer zu prüfen, welche Punkte in welcher Policy geprüft werden sollen.

Der Beitrag Intune – Custom Compliance-Policy erschien zuerst auf M365 Blog - Julian Stabentheiner.

Jedoch muss es immer mindestens einen Global Administrator Account für den Tenant geben, um über alle Bereiche Kontrolle zu erlangen. Dieser Account wird als Break Glass Account oder auch Emergency Access Account bezeichnet. Es ist im Grunde nur ein Global Administrator Account, der besonders abgesichert bzw. konfiguriert wird. Es kann zusätzlich zum Break Glass Account auch 1-2 Administratoren (Microsoft empfiehlt dies auf maximal vier zu begrenzen) im Unternehmen die Global Administrator Rolle per PIM zugewiesen werden. Der Break Glass Account sollte nie produktiv benutzt werden, denn er ist – wie schon erwähnt – wirklich nur für den absoluten Notfall gedacht.

Wie stellt man jetzt also sicher, dass dieser Account jederzeit einsatzfähig ist und auch in 10+ Jahren noch verfügbar ist? Gehen wir die Accounterstellung mal Step-by-Step durch. Die nachfolgenden Punkte sollten möglichst auch in dieser Reihenfolge durchgeführt werden, um z.B. die Global Administrator Rolle erst nach Absicherung des Accounts zu vergeben.

Erstellung des Break Glass Accounts

Wir erstellen zunächst den eigentlichen Break Glass Account. Diesem generieren wir ein möglichst langes Kennwort über einen Passwortgenerator. Das Passwort kann bis zu 256 Zeichen lang sein und das sollten wir auch nutzen, denn das Passwort wird für den Zugriff später nicht benötigt. Es muss jedoch möglichst lang und komplex sein, um die Sicherheit auf ein Maximum zu erhöhen, denn der Account wird später aus allen Conditional Access Policys ausgeschlossen. Es wäre somit ein Login nur mit Username & Passwort möglich. Je nach Unternehmensgröße und Struktur kann auch ein zweiter Break Glass Account sinnvoll sein.

Zugriff auf den Account

Der Break Glass Account sollte möglichst nur von der höchsten Ebene der Unternehmensführung zugänglich sein (z.B. Geschäftsführer). Da der Account jedoch regelmäßig validiert werden muss, sollte diskutiert werden, ob z.B. zusätzlich der IT-Leiter und sein Vertreter gemeinsam für den Zugriff legitimiert werden. Denn die regelmäßige Prüfung des Accounts bindet Zeit bei diesen Personen. Die Legitimation z.B. beim Notar sollte dann natürlich nur von der Geschäftsführung geändert werden können. Es kann auch überlegt werden, dass der Zugriff für die Personen, die die Validierung durchführen, nur nach Anmeldung der Geschäftsführung mindestens 7 Tage vorher möglich ist. So wäre sichergestellt, dass nur die Geschäftsführnug im Notfall ohne Anmeldung Zugriff zum Account erlangt.

Account absichern und Zugangsdaten sicher aufbewahren

Da wir den Account aus allen Conditional Access Richtlinien ausschließen werden, muss der Zugriff möglichst gut abgesichert sein. Deswegen auch das 256 Zeichen lange Kennwort. Meine Empfehlung ist den Zugriff über einen FIDO2 Hardwareschlüssels sicherzustellen. Dieser Schlüssel wird nach Einrichtung als Authentifizierungsmethode im Break Glass Account im Tresor der Geschäftsführung, einem Bankschließfach, beim Notar oder einem ähnlich sicheren Ort für den Notfall aufbewahrt. Zusammen mit der PIN des Hardwaretokens – welcher ebenfalls an einem anderen sicheren Ort aufbewahrt werden sollte – kann sich so im Notfall Zugriff zum Tenant mit vollen Rechten verschafft werden. Vom Einsatz eines FIDO2 Schlüssel mit Fingerabdrucksensor rate ich dringend ab! Denn was passiert, wenn die Person, dessen Fingerabdruck auf dem Key gespeichert ist, plötzlich verstirbt? Man muss leider auch diesen Fall bedenken.

Meine Empfehlung ist der Token2 T2F2-PIN+/Dual (siehe Bild), da dieser über einen USB-A und USB-C-Anschluss verfügt und die PIN-Komplexität vorab konfiguriert werden kann. Aber auch die Yubikey 5 Serie ist eine gute Wahl.

Ich empfehle, zwei FIDO2 Schlüssel auf den Breaking Glass Account zu registrierten. Einer der Schlüssel wird z.B. im Tresor der Geschäftsführung (Sicherer Ort 1) hinterlegt und der zugehörige PIN in einem versiegelten Umschlag mit Datum und Unterschrift beim Notar oder einem Bankschließfach (Sicherer Ort 2). Der zweite FIDO2 Schlüssel kann dann im Tresor zusammen mit der PIN des ersten Schlüssels hinterlegt werden. Im Tresor kann dann die PIN von Schlüssel 2 zusammen mit dem Schlüssel 1 hinterlegt werden. So ist auch ein Hardwaredefekt redundant abgesichert und es ist stets sichergestellt, dass beide Aufbewahrungsorte für die zugreifende(n) Person(en) zugänglich sein müssen. Denn nur mit dem Schlüssel selbst ist kein Zugriff auf den Account möglich. Sollte der Zugriff für die Validierung des Break Glass Accounts an Angestellte des Unternehmens delegiert sein, ist sichergestellt, dass nur beide Personen zusammen auf den Schlüssel zugreifen können.

Ausschließen aus Conditional Access Richtlinien

Den Break Glass Account wird aus allen Conditional Access Richtlinien ausgeschlossen. Dies hat zwei Gründe:

1. Der Zugriff mit diesem Account soll jederzeit von Überall möglich sein. CA-Richtlinien würden einen uneingeschränkten Zugriff möglicherweise verhindern. Sollte es z.B. Richtlinien geben, die den Zugriff aus bestimmten Ländern generell regulieren, dann könnte der Ausschluss aus dieser Richtlinie diskutiert werden. Denn wieso sollte der Break Glass Account z.B. aus Russland zugreifen können, wenn sonst generell niemand im Unternehmen zugreifen kann? Es muss allerdings der zweite Punkt ebenfalls mit in diese Überlegung einbezogen werden.
2. Der Exclude aus den CA-Richtlinien ist zudem dafür wichtig, dass bei einer Fehlkonfiguration in einer CA-Richtlinie der Break Glass Account noch Zugriff hat. Dies versucht Microsoft zwar auch über deutliche Warnhinweise beim Ändern einer CA-Policy zu verhindern, es ist jedoch nicht zu 100% ausgeschlossen. Es besteht allerdings trotzdem die Möglichkeit, eine CA-Policy mutwillig so anzulegen, dass auch der Break Glass Account keinen Zugriff mehr zum Tenant hat. Denn bei jeder neuen Richtlinie muss der Exclude für den Breaking Glass Account gesetzt werden.

Da gerade dieses Thema sehr komplex sein kann, gehe ich an dieser Stelle nicht tiefer darauf ein.

Registrierung des FIDO2 Schlüssels

Um den FIDO2 Schlüssel im Account hinzuzufügen, müssen wir uns mit dem neu erstellten Account einloggen. Mit den Standardsettings im Tenant wird man nach dem Login mit Passwort dazu aufgefordert, den Microsoft Authenticator zu einzurichten. Um das zu verhindern, erstellen wir für den Account vor dem ersten Login einen TAP (Temprary Access Pass).

Um direkt in die passende Eingabemaske zu gelangen, loggen wir uns in einem Inkognito Tab über folgende URL ein: https://aka.ms/mysecurityinfo
Nach dem Eingeben des Usernamens in der Loginmaske, werden wir jetzt nicht zur Eingabe eines Passwortes aufgefordert, sondern der gerade erstellte TAP wird verlangt. Dies führt dazu, dass wir direkt mit einer starken Authentifizierung im Break Glass Account angemeldet sind und nicht dazu aufgefordert werden, den MS Authenticator einzurichten. Auch wird das gesetzte Passwort nicht benötigt.

Wir folgen den Schritten, um den FIDO2 Schlüssel hinzuzufügen. Es muss die PIN des Schlüssels definiert werden und der Schlüssel muss mehrfach berührt werden. Dies ist eine weitere Sicherheitskomponente der FIDO2 Schlüssel. So kann ein dauerhaft eingesteckter Schlüssel nicht remote missbraucht werden, da physischer Zugriff zum Schlüssel vorhanden sein muss.

Nachdem der Sicherheitsschlüssel hinzugefügt wurde und der TAP wieder gelöscht wurde, sehen die Authentifizierungseinstellungen des Break Glass Accounts in Entra wie folgt aus:

SSPR für Administratorkonten deaktivieren

Zu diesem Thema habe ich bereits einen eigenen Artikel veröffentlicht. Ich möchte an dieser Stelle lediglich auf diesen verweisen. Aus meiner Sicht ist Self-Service-Password-Reset in größeren Umgebungen für Administratorkonten zu deaktivieren, um die Sicherheit weiter zu erhöhen.

Accountzugriff überwachen

Als weitere Sicherheitsmaßnahme konfigurieren wir eine Benachrichtigung an alle Administratoren, welche ausgelöst wird, sobald einer der Break Glass Accounts ein Login Event auslöst. Dies sorgt dafür, dass auch bei Missbrauch des Break Glass Accounts dies nicht unbemerkt passieren kann und die Administratoren hellhörig werden und den Zugriff prüfen. Die Konfiguration ist leider etwas aufwendiger und benötigt einen Log Analytics Workspace. Wie dies konfiguriert wird, ist in folgendem Microsoft Learn Artikel erklärt: https://learn.microsoft.com/en-us/entra/identity/role-based-access-control/security-emergency-access#monitor-sign-in-and-audit-logs

Zuweisen der Global Administrator Rechte

Erst wenn der Account entsprechend gesichert und der Login geprüft wurde, weisen wir dem Account auch die Rolle Global Administrator zu. Der Break Glass Account erhält die Global Administrator Rolle als permanent Assignment und nicht per PIM! Wie die Rolle zugewiesen wird, wird hoffentlich bekannt sein.

Regelmäßige Validierung des Accounts

Wichtig ist natürlich, dass der Account auch jederzeit funktioniert. Da sich immer mal etwas unbemerkt in der Konfiguration ändern kann, muss regelmäßig überprüft werden, ob der Zugriff mit den FIDO2 Schlüsseln auch weiterhin funktioniert. Wenn der Anspruch ist, dass nur die Geschäftsführung Zugriff auf den Break Glass Account hat, ist dies natürlich recht aufwendig und bindet bei der Geschäftsführung entsprechend Zeit.

Folgende Punkte sollten bei einer Validierung durchgeführt werden:

• Vor der Validierung wahlweise das SOC-Team über die Validierung informieren, oder eben nicht .
  Wer das SOC-Team nicht informiert, prüft im gleichen Zuge, ob die Alarmierung zeitnah funktioniert und ob die restlichen Administratoren Alarm schlagen. Wer das nicht möchte, der meldet die Validierung vorab an.
• Der Zugriff auf den Break Glass Account sollte dokumentiert werden, damit auch ein erstmalig hinzugezogener Dienstleister oder neuer Geschäftsführer alle relevanten Informationen vorliegen hat.
• Ein Ablaufplan für die Validierung muss erstellt und mit Protokoll hinterlegt werden.
• Nach dem Zugriff und Test müssen die PINs der FIDO2 Schlüssel geändert werden und vor dem erneuten hinterlegen am sicheren Ort neu versiegelt werden.

Wann sollte die Validierung gemacht werden?

• Alle 90 Tage
• Wenn es maßgebliche Änderungen an der M365 Konfiguration gab (z.B. neue Conditional Access Policys).
• Wenn es neues Personal gibt, welches in den Prozess eingebunden werden soll.
• Wenn die Entra Subscriptions in der Organisation sich geändert haben.

Fazit

Die Absicherung des Break Glass Accounts ist zwar aufwendig, aber zwingend notwendig. Denn der Microsoft 365 Tenant enthält viele wichtige Unternehmensdaten und ein Zugriff auf diesen muss in jedem Fall möglich sein. Sie sollten als Verantwortlicher für Micorosft 365 das Thema wirklich ernst nehmen und zeitnah nach der Einführung (oder spätestens nachdem Sie meinen Artikel gelesen haben ) auf den Weg bringen.

Ich hoffe, ich konnte einen guten Weg für den Notfallzugriff auf Microsoft 365 skizzieren und für das Thema sensibilisieren.

Der Beitrag Best Practices – M365 Break Glass Account erschien zuerst auf M365 Blog - Julian Stabentheiner.

CKT ist die aktuell letzte Ausbaustufe der Single-Sign-On (SSO) Lösungen für Windows Clients.

In diesem ersten Artikel zum Thema Cloud Kerberos Trust möchte ich zunächst die Grundlagen beschreiben und etwas in die Tiefe gehen. Im zweiten Teil geht es dann um die Einrichtung. Im letzten Part des Artikels beschäftige ich mich mit ein paar Problemen und wie man das Troubleshooting am effektivsten gestaltet (Folgt).

Windows Hello for Business? Was ist das überhaupt?

Windows Hello for Business (WHfB) ist eine im Unternehmensumfeld genutzte Technologie, um die Anmeldung an einem Windows Client für den Benutzer möglichst einfach und sicher zu gestalten.

Es gibt einige Gemeinsamkeiten mit dem im Consumer-Bereich genutzten Windows Hello (WH). Diese beschränken sich jedoch überwiegend auf die für den Benutzer sichtbaren Authentifizierungsmethoden.

Hauptmerkmale von Windows Hello (for Business)

Grundsätzlich basieren WHfB sowie WH auf folgende vier Hauptmerkmalen:

1. Biometrische Authentifizierung: Benutzer können sich per Fingerabdruck oder Kamera am Client anmelden.
2. Komfort und Benutzerfreundlichkeit: Die Anmeldung und das Entsperren des Clients ist für den User sehr bequem.
3. Sicherheit: Biometrische Daten werden lokal auf dem Gerät (muss eine TPM-Chip haben) gespeichert und nicht in die Cloud hochgeladen. Passwörter können bei der Anmeldung am Client nicht abgegriffen werden. Sogenanntes Shoulder Surfing (Abgreifen von Informationen durch direktes Zuschauen) wird damit großteils unterbunden, da sich der Benutzer nur biometrisch am Client anmeldet.
4. Integration: Windows Hello ist vollständig in Windows 10/11 integriert und muss nicht gesondert installiert, sondern nur konfiguriert werden.

Skepsis gegenüber Biometrischer Authentifizierung

Häufig begegnet mir die Sorge von Kunden, dass biometrische Daten bei WHfB abgegriffen werden könnten. Diese Angst führt oft dazu, dass weiterhin auf die weniger sichere Anmeldung mittels Benutzername und Passwort gesetzt wird.

Diese Bedenken sind unbegründet, da biometrische Daten bei WHfB verschlüsselt im TPM-Chip des Geräts gespeichert werden, was insgesamt eine höhere Sicherheit bietet. Es bedarf oft zusätzlicher Erklärungen, um diese Vorteile verständlich zu machen und Vorbehalte abzubauen. Sobald jedoch die Funktionsweise und Sicherheitsvorteile von WHfB klar sind, entscheiden sich die meisten Kunden für dessen Einsatz.

Erweiterte Features für Unternehmen

Die oben genannten Funktionen werden durch den Zusatz „for Business“ so ergänzt, dass die speziellen Anforderungen für Unternehmen bedient werden und eine passwortlose Anmeldung am Client ermöglicht wird. Folgende Zusatzfeatures bietet WHfB zusätzlich:

1. Multifaktor-Authentifizierung: Die biometrischen Daten werden durch einen PIN-Code ergänzt, um eine starke Authentifizierung zu gewährleisten. Eine Anmeldung an einem Unternehmensgerät mittels WHfB ist gleichzusetzen mit einer Anmeldung mittels MFA.
2. Zentrale Verwaltung: Alle relevanten Einstellungen für WHfB können zentral über Intune verwaltet werden.
3. Integration ins Unternehmensnetzwerk: WHfB ist so konzipiert, dass es nahtlose Anbindung ans Active Directory und andere Unternehmensressourcen ermöglicht.
4. Schlüsselbasierte Authentifizierung: Anstelle von Passwörtern verwendet WHfB asymmetrische Schlüsselpaare, um die Identität des Benutzers zu bestätigen. Diese Schlüsselpaare werden auf dem TPM-Chip des Rechners gespeichert. Der private Schlüssel verlässt niemals das Gerät und ist einmalig für jedes Gerät erstellt. Das macht WHfB so sicher.

Grundsätzlich kann man sagen, dass Passwörter unsicher sind. Identitätsdiebstahl spielt eine immer größere Rolle und ist gerade im Unternehmensumfeld eine der höchsten Sicherheitsherausforderungen.

WHfB ermöglicht es den Usern sich stets mit einer „starken“ Authentifizierung am Gerät anzumelden, ohne sich der ständigen Gefahr des Passwortdiebstahls auszusetzen. Selbst wenn der PIN gestohlen werden würde, würde dieser nur an diesem Gerät funktionieren und nicht wie das Passwort von überall. In einem solchen Fall kann gezielt nur die Authentifizierungsmethode des gestohlenen Clients deaktiviert werden.

Der Identityprovider (IDP) – hier Microsoft Entra – hat stets einen Teil des öffentliches Schlüssels, der bei der Einrichtung von WHfB zum Useraccount zugeordnet wird. Jeder durch den IDP ausgestellte Token funktioniert somit nur für das Gerät, für den er ausgestellt wurde. Sollte dieser abgefangen werden, ist dieser für den Angreifer nutzlos. WHfB ist dadurch „Phishing Resistent“ im Gegensatz zu einfachen One Time Passwords, die auch (kurzfristig) für andere Anmeldungen genutzt werden können, sofern Benutzername und Passwort ebenfalls bekannt sind.

WHfB ist eine sehr sichere Alternative zu Passwörtern. Es muss allerdings darauf geachtet werden, dass WHfB auch passend konfiguriert wird. Auch muss die Nutzungsrichtlinie den Nutzern vorschreiben, dass biometrische Methoden vorzugsweise genutzt werden. Denn wer immer die PIN benutzt, und vielleicht auch noch auf all seinen Geräten dieselbe PIN verwendet, der macht das Gerät wieder anfällig für „Shoulder Surfing“, wenn gleichzeitig das Gerät entwendet wird (z.B. im Zug). Die PIN sollte zudem nicht nur vier Nummern lang sein. Das kann aber in der WHfB Policy definiert werden.

SSO mit WHfB – Der Trust

Richtig interessant wird WHfB, wenn noch On-premises Ressourcen genutzt werden sollen. Dann stellt sich nämlich die Frage, wie der Client bzw. Benutzer ein Kerberos-Ticket bekommt, um sich z.B. an einem Fileserver, Proxyserver oder Printserver zu authentifizieren.

Unterschiede zu herkömmlicher Kerberos-Authentifizierung

1. Klassische Kerberos Anmeldung: Um an ein Kerberos Ticket zu kommen, muss der Client bei der klassischen Anmeldung seine Benutzername/Passwort-Kombination einem Domaincontroller präsentieren, um von ihm ein Kerberos Ticket ausgestellt zu bekommen. Dieses Token kann nun genutzt werden, um sich an weiteren Diensten im Netzwerk anzumelden.
2. WHfB Anmeldung: Wird der Client allerdings für WHfB konfiguriert ist, dann gibt der User beim Login nicht mehr seine Benutzername/Passwort-Kombination ein, sondern authentifiziert sich per biometrischem Merkmal bzw. als Fallback mit PIN. WHfB erstellt dann ein Schlüsselpaar, dass zur Authentifizierung an Entra genutzt werden kann. Mit diesen Daten kann der Domaincontroller nichts anfangen. Wir benötigen also eine Möglichkeit, an ein Kerberos Ticket zu kommen. Hier kommt der Trust ins Spiel. Mit dem zuvor ausgestellten Schlüsselpaar kann der User über Entra ein Kerberos-Ticket vom Domaincontroller der On-premises Infrastruktur ausgestellt bekommen und sich gleichermaßen an Cloud sowie On-premises Ressourcen anmelden, ohne dass der Benutzer sein Passwort eingeben muss. Details zur Funktionsweise und den unterschiedlichen Trust Typen folgen später.

Vorteile von Windows Hello for Business bei der Nutzung von SSO

Windows Hello for Business bietet erhebliche Vorteile, wenn es um die Integration von Single Sign-On (SSO) in Unternehmensumgebungen geht, die sowohl Cloud-basierte als auch On-Premises Ressourcen nutzen:

1. Gleichzeitige Integration mit Entra ID (Azure ID) und Active Directory: Am Client meldet man sich mit seinem (Hybrid) Entra Account an und bekommt für beide Directorys Authentifizierungsmerkmale ausgestellt.
2. Erhöhte Sicherheit: WHfB entspricht einer Multi-Faktor-Authentifizierung und bietet somit eine zusätzliche Sicherheitsebene für die Ausstellung eines Kerberos-Tickets. Klassisches Kerberos ist durch kompromittierte Passwörter anfällig für Angriffe.
3. Komfort: Es ist keine Zusätzliche Anmeldung an On-premises Diensten mehr nötig und die User können effektiver arbeiten.

Voraussetzungen für den Trust

Um einen Trust einzurichten, benötigen wir synchronisierte Hybrid-Identitäten. Das bedeutet, Entra Accounts, die mittels Entra Connect vom Active Directory Richtung Entra synchronisiert wurden. Dies wird benötigt, damit ein Kerberos-Ticket für den On-Premises AD Account ausgestellt werden kann.

WHfB mit Key Trust – Ein Rückblick

Einige Firmen haben in Vergangenheit bereits die inzwischen durch Cloud Kerberos Trust abgelöste Technologie Key Trust eingesetzt. Bei dieser Technik liegt das größte Problem bei der Ersteinrichtung und dem komplexeren technischen Hintergrund.

Bei der Inbetriebnahme von WHfB finden im Hintergrund einige Tasks statt, von denen der User nichts mitbekommt. Durch den Entra Connect Sync vergeht etwas Zeit, bis sich der Benutzer nach Einrichtung an lokalen Ressourcen anmelden kann. Dies liegt daran, da die im Entra ausgestellten Next Generation Credentials (NGC) erst beim nächsten Sync (dieser läuft im Standard alle 30 Minuten) Richtung Active Directory synchronisiert werden. Das zuständige Attribut heißt msDS-KeyCredentialLink. Solange dies noch nicht gefüllt ist, wird kein Kerberos Ticket auf dem Client landen.

Um den Ablauf aber besser zu verstehen, schauen wir uns nachfolgendes Diagramm an:

Neben Key Trust wurde auch Certificate Trust eingesetzt. Darauf möchte ich aber nicht genauer eingehen. Die Ausführungen zu Key Trust sollen lediglich die Probleme des Systems zeigen, um die Unterschiede zu Cloud Kerberos Trust zu verstehen und sind recht ähnlich beim Certificate Trust vorhanden.

Key Trust Probleme

Es ergeben sich folgende Nachteile des veralteten Key Trust:

• Domänencontroller benötigen spezielle Zertifikate für die Authentifizierung, die verteilt und verwaltet werden müssen.
• Die öffentlichen Schlüssel müssen zwischen Entra ID und Active Directory synchronisiert werden, was zu Verzögerungen führt.
• SSO funktioniert nicht unmittelbar nach dem ersten Login des Users, sondern erst nach dem nächsten Entra Connect Sync (standardmäßig 30 Minuten).

Hinweis: Certificate Trust hat ähnliche Probleme, benötigt aber zusätzlich eine vollständige PKI-Infrastruktur mit Certificate Authority (CA) und Certificate Revocation List (CRL).

Cloud Kerberos Trust – Der Goldstandard

Die vorangegangene Authentifizierungsmethoden haben alle Ihre Nachteile. Das wusste auch Microsoft und hat eine Methode entwickelt, die für den User und Admin möglichst einfach zu konfigurieren ist.

Eine Herausforderung lag darin, die Abhängigkeit von der Synchronisierung der Anmeldeinformationen aufzulösen und die Konfiguration der vielen Komponenten zu vereinfachen.

Entra Kerberos (vormals Azure AD Kerberos)

Entra Kerberos wurde eingeführt, um FIDO2 Authentifizierung an Hybrid Azure AD Joined (HAADJ) zu ermöglichen. Es wird ein Kerberos-Ticket von Entra statt dem On-Premises AD ausgestellt. Somit erhält der Client ein Ticket Granting Ticket (TGT) inklusive Primary Refresh Token (PRT) von Entra.

Daraus resultieren folgende Vorteile:

• Es müssen keine öffentliche Schlüssel mehr zwischen Entra und AD synchronisiert werden. Demnach keine Verzögerung nach der Inbetriebnehme.
• Es muss keine PKI dafür erstellt oder erweitert werden.
• Passwortlose Anmeldung an allen Ressourcen ohne Verzögerungen wird mit wenigen Konfigurationsschritten erstmals möglich.
• Die On-premises DCs werden stark entlastet, da die Ticketausstellung nun von Entra übernommen wird. Das zeigt überwiegend in größeren Firmen einen Effekt, da weniger DCs benötigt werden.

Wir haben also eine Vertrauenskette, die als Kernkomponente Entra (Azure AD) hat. Es wird also kein Kerberos Ticket mehr vom On-premises AD selbst ausgestellt, sondern die On-premises Ressourcen vertrauen jetzt dem Entra Kerberos Ticket.

Vergleich der Trust Typen

Für die bessere Übersichtlichkeit kann man in der nachfolgenden Tabelle die Unterschiede zusammengefasst vergleichen.

Trust Type	Beschreibung
Cloud Kerberos Trust	Benutzer authentifizieren sich bei Active Directory, indem sie ein TGT von Microsoft Entra ID unter Verwendung von Microsoft Entra Kerberos anfordern. Die lokalen Domänencontroller sind nach wie vor für die Kerberos-Diensttickets und die Autorisierung zuständig. Cloud Kerberos Trust nutzt dieselbe Infrastruktur, die für die Anmeldung mit FIDO2-Sicherheitsschlüsseln erforderlich ist, und kann für neue oder bestehende Windows Hello for Business-Bereitstellungen verwendet werden.
Key Trust	Benutzer authentifizieren sich beim lokalen Active Directory mit einem gerätegebundenen Schlüssel (Hardware oder Software), der während der Windows Hello-Bereitstellung erstellt wird. Es ist erforderlich, Zertifikate an Domänencontroller zu verteilen.
Certificate Trust	Der Certificate Trust stellt Authentifizierungszertifikate für Benutzer aus. Benutzer authentifizieren sich mit einem Zertifikat, das mit einem gerätegebundenen Schlüssel (Hardware oder Software) angefordert wurde, der während der Windows Hello-Bereitstellung erstellt wurde.

WHfB Cloud Kerberos Authentifizierungsworkflow

Wollen wir uns nun einmal in der Tiefe ansehen, wie die Authentifizierung im Endausbau funktioniert. Sobald ein User versucht auf eine On-premises Ressource zuzugreifen, läuft folgender Prozess ab:

• Da der User weiterhin ein synchronisierter Hybrid User sein muss, sind die Informationen zur On-premises Domain im Useraccount enthalten. Diese Information wird benötigt, um den Domainnamen für das Anfordern von Tickets vom KDC zu identifizieren.
• Der Prozess startet erst, wenn der User das erste mal versucht auf eine On-premises Ressource zuzugreifen.
• Mit den Metadaten aus dem WHfB Schlüssel kann der Domainname identifiziert werden.
• Über den DCLocator Service kann nun der nächstgelegene Domaincontroller mit KDC Dienst identifiziert werden.
• Mit dem von Entra erstellten partiellen TGT wendet sich der Client nun an den Domain Controller.
• Dieses partielle TGT ist von Entra signiert und enthält die SID des Users.
• Der Domain Controller verfiziert nun, ob das partielle TGT valide ist.
• Ist die Prüfung erfolgreich, wird vom Domain Controller ein vollwertiges TGT für den User ausgestellt und dieser kann sich damit an anderen On-premises Diensten anmelden.

Zusammengefasst erstellt Entra ein partielles TGT für den User. Dieses kann nun an einem KDC gegen ein vollwertiges TGT eingetauscht werden mit dem dann Service Tickets an den einzelnen Diensten ausgestellt werden können.

Zusammenfassung

Wir haben gelernt, was Windows Hello for Business vom Consumer Produkt Windows Hello unterscheidet und wie es im Detail funktioniert. Zusätzlich wurde die genaue Funktionsweise von WHfB erklärt und die Evolution der verschiedenen Trust Typen aufgezeigt.

Im zweiten Teil dieser Serie beschäftige ich mich genauer mit der Einrichtung und Konfiguration von WHfB Cloud Kerberos Trust.

Referenzen und weiterführende Links

Dieser Artikel basiert auf den offiziellen Microsoft Learn Dokumentationen und Praxiserfahrungen:

• Plan a Windows Hello for Business Deployment – Planungsleitfaden und Übersicht der Trust-Typen
• Windows Hello for Business cloud Kerberos trust deployment guide – Offizielle Deployment-Anleitung
• Introduction to Microsoft Entra Kerberos – Technische Details zu Microsoft Entra Kerberos
• Windows Hello for Business Overview – Allgemeine Übersicht und Features

Der Beitrag Windows Hello for Business SSO – Cloud Kerberos Trust – Part 1 erschien zuerst auf M365 Blog - Julian Stabentheiner.

Eine gut funktionierende Namensauflösung bei den Microsoft 365 Diensten ist unumgänglich für einen reibungslosen Betrieb der Microsoft Dienste. In diesem Artikel erkläre ich anhand von ein paar Beispielen, worauf speziell zu achten ist.

Normalerweise möchte man sich bei der Nutzung von Cloud Diensten keine Gedanken um das Thema Netzwerk machen. Man kauft ja schließlich fertige Dienste ein, bei denen der Anbieter schon dafür sorgt, dass Netzwerkseitig alles passt. Oft braucht man das auch nicht, da in kleineren Firmen das Netzwerk nicht sehr komplex ist und es keine Besonderheiten gibt, die einem Probleme machen können. Es gibt aber Firmennetzwerke, die einen ausführlichen Blick auf das Thema Netzwerk benötigen. Ein aktuelles Projekt brachte mich dazu, das Thema Netzwerk sehr viel genauer zu betrachten, als es in Vergangenheit nötig war. Meine Erfahrungen daraus möchte ich in diesem Artikel vertiefen.

DNS-Auflösung

Um ein Ziel im „Internet“ zu erreichen, muss der Client zunächst wissen, welchen Server er ansprechen muss. Die Hostnamen der Microsoft 365 Dienste müssen deshalb über einen DNS-Server auf die entsprechende IP-Adresse übersetzt werden. Bei einfachen Webseiten gibt es normalerweise keine Besonderheiten. Zu meinem Blog gibt es genau eine IP-Adresse des entsprechenden Webservers. Alle Anfragen, egal von wo aus der Welt diese kommen, werden zum selben Webserver mit derselben IP-Adresse geschickt.

In größeren Cloud-Konstrukten ist dies aber anders. Auf jedem Kontinent stehen mehrere Rechenzentren von Microsoft, welche die Services für Kunden bereithalten. Die Verbindung zum Exchange Online Mailserver läuft aber immer über den Hostnamen outlook.office.com.

Jetzt muss per Geo-DNS der am besten zu erreichende Server dem Client zurückgemeldet werden. Was dabei eine nicht optimale DNS-Abfrage für Folgen haben kann, möchte ich anhand von zwei Beispielen erläutern.

Der Optimalfall

Gehen wir zunächst von einem für Cloud Dienste optimalen Fall aus. Wir denken an eine kleine Firma mit vielleicht 30-50 Mitarbeitern und einem einzelnen Büro. Das Büro hat ein VLAN und einen Internetzugang. Alle Clients erhalten per DHCP vom Router ihre IP-Konfiguration und so werden alle DNS-Abfragen über den DNS-Server des Internetproviders abgehandelt. Die Mitarbeiter im Homeoffice benötigen kein VPN, da bereits alle Dienste über Microsoft 365 genutzt werden. Es gibt nur eine einfache Firewall, und der ausgehende Internetzugang ist nicht reglementiert. Der Begriff Proxyserver wurde bislang von niemandem im Unternehmen in den Mund genommen.

Wie verhalten sich nun die Cloud Dienste?

Hier wird es vermutlich keine Probleme geben. Da die Clients über den DNS-Server des Internetproviders die Hostnamen der entsprechenden Microsoft 365 Endpunkte auflösen, werden die naheliegendsten IP-Adressen vom Microsoft Rechenzentrum aufgelöst. Im Optimalfall gibt es vom Internetprovider direkt ein Peering zum Microsoft Global Network (MGN), sodass die Datenpakete nicht mehr über ein öffentliches Peering laufen, sondern direkt zu Microsoft geroutet werden. Dies spart Hops und sorgt für geringe Latenzen. Hier ein Beispiel von meinem Internetanschluss aus:

In diesem Tracert sieht man gut, dass outlook.office.com auf eine IP-Adresse in Frankfurt am Main aufgelöst wird. Hop 3-6 sind IP-Adressen meines Internetproviders (Vodafone). Ab Hop 7 gehen die Anfragen in Düsseldorf ins MGN und von dort aus über eigene Glasfaserstrecken von Microsoft ins Microsoft RZ in Frankfurt am Main.
Mein Provider hat demnach ein direktes Peering zu Microsoft. Viel kürzer können an einem privaten Internetanschluss die Datenpakete nicht bei Microsoft landen. Insgesamt 13ms vergehen, bis die Datenpakete am zuständigen Server angekommen sind.

Unternehmen mit mehreren globalen Standorten

Aber wo kann es jetzt Probleme geben? Denken wir nun an ein global agierendes Unternehmen. Der Firmensitz und somit auch die IT-Verantwortlichen sind in Australien beheimatet. Es gibt jedoch ein Büro in Düsseldorf. Da auch viele interne Server per VPN angesprochen werden müssen, wird der DNS-Server der VPN Appliance genutzt. Das VPN ist als Split-Tunnel konfiguriert. Es werden also nur die Anfragen an interne (per VPN erreichbare) Ressourcen durch den VPN-Tunnel geroutet. Die DNS Auflösung geht aber in jedem Fall an den DNS-Server am Firmenhauptsitz in Australien, damit die internen Hostnamen der über VPN erreichbaren Server aufgelöst werden können. Was soll da schon schiefgehen?

Nunja, das sieht man recht schnell mit einem erneuten Tracert auf die Adresse, die vom DNS-Server in Australien zurückgegeben wird. Der Name lässt es bereits vermuten, der Microsoft Server befindet sich in Sydney.

Im Vergleich zum ersten Beispiel sieht man schnell, dass die Datenpakete deutlich länger unterwegs sind. Zwar landen diese vom gleichen Internetanschluss auch ab Hop 7 im MGN, brauchen dann aber ca. 250ms länger, bis der Zielserver in Sydney erreicht wird. Der Weg bis nach Sydney ist halt doch etwas länger… Zwischen Hop 8 und 9 liegt vermutlich ein Seekabel zwischen Europa und Australien.

Öffentliche DNS-Server

Viele Netzwerkadministratoren setzen gerne DNS-Server wie z.B. 8.8.8.8, 9.9.9.9 oder 1.1.1.1 ein. Diese DNS-Server sind zwar sehr performant, können aber die Namensauflösung stören, wenn es um das Finden des am schnellsten zu erreichenden Servers über das MGN geht. Der DNS-Server des Internetproviders ist stets vorzuziehen.

Hier habe ich zwei DNS-Abfragen gemacht. Zunächst über die quad9 DNS-Server, und danach über den DNS-Server meines Routers, der an den DNS-Server meines Internetanbieters weiterleitet. Man sieht schön, wie unterschiedlich die DNS-Antworten sind. Die erste Antwort kommt von einem Microsoft DNS-Server aus Amsterdam, die zweite von einem Microsoft DNS-Server aus Hessen (Frankfurt).

Lessons Learned

Was lernen wir daraus? Jede Dependance eines Unternehmens sollte stets die DNS-Auflösung des lokalen Internetanbieters bzw. Internet Breakouts nutzen, um die Pakete auch zum richtigen (besten) Zielserver zu senden. Firmen, die interne WANs nutzen, müssen spätestens mit Einführung von Cloud-Diensten umdenken. Microsoft hat schließlich nicht umsonst mehrere Rechenzentren weltweit in Betrieb. Diesen Vorteil sollte man auch nutzen und nicht durch falsche DNS-Abfragen zunichtemachen.

Der Beitrag Microsoft 365 und das Netzwerk – Part 1: DNS erschien zuerst auf M365 Blog - Julian Stabentheiner.

Compliance Policys in Microsoft 365 Intune sind ein wichtiges Mittel, um die Sicherheit im Unternehmen zu gewährleisten. Durch Festlegen einiger Parameter wird sichergestellt, dass ein Gerät auch den Anforderungen des Unternehmens entspricht. Die Festplatte muss verschlüsselt sein, Defender soll aktiviert sein, eine bestimmte OS-Version wird erfordert, etc.
Die eigentliche Magie passiert aber erst, wenn Compliance Policys in Verbindung mit Conditional Access genutzt werden. Denn dann kann aktiv einem Gerät, welches nicht compliant ist, der Zugang zu bestimmten Unternehmensressourcen untersagt werden, bis das Gerät wieder den Anforderungen des Unternehmens entspricht.

Aber was macht eine Compliance Policy eigentlich?

Immer wieder stelle ich fest, dass einige Administratoren gar nicht genau wissen, was die Compliance Policy macht. Es wird oft davon ausgegangen, dass die Einstellungen in der Richtlinie geprüft werden, und wenn z.B. das Passwort nicht den Parametern aus der Compliance Richtlinie entspricht, ein Gerät als nicht compliant markiert wird. Das stimmt aber nur bedingt. Denn die Compliance Policy nimmt auch aktiv Einfluss auf die Einstellungen am Client. Wenn in der Policy z.B. Bitlocker als Required definiert wird, dann wird nicht nur geprüft, ob Bitlocker aktiviert ist, sondern es wird aktiv Bitlocker auch am Client eingeschaltet. Auch wird beim Setzen der Minimallänge des Passwortes über die Compliance Richtlinie dieses nicht geprüft, sondern es wird beim Setzen eines Passwortes dafür gesorgt, dass ein Passwort, welches nicht der Richtlinie entspricht, auch nicht gesetzt werden kann.

Besonders wichtig wird dies dann, wenn an anderer Stelle über Configuration Policys dieselben Einstellungen gesetzt werden. Denn dann hat stets die Einstellung der Compliance Policy Vorrang! Werden mehrere Compliance Policys mit demselben Setting auf ein Gerät angewandt, dann wird die restriktivste Einstellung angewandt. ¹

Dies fällt oft erst auf, wenn beispielsweise auf bestimmten Clients Bitlocker deaktiviert werden soll, und dies nicht funktioniert, weil die Compliance Policy nicht angepasst wurde. Dies ist zum Beispiel bei Windows 365 / VDI der Fall. Ein Exclude aus der entsprechenden Bitlocker Policy reicht dann nicht aus. Es muss zusätzlich dafür gesorgt werden, dass diese Clients auch eine eigene Compliance Policy erhalten, in der Bitlocker als not configured gesetzt wird. Erst dann kann durch eine Configuration Policy Bitlocker auch aktiv ausgeschaltet werden.

Wem dieser Umstand bewusst ist, der tut sich beim Troubleshooting deutlich leichter und bedenkt dies schon beim Design der Richtlinien. Es macht also durchaus Sinn, die Settings der Compliance Policy gut zu kennen.

1. https://learn.microsoft.com/en-us/mem/intune/configuration/device-profile-troubleshoot#compliance-and-device-configuration-policies-that-conflict ︎

Der Beitrag Intune Compliance Policy – Nur Auswertung? erschien zuerst auf M365 Blog - Julian Stabentheiner.

Das Problem

Ein Kennwort für alle Clients (z.B. über das Aufspielen eines Masterimages) stellt ein erhebliches Sicherheitsrisiko dar. Es kennen zu viele Personen und es muss ein Prozess zum regelmäßigem Ändern existieren. Für jeden Client von Hand ein eigenes Administratorkennwort festzulegen, erfordert einen (zu) hohen Verwaltungsaufwand.

Die Lösung

Dieses Problem löst die Local Administrator Passwort Solution (LAPS). LAPS existiert schon seit 2015 in der On-Prem Welt. Damit kann über Gruppenrichtlinien Objekte (GPO) der lokale Administrator Account auf Windows Geräten in der Active Directory Domäne gesteuert werden. Es wird aber nicht einfach nur ein „Masterpasswort“ auf alle Clients verteilt, sondern für jeden Client ein nur für diesen generiertes Passwort. Dieses Passwort wird anschließend vom Client in das AD Objekt des Clients geschrieben und kann dort verwaltet und von privilegierten Accounts eingesehen werden. Dazu musste bis April 2023 LAPS noch auf den Clients installiert werden und der Implementationsaufwand war dadurch recht hoch. Inzwischen ist LAPS Bestandteil vom Betriebssystem. Die Passwörter werden seit dem verschlüsselt im AD (bzw. Entra) abgelegt.

Auch die Installation im Active Directory bestand aus einigen ToDo’s. Es mussten Schemaerweiterungen gemacht werden und Snap-Ins auf den Maschinen installiert werden, von denen auf die Attribute zugegriffen werden sollte.

Seit einigen Monaten steht LAPS für Intune bzw. Entra ID Only und Hybrid Clients zur Verfügung. Wie LAPS für Intune einzurichten ist und was es für Möglichkeiten gibt, zeige ich dir hier. Spoiler: Es ist deutlich einfacher geworden.

LAPS im M365 Tenant aktivieren

Um LAPS überhaupt nutzen zu können, muss es zunächst im Tenant aktiviert werden. Dies erfolgt im Entra ID (Azure AD) Admincenter (https://entra.microsoft.com/) unter Devices > Overview > Device settings > Enable Microsoft Entra Local Administrator Password Solution (LAPS). Das setzen dieser Einstellung auf Yes führt dazu, dass alle nötigen Einstellungen im Entra gesetzt werden. Im AD LAPS mussten dafür noch einige Powershell-Scripte ausgeführt werden.

LAPS Richtlinie in Intune erstellen

Als nächsten Schritt müssen wir die Richtlinie erstellen, die LAPS auf dem Client konfiguriert. Dies erfolgt im Intune Admin Center (https://intune.microsoft.com/) über Endpoint security > Account Protection > Create Policy

Hier werden die relevanten Einstellungen für LAPS getätigt.

Backup Directory sollte auf Azure AD only gestellt werden.
Password Age Days definiert, in welchem Zyklus das lokale Passwort neu gesetzt werden soll. 30 Tage entspricht dabei dem Standardwert.
Administrator Account Name ist eine optionale Einstellung, mit der der Accountname des Administrator Accounts definiert werden kann.

ACHTUNG: Wird hier ein anderer Accountname festgelegt, so muss dieser separat erstellt bzw. der Build-In Administrator umbenannt werden. Diese Einstellung alleine erstellt keinen Account bzw. aktiviert auch nicht den bereits vorhandenen lokalen Administrator auf dem Client. Wie das gemacht wird, folgt gleich.

Password Complexity definiert, aus welchen Zeichen das generierte Passwort bestehen darf. Aus Sicherheitsgründen ist es ratsam, hier die möglichst höchste Stufe zu wählen.
Password Length definiert die Länge des Passwortes.
Post Authentication Actions definiert, wie verfahren wird, wenn das Kennwort genutzt wird. Ich habe hier die Standardeinstellung gewählt. Damit wird das Passwort nach der über Post Authentication Reset Delay Zeit von hier 24 Stunden neu gesetzt. Mit der Standardeinstellung wird das Kennwort anhand der definierten Regeln neu gesetzt und der Account ausgeloggt, sofern er noch am Rechner eingeloggt ist. Man hat hier also bis zu 24 Stunden Zeit, um mit dem LAPS Admin Account die nötigen Tasks zu erledigen. 24 Stunden sind die Standardzeit der Policy, falls die Einstellung nicht explizit geändert wird. Ich würde hier zu 8 Stunden raten, damit nach dem Arbeitstag das Kennwort neu gesetzt wird.

Als letzten Schritt müssen der Policy noch Clients zugewiesen werden. Grundsätzlich spricht nichts dagegen, hier All Devices zu wählen. Dies muss aber nach eigenen Anforderungen entschieden werden.

Administrator Account aktivieren

Im Standard ist der lokale Build-In Administrator deaktiviert und muss über eine zweite Richtlinie aktiviert werden. In diesem Schritt kann man auch den Administrator umbenennen. Dies bietet ein kleines bisschen zusätzliche Sicherheit. Wir erstellen eine neue Configuration Policy für Windows mit dem Typ Settings catalog.

Über den Settings picker unter Local Policies Security Options suchen wir die beiden Settings Accounts Enable Administrator Account Status und Accounts Rename Administrator Account raus und setzen die Einstellungen wie folgt:

Wie bereits erwähnt, ist das Umbenennen des Administratoraccounts optional und nicht zwingend nötig. Sollte jedoch der Administrator Account nicht aktiviert werden, kann LAPS auf dem Client nicht arbeiten. Dies bekommt man über den Event Viewer mit einer ziemlich eindeutigen Fehlermeldung quittiert.

Hat man in der zweiten Policy den Administrator Account nicht umbenannt, erhält man den Fehlercode 0x80070002, weil LAPS den konfigurierten Administratoraccount nicht finden kann.

Abrufen des Kennwortes über Entra und Intune

Sofern aber alles richtig konfiguriert ist, setzt der Client das Kennwort und pusht es Richtung Entra (Azure AD). Dort gibt mehrere Möglichkeiten, das Kennwort abzurufen.

Entra admin center

Im Entra admin center erhält man Zugriff auf alle gespeicherten LAPS Kennwörter. Auch der dazugehörige Accountname ist aufgeführt. Das Support-Team muss den pro Kunde individuell konfigurierten Accountnamen des Administrators nicht wissen. Auch wird hier die letzte und nächste Passwortrotation angezeigt. Neu setzen lassen kann man das Kennwort an dieser Stelle jedoch nicht.

Intune admin center

Im Intune admin center erhält man über das Device selbst über den Punkt Monitor > Local admin password Zugriff auf das Kennwort.

Rotation des Kennwortes über Intune

Wurde das Kennwort genutzt oder vielleicht sogar dem Anwender mitgeteilt, kann ein vorzeitiges Ändern des Kennwortes über Intune ausgelöst werden.

Nach der Bestätigung des nachfolgenden Dialogs wird der Client mit dem vorzeitigen Ändern des Passwortes beauftragt. Die Änderung erfolgt allerdings nicht direkt, sondern erst nach einem Neustart des Gerätes.

Ausblick

Das Thema LAPS steht bei Microsoft nicht still. Ab dem Windows 11 Insider Preview Build 26040 besteht die Möglichkeit, weitere Einstellungen zu setzen. Diese können aktuell allerdings nur über CSP-Settings per OMA-URI auf den Clients per Intune gesetzt werden.

Konkret wird vor allem das Thema Eingabe der Passwörter angegangen. Bei Kennwörtern ist oft das Problem, dass Zeichen wie 0 und O gerne vertauscht werden. Das führt vor allem dann zu Problemen bei der Eingabe, wenn das Kennwort nicht per Copy/Paste in einer Remotesitzung auf den Client kopiert werden kann und abgeschrieben bzw. jemandem durchgegeben werden muss.

Lesbarkeit von Passwörtern

Es kommt künftig eine fünfte Option für die PasswortComplexity dazu, bei der verwechselbare Zeichen für die Passwortvorgabe ausgeschlossen werden. Hier ein Auszug aus dem Microsoft Artikel dazu.

Wortlisten für Passphrasen

Um die Passworteingabe noch weiter zu erleichtern, können künftig auch Passphrasen als Kennwörter genutzt werden. Diese sind bei entsprechender Länger ähnlich sicher, aber deutlich schneller einzugeben. Ein Passwort für das Administratorkonto könnte dann z.B. so aussehen

SkiingProduceIdentifyStarlitOctaneDistress

Dass diese Settings ohne OMA-URI konfiguriert werden können, wird mit Verfügbarkeit im Windows 11 Current Branch soweit sein.

Automatic Account Management

Eine weitere neue Funktion ist das Automatische Account Management (Automatic Account Management). Damit wird der Administratoraccount mit einem Prefix und einer zufälligen Nummer generiert um die Sicherheit weiter zu erhöhen. Auch diese Funktion ist bereits im aktuellen Insider Build enthalten.

Fazit

Ob LAPS zum Einsatz kommt, muss individuell entschieden werden. Es bietet im Vergleich zur Entra Joined Device Local Administrator Rolle (Zuweisung über PIM vorausgesetzt) den Vorteil der sofortigen Verfügbarkeit der erhöhten Rechte und kann im Ernstfall auch offline genutzt werden. Eine dieser Varianten sollte allerdings in jedem Fall genutzt werden. Es gibt meiner Meinung nach keine Ausreden dafür. Teilweise kommen auch per Intune noch eigens gebaute PowerShell-Scripte zum Einsatz, die auf allen Clients ein „Masterkennwort“ auf den Clients setzen.

1. PIM: Microsoft Entra Privileged Identity Management ︎

Der Beitrag Einrichtung von LAPS mit Microsoft Intune erschien zuerst auf M365 Blog - Julian Stabentheiner.