AD FS 2.0: Sign-In Fails and Event 364 is Logged Showing Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7012

AD FS 2.0: Sign-In Fails and Event 364 is Logged Showing Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7012


  • 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
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= 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"></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






See Also

AD FS 2.0 Content Map

Leave a Comment
  • Please add 6 and 8 and type the answer here:
  • Post
Wiki - Revision Comment List(Revision Comment)
Page 1 of 1 (2 items)
Wikis - Comment List
Posting comments is temporarily disabled until 10:00am PST on Saturday, December 14th. Thank you for your patience.
  • Ed Price - MSFT edited Original. Comment: TOC and title guidelines

  • Fernando Lugão Veltem edited Revision 4. Comment: added tags

Page 1 of 1 (2 items)