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


> When you say it works fine under basic authentication, do you mean that
> you
> were asked for a password, you gave it, and then it connected fine?

Exactly.

> If it worked with basic authentication, did you remember to change the
> NTLM authentication and SSL settings in IIS when you changed the
> configuration in Outlook to use NTLM and SSL?

Yes. With Outlook changed to NTLM (and the server/IIS changed to NTLM), the
server never asks for a password at all.

> To see if it's a certificate issue, go to RWW or OWA (using your server's
> external IP address) and see if it pops up a security alert about your
> certificate. If it does, there's your problem; the certificate needs to
> be installed, have valid dates, and the name should match the name of your
> server (in this case, it's IP address) to avoid the security alert. A
> certificate issue will prevent Outlook from connecting via SSL without
> giving you any sign of why.

Can it be the SBS/Self-signed cert, or must it be an actual, 3rd-party cert?

GaryK

>
>
> "Gary Karasik" <gkarasik@xxxxxxx> wrote in message
> news:e2JgDDtlFHA.664@xxxxxxxxxxxxxxxxxxxxxxx
>>I may be missing a step. When I set Outlook for NTLM (after confirming the
>> other steps), Outlook doesn't ask for a password--just tries to open,
>> then
>> tells me there's no Exchange server available. Everything works fine
>> under
>> Basic Authentication. I did see the NTLM password prompt once, and check
>> remember password, and that may be the problem--wrong password may be in
>> there, but I can't figure out how to clear it if that is the problem.
>>
>> GaryK
>>
>> "Bryan L" <blinton.nospam@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:%23%23EA4VslFHA.3256@xxxxxxxxxxxxxxxxxxxxxxx
>>> My pleasure. My only request is that you and others post back their
>>> results if they find this helpful (or not).
>>>
>>> Bryan
>>>
>>>
>>> "Gary Karasik" <gkarasik@xxxxxxx> wrote in message
>>> news:uqD45JslFHA.420@xxxxxxxxxxxxxxxxxxxxxxx
>>>> Thanks for taking the time to do this, Bryan.
>>>>
>>>> GaryK
>>>>
>>>> "Bryan L" <blinton.nospam@xxxxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>>>> news:e1eFa$rlFHA.1412@xxxxxxxxxxxxxxxxxxxxxxx
>>>>> 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: (New Subject): How to eliminate prompt for credentials when using RPC over HTTP
    ... If it worked with basic authentication, did you remember to change the NTLM ... Outlook to use NTLM and SSL? ... To see if it's a certificate issue, go to RWW or OWA (using your server's ...
    (microsoft.public.windows.server.sbs)
  • Re: Can we use public IP?
    ... you've set it to use Basic authentication, not NTLM, as NTLM ... Your FE server is Exchange 2003, ...
    (microsoft.public.exchange.admin)
  • Re: ASP.NET + SQL Server Windows authentication
    ... Think the problem is just a limitation of NTLM single hop. ... > Trying to understand why I can not get SQL server to trust my IIS server. ... Basic Authentication will transfer the PW ...
    (microsoft.public.sqlserver.security)
  • Re: ASP.NET + SQL Server Windows authentication
    ... Think the problem is just a limitation of NTLM single hop. ... > Trying to understand why I can not get SQL server to trust my IIS server. ... Basic Authentication will transfer the PW ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • Re: NTLM for extranet users?
    ... > Does any one had success with NTLM over firewall??? ... Why not go the easy way and use Basic Authentication (and SSL if you ... want to secure this a bit) using another virtual server which you map to ...
    (microsoft.public.sharepoint.portalserver)