ID4270: The 'AuthenticationInstant' used to create a 'SAML11' AuthenticationStatement cannot be null.

During our upgrade to SharePoint 2013 we ran into an issue related to ADFS. For some reason, SharePoint did not like the SAML coming out of our production ADFS server. The first cryptic error showed a message indicating:

The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults (either from ServiceBehaviorAttribute or from the <serviceDebug> configuration behavior) on the server in order to send the exception information back to the client…

Figuring out where to go next required modifying: C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\WebServices\SecurityToken\web.config, and adding a line to output the debug information.

<!– The serviceMetadata behavior allows one to enable metadata (endpoints, bindings, services) publishing.

This configuration enables publishing of such data over HTTP GET.

This does not include metadata about the STS itself such as Claim Types, Keys and other elements to establish a trust.

–>

<!– Default WCF throttling limits are too low –>

</behavior>

</behavior>

</serviceBehaviors>

</behaviors>

Then, trying to log in again via ADFS, the following message was displayed.

System.ServiceModel.FaultException`1[[System.ServiceModel.ExceptionDetail, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]: ID4270: The ‘AuthenticationInstant’ used to create a ‘SAML11’ AuthenticationStatement cannot be null.

Firing up Fiddler, and using this article: http://social.technet.microsoft.com/wiki/contents/articles/3286.ad-fs-2-0-how-to-use-fiddler-web-debugger-to-analyze-a-ws-federation-passive-sign-in.aspx, I took at look at the SAML being returned. Sure enough, the AuthenticationStatement looked just fine, and practically identical to the SAML coming back from our working test instance of ADFS. Great…where to go from here?

The answer was to add the AuthenticationInstant as a claim in ADFS.

Finally, the last step was to add a mapping to our TrustedIdentityTokenIssuer:

$ti = Get-SPTrustedIdentityTokenIssuer adfs20

$ti.ClaimTypes.Add(“http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant”)

$ti.Update()

$mapNew = New-SPClaimTypeMapping –IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationinstant” -IncomingClaimTypeDisplayName “AuthenticationInstant” –SameAsIncoming

Add-SPClaimTypeMapping –Identity $mapNew –TrustedIdentityTokenIssuer $ti

Then, one last login. Boom! Success!

System.ServiceModel.FaultException`1[[System.ServiceModel.ExceptionDetail, System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]]: ID4270: The ‘AuthenticationInstant’ used to create a ‘SAML11’ AuthenticationStatement cannot be null.

Leave a Reply