Oktober 2024
Autor des Beitrags
Julian
Senior Consultant
Veröffentlicht am
22.10.2024 von Julian
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter

Windows 365 (und Azure Virtual Desktop) Conditional Access Deep-Dive

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.

Tests

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:

  1. Öffnen des Client, notieren, ob (Multi-Faktor) Authentifizierung notwendig ist
  2. Starten einer Sitzung, im Browser direkt oder über Remote Desktop App; Wenn die W365 App installiert ist, ging ich davon aus, dass diese als Client und nicht nur für die Sitzung genutzt wird
  3. Direkter Start einer Sitzung, über URL in W365 Web (https://windows365.microsoft.com/webclient/[GUID]) oder aus der Windows App an die Taskbar gepinnten Desktop
  4. Logout vom Client
  5. Erneut direkter Start einer Sitzung (Um zu prüfen, ob der Client-Login von der Sitzung vollständig getrennt ist)
  6. Prüfen der Sign-In Logs auf Auffälligkeiten und neue Applikationen / Ressourcen

Findings

  • Der Client und der Aufbau der Sitzung sind voneinander separate Login Prozesse, auch mit SSO Konfiguration
    • Dies bedeutet, dass für ein nahtloses SSO, ohne Unterbrechung, das Endgerät in der Lage sein muss, den Login zu übertragen.
  • Mit der Windows 365 App kann eine Sitzung nicht direkt über einen „Favoriten“ Aufgebaut werden, es muss sich vorher an dem W365 Client angemeldet werden
  • Im Gegensatz dazu erfordert der Sitzungsaufbau über W365 Web keine vorherige Authentifizierung im Client
    • Es ist wichtig, dass die strengsten Sicherheitskontrollen auf die „Azure Virtual Desktop“, bzw. mit aktivem SSO die „Microsoft Remote Desktop / Windows Cloud Login“ Enterprise App angewandt werden, da dies in der Regel das Tor zur „vertrauenswürdigen“ Sitzung ist
    • Das Speichern des Links zur offenen Browser-Sitzung (https://windows365.microsoft.com/webclient/[GUID]) kann ein legitimer Workaround bei SSO-Problemen sein, sofern man die Vorteile der Windows App nicht benötigt.
  • Eine CA Policy, die Browser Persistenz verbietet, betrifft natürlich auch automatisch W365 Web – Man muss sich dann dort jedes mal neu Anmelden, sofern das Gerät nicht registriert ist und SSO unterstützt

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.


Der SSO Fix

⚠️ 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.


Wie ich jetzt Conditional Access Konfiguriere

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.

Letzte Worte

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.


Terminologie

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.

W365DesktopAppExample


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.

Windos 365 Web


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.


Involvierte Applikationen im Detail

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):

  • Windows 365 Portal: 3b511579-5e00-46e1-a89e-a6f0870e2f5a
  • Windows 365 IW Service : 7c0a6aea-533c-458c-9f81-15568f10f6e4
  • Windows 365 Client: 4fb5cc57-dbbc-4cdc-9595-748adff5f414
  • (wahrscheinlich mehr, was ich nicht mehr im Detail beobachtet habe)

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

 

Kontakt

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

+49 89  71040920

michael@provectus.de

Termin vereinbaren

Zum Kontaktformular

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.

Zur Newsletter Anmeldung 

Updates & News

auf einen Blick
Whitepaper

Whitepaper – Prozessautomatisierung mit der Microsoft Power Platform

Produktivität steigern durch Prozessautomatisierung. Microsoft Power Platform Lizenzen sowie Optimierungsmöglichkeiten im Überblick.
Weiterlesen
Blogbeitrag

Optimierte Azure-Kosten mit Azure Pricing Calculator und Cost Management

Der Azure Pricing Calculator gibt einen Überblick über Cloud Kosten. Durch eine Optimierungsstrategien profitieren Unternehmen effektiv.
Weiterlesen
Whitepaper

Whitepaper – Azure Cost Management

In diesem Whitepaper zeigen wir Ihnen, wie Sie mit Azure Cost Management Ihre Cloud-Kosten effektiv steuern und gleichzeitig die Vorteile der Cloud voll ausschöpfen können.
Weiterlesen
Blogbeitrag

Neue Microsoft Optimierung verbessert Teams-Erfahrung für VDI-User

Microsoft verbessert mit der neuen SlimCore-Optimierung die Leistung und Benutzererfahrung von Teams in VDI-Umgebungen. Die technischen Details erklärt unser Experte Patrick.
Weiterlesen
Blogbeitrag

Neue Sicherheitslücke bei Microsoft

Eine kürzlich entdeckte Sicherheitslücke in Microsoft ermöglichte es Nutzern ihren User Principal Name (UPN) eigenständig zu ändern. Unser Experte Julian klärt auf!
Weiterlesen
Blogbeitrag

Ein Meilenstein: Citrix Preferred Services Partner

Seit Dezember 2024 sind wir als Citrix Preferred Services Partner zertifiziert. Mit dieser Auszeichnung zählen wir zu einer exklusiven Gruppe weltweit und sind einer von nur vier Partnern in Deutschland.
Weiterlesen
Blogbeitrag

Citrix Lizenzen: User/Device-Modell oder doch Concurrent?

Was bedeuten die Definitionen im Citrix End-User Agreement? Was wird tatsächlich technisch als Lizenz ausgeliefert und was darf ich als Kunde nutzen?
Weiterlesen
Blogbeitrag

Intune Enterprise App erlaubt Compliant Device Bypass

In diesem Blogbeitrag erläutert unser Experte das Fehlerbild, zeigt auf, wie die Schwachstelle nachgestellt werden kann und gibt Empfehlungen zur Absicherung Ihrer Systeme.
Weiterlesen
Blogbeitrag

Citrix kauft DeviceTRUST und Strong Network: Was bedeutet das für Kunden?

Citrix kauft DeviceTRUST und Strong Network, um die Sicherheit seiner digitalen Workspace-Lösungen zu stärken
Weiterlesen
Echt Ich

Echt Ich Hannes

In ECHT ICH erfahrt ihr mehr über Hannes, seinen Arbeitsalltag, seine Hobbys und warum er bei Provectus „ECHT ER“ sein kann.
Weiterlesen
Jetzt Blogbeitrag teilen
Xing LinkedIn Facebook Twitter