EWS / Autodiscover authentication failures & repeated password prompts

I recently separated an Exchange 2010 server from a single server with all roles to 4 servers (2 CAS/HUB, 2 MBX). Upon doing this I renamed the servers to be org consistent. I didn't want users to have to change settings in Outlook so I kept the old DNS name "email.company.com" pointing to the new CAS/Hub server. Doing this broke somethings, one of which has been a bitch to fix. EWS/Autodiscover would not authenticate correctly and was constantly prompting some users for their credentials. When these login prompts would come up, they would not leave any trace on the server about why they were failing, but I did find errors on the clients. This one in particular:

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server CASHUB01$. The target name used was HTTP/email.company.com. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Please ensure that the target SPN is registered on, and only registered on, the account used by the server. This error can also happen when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Please ensure that the service on the server and the KDC are both updated to use the current password. If the server name is not fully qualified, and the target domain (COMPANY.COM) is different from the client domain (COMPANY.COM), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server.
Basically the error is saying: "Keberos is f*cked because your trying to use a DNS name other than the actual server name,  fix that shit." Another way I found this problem is trying to login to the services via Internet Explorer, yes IE, there's a reason for this, I'll explain in a minute. So, try to login to these to urls with IE:

https://yourExchServer.yourDomain.com/EWS/Exchange.asmx
https://yourExchServer.yourDomain.com/Autodiscover/Autodiscover.xml

If you get repeated password prompts even though you know the credentials are correct, it's the Keberos Negotiating Authentication bullshit. The reason I say use IE is because Chrome and Firefox don't handle Windows Authentication differently than IE and will let you login correctly (shows xml code).  I didn't research why the other browsers treat it differently, it doesn't really matter. What matters is that Outlook and IE handle authentication similarly, they typically try to Negotiate a connection first and then go on to other methos (NTLM, Basic, your mom). Onward, to the fixes!

Client-side Fix, Outlook (2007 & 2010): 
  1. Close Outlook
  2. Start > Control Panel
  3. Open the Mail icon
  4. Click the Email Accounts button
  5. Highlight your account, click the Change button
  6. Click the More Settings button
  7. Click the Security tab
  8. Change Logon network security to NTLM
  9. Click OK
  10. Click Next > Finish
  11. Close remaining Windows
  12. Launch Outlook
It may prompt you initially for a username and password, enter the credentials and check Remember Password. You should be good to go.

Server-side Fix, IIS 7 (On CAS server):
  1. Open a command prompt
  2. Type: cd c:\windows\system32\inetsrv\
  3. Type: appcmd list config /section:windowsAuthentication 
    1. You'll see something like this:
      <system.webServer>
      <security>
      <authentication>
      <windowsAuthentication enabled="true" useKernelMode="false">
      <providers>
      <add value="Negotiate" />
      <add value="NTLM" />
      </providers>
      </windowsAuthentication>
      </authentication>
      </security>
      </system.webServer>
    1. Notice the two highlighted areas, we need to reverse these so NTLM is first.
  4. Type: Appcmd.exe set config /section:windowsAuthentication /-providers.[value='Negotiate']
    1. This removes the "Negotiate" entry
  5. Type: appcmd.exe set config -section:system.webServer/security/authentication/windowsAuthentication /+"providers.[value='Negotiate']" /commit:apphost
    1. This adds "Negotiate" back, but under NTLM.
  6. Type: iisreset (Note: don't issue this command during the day, you'll temp disconnect all mail users!)
That's it folks. If you have any questions, post them in the comments. 

The server side fix comes from Scott Oseychik's blog, found here: http://blogs.msdn.com/b/scottos/archive/2008/10/16/why-is-communicator-prompting-me-for-credentials.aspx Much props to him for the commands. His post is about Microsoft Communicator, but it also applies to this situation in Exchange, take a read.

Comments

  1. Some might say a better solution is to fix the kerberos, and not use NTLM.

    NTLM is from Windows 3.1 era, and MS has been recommending for ten years to turn it off.

    ReplyDelete
  2. True, NTLM is archaic but still fully supported by Microsoft. As far as fixing this problem, Microsoft did come up with a workaround to get MAPI clients 'kerberized' listed here: http://technet.microsoft.com/en-us/library/ff808313.aspx

    ReplyDelete
    Replies
    1. Maybe supported but hardly secure you dumb shit

      Delete
  3. the client side works for me...however, within a few minutes it reverts right back to "negotiate authentication" and the dreaded password prompt that never accepts the password.

    ReplyDelete
  4. Excellent blog you’ve got here.It’s difficult to find high-quality writing like yours nowadays. I really appreciate individuals like you! Take care!! Please check out my site.
    Email list providers

    ReplyDelete
  5. All you had to do was add the default domain and realm to the proper virtual directories you dumb asshole

    ReplyDelete

Post a Comment

Popular posts from this blog

Cisco ISR 4331 slow upload speed on Verizon FiOS circuit

Troubleshooting Active Directory Account Lockouts

ESXi 5.5: Host gets 503 Service Unavailable error, hostd service will not start