In the last few months, we moved our Active Directory to Windows 2008 R2. We also recently deployed ISA 2006 to front end for all of our internet facing web services including SharePoint, Team Foundation Web Services, and a few others.
To allow employees the ability to change passwords externally or after an expiration using ISA, we implemented LDAPS pre-authentication. We have ISA deployed in the single NIC configuration where it lives in the perimeter network (DMZ) since we are already using a Cisco ASA 5520 as our primary firewall. In my opinion, this is the most secure way to deploy ISA for web publishing reverse proxy purposes, but that’s another conversation.
One of the stumbling blocks getting this to work was the new Certificate Authority in Windows 2008 R2. In 2008 R2, Microsoft has released quite a few new Cryptographic providers. However many of these new providers are not backwards compatible with Windows 2003 or Windows XP before SP3. Our ISA 2006 server is running on Windows 2003 since it’s deployed on older non 64-bit capable hardware.
The solution was to uninstall the Certificate Authority from the domain controller and then reinstall ensuring to pick the older Microsoft Strong Cryptographic provider and SHA-1 as the algorithm. Once this was done, a server certificate was automatically issued to my domain controller. I was also able to export the Root CA certificate, bring it over to ISA and import it into my Trusted Certificate Authorities store without getting the non-valid certificate signature error I was getting before. Now with ISA trusting my Certificate Authority, I was able to authenticate, change passwords, or warn of impending password expirations on the FBA screen.
As I talked about in a previous post, a common solution for companies running Exchange is to use redirection to dump all incoming user request to the OWA sub directory on the CAS server. HTTP to HTTPS redirection is also commonly implemented. Recently I found a gotcha to this configuration. When a user connected with Outlook Anywhere does a Send/Receive, it will hang on the Offline Address Book, sometimes permanently until either the task is cancelled or Outlook is restarted.
After a long while of troubleshooting this issue, I finally lucked on to the answer when I did a browse to the OAB.xml file on port 80 from the console in IIS and received a 500 error. After digging around for the reason I was locked out, I finally found why.
When you enable redirection with the HTTP redirection feature in IIS 7, it places a web.config file in every sub directory of the default web site. This is the reason you have to go disable redirection on all the sub directories after turning it on at the DWS. For some reason, the web.config file in the OAB subdirectory was the only one that authenticated users did not have read access to. To fix the issue, I granted authenticated users read rights to the web.config file.
Note: The OAB subdirectory is located at
C:\Program Files\Microsoft\Exchange Server\Client Access\OAB