Hey folks, our good friend Adam C. in SharePoint support recently alerted the folks here with a complaint we're seeing come up more frequently from customers that are using SAML claims. It starts out as taking a very long time to log into a site using SAML authentication. If you monitor the requests via a tool like Fiddler, you see that the majority of the time is spent on the SharePoint server, most likely in the /_trust subdirectory. If you experience this behavior and find you're request is spending most of it's time on the SharePoint server, it may be that your farm does not have Internet access. You would likely be able to see this if you turn on CAPI2 logging on the SharePoint servers. Adam explains how to do so here:
CAPI2 is the new cryptography API available in Vista/2008. CAPI2 diagnostics greatly improves on the PKI diagnostics available in 2000/XP/2003. CAPI2 diagnostic information is logged to the CAPI2 Operational log, which is located at Applications and Services Logs\Microsoft\Windows\CAPI2\Operational in Event Viewer. You can use CAPI2 logging to troubleshoot most PKI operations in Vista/2008.
CAPI2 logging is not enabled by default. To enable it, right-click the CAPI2 Operational log in Event Viewer and select Enable Logging. You can also enable it using Wevtutil:
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:true
To disable it with Wevtutil the syntax is:
wevtutil.exe sl Microsoft-Windows-CAPI2/Operational /e:false
For more information, see Troubleshooting PKI Problems in Windows Vista
Once you've enabled CAPI2 logging you'll want to authenticate to SharePoint again, then look in the Event Viewer. If you see event codes 11 (BuildChain) and 53 (Retrieve Object from Network), you should look into event 53 closer and see if it is trying to make a request to http://www.download.windowsupdate.com/msdownload/update/v3/static/trustedr/en/authrootstl.cab. If you see this and your farm does not have Internet access then you will endure all sorts of painful timeouts while it tries to reach it. For now you can work around this problem in two ways:
Once you've made these changes you should see login times improve considerably. Thanks again to Adam for sharing this information.
When you disable CRL checking by modifying the machine.config file, does this also remedy this situation?