Hello, We have a 2 node CAS server and a separate 2 node DAG mailbox server Exch2013CU7 environment.  After a reboot a couple of days ago the OWA and ECP pages are able to be logged into by any user or Ex Admins.  This is an existing year-old environment that hasn't had any issues until this a couple of days ago.  The OWA and ECP pages load however after entering the credential and user name and clicking the Sign in link the page returns to the login page.  On some occasions theres a message that it's opening mailbox which then quickly changes to Still working on it after which it never does open the mailbox or opens the ECP page.  This also occurs internal and external and has the same response

Ive browsed this and other forums and found information about the IIS binding settings which state to remove the http and https binding with the 127.0.0.1 which has been done.  There are two other bindings for 80 and 443 with the * are still present.  Ive confirmed that there is the correct SSL certificate on those bindings.

Ive also confirmed the OWA and ECP virtual directories and see that the Basic and Forms Authentication are set to True.  The others are set to false.

Ive confirmed that the settings are the same on both CAS servers.  So far the ECP and OWA are not able to be logged into.

Appreciate any help on this to be able to log in to the ECP and OWA. 

Thank you.

Are all the Exchange services running on the CAS box?

On a side note, it is ideal to have a multi-role server in 2013, it will save money spend on hardware, Windows and Exchange licenses and that is the recommended way to deploy. 

Thank you Rajith and yes the services are running. 

This issue has been corrected internally.  It was a tough fix but corrected the issue.

Additional Info: Over 2 weeks prior the certificates had been changed out but the server had not been rebooted.  That allowed the cache of the cookie type and the new certs were performing correctly until the reboot when that functionality was reset. 

Steps followed:  The issue described is exactly described in this blog http://blogs.technet.com/b/jasonsla/archive/2015/01/15/the-owa-and-ecp-fba-redirect-loop.aspx

1. We exported the current certificate using the certificate manager, MMC to c:\temp\sslcer.pfx

2. We were using the cert for IIS and SMTP Exchange services.

3. We exported the certificate from the MMC with the private key but with the Delete Private Key if export successful check box.https://technet.microsoft.com/en-us/library/aa996305.aspx (bottom Important Note)

4. The certificate was verified that it didnt have the private key and then was deleted in the Certificate MMC

5. We then did the certutil -csp "Microsoft RSA SChannel Cryptographic Provider" -importpfx c:\temp\sslcert.pfx      but we got an error that it was not supported.  The certificate being a Windows cert there were headers in the certificate that was causing the issue for the conversion to The MS RSA Cryptographic Provider type of cert.  One of our Linux engineers used openSSL to correct the headers, resaved the certificate and then gave it back to continue.  (OpenSSL details were not provided)

6.  That allowed the certificate to be imported using step 4 of the blog.

7.  Rebooted the server.

8.  We checked the cert was back in the Certificates manager MMC

9.  Logged into the local computer URL https://CAS1/ECP which allowed the log in to ECP. 

10. We verified the cert is Server/Certificates and verified the Services assigned to the cert.  SMTP and IIS were checked.

11. Rebooted

12.  We repeated all of the steps for our second CAS server except the conversion process of the SSL cert with OpenSSL.

13.  The ECP and OWA were both able to be logged into on CAS1 and only OWA on CAS2.  One of the troubleshooting steps earlier had been to change the Authentication settings in IIS for the Form Authentication for ECP.  It had been set to Enable.  We disabled the Form Authentication and the ECP was able to be logged into.

 Additional note:  With the OpenSSL sidestep the solution from Jason Slaughter was dead on.  Thanks to him for that.  We choose the single role exchange servers for a reason.  We also use Kemp NLB which to keep mail flowing we disabled each of the CAS servers as we worked on them.