Consider a scenario where external client is trying to authenticate in an OWA publishing rule through ISA Server 2006 using Forms Base Authentication. In this scenario ISA Server 2006 was in workgroup and the FBA was using LDAPS authentication method. Problem: authentication doesn’t go through; it keeps in the same FBA window without saying any error message.
To narrow it down the problem the following article was followed:
Troubleshooting Forms Base Authentication using Secure LDAP Authentication on ISA Server 2006
2. Don’t Forget the CRL
While the core reasons for this scenario fails are covered in the above article, there are two others things to validate:
· Is ISA Server allowing the access to the CRL (Certification Revocation List)?
· Is the CRL accessible by ISA Server?
For this case the first option was true, the system policy that allows that was enabled. You can check that by opening the ISA Server 2006 System Policy and reviewing the option below:
Figure 1 – CRL Download System Policy
How to check the second option? You can use a command line utility called certutil to test that from the ISA Server itself. You just need to have the Root CA certificate file (.CER) available to test that. Here the command and the result for this scenario:
C>:\>certutil -verify –urlfetch rootca.cer
Cert Serial Number: 230acfb9d8e6468c4fd78ed8a899a466
dwFlags = CA_VERIFY_FLAGS_DUMP_CHAIN (0x40000000)
ChainFlags = CERT_CHAIN_REVOCATION_CHECK_CHAIN_EXCLUDE_ROOT (0x40000000)
-------- CERT_CHAIN_CONTEXT --------
ChainContext.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
SimpleChain.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
CertContext: dwInfoStatus=10c dwErrorStatus=0
Issuer: CN=Fabrikam CA, DC=fabrikam, DC=msft
Subject: CN=Fabrikam CA, DC=fabrikam, DC=msft
99 56 45 8f a5 57 de 5d 60 43 cb 3b ac 40 a0 53 f0 91 ff 54
Element.dwInfoStatus = CERT_TRUST_HAS_NAME_MATCH_ISSUER (0x4)
Element.dwInfoStatus = CERT_TRUST_IS_SELF_SIGNED (0x8)
Element.dwInfoStatus = CERT_TRUST_HAS_PREFERRED_ISSUER (0x100)
---------------- Certificate AIA ----------------
No URLs "None" Time: 0
---------------- Certificate CDP ----------------
Failed "CDP" Time: 0
Error retrieving URL: The specified network resource or device is no longer available. 0x80070037 (WIN32: 55)
Error retrieving URL: The server name or address could not be resolved 0x80072ee7 (WIN32: 12007)
Exclude leaf cert:
da 39 a3 ee 5e 6b 4b 0d 32 55 bf ef 95 60 18 90 af d8 07 09
Verified Issuance Policies: All
Verified Application Policies: All
Cert is a CA certificate
ERROR: Verifying leaf certificate revocation status returned The revocation function was unable to check revocation because the revocation server was offline. 0x80092013 (-2146885613)
CertUtil: The revocation function was unable to check revocation because the revocation server was offline.
CertUtil: -verify command completed successfully.
This result is very clear: ISA Server is unable to access the CRL and therefore it can’t authenticate the user. For this particular scenario (the real on, not my lab), the issue was resolved after opening port 80 between ISA Server and the Root CA. Yeah, ISA Server was running in sandwich mode, in between two others two firewalls (Root CA à Hardware Firewall à ISA Server à Hardware Firewall à Internet). Not an ISA issue, just again.
When the scenario involves LDAPS Authentication and SSL Publishing the amount of variants are quiet big. On top of that if your topology uses ISA Server in sandwich mode and your security policy is so tight that ISA can’t even check a CRL things can get worst. This is a scenario born to fail, due the lack of planning before put in production. Remember, planning is a key factor of any type of deployment and when the topology needs to be complex like this, be realistic, give yourself a couple of weeks to build a pilot environment that reflects the production one. Test it, write the results, work in the errors, write the results, resolve the problems, write the results, test it, test it and make sure that you cover at least what you plan to publish. Watch around ISA, because everyday my statistics that on every 5 cases 3 are not an ISA issue are just growing.
PingBack from http://blogs.isaserver.org/shinder/2009/04/05/beware-poor-designs-bad-things-can-happen/