Wednesday, April 04, 2007

While I'm In Nerdville...

I'm putting up this post for my own posterity, as the next time I blow up my Exchange Server configuration I'll hopefully have enough bread crumbs laying around allowing myself to fix the problem in an expedient manner. That is, in less than an hour rather than a whole week. This little story is actually an epoch, so you can either bail out or buckle up.

I had a bangup week when the church server blew up, because that same week I also messed up my access to my Exchange server. Typically Outlook will talk with Exchange Server over using RPC (remote procedure call) protocol over the Internet. RPC allows one computer to pass commands to another computer over the network. RPC uses port 135 on your computer and is typically blocked by ISP's as access to port 135 (and therefore the RPC service on any computers listening) can wreak all sorts of neat havoc, as you can imagine.

So Microsoft introduced HTTP over RPC, effectively wrapping RPC calls inside of the same protocol used for web surfing. I won't go into the gory details of how to enable this on an Exchange Server as there are two great how-to articles I've used here and here.

In my original setup of this I had deviated from their recommended plan and used plain HTTP rather than HTTPS for the simple reason that I did not want to pay for a server certificate for the box. These can cost anywhere from 75 to 300 bucks per year. Neither of these articles really touched on how to use straight HTTP for RPC. After sufficiently messing around inside the RPC folder properties in IIS I got it to work on a regular basis both in and outside my local network by using NTLM authentication without also enabling basic authentication. On the client side in Outlook I configured the Exchange account to use NTLM authentication on the HTTP connection. Every time I fired up Outlook I would receive a username/password challenge, and after I passed through that Outlook worked hunky dory.

Until the day I installed a SharePoint site on the same server using the same default web site that the Exchange server was using for RPC. After wrestling through a few rounds of SharePoint installation struggles I told it to can the website it was using in IIS. Oops. Bye bye HTTP over RPC, bye bye Outlook Web Access, and bye bye some other projects I was hosting there for client review.

First I had to create a new default app in IIS including a place for it to live. Then with a little finagling I was able to reconstitute all the folders Exchange Server had built in the default app with a little help from this thread. Replacing the RPC folder was a sinch, and then I basically just went and redid everything those two aforementioned articles told me to do.

Except this time when I tried to log into Exchange from Outlook I kept getting prompted. Over and over and over. Every once in awhile it would log in, but most of the time not. The authentication just wasn't taking, and I tried six ways to Sunday to fix it either in IIS or in the account settings in Outlook.

From my research it appeared that it just wasn't going to work without switching the connection over to SSL and changing the authentication mode from NTLM to basic. When you do that, Outlook requires SSL. The nerve.

I'm a complete idiot when it comes to SSL, certificates, etc. I know I could install the service on my server that would allow me to issue certificates to my own websites (thereby allowing my to connect to them via SSL) but since my server is not an official certificate authority (CA) I knew that Outlook would choke when trying to log in (it did, I tried). When I used Internet Explorer to surf to the area that Outlook was trying to access, I would get one of those big ugly warning dialogs pop up telling me the certificate looked valid but the CA is not found or trusted. I tried installing the certificate through that dialog into my trusted root certification authorities (through internet options in your control panel) but it would never stick.

What did finally work was exporting the certificate from the server through IIS. I viewed the certificate in IIS for the RPC site, and then chose export. The certificate export wizard fires up, which for some reason does not appear if you try to export the certificate through the certificate authority control panel. The wizard allows you to include the private key in the certificate, which I did, and this causes the export format to be a personal information exchange (.pfx) file. I told it to include all certificates in the path, enable strong protection, and to leave the private key after exporting.

After exporting I hauled this key over to my laptop and imported it into the trusted root certification authorities. Bingo, it stuck, and when I tested in IE it worked without popping up a big ugly dialog box. The final test, using Outlook, also passed. It prompts me once the first time I log in, but then connects and is happy. I can also see that Outlook is using HTTPS for the connections to Exchange Server when snooping the Exchange Server connection status window. See, when I had the whole shooting match configured for HTTPS without actually implementing HTTPS, Outlook would fall back to TCP/IP on the local network. Great at home, not so much when accessing through the Internet.

The benefit of going through this pain and anguish is that now my email communication is encrypted. All it cost was about a week of my life and 1/16th of an inch of my hairline.

No comments: