Wie schon in Teil 1 angekündigt geht es nun um die Outlook Anywhere Verbindung (RPCoverHTTPS) an sich und warum die Zertifikate eine entscheidende Rolle spielen.
Wie im ersten Teil zu sehen war, wurde das Outlook Profil aktualisiert und die Outlook Anywhere Einstellungen an den Client übertragen:
Mein Testrechner ist jetzt nicht mehr mit dem lokalen Netzwerk verbunden, sondern per UMTS und möchte Outlook Anywhere nutzen. Outlook wird gestartet und es erscheint nach kurzer Zeit ein Fenster, welches zur Eingabe von Benutzer und Passwort auffordert.
Hintergrund ist folgender: In Teil 1 wurde eingestellt, das die Standard Authentifizierung verwendet werden soll, und Standard Authentifizierung erfordert das Benutzername und Passwort eingegeben werden. Der Benutzer kann natürlich auf „Anmeldedaten speichern“ klicken. Es ist also ein ganz normales Verhalten das an dieser Stelle Benutzername und Passwort abgefragt wird.
In Teil 1 wurde ebenfalls das Zertifikat nicht angepasst, daher kommt es direkt nach der Anmeldung zu diesem Zertifikatsfehler:
Wer genau hinschaut erkennt, das es sich um 2 Fehler handelt: Die obere Meldung zeigt an, dass zwar ein Zertifikat von einer vertrauenswürdigen CA ausgestellt wurde, aber der Name „autodiscover.frankysweb.org“ nicht auf dem Zertifikat gefunden wurde. Die obere Meldung könnte man noch bestätigen, aber die untere zeigt an, das jetzt ein schweres Problem mit dem Zertifikat gibt. Im ersten Screenshot sieht man das der Haken bei „Verbindung nur mit Proxyservern herstellen, deren Zertifikat folgenden Principalnamen enthält“, heißt frei übersetzt: Keine Verbindung solange nicht „oa.frankysweb.org“ auf dem Zertifikat steht. Jetzt könnte man den Haken manuell entfernen, aber Autodiscover konfiguriert das eh wieder um, siehe Teil 1. In diesem Fall wird ein SAN (Subject Alternate Name) bzw UC-Zertifikat benötigt. Wie ein solches Zertifikat der Windows CA ausgestellt werden kann, steht hier:
https://www.frankysweb.de/exchange-2010-san-zertifikat-und-interne-zertifizierungsstelle-ca/
Damit es zu keinen Warnungen oder Fehlern kommt, müssen die folgenden Namen auf dem Zertifikat stehen:
- autodiscover.frankysweb.org
- oa.frankysweb.org
- EX1.frankysweb.local
- autodiscover.frankysweb.local (optional, nur wenn intern kein SRV Record, sondern ein HOST-A Eintrag konfiguriert wurde)
- EX1 (optional, aber hilfreich falls Benutzer auf die Idee kommen https://EX1/owa) einzutippen)
Der Name des CAS-Arrays muss nicht auf dem Zertifikat stehen, es kann aber nicht schaden ihn mit anzugeben, wenn der Name des CAS-Arrays auch für OWA etc. genutzt wird. Auch der Name autodiscover.frankysweb.org muss nicht zwingend auf dem Zertifikat stehen, dann müssen aber SRV Records für die Domain frankysweb.org konfiguriert werden. Nicht jeder Provider unterstützt dies (Strato schon). Es wird also ein Zertifikat mit mindestens 2 Namen benötigt: Outlook Anywhere DNS-Name und interner FQDN.
Nachdem ich ein passendes Zertifikat konfiguriert habe, klappt jetzt auch die Outlook Anywhere Verbindung. Im Screenshot kann man erkennen, dass Outlook jetzt eine Verbindung über den Proxyserver oa.frankysweb.org zu dem Server outlook.frankysweb.local herstellt.
Was passiert da jetzt aber genau? Wenn Outlook gestartet wird versucht Outlook zunächst Autodiscover zu erreichen, dazu probiert Outlook verschiedene Wege aus. Erst dann stellt Outlook eine Verbindung zum Proxy her. Der Proxy ist in diesem Fall der Exchange Server selbst. Die Verbindung kommt also am IIS im /RPC Verzeichnis an. Die Verbindung taucht also in den IIS-Logfiles auf, hier zum Beispiel mal ein Auszug, wenn die UMTS Verbindung alles andere als stabil ist (C:\Windows\System32\LogFiles\HTTPERR):
2014-02-06 19:56:33 80.187.104.58 5326 192.168.100.251 443 HTTP/1.1 RPC_OUT_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:56:48 80.187.104.58 2669 192.168.100.251 443 HTTP/1.1 RPC_OUT_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:57:33 80.187.104.58 3845 192.168.100.251 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool 2014-02-06 19:57:48 80.187.104.58 18916 192.168.100.251 443 HTTP/1.1 RPC_IN_DATA /rpc/rpcproxy.dll?outlook.frankysweb.local:6001 - 1 Timer_MinBytesPerSecond DefaultAppPool
Und hier ein Beispiel für den Aufruf von Autodisover (c:\inetpub\logs\LogFiles\W3SVC1)
2014-02-06 19:54:39 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 0 0 1343 2014-02-06 19:54:56 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 0 0 4404 2014-02-06 19:55:02 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 - 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 401 1 2148074254 5826 2014-02-06 19:55:05 192.168.100.251 POST /autodiscover/autodiscover.xml - 443 FRANKYSWEB\frank 80.187.104.58 Microsoft+Office/14.0+(Windows+NT+6.1;+Microsoft+Outlook+14.0.6129;+Pro) 200 0 0 2327
Wie schon in Teil 1 beschrieben, tunnelt der Dienst „RPC-über-HTTP-Proxy“ die Outlook Verbindung an den Dienst „Microsoft Exchange RPC-Clientzugriffsdienst“. Im CAS Log findet sich dann zum Beispiel ein Logon Event (C:\Program Files\Microsoft\Exchange Server\V14\Logging\RPC Client Access)
2014-02-06T19:56:12.477Z,9,8,/o=FrankysWeb/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=usercf007cf3,,OUTLOOK.EXE,14.0.6131.5002,Cached,,,ncacn_http,,OwnerLogon,0,00:00:00.0156200,"Logon: Owner, /o=FrankysWeb/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=usercf007cf3 in database MBDB01 last mounted on EX1.frankysweb.local at 06.02.2014 19:48:05, currently Mounted; LogonId: 2",
Eigentlich handelt es sich bei dem Feature „RPC-über-HTTP-Proxy“ um keinen Dienst, sondern um eine ISAPI-Modul im IIS. Daher ist das Feature nicht direkt als Prozess im Taskmanager erkennbar, denn es wird mit dem IIS w3wp.exe Prozess geladen. Prüfen lässt sich das mit:
tasklist /m rpcproxy.dll
Im Normalfall sollte dann die Ausgabe so in der Art aussehen:
Und der Vollständigkeit halber findet sich die DLL hier: c:\Windows\System32\RpcProxy und eine Konfiguration dazu gibt es in der Registry, die wiederrum wird allerdings auch RpcHttpConfigurator alle 15 Minuten überschrieben, daher bringt auch das Ändern hier nicht viel.
In den oben genannten Logfiles wird so ziemlich alles relevante protokolliert, daher ist es ein guter Einstieg für die Fehleranalyse.
In Teil 3 geht es dann um die Client Seite.