Kennen Sie dieses Szenario? Ihr Unternehmen hat den Schritt in die Cloud-Ära gewagt. Geräte sind direkt mit Azure AD verbunden, werden elegant über Microsoft Intune verwaltet, und die IT-Abteilung genießt die Vorteile der modernen Geräteverwaltung. Doch plötzlich taucht ein unerwartetes Problem auf: Ein lokales Benutzerkonto – vielleicht für eine spezielle Anwendung, einen Dienst oder als Break-Glass-Admin-Zugang – meldet, dass sein Kennwort abgelaufen ist. Verwirrung macht sich breit. Wie kann ein lokales Konto, das doch angeblich „unabhängig“ ist, von Cloud-Richtlinien betroffen sein? Diese Frage hören wir oft. Die gute Nachricht ist: Das Problem ist lösbar, und wir zeigen Ihnen, wie.
Die Transformation zur Cloud-First-Strategie bringt viele Vorteile, aber auch neue Herausforderungen und Lernkurven mit sich. Traditionelle IT-Denkweisen müssen angepasst werden, besonders wenn es um die Interaktion zwischen alten Strukturen (wie lokalen Konten) und neuen Verwaltungsparadigmen (wie Intune und Azure AD) geht.
Die neue Welt: Intune, Azure AD und lokale Konten
Bevor wir uns der Lösung widmen, ist es wichtig, das Setup zu verstehen. Ein Azure AD joined Device ist ein Gerät, das direkt mit dem Azure Active Directory Ihres Unternehmens verbunden ist, ohne eine lokale Active Directory-Domäne. Dies vereinfacht die Authentifizierung und ermöglicht Benutzern, sich mit ihren Cloud-Anmeldeinformationen anzumelden. Microsoft Intune ist die Plattform für die einheitliche Endpunktverwaltung, die es Ihnen ermöglicht, Sicherheitsrichtlinien, Anwendungen und Konfigurationen auf diesen Geräten bereitzustellen und zu verwalten. Im Wesentlichen ist Intune der moderne Nachfolger der Gruppenrichtlinien (GPOs) für die Cloud-Welt.
In dieser modernen Landschaft spielen lokale Konten eine zunehmend kleinere Rolle. Idealerweise sollten alle Benutzerkonten zentral in Azure AD verwaltet werden. Dennoch gibt es berechtigte Gründe für die Existenz lokaler Konten: Sie könnten für Legacy-Anwendungen benötigt werden, die keine Azure AD-Authentifizierung unterstützen, als lokale Service-Konten für bestimmte Dienste, oder eben als „Break-Glass”-Administrator, falls die Cloud-Anmeldung einmal nicht funktioniert. Das Problem entsteht, wenn die Erwartung besteht, dass diese lokalen Konten völlig unabhängig von den Intune-Richtlinien sind – eine Annahme, die sich oft als falsch erweist.
Das unerwartete Problem: Lokale Kennwörter laufen ab
Das typische Symptom ist eine Fehlermeldung auf dem Bildschirm, dass das Kennwort des lokalen Kontos abgelaufen ist. Der Benutzer (oder der Administrator, der das Konto verwendet) versucht sich anzumelden und scheitert. Die Verwirrung ist groß: „Ich habe dieses Konto doch nie mit einer Kennwortrichtlinie verknüpft! Es ist ein lokales Konto!” Diese Irritation ist verständlich, denn standardmäßig haben lokale Windows-Konten keine Kennwortablaufrichtlinie oder eine sehr lange (z.B. 42 Tage, was auf eine Standardeinstellung hindeutet, die überschrieben wurde). Die Tatsache, dass das Kennwort abläuft, deutet darauf hin, dass eine übergeordnete Richtlinie greift und diese Einstellung auf das lokale System erzwingt.
Dieses Phänomen kann zu echtem Ärger führen. Ein Dienst fällt aus, weil sein Service-Konto plötzlich gesperrt ist. Ein Administrator kann sich im Notfall nicht anmelden, weil das „Break-Glass”-Konto ein neues Kennwort benötigt, das niemand parat hat. Es ist ein klassisches Beispiel dafür, wie scheinbar isolierte Elemente in einer komplexen IT-Umgebung doch miteinander verbunden sein können.
Die Wurzel des Übels: Intune Richtlinien greifen weiter als erwartet
Der Schlüssel zur Lösung liegt im Verständnis, wie Intune-Richtlinien funktionieren und welche Reichweite sie haben. Wenn ein Gerät über Intune verwaltet wird, kann Intune Richtlinien auf das Gerät selbst anwenden, nicht nur auf die Azure AD-Benutzer, die sich anmelden. Viele dieser gerätebezogenen Richtlinien sind nicht wählerisch zwischen Azure AD-Konten und lokalen Konten – sie beeinflussen einfach die Sicherheitskonfiguration des gesamten Betriebssystems. Dies gilt insbesondere für Kennwortrichtlinien.
Die häufigsten Übeltäter, die einen ungewollten Kennwortablauf für lokale Konten verursachen können, sind:
1. Sicherheitsbaselines (Security Baselines)
Microsoft Security Baselines sind vordefinierte Sicherheitseinstellungen, die von Microsoft empfohlen werden, um die Sicherheit von Windows-Geräten zu erhöhen. Wenn Sie beispielsweise die „Windows 10 Security Baseline” oder „Microsoft Defender for Endpoint Baseline” in Intune bereitstellen, wenden Sie eine umfassende Reihe von Sicherheitseinstellungen an. Diese Baselines enthalten oft auch Einstellungen für Kennwortrichtlinien, die auf alle Konten des Geräts angewendet werden, einschließlich lokaler Konten. Suchen Sie hier nach Einstellungen wie „Maximale Kennwortalter” (Maximum password age).
2. Geräteeinschränkungsprofile (Device Restriction Profiles)
Diese Profile sind eine der gängigsten Methoden, um diverse Einstellungen auf Geräten zu konfigurieren. Im Bereich „Kennwort” innerhalb eines Geräteeinschränkungsprofils finden Sie Optionen wie „Kennwort erforderlich”, „Maximale Kennwortalter (Tage)” oder „Kennwortablauf erforderlich”. Wenn hier eine Zahl ungleich 0 für das maximale Kennwortalter konfiguriert ist, wird diese Richtlinie auf das Gerät angewendet und damit auch auf lokale Konten.
3. Benutzerdefinierte Konfigurationsprofile (Custom Configuration Profiles mit OMA-URI)
Für erweiterte oder spezifische Einstellungen, die nicht direkt in den grafischen Oberflächen von Intune verfügbar sind, können Sie benutzerdefinierte Profile verwenden, die auf OMA-URI (Open Mobile Alliance Uniform Resource Identifier) basieren. Eine Kennwortablaufrichtlinie könnte beispielsweise über den OMA-URI ./Device/Vendor/MSFT/Policy/Config/DevicePassword/MaxPasswordAge mit einem Wert in Tagen konfiguriert worden sein. Wenn dieser Wert gesetzt ist, erzwingt er den Kennwortablauf.
4. Endpunktsicherheitsprofile (Endpoint Security Profiles)
Innerhalb der Endpunktsicherheit gibt es Profile wie „Kontoschutz”, die sich direkt auf die Sicherheit von Konten auswirken können. Obwohl sie primär für Windows Hello for Business oder andere moderne Authentifizierungsmethoden gedacht sind, können einige ihrer Untereinstellungen indirekt auch klassische Kennwortrichtlinien beeinflussen oder zumindest als Quelle für Konflikte dienen.
Schritt für Schritt zur Lösung: Die Detektivarbeit
Die Behebung des Problems erfordert eine systematische Herangehensweise im Microsoft Intune Admin Center (Endpoint Manager admin center). Hier ist ein Leitfaden:
Schritt 1: Das betroffene Gerät identifizieren und überprüfen
Melden Sie sich im Microsoft Intune Admin Center an. Navigieren Sie zu „Geräte” > „Alle Geräte”. Suchen Sie das betroffene Gerät. Klicken Sie auf das Gerät und dann auf „Gerätekonfiguration”. Hier sehen Sie alle Profile, die auf dieses Gerät angewendet wurden. Achten Sie auf den Status „Erfolgreich” oder „Fehler”, um zu sehen, welche Richtlinien aktiv sind.
Schritt 2: Potentielle Richtlinien identifizieren
Konzentrieren Sie sich auf Profile, die Kennwortrichtlinien enthalten könnten:
- Unter „Geräte” > „Konfigurationsprofile”
- Unter „Endpunktsicherheit” > „Sicherheitsbaselines”
- Unter „Endpunktsicherheit” > „Kontoschutz”
Achten Sie auf Profile, die generische Namen wie „Windows 10 Security Baseline”, „Standard Device Restrictions”, „All Users” oder „All Devices” haben, da diese oft breit angewendet werden.
Schritt 3: Richtlinieneinstellungen analysieren
Öffnen Sie jedes verdächtige Profil und navigieren Sie zu den relevanten Abschnitten.
- Sicherheitsbaselines: Suchen Sie nach „Gerätekonfiguration” oder „Lokale Richtlinien” und dort nach „Sicherheitsoptionen” oder „Kennwortrichtlinien”. Die Einstellung „Maximale Kennwortalter” (Maximum password age) ist der Hauptverdächtige.
- Geräteeinschränkungsprofile: Gehen Sie zum Abschnitt „Kennwort”. Überprüfen Sie die Einstellung „Maximale Kennwortalter (Tage)”. Wenn sie auf einen Wert ungleich 0 (z.B. 42, 90, 180) gesetzt ist, haben Sie den Übeltäter gefunden. Ein Wert von „0” bedeutet in der Regel „läuft nie ab”.
- Benutzerdefinierte Profile: Suchen Sie nach OMA-URI-Einstellungen, die sich auf Kennwörter beziehen, insbesondere
./Device/Vendor/MSFT/Policy/Config/DevicePassword/MaxPasswordAge.
Es ist wichtig zu verstehen, dass Intune auf Konflikte überprüft und im Zweifelsfall die restriktivste Richtlinie anwendet oder Sie den Konflikt manuell lösen müssen. Selbst wenn Sie denken, dass ein Wert auf „nicht konfiguriert” steht, könnte eine andere Richtlinie den Wert explizit setzen.
Schritt 4: Den Zielkonflikt verstehen
Wenn mehrere Richtlinien die gleiche Einstellung konfigurieren, wendet Intune eine Hierarchie an. Im Allgemeinen gewinnt die restriktivste Einstellung. Wenn Sie ein Gerät haben, das zu mehreren Gruppen gehört, die unterschiedliche Kennwortrichtlinien erhalten, kann es zu einem Konflikt kommen. Intune zeigt Konflikte im Status des Gerätes an, aber es ist immer besser, eine klare Richtlinienstruktur zu haben.
Schritt 5: Richtlinien anpassen oder ausschließen
Sobald Sie die oder die Richtlinien identifiziert haben, die den ungewollten Kennwortablauf verursachen, haben Sie mehrere Optionen:
- Wert ändern: Bearbeiten Sie die Richtlinie und setzen Sie das „Maximale Kennwortalter” auf 0 (für „läuft nie ab”) oder auf einen sehr hohen Wert (z.B. 999 Tage), wenn Sie eine Ablauffrist wünschen, diese aber sehr lang sein soll. Beachten Sie die Sicherheitsimplikationen dieser Änderung.
- Zuweisung anpassen: Wenn das lokale Konto nur auf einer sehr spezifischen Teilmenge von Geräten benötigt wird, könnten Sie die Zuweisung der betreffenden Richtlinie so ändern, dass diese Geräte ausgenommen werden. Dies ist jedoch oft komplex und potenziell unsicher, da eine Kennwortrichtlinie fast immer auf alle Geräte angewendet werden sollte. Eine Alternative wäre, eine separate Gruppe für die Ausnahmen zu erstellen und diese Gruppe von der Richtlinienzuweisung auszuschließen.
- Benutzerdefiniertes Profil erstellen (zur Überschreibung): Im äußersten Notfall könnten Sie ein neues benutzerdefiniertes OMA-URI-Profil erstellen, das explizit
./Device/Vendor/MSFT/Policy/Config/DevicePassword/MaxPasswordAgeauf 0 setzt und dieses Profil auf die betroffenen Geräte mit einer höheren Priorität anwenden (falls anwendbar oder durch spezifische Zuweisung). Dies sollte jedoch die letzte Option sein.
Denken Sie daran, dass Änderungen an Sicherheitsrichtlinien weitreichende Auswirkungen haben können. Stellen Sie sicher, dass Sie die Notwendigkeit des lokalen Kontos und die Sicherheitsrisiken eines nicht ablaufenden Kennworts sorgfältig abwägen.
Schritt 6: Synchronisation und Überprüfung
Nachdem Sie die Richtlinie geändert haben, müssen die Geräte die neuen Einstellungen erhalten. Sie können die Synchronisation auf dem Gerät manuell anstoßen: Gehen Sie zu „Einstellungen” > „Konten” > „Auf Arbeits- oder Schulkonto zugreifen”, klicken Sie auf Ihr primäres Azure AD-Konto und dann auf „Info”. Klicken Sie auf „Synchronisieren”. Es kann einige Minuten dauern, bis die Richtlinie angewendet wird. Überprüfen Sie im Intune Admin Center unter dem Gerätestatus, ob die aktualisierte Richtlinie erfolgreich angewendet wurde. Sie können auch das Ereignisprotokoll auf dem Gerät überprüfen (Ereignisanzeige > Anwendungs- und Dienstprotokolle > Microsoft > Windows > DeviceManagement-Enterprise-Diagnostics-Provider > Admin), um zu sehen, ob die Richtlinie erfolgreich übernommen wurde.
Best Practices und Prävention
Um solche Probleme in Zukunft zu vermeiden und die Sicherheit zu erhöhen, sollten Sie folgende Best Practices berücksichtigen:
- Lokale Konten minimieren: Versuchen Sie, die Anzahl lokaler Konten auf Azure AD-joined Devices so gering wie möglich zu halten. Je weniger lokale Konten, desto weniger Angriffsfläche und weniger Managementaufwand.
- Azure AD für Administration nutzen: Nutzen Sie Azure AD-Benutzer und -Gruppen für administrative Aufgaben. Implementieren Sie Just-In-Time (JIT) oder Privileged Identity Management (PIM) für erhöhte Sicherheit bei privilegierten Zugriffen.
- Managed Local Administrator Password Solution (LAPS): Für lokale Administratorkonten auf Azure AD-joined Devices bietet Microsoft die Windows LAPS-Lösung. Damit können Kennwörter lokaler Administratorkonten automatisch rotieren und sicher in Azure AD oder einem lokalen Active Directory gespeichert werden. Dies ist eine hervorragende Lösung, um die Sicherheit lokaler Administratorkonten zu gewährleisten, ist aber für generische lokale Benutzerkonten weniger relevant.
- Dokumentation: Pflegen Sie eine umfassende Dokumentation Ihrer Intune-Richtlinien, insbesondere derer, die sicherheitsrelevante Einstellungen wie Kennwortrichtlinien betreffen.
- Testen: Testen Sie Änderungen an Intune-Richtlinien immer zuerst in einer Testumgebung oder mit einer kleinen Gruppe von Pilotgeräten, bevor Sie sie unternehmensweit ausrollen.
Fazit
Der ungewollte Kennwortablauf von lokalen Konten auf Intune-verwalteten Azure AD-Geräten ist ein klassisches Beispiel dafür, wie moderne Management-Tools umfassender wirken, als man manchmal annimmt. Es ist keine Fehlfunktion, sondern das Ergebnis einer Richtlinie, die so konfiguriert wurde, dass sie das gesamte Gerät betrifft. Durch systematisches Vorgehen im Microsoft Intune Admin Center, die Kenntnis der relevanten Richtlinientypen und ein Verständnis der geräteweiten Anwendung von Sicherheitseinstellungen können IT-Administratoren die Ursache schnell identifizieren und das Problem effektiv lösen.
Dieser Einblick hilft nicht nur bei der akuten Problemlösung, sondern stärkt auch das Verständnis für die komplexe, aber leistungsstarke Synergie zwischen Azure AD und Microsoft Intune. Mit dem richtigen Wissen können Sie Ihre Cloud-Umgebung sicher und effizient verwalten, ohne von unerwarteten Abläufen überrascht zu werden.