I have a working test application that uses Windows Idendity Foundation SDK and ADFS 2.0 for authentication, which runs on Windows Server 2008 R2, IIS 7.5, Integrated managed pipeline application pool mode.

My problem is that the "real" application I need to setup with this kind of authentication can only run on Classic managed pipeline application pool mode due to a legacy code, and when I select it I recieve an "HttpException (0x80004005): Failed to Execute URL" error.

Does anyone have an idea how to solve this problem?

UPDATE: I have found out that https://example.com/myapplicatio/ gives me the error, but https://example.com/myapplicatio/Default.aspx works.

  • This help?
    – Jaxidian
    Jun 3, 2011 at 15:14
  • Unfortunately not - I added the isapi module and i still get the same error. Jun 6, 2011 at 8:19

2 Answers 2


I'm having the same issue. Here is another discussion elsewhere that is similar. Did you wind up solving your problem?


paullem's comments at the bottom are useful.


I was able to find a solution to the cause of my application failing with this error.

In my virtual environment, I was trying to get a MOSS 2007 extranet instance to authenticate using an ADFS 2.0 server using SharePointClaimsMembershipProvider.

The hint I got from some of the other answers was that the claims identity was not getting populated correctly, particularly when anonymous access was used. Some people provided some code to handle anonymous access situations.

In my case, I was authenticating, but still getting this error. So, basically, the issue is that ADFS2.0 was not providing the claims identity types that my application was configured for.

You can see which claims you want to get for your application in the web.config file.

        <add value="https://moss2007hv.kor.cmil.mil/" />
          <!--Following are the claims offered by STS 'http://adfs.kor.cmil.mil/adfs/services/trust'. Add or uncomment claims that you require by your application and then update the federation metadata of this application.-->
          <claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" optional="true" />
          <claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/role" optional="true" />
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/claims/CommonName" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/claims/EmailAddress" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/claims/Group" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/claims/UPN" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod" optional="true" />-->
          <!--<claimType type="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/denyonlysid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarysid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/denyonlyprimarygroupsid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/primarygroupsid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid" optional="true" />-->
          <!--<claimType type="http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" optional="true" />-->
      <!--Commented out by Federation Utility for SharePoint 3.0-->
      <!--<serviceCertificate><certificateReference x509FindType="FindByThumbprint" findValue="DAC77B6076433468D5E1030F8B66126BF261F2BB" storeLocation="LocalMachine" storeName="My" /></serviceCertificate>-->
        <wsFederation passiveRedirectEnabled="true" issuer="https://adfs.kor.cmil.mil/adfs/ls/" realm="https://moss2007hv.kor.cmil.mil/" requireHttps="true" />
        <cookieHandler requireSsl="true" />
        <certificateReference x509FindType="FindByThumbprint" findValue="DAC77B6076433468D5E1030F8B66126BF261F2BB" storeLocation="LocalMachine" storeName="My" />
      <issuerNameRegistry type="Microsoft.IdentityModel.Tokens.ConfigurationBasedIssuerNameRegistry, Microsoft.IdentityModel, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35">
          <add thumbprint="FC144B44D2D81BCA7CFB933A8D818236C94E8505" name="http://adfs.kor.cmil.mil/adfs/services/trust" />

In the sample above, the name and role claims are expected.

So, then I went back to my ADFS server and verified that I had created the relying party trust correctly.

Next, you right click on the relying party trust and edit claim rules. Right click the existing rule or Add a rule if not exists. For this example, I noticed I had not set the Outgoing Claim Type for name. So, I used LDAP Attribute: User-Principle-Name and mapped that to Outgoing Claim Type name.

For Roles, I used Token-Groups-Unqualified Names and mapped that to Role.

Once I configured the rule properly on my ADFS server to provide the claims that were requested in my web.config, the error went away and things worked, as expected.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .