Wenn sich ein Benutzer mit einem Passkey über die Option „Mit Smartphone anmelden“ / QR-Code anmeldet, schlägt die Anmeldung in Netzwerken fehl, die einen HTTP-Proxy erzwingen oder direkten Internetzugriff blockieren. Derselbe Passkey und dasselbe Smartphone funktionieren in Heim- oder Mobilfunknetzen. Der fehlschlagende Schritt ist eine Windows-Plattformkomponente - nicht der Browser und nicht die Website - und betrifft daher jeden Dienst, der die Smartphone-/QR-Passkey-Anmeldung nutzt.

Dieser Artikel behandelt die Drittanbieter-Relay-Hosts, die geräteübergreifende Passkeys verwenden. Für Flips eigene Domains und die allgemeine Firewall-/Proxy-Freigabe siehe den Artikel „Allowlisting Flip App“ in diesem Bereich.

Prüfen, ob du betroffen bist

Windows protokolliert jeden geräteübergreifenden Passkey-Versuch in der Ereignisanzeige:

1. Öffne die Ereignisanzeige (Event Viewer).
2. Navigiere zu Anwendungs- und Dienstprotokolle → Microsoft → Windows → WebAuthN → Operational.
3. Reproduziere eine fehlgeschlagene Anmeldung oder sieh dir frühere Versuche an.
4. Suche nach Ereignis-ID 2336 mit Action = QR und einem Fehlercode, meist gefolgt von Ereignis-ID 2103 mit demselben Fehler.

Du bist betroffen, wenn Ereignis 2336 einen dieser Fehlercodes zeigt:

0x80072EE7 bei Ereignis 2336 ist das typische Kennzeichen dieses Problems: Der Client versuchte einen Direktzugriff in einem Netzwerk, das nur Proxy-Verkehr zulässt.

Wie geräteübergreifende Passkeys kommunizieren

Wenn sich ein Benutzer mit einem Passkey über sein Smartphone anmeldet, verlässt der Passkey niemals das Smartphone. Um die Anmeldung auf dem PC abzuschließen, tauschen PC und Smartphone eine kurze Folge verschlüsselter Nachrichten aus.

Sie kommunizieren nicht direkt miteinander. Beide bauen eine ausgehende Verbindung zu einem kleinen Relay- (Tunnel-)Server im Internet auf und leiten die Nachrichten darüber. Die Verbindung ist ein WebSocket über HTTPS (TCP 443) und zwischen PC und Smartphone Ende-zu-Ende verschlüsselt - ein Proxy kann den Inhalt weder lesen noch sinnvoll inspizieren. Bluetooth bestätigt nur, dass sich das Smartphone physisch in der Nähe des PCs befindet; es überträgt keine Anmeldedaten.

Das Relay wird vom Betriebssystem des Smartphones gewählt, nicht vom PC und nicht von der Website:

Auf iPhone/iPad trägt cable.auth.com die Anmeldung, und die beiden app-site-association.*-Hosts werden von Apple bei der Passkey-Registrierung verwendet. Gib alle frei, damit sowohl Registrierung als auch Anmeldung funktionieren. Der PC muss diese Hosts über TCP 443 erreichen.

Warum übliche Proxy-Einstellungen nicht greifen (Windows)

Unter Windows wird diese Verbindung nicht vom Browser und nicht im Kontext des angemeldeten Benutzers geöffnet. Sie wird von einem Windows-Systemdienst - Kryptografiedienste (CryptSvc) - geöffnet, der als NT AUTHORITY\NETWORK SERVICE läuft. Daraus folgt:

• Er verwendet nicht die Proxy-Einstellungen des angemeldeten Benutzers (HKCU oder benutzerbezogene Gruppenrichtlinie).
• Er verwendet nicht den maschinenweiten WinHTTP-Proxy (netsh winhttp set proxy).
• Er verwendet die Proxy-Konfiguration seines eigenen Dienstkontos (das NETWORK SERVICE-Profil, HKEY_USERS\S-1-5-20).
• Er verbindet sich über eine (ggf. zwischengespeicherte) IP-Adresse, daher sind reines Hostnamen-Blocking und hosts-Datei-Einträge gegen ihn unzuverlässig.

Behebung

Es gibt zwei Optionen. Variante 1 (Direktzugriff) wird empfohlen. Variante 2 (Proxy) ist eine Konfiguration, die wir durch Tests gefunden haben, für Umgebungen, in denen Direktzugriff nicht möglich ist.

Variante 1 - Direkten Zugriff auf die Relay-Hosts erlauben (empfohlen)

Lass die Client-PCs diese Hosts direkt - unter Umgehung des Proxys - erreichen:

• cable.ua5v.com (Android)
• cable.auth.com (iPhone / iPad)
• app-site-association.cdn-apple.com und app-site-association.networking.apple (Apple, für die Passkey-Registrierung)

1. Erlaube ausgehendes TCP 443 zu diesen Hosts. Da der Client eine zwischengespeicherte IP-Adresse verwenden kann, bevorzuge Freigaberegeln, die die vollständigen veröffentlichten Adressbereiche der Relays (Apple / Google) abdecken, oder eine FQDN-Regel, die alle A-Records erfasst - eine einzelne fest gepinnte IP wird sich ändern.
2. Führe keine TLS-/SSL-Inspektion für diese Hosts durch. Der Tunnel prüft das echte Zertifikat des Relays; ersetzt der Proxy es durch ein eigenes, wird die Verbindung abgelehnt. Nimm diese Hosts in die Ausnahmeliste der SSL-Inspektion auf.

Dies ist der einzige von Microsoft dokumentierte Ansatz, und der Tunnel ist Ende-zu-Ende verschlüsselt, sodass eine Weiterleitung über den Proxy keinen Inspektionsnutzen bringt. Microsofts Leitlinie: „Your organization needs to allow connectivity to endpoints in the following table to enable cross-device registration and authentication. Devices must be allowed to reach these URLs.“ (siehe Referenzen).

Variante 2 - Weiterleitung über den Proxy (Ausweichlösung)

Verwende dies, wenn Direktzugriff nicht gewährt werden kann. Dies ist eine Konfiguration, die wir durch eigene Tests gefunden haben; sie ist in der Microsoft-Dokumentation nicht beschrieben. Zwei Einstellungen zusammen führten zum Erfolg.

A) Die beiden Relay-Hosts ohne Authentifizierung über den Proxy zulassen

Der Tunnel-Client verbindet sich mit dem Proxy ohne Authentifizierung - er bietet ein anonymes Token statt einer Benutzer- oder Domänen-Anmeldeinformation. In Tests gab ein Proxy, der eine Authentifizierung verlangte, 0x80190197 (HTTP 407) zurück, und die Anmeldung wurde nicht abgeschlossen. Konfiguriere den Proxy daher so, dass er CONNECT ohne Authentifizierung genau zu Folgendem zulässt:

• cable.ua5v.com:443
• cable.auth.com:443

Beschränke dies auf diese beiden Hosts; der Rest des Proxys kann weiterhin eine Authentifizierung verlangen. Dies entspricht dem Muster, das Microsoft für andere systeminitiierte Verbindungen verwendet - eine kleine unauthentifizierte Ausnahme für bestimmte benannte URLs (siehe KB 2778122 in den Referenzen).

B) Den Proxy in den WinINET-Einstellungen des Dienstkontos konfigurieren (HKEY_USERS\S-1-5-20)

Da der Client die Proxy-Konfiguration des NETWORK SERVICE-Kontos liest, setze den Proxy dort - nicht in den Benutzereinstellungen und nicht über netsh winhttp. Jede der üblichen WinINET-Methoden funktioniert, solange sie in dieser Struktur (Hive) liegt:

• Manueller Proxy - unter …\Internet Settings setzen:

  HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings
      ProxyEnable  (DWORD)  = 1
      ProxyServer  (String) = proxy.corp.example:8080

• PAC (Konfigurationsskript) - AutoConfigURL unter …\Internet Settings setzen und den Binärwert DefaultConnectionSettings unter …\Internet Settings\Connections mit gesetztem Auto-Config-Flag konfigurieren.
• WPAD (automatische Erkennung) - den Binärwert DefaultConnectionSettings unter …\Internet Settings\Connections mit gesetztem Auto-Detect-Flag konfigurieren.

DefaultConnectionSettings ist derselbe Binärwert, den Windows schreibt, wenn du in der Proxy-Oberfläche „Skript für automatische Konfiguration verwenden“ oder „Einstellungen automatisch erkennen“ wählst. Übertrage ihn mit den in deiner Umgebung verwendeten Flags in die S-1-5-20-Struktur.

Ausrollen (Rollout)

Dies ist eine Änderung im Maschinen-/Dienstkontext; verteile sie daher mit einem Mechanismus, der im SYSTEM-Kontext läuft:

• Gruppenrichtlinie - ein Computer-Startskript (läuft als SYSTEM), das die obigen Registry-Werte schreibt.
• Intune / MDM - ein Geräte-PowerShell-Skript (Systemkontext) oder eine Registry-Richtlinie (Settings Catalog / OMA-URI).
• Configuration Manager (SCCM) - ein Skript oder Konfigurationselement, das auf Geräte verteilt wird.
• Ad-hoc / Test - ein Skript als SYSTEM ausführen (z. B. mit psexec -s).

Beispielskript (als SYSTEM ausführen):

$key = 'Registry::HKEY_USERS\S-1-5-20\Software\Microsoft\Windows\CurrentVersion\Internet Settings'
New-Item -Path $key -Force | Out-Null
Set-ItemProperty -Path $key -Name ProxyServer -Value 'proxy.corp.example:8080'
Set-ItemProperty -Path $key -Name ProxyEnable -Value 1 -Type DWord
# Der Dienst speichert seine Proxy-Konfiguration zwischen. Ein Dienstneustart wendet sie an;
# ein Neustart des Rechners ist auf verwalteten Geräten am zuverlässigsten.
Restart-Service CryptSvc -Force

Hinweise

• Der Dienst speichert seine Proxy-Konfiguration zwischen, die Änderung wird also nicht sofort übernommen. In Tests wurde sie nach einer „Settings-Changed“-Benachrichtigung oder einem Dienstneustart wirksam; ein Neustart des Rechners ist der zuverlässigste Weg für den Rollout.
• Lass die TLS-Inspektion für die beiden Hosts deaktiviert, wie in Variante 1.

Wir haben dies auf einem Rechner getestet, der nicht domänengebunden war und bei dem der Client ein anonymes Token anbot. Auf einem domänengebundenen Rechner kann der Client stattdessen das Maschinenkonto oder ein Kerberos-Ticket vorlegen; prüfe daher, ob die unauthentifizierte Ausnahme dort noch nötig ist.

Behebung überprüfen

• Führe eine echte Anmeldung per Smartphone auf einem Client durch. Für einen schnellen End-to-End-Test kannst du unter https://webauthn.io einen Passkey mit dem Smartphone registrieren und dich anmelden (Option „geräteübergreifend“ / „Mit Smartphone anmelden“ per QR wählen).
• Bestätige in WebAuthN/Operational das Ereignis 2335 (QR-Einrichtung abgeschlossen) und ein erfolgreiches GetAssertion, ohne Fehler 2336.
• Prüfe bei Variante 2 im Proxy-Zugriffsprotokoll, dass ein (unauthentifiziertes) CONNECT cable.auth.com:443 oder CONNECT cable.ua5v.com:443 vom Gerät erscheint.

Referenzen

• Enable and support passkeys in Authenticator for Microsoft Entra ID - „Prerequisites for passkeys in Authenticator“ (die Endpunktliste).
• Use authenticated proxy servers (Microsoft KB 2778122) - Hintergrund dazu, warum bestimmte Windows-Verbindungen im Systemkontext sich nicht an einem Proxy authentifizieren können, sowie das Zulassen einzelner URLs ohne Authentifizierung.
• Support for passkeys in Windows.
• Apple - Leitfaden für Unternehmensnetzwerke (Ports/Hosts).

Das Verhalten von Dienstkonto und Proxy oben beruht auf unseren eigenen praktischen Tests dieses Anmeldeablaufs.