(New Subject): How to eliminate prompt for credentials when using RPC over HTTP

It's been a while, but here's what I remember about what I had to do. Note
that your Outlook 2003 client must be running on XP Pro for this to work.
XP Home can connect fine, but it will always prompt for credentials even if
you follow all these instructions. That's just the way it is,
unfortunately. For the benefit of others, I've tried to make this as
comprehensive as I can (and have time for). For additional information
resources, see the KB link at the end of this post.

Also please note that I'm certainly not a SBS MVP, or any other kind of MVP,
for that matter. Any corrections or clarifications by the experts are
welcome and should be taken into consideration.

The basic things that must be done:

- Make sure the web certificate for your SBS is correctly configured, and
that it is installed on the client running Outlook 2003.
- Make sure the RPC virtual directory in IIS is configured to use Integrated
Windows authentication instead of Basic authentication, and to use 128-bit
SSL encryption.
- Make sure the client's registry is configured to use LMCompatibilityLevel
2 or 3
- Configure Outlook's Exchange Proxy Settings with the Public IP, SSL, and
authentications settings that match what you did in the steps above.

I'll now hit on each of the above.


*Certificate Configuration*

First of all, a web server certificate is automatically created when you run
the Configure E-mail and Internet Connection Wizard. This certificate is
used to configure Secure Sockets Layer (SSL), which secures communications
between a Web browser and your Web server. You need to be using such a
certificate, and it needs to be configured so that no Security Alert pops up
regarding the certificate. To avoid the security alert pop-up, three things
must be true:

1. That certificate needs to be trusted by the client (installed on the
client).
2. The certificate must have valid dates.
3. The certificate name must match the name of the page using it.

Take care of any issues with "2" or "3" before doing "1". The reason for
this is that if you have to make changes to 2 or 3, you'll have to reinstall
the certificate on the client anyway.

If you're not sure whether you've created a certificate for use with SSL, do
this: while visting RWW or OWA, check the address bar. If it says "https:",
then your server is using a certificate; if it says "http:", you should run
the Configure E-mail and Internet Connection Wizard to create a web
certificate.

If you have already created a certificate but find you need to change the
valid dates or certificate name, re-run the wizard. When choosing a name,
consider the following:

- We are a smaller organization and do not have a public DNS entry for our
public IP (our website is hosted elsewhere), so we have to use the public IP
when connecting to OWA and RWW services on our server. To avoid problems
with the name not matching, I re-ran the wizard and selected our public IP
address as the Web server name. I'm assuming that you already have port
forwarding or 1:1 NAT set up to direct this external traffic to your
server's internal IP.

Once you've set things up so the certificate name or valid dates won't cause
a security alert, you can install the certificate on the client. To do
this, on the client computer, navigate to RWW or OWA using your public IP
address. When the Security Alert dialog box appears, there should be only 1
yellow alert that says "The security certificate was issued by a company you
have not chosen to trust"; the other two items should have green check marks
and say "The security certificate date is valid" and "The security
certificate has a valid name". If not, go back and make sure you've
addressed those issues. If the only alert is on the certificate not being
trusted, click View Certificate, and then Install Certificate. Accept all
defaults offered by the Certificate Import Wizard until the installation is
complete.

Now, a visit to RWW or OWA should not cause a Security Alert. This means
the certificate is correctly installed. This is important, because if
Outlook tries to use RPC over HTTP with SSL and the certificate isn't
correctly configured, you won't get a warning or a message; it just won't
connect.



*IIS Configuration on SBS*

- Open IIS on the SBS. Browse to the Default Web Site > Rpc virtual
directory, right-click it, and choose "Properties", then select the
Directory Security tab.

- Under Authentication and access control, click Edit. The default setting
here will probably be "Basic authentication (password is sent in clear
text)". Change it to "Integrated Windows authentication" and make sure it's
the only checkbox selected, then click OK.

- Under Secure communications, click Edit. Make sure "Require secure
channel (SSL)" and "Require 128-bit encryption" are both checked. Under
Client certificates, you probably want "Ignore client certificates" (that's
what I've got). Click OK to exit all dialog boxes and close IIS.


*LMCompatibilityLevel settings*

- Open registry editor by clicking Start > Run, and typing regedit, then hit
enter or click OK

- Locate and the click the following registry subkey:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\

- In the right pane, double-click lmcompatibilitylevel

- In the Value data box, type a value of 2 or 3 that is appropriate for your
environment, and then click OK. Then quit registry editor and restart your
computer.


*Configure Outlook*

- Navigate to the Exchange Proxy Settings box in Outlook 2003.

- For the URL to connect, type the external IP used to connect to your SBS;
this should also happen to be what you used as the Web server name in the
Configure E-mail and Internet Connection Wizard.

- Select the "Connect using SSL only" checkbox and the "Mutually
authenticate" checkbox underneath it. In the "Principal name for proxy
server" field, type "msstd:" followed immediately by the Public IP address
you just typed above, using no spaces.

- Under "Proxy authentication settings", choose "NTLM Authentication"

Note: if you're doing this on the SBS Lan (or if you have a *very* fast WAN
connection to your SBS from the outside), you might want to also check the
"On fast networks" option in addition to the "On slow networks" option, so
you can test whether RPC over HTTP is working properly. Do this by running
Outlook from the command prompt with the /rpcdiag switch. If you don't want
to use RPC over HTTP for fast connections, make sure you change this setting
back once you've finished testing.

And, you're done! Unless I'm forgetting something (I don't think I am, but
I could be wrong), you should now be able to connect Outlook 2003 clients
running on XP Pro to Exchange, without providing credentials. Except for
the first time, of course; enter the password and tell it to remember it,
and you shouldn't have to type it again.

This works for home computers even when the computer is not a member of the
domain, and the user account name used at home doesn't match the domain
username of the exchange user. I don't recall if you need a VPN connection
for the initial setup of the user in Outlook, but I don't believe you do, if
all this is correctly configured; you should be able to resolve the user
name over the RPC over HTTP connection during setup. Again, if I'm
misstating this, someone more expert than me will hopefully please say so.

Hope this was useful.

For more information, here's one article you may wish to refer to:

http://support.microsoft.com/default.aspx?scid=kb;en-us;820281

Good luck!

Bryan


"Gary Karasik" <gkarasik@xxxxxxx> wrote in message
news:Ozieh3IlFHA.708@xxxxxxxxxxxxxxxxxxxxxxx
> How have you configured this so that Outlook supplies the credentials? I
> haven't been able to figure out how to do that.
>
> GaryK
>


.

Relevant Pages

  • RE: Outlook HTTPS over RPC error - Inconsistent users
    ... If the clients are using Outlook with PRC over HTTP and issue ONLY occurs ... issue which means it might be a client Outlook configuration or workstation ... over HTTPS because there is a problem with the certificate assigned to the ... With RPC over HTTPS no such pop up ...
    (microsoft.public.windows.server.sbs)
  • Re: Somewhat Urgent - Exchange 2007 Configuration Question
    ... public cert> ... to resolved the internal / external certificate issue. ... for "Exchange" so Outlook clients no longer get the certificate warning. ... The client computers having this issue are located across a security ...
    (microsoft.public.exchange.admin)
  • Re: (New Subject): How to eliminate prompt for credentials when using RPC over HTTP
    ... > that it is installed on the client running Outlook 2003. ... > *Certificate Configuration* ... > Security Alert pops up regarding the certificate. ...
    (microsoft.public.windows.server.sbs)
  • Re: (New Subject): How to eliminate prompt for credentials when using RPC over HTTP
    ... When I set Outlook for NTLM (after confirming the ... >>> and that it is installed on the client running Outlook 2003. ... a web server certificate is automatically created when you ... you can install the certificate on the client. ...
    (microsoft.public.windows.server.sbs)
  • Re: Cannot request computer certificate.
    ... >problem since you can not request a certificate while logged onto the CA. ... Verify that you can ping it by name and IP address from the client ... >> Kerberos, or dns. ... >> List of NetBt transports currently bound to the Redir ...
    (microsoft.public.windows.server.security)
Loading