The end customer had migrated from EX2007SP3 to EX2013 earlier this year. In January or so they uninstalled EX2007 environment based on http://technet.microsoft.com/en-us/library/bb123893(v=exchg.80).aspx. Everything worked flawlessly until they installed Exchange 2013 CU4 (SP1).
After the CU4 update both Outlook, Lync and also Internet explorer was unable to authenticate with EWS and Autodiscover sites. The Outlook clients could not use OOF and other services based on Autodiscover and EWS. Lync was repeatedly getting credential prompts, and was not able to integrate with Exchange.
NB!: The testexchangeconnectivity.com and external users did not report any problems.
Outlook fix, but obviously not the fix :
After resetting the EWS and Autodiscover virtual directory in IIS and changing the authentication method on Windows authentication to use NTLM before Negotiate all Outlook clients and internet explorer issues were solved,
But Lync clients had the same continuous credential prompts, and could not authenticate with Autodiscover and therefore never get the URL for EWS. From netmon traces from both server and clients the traffic seemed to be OK, the only thing it reported was URL: /autodiscover/autodiscover.xml HTTP:Response, HTTP/1.1, Status: Unauthorized.
I tested another application (calendar sync tool) that use EWS to synchronize calendar items. This tool using NTLM authentication, and I could see the same issue from that tool. It was unable to authenticate on NTLM.
The actual problem:
I then looked at security logs on a domain controller, and finally found this event (in red)
Log Name: Security
Date: 18.06.2014 14:42:34
Event ID: 4769
Task Category: Kerberos Service Ticket Operations
Keywords: Audit Success
A Kerberos service ticket was requested.
Account Name: email@example.com
Account Domain: domain.com
Logon GUID: GUID
Service Name: OLDCAS$
Service ID: DOMAINOLDCAS$
Client Address: ::IP
Client Port: 50835
Ticket Options: 0x40810000
Ticket Encryption Type: 0x17
Failure Code: 0x0
Transited Services: –
This event is generated every time access is requested to a resource such as a computer or a Windows service. The service name indicates the resource to which access was requested.
This event can be correlated with Windows logon events by comparing the Logon GUID fields in each event. The logon event occurs on the machine that was accessed, which is often a different machine than the domain controller which issued the service ticket.
Ticket options, encryption types, and failure codes are defined in RFC 4120.
I found that the domain controller issued kerberos tickets to the client. But it was issuing for and old and decommissioned EX2007 CAS server.. WTF?!?!
The service name (OLDCAS$) was the old Exchange 2007 CAS server. Which was uninstalled correctly back in January or so. I searched Active Directory after the computer name, and found the computer object. The server was removed from the network. After disabling the computer account, the clients was getting correct Kerberos ticket and was correctly authenticated.
From what I can see, it does not stand anything about deleting the computer account from the Exchange uninstall documentation. But off course this is best practice.
I has submitted this as a bug to MS Support, waiting for the response.