I am trying to configure ADFS 3.0 as an authentication provider in SharePoint 2013. Unfortunately, I am running into issues with the default token-decrypting and token signing certificates that are installed when ADFS 3.0 is installed.
I have exported both certificates (without Primary Keys) onto the SharePoint servers and trusted them. They are also trusted on the AD and SQL boxes.
I configured SharePoint via the following
$cert = New-Object System.Security.Cryptography.x509Certificates.x509Certificate2 ("d:\certs\sp2013devWildcard.cer") New-SPTrustedRootAuthority -Name "Token Signing Cert" -Certificate $cert $upnClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" -IncomingClaimTypeDisplayName "UPN" -SameAsIncoming $emailClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming $roleClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/role" -IncomingClaimTypeDisplayName "Role" -SameAsIncoming $sidClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid" -IncomingClaimTypeDisplayName "SID" -SameAsIncoming $windowsaccountnameClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname" -IncomingClaimTypeDisplayName "WindowsAccountName" -SameAsIncoming $givennameClaimMap = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" -IncomingClaimTypeDisplayName "GivenName" -SameAsIncoming $realm = "urn:sharepoint:Portal" $signInURL = "https://sts.sp2013dev.com/adfs/ls" $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS for SharePoint" -description "ADFS - SAML secured SharePoint" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $upnClaimMap, $windowsaccountnameClaimMap, $emailClaimMap, $roleClaimMap, $sidClaimMap, $givennameClaimMap -SignInURL $signInURL -IdentifierClaim $upnClaimMap.InputClaimType $ap = Get-SPTrustedIdentityTokenIssuer "ADFS for SharePoint" $uri = "https://connectto.sp2013dev.com" $id = "urn:sharepoint:Portal" $ap.ProviderRealms.Add($uri, $id) $ap.update()
After I add ADFS as an authentication provider, get the following error:
ID4036: The key needed to decrypt the encrypted security token could not be resolved from the following security key identifier
Adding the lines to the web.config of the web config fixed that problem but exposed another:
<add type="Microsoft.IdentityModel.Tokens.X509SecurityTokenHandler, Microsoft.IdentityModel, Version=188.8.131.52, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<securityTokenHandlers> section and add:
<serviceCertificate> <certificateReference x509FindType="FindByThumbprint" findValue="certificatethumbprintvalue" storeLocation="LocalMachine" storeName="My" /> </serviceCertificate>
right before the closing
certificatethumbprintvalue is the value of the token decrypting certificate (I also tried repeating this process with the token signing certificate).
This exposes the error:
Error: 'ID1001: The certificate does not have an associated private key.
So I went looking for the private key for the certs. After a few hours and copious amounts of cursing, I found them on the personal store of the ADFS Service Account.
Unfortunately, When I try to copy to key to a file, 'Yes, export the private key' is greyed out.'
Then I ran winhttpcertcfg to try to add permissions for my App Pool Account to the cert's private key.
winhttpcertcfg -l -c LOCAL_MACHINE\Root -s "ADFS Encryption - sts.sp2013dev.com"
Unfortunately I get the error, Access was not successfully obtained for the private key. This can only be done by the user who installed the certificate.
So I tried repeating that command as the user that installed ADFS and the ADFS service account (with and without running as admin). I tried again after making the ADFS Service account a local admin and even a domain admin, just to be sure. There are no other possible users who could have installed the certificate unless it was installed as LOCAL SYSTEM, etc.
So my question is, what am I doing wrong? Why can't I get SharePoint to play nicely with default ADFS certs? Most of the guides do not even mention this mess. Am I just missing something? I have tested using my own cert and it works fine. However, the client wants to use the default certs so I'm a bit stuck.