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

Symptoms
Cause
Resolution
See Also

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: