Markus Büttner, Author at IT-Consulting Blog

Intune schneller als GPOs?

Bisher hatte die Verwaltung von Richtlinien für Windows Geräte über Intune einen entscheidenden Nachteil gegenüber GPOs. Der Refresh Zyklus von 8 Stunden. So werden bisher die MDM-Richtlinien nur alle 8 Stunden aktualisiert. Die GPOs jedoch alle 90 Minuten. Mit dem neuen Feature Config Refresh ist das nun Vergangenheit und der Aktualisierungszeitraum für Intune Richtlinien lässt sich anpassen. Mit diesen Anpassungen ist Intune schneller als GPOs!

Was ist der Config Refresh?

Config Refresh ist eine Funktion, die für Windows 11 ab dem Juni 2024 Security Update verfügbar ist. Es ermöglicht, die Häufigkeit der Aktualisierung von MDM-Richtlinien zu konfigurieren. Dies ist wichtig, um sicherzustellen, dass die Einstellungen nicht von den vorgesehenen Richtlinien abweichen. Aber auch, dass Konfigurationsanpassungen schnell auf den Endgeräten ankommen.

Die Vorteile von Config Refresh

Mit Config Refresh können Administratoren die Aktualisierungszeit der Richtlinien auf ein Intervall zwischen 30 Minuten und 24 Stunden einstellen. Zu den weiteren Schlüsselfunktionen von Config Refresh gehören:

Eine Reset-Operation, um die Einstellungen, die über den Policy CSP verwaltet werden, zurückzusetzen
Offline-Funktionalität
Pausieren von Config Refresh für Troubleshooting

Die Konfiguration des Config refresh und des Aktualisierungsintervall findet sich bereits innerhalb des Settings catalog:

Intune Settings catalog: Einstellung für ein schnelleres Intune

Ein benutzerdefiniertes Profil ermöglicht die Konfiguration der Pause. Der Entsprechende Key lautet:

./Device/Vendor/MSFT/DMClient/Provider/MS%20DM%20Server/ConfigRefresh/PausePeriod

Gültige Werte sind eine Zahl zwischen 0 und 1440 Minuten (24 Stunden).

Wichtiger Hinweis

Der Config Refresh ist für MDM-Richtlinien konzipiert, die durch den Policy CSP verwaltet werden. Einige Richtlinien, insbesondere der BitLocker CSP, werden ebenfalls Config Refresh-Regeln folgen. Andere Richtlinien, wie Firewall, AppLocker, PDE und LAPS, fallen nicht in diesen Bereich!

Fazit

Ein interessantes Feature und weiterer Pluspunkt Policies über Intune, anstatt GPOs zu konfigurieren. Neben dem Vorteil Statusmeldungen zu den Policies zu erhalten und der Tatsache, dass eine Verbindung zum Internet ausreichend ist, um eine Policy-Änderungen auf ein Gerät anzuwenden. Bei den klassischen GPOs ist hierfür immer eine Verbindung zum Domain Controller erforderlich. Nun sind ist Intune auch deutlich schneller als die klassischen GPOs.

Microsoft MFA für alle Benutzer ab Juli 2024?

Eigentlich sollte sie bereits für jeden Microsoft 365 Benutzer aktiv sein, die Multi Faktor Authentifizierung (MFA). Trotzdem hat Microsoft mit der Ankündigung MFA für alle Benutzer anzufordern für Aufregung gesorgt (Microsoft will require MFA for all Azure users). Insbesondere da es Gründe für bestimmte Benutzer bestehen, keine MFA zu forcieren. Hierunter fallen z.B. Service Benutzer oder auch bestimmte Benutzergruppen.

Die Ankündigung wurde mittlerweile präzisiert und es betrifft nur Benutzer, die auf folgende Anwendungen zugreifen:

Azure portal
Microsoft Entra admin center
Azure PowerShell
Azure CLI
Terraform für die Administration von Azure

Auf die genannten Anwendungen greifen in der Regel nur Benutzer zu, die administrative Vorgänge durchführen. Vom MFA-Zwang ausgenommen werden sollen: Dienstprinzipalobjekte, verwaltete Identitäten, Workload-Identitäten und weitere tokenbasierte Konten. Microsoft sammelt hier auch noch weiteren Input für weitere Szenarien, wie z.B. Break-Glass Administratoren. Diese sind als Best-Practise ohne MFA empfohlen, um im Notfall weiterhin Zugang zum Tenant zu bieten.

Wie setzt Microsoft die Anforderung technisch um?

Dazu gibt es leider noch keine konkrete Aussage. Ich vermute allerdings, dass dies über eine von Microsoft verwaltete Regel des bedingten Zugriffs realisiert wird. In der Technet zu den von Microsoft verwalteten Richtlinien (Secure your resources with Microsoft-managed Conditional Access policies – Microsoft Entra ID | Microsoft Learn), findet sie die folgende Regel, die stark an die Ankündigung von Microsoft erinnert: „Require multifactor authentication for Azure management.“

Welche Aufgaben ergeben sich hieraus?

Prüfen der Sign-in Logs auf die oben genannten Anwendungen, um die betroffenen Benutzer, insbesondere Service Benutzer zu identifizieren.
Registrieren der MFA für alle Benutzer, die auf die oben genannten Anwendungen zugreifen.
Bei allen klassischen Service Benutzern die Möglichkeit prüfen, diese auf tokenbasierte Konten umzustellen.
Falls es über eine von Microsoft verwaltete Richtlinie realisiert wird, unbedingt die Break Glass Admins ausschließen.

Fazit

Zusammenfassend handelt es sich um eine sinnvolle Maßnahme um die Sicherheit der Tenants zu erhöhen. Noch immer gibt es viele ungesicherte Konten mit kritischen Zugriffen. Für diese soll nun die MFA aktiviert werden. Auch sind viele Service Accounts im Einsatz, die längst durch tokenbasierte Konten ersetzt werden könnten. Leider ist die ist die Kommunikation recht kurzfristig und vage.

„Mit Anmeldung fortfahren?“ Änderung bei Windows Single-Sign-On

Microsoft hatte es bereits im Dezember angekündigt. Aufgrund des Digital Markets Act (DMA) müssen die Benutzer dem Single-Sign-On auf Windows Geräten zustimmen. Hierzu erhält der Benutzer bei dem Zugriff auf M365 Ressourcen die Frage „Mit Anmeldung fortfahren?“. Diese muss der Anwender mit „weiter“ bestätigen um sich zu authentifizieren. Unter aka.ms/sso-info werden weitere Informationen angeboten. Die Infoseite erklärt, dass SSO weiterhin nur nach Bestätigung dieser Abfrage möglich ist.

Der Benutzer muss diese Meldung auf jedem Gerät an dem er arbeitet einmalig bestätigen. Die Bestätigung ist anschließend nicht mehr nötig, nur wenn sich der Benutzer 90 Tage nicht mehr an diesem Gerät authentifiziert hat.

Die Änderung wird nach und nach innerhalb des Europäischen Wirtschaftsraums aktiviert. Betroffen davon sind die Betriebssysteme Windows 10 und 11, bei denen innerhalb des initialen Gerätesetups ein Land innerhalb des Europäischen Wirtschaftsraums gewählt wurde. Explizit wirkt diese Änderung nicht auf Server Betriebssystemen.

Innerhalb der Entra-Anmeldeprotokolle führen fehlende Benutzerzustimmungen zu Anmeldefehlern mit dem Code 9002341 und der Fehlerursache „User is required to permit SSO“.

In einigen Fällen führt dies zu Problemen, da beispielsweise die Authentifizierung gegen Microsoft 365 Dienste wie z.B. bei einem automatischen Intune Join via GPO nicht durchgereicht wird. Dies klappt erst, wenn der Benutzer den SSO bestätigt hat. Aber auch bei nicht-persistenten VDIs führt das neue Feature bei jeder neuen Sitzung zur oben genannten Abfrage. Microsoft sind Probleme bekannt und will zeitnah nachbessern.

Weitere Infos und der Blog-Eintrag von Microsoft dazu:

Upcoming changes to Windows Single Sign-On | Windows IT Pro (microsoft.com)

Doppelte Accounts innerhalb von Office 365 mit identischer UPN

In der Welt der Microsoft 365 Konten kommt es gelegentlich zu einem seltsamen Phänomen auf Windows Geräten.: Doppelte Konten mit identischem User Principal Name (UPN) Diese Duplikate haben unterschiedliche Verläufe, aber den gleichen UPN. Dies führt bei betroffenen Anwendern zu Verwirrung und teilweise zu Problemen beim Zugriff auf Ressourcen. Für den Benutzer sind außer dem abweichenden Dokumentenverlauf keine Unterschiede erkennbar.

Was hilft?

Durch das Löschen des Registry Schlüssels: „HKCU\SOFTWARE\Microsoft\Office\16.0\Common\Identity“ des betroffenen Benutzers wird eine erneute Anmeldung innerhalb der Office Produkte durchgeführt. Danach ist nur noch das „richtige“ Konto verfügbar und wird über SSO angemeldet.