Exchange und Android: ActiveSync via WAP funktioniert nicht
Wenn man ActiveSync über den Windows WAP (Web Application Proxy) veröffentlichen möchte, sollte man beachten, dass der WAP SNI verwendet. Bei einem unserer Kunden fiel uns dann auf, dass einige Android Versionen diese Erweiterung des TLS SSL Protokolls (SNI) nicht unterstützen.
Inhaltsverzeichnis
ActiveSync Mails: iPhones ja, Android Geräte nein
Wir standen also vor dem spannenden Problem, dass iPhones über ActiveSync E-Mails erhalten konnten – bei Android Geräten funktionierte ActiveSync via WAP hingegen nicht. Daraufhin gingen wir auf Spurensuche, woran dies denn liegen könnte. Nach unzähligen Support Calls und ein wenig Glück entdeckten wir die SNI Thematik. Diese wiederum führte uns dann zur Lösung unseres Problems.
Was ist SNI?
SNI steht für „Server Name Indication“ und ist eine Erweiterung des TLS SSL Protokolls. Dieses Protokoll kommt zum Einsatz, wenn hinter einer IP mehrere Hostnamen zu finden sind. Hierbei sendet der Client ein „ClientHello“ Paket. In diesem Paket ist unter dem Feld „ClientHelloExtension“ der entsprechende Servername enthalten. Dieser taucht dann erst wieder auf, sobald der verschlüsselte Tunnel aufgebaut wurde.
Genau hier setzte auch unser Problem an, da die Android Devices unseres Kunden nicht SNI sprechen konnten.
Lösung: http.sys Fallback Zertifikat
Um die Einschränkung aufzuheben, mussten wir ein http.sys Fallback Zertifikat erstellen. Auf diese Weise kann die Konnektivität der Geräte wiederhergestellt werden. Also erstellten wir ein http.sys Zertifikat mit einem Binding für 0.0.0.0:443 mittels folgendem Befehl
|
1 |
netsh http add sslcert ipport=0.0.0.0:443 certhash=certthumprint appid={applicationguid} |
Der appid Parameter ist die GUID der Anwendung, die man an das Binding anlegen möchte. In unserem Fall wäre es WAP.
Für ADFS und Web Application Proxy existieren folgende fest definierte IDs:
| Application | appid |
| AD FS App ID | {5d89a20c-beab-4389-9447-324788eb944a} |
| WAP App ID | {f955c070-e044-456c-ac00-e9e4275b3f04} |
Certhash
Den certhash vom WAP kann über folgenden PowerShell Befehl erhalten. Bitte beachten Sie, dass dieser Befehl nur auf einem Server ausgeführt werden kann, der die Remote Access Command Tools installiert hat.
|
1 |
Get-WebApplicationProxyApplication | fl Name, ExternalUrl, ExternalCertificateThumbprint |
Die Ausgabe sieht dann in etwa so aus:
Name : WAP
ExternalUrl : https://wap.testdomain.com/WAP/
ExternalCertificateThumbprint : 1C96DC2450A01B5660F756D1BDDE3B49B4887035
Installierte Zertifikate prüfen
Mit folgenden Befehl können Sie in der PowerShell die bereits auf dem Server installierten Zertifikate sehen und überprüfen.
|
1 |
dir Cert:\LocalMachine\My |
Thumbprint Subject
———- ——-
1FAAA1B7FA33D266E5CC54E4EBE41CB6C68E583B CN=ADFS ProxyTrust – 2012R2-WAP01
1C96DC2450A01B5660F756D1BDDE3B49B4887035 CN=*.testdomain.com
Vollständiger Befehl
So könnte dann z. B. der vollständige Befehl aussehen:
|
1 |
netsh http add sslcert ipport=0.0.0.0:443 certhash=3638de9b03a488341dfe32fc3ae5c480ee687793 appid={5d89a20c-beab-4389-9447-324788eb944a} |
Für einen tieferen Einblick hat Ian Parramore noch einen sehr guten Artikel geschrieben. Diesen finden Sie hier:
https://blogs.technet.com/b/applicationproxyblog/archive/2014/06/19/how-to-support-non-sni-capable-clients-with-web-application-proxy-and-ad-fs-2012-r2.aspx
Leave a Reply
<p>Danke für Ihre Anregungen, Fragen und Hinweise.<br/>Infos zum <a href="https://www.active-directory-faq.dekontakt/">Datenschutz</a></p>