Ich hatte vor kurzem die Freude, Windows 365 Single Sign On (SSO) zu troubleshooten – das Problem war recht seltsam: Wenn man die Windows 365 Webseite (windows365.microsoft.com) oder die „Windows App“ öffnet, wird wie erwartet eine Authentifizierung angefordert. Wenn man aber dann eine Sitzung mit einem der virtuellen Desktops aufbaut, sollte eigentlich der Login nicht wiederholt werden, sondern direkt Zugang zum Windows PC gewährt werden. Stattdessen: Direkt wieder eine Authentifizierungsanforderung.
Das Thema wurde mir zugewiesen, da nach Prüfung der Windows 365 SSO Konfiguration der Verdacht geäußert wurde, dass es sich um ein Conditional Access (CA) Problem handelt. Einige Stunden später bestätigte sich der Verdacht teilweise und ich hatte ein tieferes Verständnis des Verhaltens als mir vielleicht lieb war.
Doch bevor ich zu weit vorgreife, lassen Sie uns einen Blick auf die Ergebnisse der Analyse werfen.
⚠️ Während ich diesen Artikel verfasste, wurde der ursprüngliche Fehler in Windows vermutlich (vorläufig?) durch ein Update behoben. Das Problem bestand etwa April 2024 bis Anfang September 2024⚠️
Obwohl der Fehler behoben wurde, können die hier enthaltenen Informationen bei der Lösung ähnlicher oder wiederkehrender Probleme hilfreich sein. Aus eigener Erfahrung weiß ich, wie nützlich alte Troubleshootings sein können, weshalb ich diesen Artikel als eine Art ‚Zeitkapsel‘ größtenteils unverändert lassen wollte.
„Azure Virtual Desktop“ steht in Klammern, weil ich die Tests nicht mit AVD wiederholt habe, aber die in CA Konfigurierten Enterprise Apps die selben sind – „I am making an educated guess“, dass es sich gleich verhält.
Ich gehe davon aus, dass Sie für Windows 365 immer Entra ID SSO einrichten – die Vorteile von Modernen Authentifizierungsmethoden wie FIDO2 Keys und Hello for Business sollten Totschlagargumente sein, ganz abgesehen von dem Seamless SSO wenn nicht gerade ein Problem besteht. Das selbe gilt für AVD.
Ich erspare Ihnen das vollständige, unstrukturierte Testprotokoll und gebe stattdessen einen Überblick über das Vorgehen.
⚠️ Der volle Testkatalog erfolgte auf einem Gerät, das nicht Entra Registered oder Joined ist. Warum dies Relevant ist, folgt später. ⚠️
Zuerst wurde ein Testbenutzer eingerichtet, der von allen anderen CA-Policies freigesprochen ist. Auf diesen Benutzer gilt immer eine CA-Policy, mit wechselndem Targeting der in der Dokumentation gelisteten Enterprise Applikationen, die bei einem Windows 365 Login Involviert sind (siehe Kapitel „Involvierte Applikationen“). Auch Grant und Condition Verhalten wurde geprüft.
Meine Hoffnung war, dass ich mir über „Sign-In Frequency: Every Time“ erspare, jedes mal Abzumelden und neu Anzumelden sowie Caching Probleme zu vermeiden, das sollte sich aber als Fehler herausstellen. Weshalb erläutere ich im SSO Fix.
Conditional Access Referenz:
Control Setting Target resources Wechselnd: [Windows 365, Azure Virtual Desktop, Microsoft Remote Desktop, Windows Cloud Login] Conditions Wechselnd: [Mobile apps and desktop clients, Web Browser] Grant Wechselnd: [Require MFA, Require Authentication Strength] Session Sign-In Frequency: Every Time, Wechselnd: Browser Persistence
Eine weitere Herausforderung bei den Tests war, dass ich 10 Minuten zwischen jedem Schritt ließ, um Prompt Tolerance zu umgehen. Entra ID würde bei zu schnell aufeinanderfolgenden Requests keinen erneuten Login auslösen, um eine zu hohe Belastung für Benutzer und Dienste bei fehlkonfigurierten Apps oder Richtlinien zu vermeiden.
War die Richtlinie gesetzt, wurden folgende Tätigkeiten jeweils für W365 Web und die Windows App wiederholt:
https://windows365.microsoft.com/webclient/[GUID]
) oder aus der Windows App an die Taskbar gepinnten Desktophttps://windows365.microsoft.com/webclient/[GUID]
) kann ein legitimer Workaround bei SSO-Problemen sein, sofern man die Vorteile der Windows App nicht benötigt.Neben den hier gelisteten Findings habe ich auch eine detaillierte Liste der involvierten App Registrationen und Login flows gesammelt, da ich aber gerade keinen sinnvollen Zweck für diese Tabelle kenne, ist sie am Ende des Artikels.
⚠️ Wie bereits in der Einleitung erwähnt, wurde dieses Verhalten inzwischen behoben. ⚠️
Zunächst ein Überblick über meinen Ausgangspunkt: Unsere firmeninterne Konfiguration von Windows 365 / AVD hatte einen absolut reibungslosen SSO, auch auf einem unverwalteten Gerät. Hat man sich über W365 Web oder die Windows 365 App angemeldet, musste man sich beim Aufbau der Sitzung nicht erneut Authentifizieren.
Das Problem existierte ausschließlich bei einem bestimmten Kunden, wo alle meine Tests zu keiner Besserung geführt hatten. Meine vorläufige Schlussfolgerung war, dass das Problem vermutlich in der Konfiguration des Kunden lag.
Während ich die Testergebnisse strukturierte und analysierte, hatte ich eine Eingebung. Konstante in allen Tests war die Einstellung ‚Sign-In Frequency (SIF): Every Time‘. Und da ich bereits einmal in der Vergangenheit Probleme mit SIF hatte, wollte ich mir ansehen, wie es sich komplett ohne sie verhält.
Und siehe da – wenn ich mich ohne Sign-In Frequency an der Desktop-App anmelde, musste ich mich anschließend in der Sitzung nicht erneut authentifizieren.
Wir hatten bereits ein ähnliches Problem an anderer Stelle, dem Troubleshooting rund um den Entra ID Fehlercode 9002341 – Die Sign-In Frequency scheint auf unregistrierten Geräten das Sitzungsmanagement zu destabilisieren, was dazu führt, dass erweiterte SSO-Funktionen sich nicht korrekt verhalten.
Merkt das Wort „unregistriert“ – Wenn ein Gerät einen Primary Refresh Token erhält, bestehen diese Probleme nicht. Ich habe dies überprüft, indem ich ein weiteres Testgerät verwendet habe und den Benutzeraccount des Kunden zu Windows hinzugefügt habe (Settings -> Accounts) – und tatsächlich, die Probleme verschwanden.
Als Grundlage zu diesem Thema empfehle ich die Microsoft Dokumentation. Hier eine Kurzfassung:
Clients: Windows 365 (app ID 0af06dc6-e4b5-4f28-818e-e78e62d137a5)
Sitzung: Azure Virtual Desktop / Windows Virtual Desktop (app ID 9cdead84-a844-4324-93f2-b2e6bb768d07)
SSO : Microsoft Remote Desktop (app ID a4a365df-50f1-4397-bc59-1a1564b8bb9c) + Windows Cloud Login (app ID 270efc09-cd0d-444b-a71f-39af4910ec45)Die gemeinsam aufgeführten Apps sollten einheitlich behandelt werden. Die Sitzung sowie der SSO sollten immer mindestens MFA fordern und für Sign-In Frequency gleich konfiguriert sein. In der Regel ist das aber schon über eine All Applications Policy gedeckt. Stimmts?
⚠️ Da der SIF-Fehler nun behoben ist, sind die unten aufgeführten Workarounds nicht mehr notwendig. ⚠️. Es bleibt jedoch manchmal von Interesse, die Clients mit einer längeren SIF als die Sitzung zu konfigurieren, besonders für Android- und iOS-Geräte, wo oftmals eine längere Sign-In Frequency gilt. Länger als vielleicht für eine Sitzung in einem „vertrauenswürdigen“ Windows PC erwünscht.
Wenn keine Sign-In Frequency-Anforderungen bestehen, sehe ich keine notwendigen „Workarounds“ für Windows 365. In der Regel ist es aber Teil des Usecase von virtuellen Deskopts, dass auch uncompliant Geräte auf sie zugreifen dürfen (also eine Ausnahme von Regeln mit „Require Compliant Device“) und dort will man Sitzungen in meinen Branchen so schnell wie möglich auslaufen lassen.
Falls die Sign-In Frequency verpflichtend ist, sind Geräte idealerweise Entra ID registriert oder joined und über Intune verwaltet. In diesem Fall muss für Windows 365 keine Sonderkonfiguration vorgenommen werden. Ist der primäre Anwendungsfall für Windows 365 bzw. AVD jedoch unverwaltete Geräte, kann man sich darauf nicht verlassen.
Um die Registrierung zu verbessern, könnte man eine Benutzerkampagne in Erwägung ziehen. (Hier zum Beispiel das FAQ der University of Illinois – In Deutschland sind dabei jedoch Datenschutz- und Betriebsratsvorgaben besonders zu beachten.)
Wenn eine Sign-In Frequency erforderlich ist, empfehle ich eine Conditional Access-Ausnahme für die „Windows 365“ Enterprise App, zumindest bis sich das Verhalten der SIF verbessert. Ich wähle diese App, da in ihr nur rudimentäre Kontrollen des Desktops möglich sind. Wenn z.B. die Sitzung in den Clients nur alle zwei Wochen erneuert wird, muss der Benutzer sich in der Regel nur beim Start einer neuen Sitzung authentifizieren.
Sollte dies keine Option sein, muss man entweder in Kauf nehmen, dass sich die Benutzer doppelt anmelden oder den in den Findings erwähnten Workaround nutzen: verwenden der Browser-Sitzung über https://windows365.microsoft.com/webclient/[GUID]
, mit den entsprechenden Einschränkungen.
In meinen Recherchen bin ich auch über einige andere sehr interessante Artikel gestolpert, die Weitergehende Tricks / Tipps rund um W365 Conditional Access liefern, die ich natürlich nicht vorenthalten will:
Falls interesse besteht, wie W365 in den Entra ID Sign-In Logs aussieht, habe ich am Ende des Artikels die mir bekannten Apps gesammelt, sowie wie man einen aktuellen Stand ausliest.
Wenn dieser Artikel für Sie eine Wissenslücke geschlossen oder ein Problem behoben hat, oder wenn noch Fragen offen sind, lassen Sie es mich auf LinkedIn Wissen.
Um die oftmals doch sehr ähnlich klingenden Begriffe klar zu unterscheiden habe ich mich bemüht, weitestgehend der bestehenden Dokumentation zu folgen. Zur Sicherheit stelle ich aber noch einmal dar, wovon ich spreche:
Windows App
Die Windows App ist der neue Desktop (oder auch Mobile) Client für Windows Remote-Sitzungen. Darunter fallen AVD und W365- Apps sowie Desktops. Für Nutzer anderer VDI-Umgebungen entspricht sie ungefähr der Citrix Workspace App oder dem VMware Horizon Client.
Windows 365 Webseite
(Kurz: W365 Web)
Das reine Webinterface für Windows 365 (https://windows365.com), mit der Option eine Sitzung in Windows Remote Desktop oder auch im Browser zu öffnen.
Sitzung
Die Sitzung bezeichnet die aktive Verbindung zu einem Remote-PC. In den beiden vorhergehenden Screenshots effektiv alles was passiert, wenn man auf den „Verbinden“ Knopf drückt (Oder in W365 Web Im Browser / in der Desktop App öffnet).
Client
Der Begriff ‚Client‘ umfasst sowohl W365 Web als auch die Windows App (wahrscheinlich auch Windows Remote Desktop, jedoch war dieser nicht Teil meiner Tests). Hierüber werden Sitzungen gestartet.
Hier sind die Application- und Resource-IDs, die ich in den Sign-In Logs beobachtet habe:
Mit der in Conditional Access auswählbaren „Windows 365“ Applikation werden diverse Frontend Endpunkte zusammengefasst (man denke „Office 365“, das Exchange, Teams, etc. umfasst):
Aus dieser Sammlung habe ich mitgenommen, dass es schwierig ist, das Zusammenspiel über die Sign-In Logs vollständig nachzuvollziehen, was das Reporting der Windows 365-Nutzung erschwert. Plus wird sie hoffentlich jemandem helfen, einer Application ID zuzuordnen, wozu sie eigentlich dazugehört.
Die genutzten Ressourcen sind immer der jeweils zuerst genannten Applikation zugeordnet, die IDs gehören immer zu dem Anzeigenamen Darüber. Der Windows 365 Client hat zum beispiel die ID 4fb5cc57-dbbc-4cdc-9595-748adff5f414.
Applikation | Genutzte Ressourcen |
---|---|
Windows 365 Client | Azure Virtual Desktop |
4fb5cc57-dbbc-4cdc-9595-748adff5f414 | Microsoft Graph |
Windows 365 IW Service | |
Windows 365 Portal | |
Windows 365 Portal | Azure Virtual Desktop |
3b511579-5e00-46e1-a89e-a6f0870e2f5a | Windows 365 Portal |
Microsoft Remote Desktop | |
Office365 Shell WCSS-Server | |
Microsoft Graph | |
Windows 365 IW Service | |
Windows Cloud Login | |
OCaaS Client Interaction Service |
Ressource | Zugreifende Applikationen/Clients |
---|---|
Azure Virtual Desktop | Azure Virtual Desktop Client |
9cdead84-a844-4324-93f2-b2e6bb768d07 | Windows 365 Portal |
Windows 365 Client | |
Windows 365 Client – iOS | |
Windows 365 Client – Web | |
Microsoft Remote Desktop | Windows 365 Portal |
a4a365df-50f1-4397-bc59-1a1564b8bb9c | Azure Virtual Desktop Client |
Windows 365 IW Service | Windows 365 Portal |
7c0a6aea-533c-458c-9f81-15568f10f6e4 | Windows 365 Client |
Windows Cloud Login | Azure Virtual Desktop Client |
270efc09-cd0d-444b-a71f-39af4910ec45 | Windows 365 Portal |
Windows 365 Portal | Windows 365 Portal |
3b511579-5e00-46e1-a89e-a6f0870e2f5a | Windows 365 Client |
Eine Vollständige Sign-In Konstellation lässt mit KQL wie folgt auswerten:
Die ursprüngliche Liste der App IDs stammt aus Beobachtung der Sign-In Logs in meinen Tests
Eine View ist speichereffizienter, da sie die Daten nicht in einer temporären Variablen speichert, sondern direkt in der Abfrage verwendet
let involvedApps = dynamic(["0af06dc6-e4b5-4f28-818e-e78e62d137a5","9cdead84-a844-4324-93f2-b2e6bb768d07","a4a365df-50f1-4397-bc59-1a1564b8bb9c","7c0a6aea-533c-458c-9f81-15568f10f6e4","4fb5cc57-dbbc-4cdc-9595-748adff5f414","3b511579-5e00-46e1-a89e-a6f0870e2f5a","270efc09-cd0d-444b-a71f-39af4910ec45"]);
let accessedAsResource = view()
{ AADSignInEventsBeta
| where ResourceId in (involvedApps)
| summarize make_set(Application), make_set(ResourceDisplayName) by ResourceId
};
let accessedAsApp = view()
{ AADSignInEventsBeta
| where ApplicationId in (involvedApps)
| summarize make_set(Application), make_set(ResourceDisplayName) by ApplicationId
};
union withsource = "SourceTable" accessedAsApp, accessedAsResource
| project ApplicationId, ResourceId, Applikationen = set_Application, Resourcen = set_ResourceDisplayName
Ihr persönlicher Ansprechpartner
Bei welchem Projekt oder welcher Herausforderung dürfen wir Sie unterstützen? Wir sind gerne für Sie da.
MICHAEL WILDGRUBER | Team Lead Digital Workplace – Cloud Productivity
Wollen Sie immer up2date sein? Dann melden Sie sich jetzt zu unserem Newsletter an
Bleiben Sie auf dem Laufenden. Wir informieren Sie regelmäßig über aktuelle Trends und technologische Neuerungen sowie geplante Webinare und Events. Sie erhalten Einblick in interessante Kundenprojekte und werfen einen Blick hinter die Kulissen. Melden Sie sich jetzt an.