Resources For IT Professionals
Page Details
Options

Revision #2

Wiki  >  TechNet Articles  >  AD FS 2.0: Sign-In Fails and Event 364 is Logged Showing Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7012  >  Revision #2
AD FS 2.0: Sign-In Fails and Event 364 is Logged Showing Microsoft.IdentityServer.Protocols.Saml.NoAuthenticationContextException: MSIS7012
You are currently reviewing an older revision of this page.
Go to current version

Table of Contents

Symptoms

  • 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
User: NETWORK SERVICE
Computer: adfs.contoso.com
Description:
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)

 

Cause



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.


Resolution



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:RequestedAuthnContext>
    <samlp:AuthnContextClassRef xmlns:samlp="urn:oasis:names:tc:SAML:2.0:assertion">urn:federation:authentication:windows</samlp:AuthnContextClassRef>
  </samlp:RequestedAuthnContext>
</samlp:AuthnRequest>


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:Status>
    <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Responder">
      <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:NoAuthnContext" />
    </samlp:StatusCode>
  </samlp:Status>
</samlp:Response>


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:

 

Protocol

Paramter

 SAML 2.0

RequestedAuthnContext

 WS-Federation

WAuth

 

 

See Also

 

AD FS 2.0 Content Map

Revert to this revision