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.

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.

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.

Bei Administratoren sieht die Sache aus meiner Sicher aber anders aus. Aber sehen wir uns erst einmal an, wie es im Standard konfiguriert ist.

In den Password Reset Settings im Microsoft Entra admin Center existiert der separate Punkt Administrator Policy. Wer sich schon einmal dahin verirrt hat, merkt schnell das dort nichts eingestellt werden kann und nimmt dies wohl einfach so hin.

SSPR ist also für Administratoren stets aktiviert. Dafür muss die SSPR (für User) nicht aktiviert werden. In den eigentlichen Einstellungen ist dazu auch ein Hinweis zu sehen.

Aber warum ist dies so und wie ist dies zu bewerten? Wenn man sich einen M365 Tenant für kleine Firmen ansieht, ist oft ein einziger Administrator für die M365 Instanz verantwortlich. Da dies in der Praxis „nebenbei“ gemacht wird und kaum jemand Zeit hat, alle M365 Security Guidelines umzusetzen, muss sichergestellt sein, dass ein Administrator sich auch bei vergessenem Passwort zeitnah wieder einloggen kann. Ohne SSPR wäre dann erst die Eröffnung eines Support-Tickets bei Microsoft nötig, um wieder Zugriff zum Tenant zu erlangen. Das SSPR also im Standard für Administratoren aktiviert ist, hilft also vor allem bei kleineren Umgebungen, senkt aber die Sicherheit.

In größeren Umgebungen liegt der Fokus aber häufig auf bestmöglicher Sicherheit. Denn auch wenn Administrator Konten in den Regel durch MFA und PIM geschützt sind, besteht ein Restrisiko, dass SSPR missbraucht wird um an ein Kennwort eines Administrator Accounts zu gelangen. In größeren Umgebungen sind zudem in der Regel mehrere Administratoren vorhanden, die sich gegenseitig kennen und bei Bedarf das Kennwort gemeinsam (bei physischer Anwesenheit beider Administratoren) neu setzen können.

Empfehlung zum Umgang mit der SSPR Administrator Policy

Meine Empfehlung lautet deshalb: In allen M365 Enterprise Umgebungen wird SSPR für Administratoren deaktiviert. Eine Passwortrücksetzung für Administratoren wird über einen anderen Prozess durchgeführt. Face-to-Face oder über ein Change mit Freigabe über einen Vorgesetzten.

Aber wie wird die Admin SSPR Policy deaktiviert? Es gibt im Entra admin center wie oben beschrieben ja keine Einstellmöglichkeiten. Die Antwort lautet wie so oft: Powershell bzw. Microsoft Graph

Ich nutze dafür das MS-Graph Powershell Modul. Wichtig ist beim Connect, den entsprechenden Scope mitzugeben, damit man auch die passenden Rechte hat um die Einstellung zu ändern. Bei der TenantId muss natürlich die entsprechende ID des Zieltenants eingegeben werden.

PS C:\Users\stabidev> Connect-MgGraph -TenantId e67cf366-027a-4191-b076-xxxxxxxxxx -Scopes "Policy.ReadWrite.Authorization"
Welcome to Microsoft Graph!

Connected via delegated access using 14d82eec-204b-4c2f-b7e8-296a70dab67e
PS C:\Users\stabidev> Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false

Ein eigentliche Befehl zur Deaktivierung der Policy lautet:

Update-MgPolicyAuthorizationPolicy -AllowedToUseSspr:$false

Microsoft hat sich bei der Wahl des Namens für den Flag leider nicht sehr viele Gedanken gemacht. AllowedToUseSspr suggeriert mir, dass man damit SSPR generell steuert. AdminAllowedToUseSspr oder AllowAdminSspr wären dafür wohl passender gewesen.

Nach erfolgreicher Umstellung kann man das Setting dann noch per Powershell prüfen.

PS C:\Users\stabidev> Get-MgPolicyAuthorizationPolicy | fl

AllowEmailVerifiedUsersToJoinOrganization : False
AllowInvitesFrom                          : everyone
AllowUserConsentForRiskyApps              :
AllowedToSignUpEmailBasedSubscriptions    : True
AllowedToUseSspr                          : False
BlockMsolPowerShell                       : False
[...]

Auch im Entra admin center wird die Einstellung nun als deaktiviert angezeigt.

Fazit

Die SSPR Administrator Policy ist schnell angepasst und erhöht die Sicherheit im M365 Tenant ein gutes Stück. In kleineren Umgebungen sollte man damit allerdings vorsichtig sein, damit sich bei einem vergessenen Passwort stets Zugriff ohne Microsoft Support auf den Tenant verschafft werden kann.

Der Beitrag Self-Service Password Reset (SSPR) für Administratoren deaktivieren erschien zuerst auf M365 Blog - Julian Stabentheiner.