Requirements
- Windows 2012
- AD FS 2.0 Feature installed
- ASP.Net MVC 4.0
- Valid SSL certs
- Visual Studio 2012
This document covers setting up an ASP.NET MVC 4.0 application using Visual Studio 2012, Windows 2012 and AD FS 2.0 to enable Web Single Sign On.
It’s important to have valid SSL certificates. Self signed certificates will not work. SSL certificates are used to encrypt the tokens and will not work with self-signed certificates. This is very important. If you do not have valid certificates this will not work. Don’t waste your time without valid certificates.
Setting up AD FS 2.0 on Windows 2012
Assuming Windows 2012 is installed. With a valid SSL certificate install the SSL certificate in IIS. This is done by opening IIS (7+) Management Console, selecting the root web server node and opening the Server Certificates found in the Feature view. Do not install the AD FS feature before installing the certificate. AD FS extracts the host name from the SSL certificate and will use localhost if a certificate is not found.
If AD FS is installed before installing the SSL certificates
If this does happen, you’ll need to uninstall the the AD FS role and manually delete the IIS applications (removing them from the IIS management console is not enough they must be removed from the IIS metabase via the command line).
C:WindowsSystem32inetsrvappcmd.exe delete app "Default Web Site/adfs"
C:WindowsSystem32inetsrvappcmd.exe delete app "Default Web Site/adfs/ls"
Once a valid certificate is installed the AD FS role can be installed.
When reinstalling ADFS, the relying party needs to rebind to AD FS’s FederationMetadata otherwise you’ll encounter an ASP.Net error stating there was a token error.
Federation Services URL
At times this url uses localhost as the host. I am not certain of the cause, but unless localhost is the domain used in the ssl cert, it will not work. The following link describes how to change it.
http://technet.microsoft.com/en-us/library/dd353709%28v=ws.10%29.aspx
At this point AD FS is setup on the server. However, it does not have any trusts established, with the exception of Active Directory (configured by default). The next step is to create a trust with a Relying party.
A trust is a relationship setup between the relying party(ASP.Net MVC) and the issuer (AD FS). The trust is setup on both the relying party and the issuer.
https://myhostname.com/federationmetadata/2007-06/federationmetadata.xml
Creating a Relying Party
Assuming you have installed Visual Studio 2012, download the Windows Identity Foundation Identity and Access Tool Extension tools. Once installed create a MVC 4 project. The option “Identity and Access” is added to the project right-click menu. The Windows Identity Foundation SDK might also be a requirement.
This brings up the Identity and Access option screen.
Enter the path to the STS metadata document
The STS metadata document is generated by the AD FS server. The FederationMetadata.xml defines the Issuer (sometimes referred to as the Identity Server) and allows MVC 4(Relying Party) to create a trust between itself and the Issuer.
Enter the Realm for your Application
The realm is the MVC application. Unless the MVC application and the AD FS are on the same server the localhost host will not work. The realm is the url to your site.
Setting up a Relying Party Trust in AD FS
The Relying Party is created, now it’s time to set up the Relying Party Trust in AD FS. Back on the server open up AD FS MMC screen and click on “Add Relying Party Trust…”
The next screen asks for the FederationMetadata.xml from the relying party. In the previous step when the FederationMetadata.xml was added into the MVC 4 application a FederationMetadata.xml was created for the MVC 4 application. Now we must import the Relying Party FederationMetadata.xml into the AD FS server to complete the trust.
The FederationMetadata.xml can either be imported via a url or added via a local file. The default FederationMetadata.xml path is https://myhostname.com/FederationMetadata/2007-06/FederationMetadata.xml (same as it was for the AD FS server). If it successfully retrieves the FederationMetadata.xml you can click next until the end.
The next step is to add an endpoint. The endpoint is where a user is redirected to upon successful authentication. Start by clicking the Relying Party Trusts folder, you’ll see the Relying Party Trust that was just created. Right-click on it and select “Properties” a tabbed interface will appear. From the monitoring tab Uncheck “Automatically update relying party” this feature does not work out of the box.
Note: If the relying party is configured correctly this step is not necessary.
Click on the endpoint tab and click add. The “Add an Endpoint” dialog will appear. Select WS-Federation for the Endpoint Type. This will automatically set the Binding dropdown to “POST”. In the URL field enter the url in which an authenticated user is sent.
That’s it! The AD FS single sign on should prompt you for credentials. Once entered it will redirect you back to your site’s landing page.
Accessing AD FS with a non-IE browser
Out of the box you’ll encounter a dialog asking for username and password. For whatever reason it would not accept my domain credentials.
In a nutshell a property ExtendedProtectionTokenCheck is set to required when running windows 7. Only IE supports this feature.
More information on the issue
http://stackoverflow.com/questions/6309210/ntlm-authentication-to-ad-fs-for-non-ie-browser-without-extended-protection-sw
How to disable it
http://social.technet.microsoft.com/wiki/contents/articles/1426.ad-fs-2-0-continuously-prompted-for-credentials-while-using-fiddler-web-debugger.aspx
Troubleshooting Tips
1. Recompile the website and trying adding the trust for both ADFS and the web site.
2. Re-install AD FS, that had some issues also, but sometimes it getting to get a fresh start.
3. Installing ADFS Multiple times and you encounter a 503 on the FederationServerServices.asmx
Try removing the ACLs
netsh http delete urlacl url=http://+:80/adfs/services/
netsh http delete urlacl url=https://+:443/adfs/services/
netsh http delete urlacl url=https://+:443/FederationMetadata/2007-06/
netsh http delete urlacl url=https://+:443/adfs/fs/federationserverservice.asmx/
Continuing with the tips
4. When reinstalling ADFS after IIS was removed, the previous ADFS web directory under C:inetpubadfs* needs to be deleted.
5. The configuration service URL 'net.tcp://localhost:1500/policy' may be incorrect or the AD FS 2.0 Windows Service is not running.
setspn -l myservername
before
The SPN is not set or is incorrect. The following thread discusses it in more detail.
hint: casing does matter.
After
6. The X.509 certificate CN=ADFS Signing - mydomain.com is not in the trusted people store. The X.509 certificate CN=ADFS Signing - mydomain.com chain building failed. The certificate that was used has a trust chain that cannot be verified. Replace the certificate or change the certificateValidationMode. A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.
This is not recommended for going into production, but it will get you past the issue:
In Conclusion
My overall experience with AD FS 2.0 and Windows 2012 has been painful. Working with AD FS 2.0 reminds me of working with Sharepoint 2010 in the early days.
Some of the configuration is done differently on the Windows 2012 server versus in Visual Studio, even though you are doing the same exact things (i.e. setting up a trust). Once the server is setup and the trusts are established and working correct it’s a thing of beauty, until you get there, good luck!