As already announced in Part 1, we will now look at the Outlook Anywhere connection (RPCoverHTTPS) itself and why the certificates play a decisive role.
As shown in the first part, the Outlook profile was updated and the Outlook Anywhere settings were transferred to the client:
My test computer is no longer connected to the local network but via UMTS and wants to use Outlook Anywhere. Outlook is started and after a short time a window appears prompting me to enter my user name and password.
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 part 1, the certificate was also not adjusted, which is why this certificate error occurs directly after logging in:
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/
To avoid warnings or errors, the following names must appear on the certificate:
- autodiscover.frankysweb.org
- oa.frankysweb.org
- EX1.frankysweb.local
- autodiscover.frankysweb.local (optional, only if no SRV record has been configured internally, but a HOST-A entry)
- EX1 (optional, but helpful if users get the idea to type in https://EX1/owa)
The name of the CAS array does not have to be on the certificate, but it can't hurt to include it if the name of the CAS array is also used for OWA etc. The name autodiscover.frankysweb.org does not necessarily have to be on the certificate either, but then SRV records must be configured for the frankysweb.org domain. Not every provider supports this (Strato does). A certificate with at least 2 names is therefore required: Outlook Anywhere DNS name and internal FQDN.
After I configured a suitable certificate, the Outlook Anywhere connection now also works. In the screenshot you can see that Outlook now establishes a connection via the proxy server oa.frankysweb.org to the server outlook.frankysweb.local.
But what exactly is happening? When Outlook is started, Outlook first tries to reach Autodiscover. different ways off. Only then does Outlook establish a connection to the proxy. In this case, the proxy is the Exchange Server itself. The connection therefore arrives at the IIS in the /RPC directory. The connection therefore appears in the IIS log files, for example here is an excerpt if the UMTS connection is anything but stable (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
And here is an example of calling 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
Normally, the output should look something like this:
And for the sake of completeness, the DLL can be found here: c:\Windows\System32\RpcProxy and there is a configuration for it in the registry, which in turn is also overwritten by RpcHttpConfigurator every 15 minutes, so changing it here doesn't help much either.
Pretty much everything relevant is logged in the log files mentioned above, so it is a good starting point for error analysis.
Part 3 then deals with the client side.