SharePoint 2013 – 404 Error When Connecting to ACS or ADFS /_trust/default.aspx

Ran into an interesting error this morning that I thought I’d share. Recently, I worked on a project utilizing Azure ACS with Google Accounts. This was working on multiple servers, but one was displaying a Page Cannot Be Displayed message when clicking the Google Sign-In button. Looking at a network trace it was getting a 404 error for the following page:

http://webappurl/_trust/default.aspx?trust=Google%20Account&ReturnUrl=/_layouts/15/Authenticate.aspx?Source%3d%252F&Source=/

Doing a little bit of research this page is used when utilizing ADFS/ACS. Interesting part about this is it worked on 2 out of the 3 servers and the server affected worked with Windows Integrated login. I checked a network trace on a working server and saw that after it hits the /_trust/default.aspx it redirects to the ACS URL (https://acsname.accesscontrol.windows.net) and then redirects to https://accounts.google.com/ServiceLogin. I was able to hit both of these URL’s individually on the non-working server.

I popped open IIS on the problematic server and noticed something interesting. The _trust IIS Virtual Directory was missing!

TrustsFolderMissingInIIS

Big surprise, the other 2 (working) servers had this Virtual Directory. Running the provision PowerShell method fixed the issue..I’m really digging this command lately.

Thanks Jasper for the tip!

http://blog.repsaj.nl/index.php/2014/07/sp2013-sharepoint-adfs-and-404-on-_trustdefault-aspx/

SharePoint/Azure ACS Token Signing Certificate. Will you please just sign my tokens?!

Setting up Azure ACS was fun. It’s so easy to get it up/running/connected to SharePoint and you have the instant satisfaction of using Microsoft/Google/Facebook accounts to login to SharePoint. Great success! Note: Microsoft only gives you the UPN claim..which is a unique ID so when users log in it looks gross. Google and Facebook are able to pull in a lot more claims..but Microsoft is more secure in that fashion I suppose.

Anyways there is great documentation out there already on how to get rocking and rolling. Here’s a few I’ve used:

Anyways there isn’t really much documentation out there on the Token Signing Certificate. Most of the documentation out there states to use a self-signed certificate for DEV and get a certificate from a Commercial Certificate Authority for PROD. Alrighty then. Here’s the screen in Azure

ACSTokenSigningCertPage

Not knowing too much in the ADFS token signing cert space (In the past most environments I have worked with use ADCS or PKI to generate these)  I took to the interwebs.

The reason I was researching is because if I were to put in a CSR for acstenant.accesscontrol.windows.net I wouldn’t get it or it would get revoked…I don’t own windows.net. Companies like Comodo have a DCV (Domain Control Validation) questionnaire built right into the certificate purchasing process. For the self-signed cert you can use whatever you want.

I researched to see if Azure ACS could have a friendly name or DNS CName that we could pull the cert for. NOOPE!

http://stackoverflow.com/questions/16589648/can-i-have-a-friendly-name-in-an-acs-service-namespace

I found a great tool by Steve Peschka that allows you to actually export the token signing certificate right out of ACS. The ACS tenant is actually already an HTTPS site so there is a preexisting cert. SWEEET! It works like a charm too..

https://samlman.wordpress.com/2015/03/02/tool-to-get-token-signing-certificate-out-of-acs/

This specific client had their heart set on using the commercial certificate authority so I kept trucking.

The certificate for ACS is described in detail here: https://msdn.microsoft.com/en-us/library/gg185932.aspx

Alright I’m still not sure what subject name to use..until I found this forum post: https://social.msdn.microsoft.com/Forums/vstudio/en-US/0dc942cd-ced1-4d09-9f10-73e325c241a9/adfs-installation-and-token-signning-certficate?forum=Geneva

Frank Lesniak had the answer I was looking for (This was for ADFS, but still applied to ACS):

**I’m just copying his answer in here in case the forum post ever gets deleted

  1. The certificate’s key length should be at least 2048 bits.
  2. Validity period should be as long as possible (given cost), up to 5 years
  3. The signing algorithm should be either SHA-1 or SHA-256. If you need to support ADFS 1.x legacy federation, Windows 2000, Windows XP SP2, or Windows Server 2003, use SHA-1. Otherwise, for best security, use SHA-256. You may need to call your publically-trusted certificate issuer to validate the signing algorithm.
  4. Ensure that the private key is exportable
  5. Subject name does not matter… but something like adfstoken.yourdomainname.com would be a common implementation.
  6. Key usage does not matter.

The key points being #5 and #6 – ADFS does not care what you name the certificate or what kind of certificate is being used (i.e. code signing, server authentication, client authentication, etc.). My advice would be to generate a certificate however you’d normally feel comfortable doing so. For example, many of my clients use IIS to generate the certificate signing request (CSR), then submit the CSR to the commercial CA. Once you’ve loaded the certificate into the computer store, it should be available for AD FS to use.

 

In summary – It doesn’t matter! Use acstoken.yourdomain.com or if you’re already rocking a wildcard cert for everything use that. Any X.509 certificate will do…