Note: Outlook 2010 reverses the information below. Basic Authentication passwords *are* saved, and in fact don’t require Professional edition of windows (as NTLM password saving would do).
All the stuff I see out there, from knowledgeable people like Daniel Petri, seems to recommend using Basic Authentication over HTTPS for RPC/HTTP. The problem with this is that Outlook will prompt for the user’s password every time, which could be useful in some situations, but it’s a pain in other situations.
The solution to stopping the password prompt is to use NTLM. There is a lot of discussion around people playing with lmcompatibilitylevel in the registry (under HKLM\System\CCS\Control\Lsa), and people talk about it in a hit and miss sort of way, e.g. “this way worked for me, but not that way”, and then somebody else does it a little differently. The consensus comes across that there’s no one way that just works.
Well, for me there is one way that just works. I’ll point out a few gotchas that can get in the way too.
Here’s how I do it. If for some reason this is bad, please let me know!
1. I “connect using SSL”.
2. I do not “mutually authenticate”, so that second box is left blank and greyed out.
3. I always have “on slow networks connect using HTTP first”.
4. I sometimes have “on fast networks connect using HTTP first”, but I configure split-DNS so that if the user is within the office, the Exchange proxy resolves to the internal IP of the RPC proxy. I do this just to test that RPC/HTTP is working. I Ctrl-RightClick the Outlook icon in the system tray and check the connection status to see if we’re working over HTTPS.
5. I set lmcompatibilitylevel to 2.
I use self-signed certificates, so I first browse to https://server, when the certificate warning comes up I view the certificate, go to the last tab and import the certificate. I manually choose where to store the cert and I put it in trusted root certification authorities. If the client is Vista then I “run as administrator” Internet Explorer before doing this.
In SBS 2003, under IIS Manager -> websites -> default website -> RPC or RpcWithCert -> Properties -> Directory Security -> Authentication & Access, “Integrated Windows Authentication” is disabled out of the box, so NTLM doesn’t work until you tick this. This is easy to forget.
In SBS 2003, if you change the server’s IP address and subnet, e.g. from 192.168.0.x to 192.168.1.x or 10.x.x.x, you might want to check “IP address and domain name restrictions” on that same tab in IIS Manager as above. Also do the same for Microsoft-Server-ActiveSync because your smartphones won’t be working.
In SBS 2003 no ports need configuring.
In normal Server 2003 & Exchange 2003, I use “RpcNoFrontEnd” from the Petri.co.il article to configure the ports for me, after I have ticked to enable Exchange for RPC as per Daniel’s instructions.
Be Broadband (http://www.bethere.co.uk)’s Speedtouch routers won’t port-foward HTTPS when configured through the GUI. This is a pain. I’ll do a separate blog entry for how to fix that.
That’s about it. It works every time for me, for different companies with different ISPs. In most cases, the client computer is joined to the domain and the user is logging onto the computer with their domain account, hence there are no popups asking for the password when launching Outlook. If the computer is not joined to the domain, I open up User Accounts in the Control Panel and I click “Manage network passwords”, and I add something like “*.ourdomain.local” and put the password in and the username in the form of either user@domain or domain\user, and also “mail.ourdomain.com” (the outside hostname/IP) and put the credentials in there too. This works fine for XP Pro/Vista Business computers that aren’t part of the domain. For Home Edition of XP or Vista, the user name must be correct, (this cannot be changed after the user is created on the computer – renaming just alters the display name and not the username), and the user’s password must match. I also set the workgroup to be the same as the netbios domain of the company. This seems to work fine, of course along with the lmcompatibilitylevel tweak.
I’d be interested if anybody knows any reasons why the above should not be the preferred way of doing things. I know I should look into getting certificates from a globally trusted CA, as it’s a pain for OWA users with a self-signed cert.
Comments (1)