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.

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!

As I was trying to get the User Profile Service up and running with our ADFS implementation, I ran into a bit of a snag trying to set up the Profile Synchronization using the “SharePoint Active Directory Import”.

After setting the sync to “Use SharePoint Active Directory Import” in the “Configure Synchronization Settings”, and then, going into “Configure Synchronization Connections” an setting up a new connection, you will notice that all mapped properties are cleared out under “Manage User Properties.” Unfortunately, none of the properties are available for selection, so they need to be entered manually.

The snag I ran into was related specifically to the Claim mappings. I was able to enter the “Claim User Identifier” without issue, however, when attempting to enter the “Claim Provider Identifier”, it would not let me add it, as the “Add” button was greyed out. After fumbling around for a bit and trying a page refresh, I realized that it would not let me add a new value, because it had kept a previous empty value. Clicking the “Remove” button, allowed me to enter in a new value for the “Claim Provider Identifier” and save it. A fairly straightforward solution, but not completely obvious.

Despite deactivating the Office integration, you may still have documents that try to open in the browser.

To work around this, add a bit of script to your site:

jQuery("a[onclick*='SharePoint.OpenDocuments']").each(function (data) {
    var h = this.href;
    if (h.indexOf('http') >= 0) {
        var p = h.indexOf('/', h.indexOf('/') + 1);
        h = h.substring(p, h.length);
        p = h.indexOf('/', h.indexOf('/') + 1);
        h = h.substring(p, h.length);
    }
    this.href = '/_layouts/download.aspx?SourceURL=' + h;
    jQuery(this).removeAttr('onclick');
});