This week I was at a customer site who had problems logging in to Exchange webmail. After logging in using the forms-based authentication dialog it took the site about a minute to show the contents of the inbox. Analyzing the problem with Wireshark or the builtin Forefront TMG did not show any usable information as all traffic was redirected to the exchange server correctly. Also, Exchange ActiveSync behaved normally and fast.
In my case, the customer used Microsoft Exchange 2007 with Microsoft Forefront TMG 2010 RTM. After some inspection of the Web listener I saw that the following options were enabled:
- Allow users to change their passwords
- Remind users that their password will expire in this number of days …
To remove the delay when authentication is performed after logging in, disable the option that enables users to change their passwords at the initial login screen presented by Forefront.
So what is happening under the hood?
In the time that you are waiting a minute for your inbox to appear (or grabbing a cup of coffee in the meantime) forefront does the following when the password options are enabled:
When Windows Server 2003 detects the default purpose setting of “Client Authentication”, the operating system attempts to perform TLS with mutual authentication to the domain controller. The mutual authentication process requires ISA Server to have access to the private key of the server certificate with the “Client Authentication” setting enabled, and ISA Server does not (and should not) have this access.
Solution: Ensure that all server certificates do not have the default “Client Authentication” purpose enabled. You can disable this setting on the property pages of the relevant server certificate.
According to the above mentioned site it is also possible to disable the “Client Authentication” Purpose of your certificates used on both your ISA server and domain controllers. Using this method, you can keep using the option to change the password before logon.