From: St. Louis MO
Thought I'd share this with everyone --
I've had an ongoing problem with HTTPS publishing rules. Simply, if an external user was required to auth to a published secure site, the page load after submitting the ISA login form would take literally 2-3 minutes. Didn't matter if it was OWA or a simple HTML page - it took FOREVER.
This evening I found a hopeful-looking MSKB: 555958 However, when I checked the registry on the ISA server, all of the values were present and configured as suggested in the article.
But....on a hunch...I unticked "Allow users to change their passwords" on all of my SSL web listeners and applied the changes. I waited a few minutes and tried to log in. BINGO! Everything is soooo speedy now.
In retrospect I don't need the password-change capability at all. I'm leaving it switched off.
Please contribute to this topic if you've experienced similar behavior, or know of a better way to handle the problem.
From: United Kingdom
Does the ISA Server have a computer certificate installed that has the "Client Authentication" usage enabled?
Do you DCs have computer certificates installed that have the "Client Authentication" usage enabled?
Basically, if you have certificates that have the client authentication option enabled then the password change element introduces a delay as the servers try to utilise mutual authentication (which will fail anyhow) due to failure timeout.
Disable the Client Authentication usage on *both* ISA and the DCs - this will allow password change to be enabled, but without the slowness...
Client logon is slow and server certificates used for Web publishing are configured with the default purpose settings "Server Authentication" and "Client Authentication"
Issue: 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 as follows: Disable Client Authentication purpose on a certificate
Open the Certificates Microsoft Management Console (mmc) snap-in. To add the Certificate Manager to the mmc, do the following:
Click Start, and then click Run.
Type mmc and then press ENTER.
Select the File menu, and then select Add/Remove Snap-in.
In the Add/Remove Snap-in box, and then click Add.
Double-click the Certificates snap-in, select Computer Account, and then click Finish.
Select Local Computer, and then click Finish.
Close the dialog boxes.
In the Certificates mmc, click to expand the Certificates node, and then expand Personal.
Right-click the relevant certificate and then click Properties.
On the Details tab, click Edit Properties.
Select Enable only the following purposes, and clear the Client Authentication purpose.
This is a great post and I have fund a lot of information here but I still seem to be having a problem. The logon takes a long time and once in a while I will get the following message in the log files:
10060 A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
I have checked the certificates and allowed only the server authentication purpose. The strange thing is it seems to be hit and miss. Sometimes it authenticates right away and sometimes it takes up to 30 seconds or more.
I have tried with password changes and without it does not make a difference.
Our ISA server is on the domain and we are using AD for authentication.
I have monitored the application server that these publishing rules are setup for and have not found any packet drops on the NIC or the switch.
I found the answer to this issue and thought I would share my solution just in case.
We have an iSCSI SAN that is on a different subnet and is connected to an isolated switch. All of our servers that use the SAN have a second NIC on this subnet. The second NIC was configured to register with DNS ISA server was trying to resolve 2 seperate IP addresses which explains why it worked sometimes and not other times. To resolve this issue I unceheked the register option with DNS for the iSCSI NIC cards and now everything is working great.
Greetings, I had the same problem. Initial authentication taking up 1-2 minutes, but once authenticated the performance was as expected. As well there were issues with password resets through ISA due to the timing issues.
There was a certificate installed on the ISA servers for SCOM. This certificate supported client authentication and server authentication. Disabled the client authentication on this certificate only (not the Domain Controller certificates), and the problem disappeared. Authentications back to a normal speed of 1-2 seconds.
Thanks for the post. Just though I would share my experience.