Forum Discussion
mikem_62860
Nimbostratus
Nimbostratusf5 and Exchange 2010 Outlook 2010 password prompt
I am experiencing a password prompt on Outlook 2010 on a initial load. For example, I reboot my machine, log into Windows, then load up Outlook 2010. I get a password prompt.
What I am noticing on the Connection Status when I see the password prompt is that it is pending on "Referral" or "Mail". I see it waiting on TCP/IP and HTTP.
If I change my local hostfile to point to a Exchange 2010 CAS front-end, I never get a prompt.
I have removed the oneconnect profile. I have changed to be kernel auth on all virtual directories. I don't know what else to do. Any thoughts?
On the client side we are migrating users to Exchange 2010 with Windows 7 64bit and 32bit Outlook 2010.
What I have noticed with the one offs that are still on Outlook 2007 but on Exchange 2010 is there are constant password prompts. Putting in credentials doens't work. You have to hit cancel, then try to auth again and it seems to work until it happens again. We aren't really support Outlook 2007 on Exchange 2010 but it may be a clue?
Any ideas?
- Hi mikem-
Did you manually configure your BIG-IP, use the iApp included in 11.0.x-11.1.x, or use the new downloadable iApp? Also, are you using the APM module, or LTM only?
If you've done anything other than use the new iApp, please try that and see if your results differ. It could be, for instance, that EWS (used by Outlook for Free/Busy lookups) isn't configured correctly, or something of that nature.
I believe you shouldn't have to enable kernel authentication mode.
Can you please open a support case with F5? A support engineer will work with you to gather qkview and other relevant info from your BIG-IP system and can then offer some suggestions.
Thanks. 
brent112_11716We had the same issue, I spent about 4 months on a support case with F5 before finally finding the fix. On the exchange http and https combined virtual server set the failback persistence profile to *appname*_source_address_persistence_profile. The latest downloadable iapp does this for you when you set it up.
Also under the Exchange source address persistence profile check both "match across services" and "match across virtual servers".
After doing the above steps and then deleted all existing persistence records for the virtual server the popups stopped.
mikem_62860Dayne, we are still on 10.2.1. We do have a ticket open with f5 but nothing has been resolved yet.
Brent, I did try this, and it didn't seem to work.
I am not sure if this is the solution, but what seemed to have resolved it for us is setting NTLM on OutlookAnywhere for -ClientAuthenticationMethod and -IISAuthenticationMethod
Set-OutlookAnywhere -Name CASServer -IISAuthenticationMethod Basic,NTLM
Identity: CASServer\Rpc (Default Web Site)
Set-OutlookAnywhere -Name CASServer -ClientAuthenticationMethod Ntlm
Identity: CASServer\CASServer
So far, no more password prompts.... I am going to wait a couple days to see if this is the solution.
Michael_Koyfma1Cirrus
Did you follow the errata in the 10.2.1 Deployment Guide to disable OneConnect when Negotiate header is detected? Sounds like the fact that OA was trying to Negotiate instead of offering straight-up NTLM was tripping this up - but disabling OneConnect for those requests should've solved it.- mikem_62860This is one of the things we did per the tech and it did not resolve the issue...
In OutlookAnywhere options on the Outlook client, we see that there is Basic Auth and NTLM as the options. I do not see a Negotiate selection. Does Basic mean negotiate?
Mike - Michael_Koyfma1Outlook Client settings don't matter in this case - the issue is caused by the CAS trying to use Negotiate header for Kerberos and NTLM when it does 401 challenge to the client.
Scott_Polton_82Just a guess but it sounds like you might have a certificate issue. Are you offloading SSL? if so then when you connect direct to the CAS you are not using SSL.
Another thought: We were having problems connecting via RPC at all until we manually unchecked the "port translation" option on the Exchange RPC Virtual Server. We are NOT offloading SSL so traffic is being re-encrypted before passing to the CAS.
