You are currently reviewing an older revision of this page.
Go to current version


  • Sign-in to AD FS 2.0 fails
  • The AD FS 2.0/Admin event log shows the following:

Log Name: AD FS 2.0/Admin
Source: AD FS 2.0
Date: 6/5/2011 1:32:58 PM
Event ID: 364
Task Category: None
Level: Error
Keywords: AD FS
Computer: adfs.contoso.com
Encountered error during federation passive request.

Additional Data

Exception details:
Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7012: An error occurred while processing the request. Contact your administrator for details.
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponseForProtocolResponse(FederationPassiveContext federationPassiveContext)
at Microsoft.IdentityServer.Web.FederationPassiveAuthentication.BuildSignInResponse(SecurityToken securityToken)


The NoAuthenticationContextException means AD FS 2.0 received a SAMLResponse from a Claims Provider (CP), and the SAML Status stated that the requested authentication method was not supported by the CP.


Examine the SAMLRequest that AD FS 2.0 sent to the CP. There is an AuthnRequest section that will show the authentication method requested. This is called RequestedAuthnContext. AD FS 2.0 must be able to either omit RequestedAuthnContext, or send a RequestedAuthnContext value that the CP supports.

Example of a decoded SAMLRequest containing RequestedAuthNContext:

<samlp:AuthnRequest ID="id-9f63a122-781f-40e0-9bd9-a6f2227ab117" Version="2.0" IssueInstant="2011-06-05T17:32:46.000Z" Destination=https://adatum.com/idp/saml2.0 Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
  <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://adfs.contoso.com/adfs/services/trust</Issuer>
  <samlp:NameIDPolicy Format="urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified" AllowCreate="true" />
    <samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</samlp:AuthnContextClassRef>

The CP, in this example, does not support Windows authentication, and the CP set the SAML Status accordingly.

Example of a decoded SAMLResponse containing the NoAuthnContext status code:

    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext" />

AD FS 2.0 will fail the sign-in request in the case of the NoAuthnContext exception because we are required to honor the authentication method specified. If you are not sure why AD FS 2.0 is specifying RequestedAuthnContext in the request to the CP, the most likely cause is that you are performing Relying Party (RP)-initiated sign-on, and the RP is specifying a requested authentication method. In this case, AD FS 2.0 is simply passing along the request from the RP. The way the RP specifies the authentication method request will vary based on protocol:



 SAML 2.0




More Information

AD FS 2.0 Content Map

Revert to this revision