Share via

You May Experience Slowness When Using SAML Claims with SharePoint 2010

  • Article

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 https://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:

  1. Export the “SharePoint Root Authority” certificate from SharePoint and import to the Trusted Root Certification Authorities store.  Go into the Certificates MMC and export the SharePoint Root Authority certificate, then import it into the Trusted Root Authorities.  You will find both of these in Computer certificate store, and you will find the SharePoint root authority certificate in the SharePoint node in the MMC.
  2. Disable retrieval of third-party root certificates from the network via Group Policy.  You can do this by going into your GPO and drilling down into Computer Configuration, Windows Settings, Security Settings, Public Key Policies.  Look for a policy in there called Certificate Path Validation Settings; open it up and click on the Network Retrieval tab.  Check the box that says "Define these policy settings" and then make sure you uncheck the box that says "Automatically update certificates in the Microsoft Root Certificate Program (recommended)".

Once you've made these changes you should see login times improve considerably.  Thanks again to Adam for sharing this information.

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    July 14, 2011
    When you disable CRL checking by modifying the machine.config file, does this also remedy this situation?

  • Anonymous
    December 30, 2013
    Pingback from SharePoint 2010 with Claims authentication – Lessons Learned Part 1 | SharePoint Slade

  • Anonymous
    December 30, 2013
    Pingback from SharePoint 2010 with Claims authentication – Lessons Learned Part 1 | SharePoint Slade

  • Anonymous
    September 18, 2014
    The comment has been removed