400 Bad Request Error with ADFS

I spent waaayyyyy too much time trying to resolve this problem so am capturing it here in case any of the rest of you run up against this.  I installed a new ADFS 3.0 on Windows Server 2012 R2 machine in my environment, and then configured a new SharePoint SPTrustedIdentityTokenIssuer for it.  Every time I tried to authenticate to it I entered my credentials, and then I would get a 400 bad request back and the whole thing came to a grinding halt.  I was getting no errors in any of the event logs on the ADFS server.  What was also weird is that if I configured ADFS to use forms based authentication instead of Windows, I could log in just fine.

I suspected Kerberos SPN issues, but when I had tried to set it after setting up ADFS (using setspn) it said that the SPN was set.  Well, guess what – turns out that was not true.  I finally just went in to adsiedit.msc on my domain controller and looked at my service account.  If you go into the properties you can scroll down to servicePrinicpalName and see exactly what’s configured for it, and sure enough, my ADFS server was not listed there.  So, I just added the SPN needed for it – http/yourFqdnAdfsServer – saved it, and authentication started working then.  As always, note that the SPN is NOT a Url, like http://myserver, it’s just the protocol and host name, so http/myserver.

Hopefully this will save you some time, I know a lot of folks build all this out in their labs at home so start by double-checking your service account SPNs.

Tips for Upgrading or Moving ADFS 2.0

I recently spent too much time trying to get an ADFS Server upgraded, in my case from Windows Server 2008 to 2008 R2.  Like many SharePoint folks that are just trying to get along in a claims happy world, seemingly simple things like this can cause a surprising amount of churn.  Here are some tips that may help you get through it:

  • There really isn’t a straight upgrade path from ADFS 2.0 on Windows Server 2008 to Windows Server 2008 R2.  It just completely uninstalled ADFS for me.  So once you’re done you’ll need to start over from scratch, sort of.  I recommend you back up the database first.  More on that next.
  • ADFS really wants to use that dang Windows Internal Database.  If you’re just trying to get things up and going for your SharePoint farm then that’s often okay.  So how do you manage it though when you need to backup and restore the database?  Fortunately there is a free download for managing it.  The link I found said SQL Server 2005 but it still worked fine with Windows Internal Database.  I downloaded the tool from http://www.microsoft.com/download/en/details.aspx?DisplayLang=en&id=8961, where it calls the tool “SQL Server Management Studio Express”.
  • The connection you need to use when you open the tool is about as unintuitive as you will find, so I will just paste it here; you should be able to copy from here and paste into the tool when the connect dialog opens:  “\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query” (without the quote marks)
  • When you install ADFS again, you may get a warning after you complete the ADFS wizard that says something like the ADFS web site is already installed so it didn’t overwrite the contents of it.  It then gives you a link that it tells you to follow if you want to redploy the web site.  NEWSFLASH:  the link is WORTHLESS!  Shocking, I know…please hold your gasps of disbelief in abeyance for now.  What’s more irritating is that if you look in the IIS Manager snap-in you will not see any ADFS virtual directories.  Frustrating!  Turns out you need to use appcmd to delete the vdirs.  I did it with these two commands:
    • C:\Windows\System32\inetsrv>appcmd delete app “Default Web Site/adfs/card”
    • C:\Windows\System32\inetsrv>appcmd delete app “Default Web Site/adfs/ls”
  • Now, after you’ve done all that goo you can run the ADFS wizard again to get everything set up.  Once it’s all up then you can restore the databases that you backed up from above.  Here’s a tip to help with that though:
    • Close the ADFS Management app if you have it open
    • Stop the ADFS service
    • Restore the AdfsConfiguration database first
    • Start the ADFS service
    • Restore the AdfsArtifactStore database
    • Open up the ADFS Management app and everything should be working and restored
  • Finally you want to see what it’s using for the token signing certificate.  It will again try to use the self-signed certificate that it creates at install time.  However if you had previously been using a different certificate that will of course break when you try to go to any SharePoint sites that were working prevoiusly with it (the old not trusted root authority message that I described at http://blogs.technet.com/b/speschka/archive/2010/02/13/root-of-certificate-chain-not-trusted-error-with-claims-authentication.aspx).  However, before you can just add a new token signing certificate you must run these PowerShell commands on the ADFS server:
    • add-pssnapin Microsoft.adfs.Powershell
    • set-adfsproperties -AutoCertificateRollover $false
  • If you add a token signing certificate, remember to make it the Primary certificate if that’s how you had it configured previously.

Hope this is helpful to you.

SharePoint 2010 Claims Auth Login Stops at ADFS Authentication Page

I’ve had this happen a number of times and it always temporarily gets me gummed up so I thought I would describe this problem and resolution here because I’m sure others have seen it too.

Assume you have configured a SharePoint web app to use SAML claims, and the IP-STS is ADFS 2.0.  What I see sometimes is that after SharePoint redirects to the ADFS login page, the browser just “stops”.  The status says “complete”, like it’s all done and that’s all there is too it.  The address bar in the browser shows the correct ADFS server Url.  So no error shows up, the browser looks like it’s at the ADFS login page, but you are never authenticated, never prompted for credentials, and never get back to your SharePoint site.

In that case the problem I’ve found is that I have a proxy server configured in your browser, and the request is being redirected to the fully qualified domain name of the ADFS server (i.e. https://adfs.foo.com).  In that case, you need to go into the browser (by the way, I’m describing this for IE users, not sure what the process is for other browsers), into Tools…Options…Connections…LAN Settings…Advanced.  There is an edit box there for exceptions, which is basically a list of Urls that the proxy server will not try to resolve for you.  If you add the Url for your ADFS server to that list then save your changes, you should be able to successfully redirect and get authenticated. 

Unfortunately there is zero feedback from the browser in this scenario as to what it is actually having a problem with.  So if you get the “Blank Screen of Death”, consider this tip.

 

The Dreaded 3 Login Prompts When Authenticating

I had this all too common problem hit me this weekend, but this was happening on my ADFS server, which I unfortunately was rebuilding.  The most common reasons as you know have to do with some misconfigured Kerberos setting, or with using some name other than the server name for a web application (the ‘ol disable loopback scenario).  This one is different though, and is specific to an ADFS server so I thought I’d capture it for future reference.

AD FS 2.0 is actually pretty good about writing problems to the event log.  When you open the Event Viewer you will see a separate node for AD FS 2.0 so look in there.  In this particular case I did end up finding the culprit in there, it just took a fairly long time because it seems like there’s so many different things that can give you the dreaded three login prompts anymore.  Long story short, when I configured my ADFS server, I a) configured it to run as a domain account and b) I used a certificate I created just for ADFS for token signing.  The problem as it turns out is that the service account I used for ADFS did not have rights to the private key for my token signing certificate.  That, of all things, caused the 3 login prompts, which in interesting, amazing and frustrating all at the same time.  To grant rights to the service account to the private key for the cert, you need to run the MMC, add the Certificates snap-in for the Local Computer, open up the Personal node, right-click on the token signing certificate and choose the Manage Private Key menu.  From there you can get to a Security tab where you can add your ADFS service account with at least read rights to the private key.

Hope this saves someone some time down the road.

Configuring ADFS Trusts For Multiple Identity Providers with SharePoint 2010

Hey all, on Thanksgiving eve I’ve finally finished something I’ve been wanting to do for a while, and been getting questions on for a while.  There are often scenarios where you need to have a trust from the ADFS server to which SharePoint authenticates.  It may be that you have another identity provider you need to go authenticate too, or you are federating multiple Active Directory forests, etc.  In this post I’m going to walk through how you establish a trust between two ADFS servers that are hosted in two different Active Directory forests, and get the claims to go all the way across back to SharePoint.  Please note that in this example I’m using the RTM version of AD FS 2.0.  I’m also going to assume that you already have added SharePoint as a trusted relying party in one of the ADFS servers.

To begin with, start on the ADFS server to which your SharePoint site has the trust (we’ll call it RP).

  1. Open the federationmetadata.xml file from the ADFS server that users will be authenticating against (we’ll call it IP) in the browser.  By default the location will be https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml.  If you get an untrusted certificate error in the browser you’ll need to add the root authority certificate for the IP ADFS server’s SSL to your trusted root authorities store.  NOTE:  This assumes that you have the same root authority certificate for both the SSL access to the IP ADFS web server and the IP ADFS token signing certificate.  If they are not the same then you need to add the root certificate authority for BOTH to the local RP ADFS server’s certificate store.  To do that:
    1. Click through to view the web site, which should show the Xml file.
    2. Click on the View Certificates icon so you can see the SSL certificate that was used.
    3. Click on the Certificate Path tab.
    4. Double-click on the top certificate in the chain – this is the root authority certificate.
    5. Click on the Details tab.
    6. Click on the Copy to File… button and save the certificate in CER format to the local disk.  You can now close out all of the certificate dialogs and browser.
    7. Open up the Certificates MMC; if you don’t have a shortcut for this then just start the MMC from the Run menu, Add snap-ins, and add the Certificates snap-in for the Computer (local).
    8. Expand the Trusted Root Certification Authorities node, right-click on the Certificates node, and choose the Import menu.  Follow the wizard to import the root authority .CER file you exported above.
  2. Open up the AD FS 2.0 Management application.
  3. Expand the Trust Relationships node, then right-click on the Claim Provider Trusts node and select Add Claims Provider Trust…
  4. Click the Start button to begin the wizard.
  5. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myIpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
  6. Provide a Display Name and optionally Notes, then click the Next button.
  7. Review your data if needed, then click the Next button.
  8. Click the Close button to complete the wizard.  Leave the box checked to open up the rules dialog when complete.

Now for the claims provider trust, you need to create rules to pass through all of the claims that you get from the IP ADFS server.  So in the rules dialog, for each claim you want to send to SharePoint you’re going to do the following:

  1. Click on Add Rule.
  2. Select the Pass Through or Filter an Incoming Claim in the Claim Rule Template drop down and click the Next button.
  3. Give it a Claim Name – probably including the name of the claim being passed through would be useful.  For the Incoming Claim Type drop down, select the claim type you want to pass through, for example E-Mail Address. I usually leave the default option for Pass through all claim values selected, but if you have different business rules then select whatever’s appropriate and click the Finish button.  Note that if you choose to pass through all claim values ADFS will give you a warning dialog.

Once you’ve added pass through claims for each claim you need in SharePoint you can close the rules dialog.  Now, for the last part of the RP ADFS server configuration, you need to find the SharePoint relying party.  Click on the Edit Claim Rules dialog, and for each Pass Through claim rule you made in the previous step, you ALSO need to add a Pass Through claim rule for the SharePoint relying party.  That will allow the claims to flow from the IP ADFS server, to the RP ADFS server through the trusted claim provider, and out to SharePoint through the trusted relying party.  If your claims from your IP ADFS server are not showing up in SharePoint these are the two locations to start looking.

Now move to the IP ADFS server.  Do step 1a through 1h as described above to ensure that you have added the root authority certificate(s) to the IP ADFS server.

  1. Open the AD FS 2.0 Management application.
  2. Expand the Trust Relationships node, then right-click on the Relying Party Trusts node and select Add Relying Party Trust…
  3. Click the Start button to begin the wizard.
  4. Leave the default option selected to Import data about the claims provider published online or on a local network, and in the edit box put in the address to the FederationMetadata.xml file (https://myRpAdfsServer/FederationMetadata/2007-06/FederationMetadata.xml by default) then click the Next button.  If your root authority certificate is correctly installed and the name can be resolved, then the wizard will continue to the next step.  If not, you have troubleshooting to do.
  5. Provide a Display Name and optionally Notes, then click the Next button.
  6. Review your data if needed, then click the Next button.
  7. Click the Close button to complete the wizard.  Leave the box checked to open up the rules dialog when complete.

Since this is the ADFS IP, we need to create a rule to pass along all of the claims that are going to be needed by SharePoint, the same way as you do when you add SharePoint as a relying party in ADFS.  Rather than walk through it in step-by-step detail, I’ll just suggest you read the ADFS end to end configuration posting I made at http://blogs.technet.com/b/speschka/archive/2010/07/30/configuring-sharepoint-2010-and-adfs-v2-end-to-end.aspx.  So in a nutshell you want to add a rule to Send LDAP Attributes as Claims.  Configure this rule the same way (meaning select the same claims and make the same mappings) as you do when you configure SharePoint as a relying party in ADFS.  That concludes the configuration you need to do on the ADFS IP.

That’s it.  You should now be set up to browse to your SharePoint farm and get redirected to the IP ADFS server to authenticate, while hitting your RP ADFS server coming and going.  Again, remember that if your client machines do not have the root authority certificate for the IP ADFS server’s web site SSL certificate, you will need to add this certificate to your client’s local trusted root authority certificate store.  Otherwise when you go to authenticate and you are redirected to the IP ADFS server’s web site, you will get a certificate warning dialog.

Once you have this set up, if you try and authenticate as a user on IP ADFS, you may get an error message in the browser coming from the IP ADFS saying that some error has occurred.  If you look in the event log on the IP ADFS server, you may see message ID #317 in the Applications and Services Logs…AD FS 2.0…Admin node:  The following errors occurred while building the certificate chain:  The revocation function was unable to check revocation for the certificate.  You will likely see that message if the token signing certificate used by the RP ADFS is either self-signed or domain issued.  You can eliminate this problem if you wish by turning off certificate revocation checking for your relying party.  To do so, open a PowerShell window on the IP ADFS server and type the following commands:

add-pssnapin microsoft.adfs.powershell
SEt-ADFSRelyingPartyTrust -TargetName <YourRelyingPartyName> -EncryptionCertificateRevocationCheck None

You may need to restart the AD FS 2.0 service after making this change.

And that my friends, does it.  It’s “interesting” to boil several hours of hair-pulling frustration into a 30-minute blog post.  I hope this helps someone, somewhere, and that everyone has a great Thanksgiving holiday.  One side note to this – I will add another post here shortly – a companion piece – that describes how to configure a SharePoint web app to redirect automatically to the write claims provider when AD FS has more than one (as we demonstrated creating here).

Configuring SharePoint 2010 and ADFS v2 End to End

In this post I’m going to do an end-to-end walk through on how to configure SharePoint 2010  and ADFS v2 together to use SAML claims authentication.  I’ll includes steps and PowerShell scripts to demonstrate and will try and bring all of the pieces together in one big posting.

First a brief overview of the components involved and what we’re going to need to do.  In this scenario ADFS v2 is our Identity Provider, also known as an IP-STS (Security Token Service).  We need to configure ADFS with information about our Relying Party, or RP.  In this case, SharePoint is our RP – it’s depending on ADFS to do the authentication and provide the claims.  From the SharePoint perspective, we have to configure it to trust the IP-STS that is sending us claims, and then we have to set up a web application and site that’s going to consume those claims.

We’ll begin by creating the relying party in ADFS.  Note that it really doesn’t matter which order you do these things in, but as a matter of practice I generally configure ADFS first.  So go to the server on which ADFS is installed and open the AD FS 2.0 Management application. Expand the Trust Relationships node and click on the Relying Party Trusts node.

Click on the Add Relying Party Trust link in the right pane to start the Add Relying Party Trust wizard. 

Click the Start button to continue.

Select the option to Enter data about the relying party manually, and then click the Next button.

Enter a Display name and optionally a description for the relying party and then click the Next button.

Select the option to use the AD FS 2.0 profile and then click the Next button.

You can select a certificate to encrypt the SAML token itself.  This isn’t done frequently because ADFS will require our connection to SharePoint be made over SSL, so the channel the token is sent over is encrypted already.  Click the Next button.

Check the box to Enable support for the WS-Federation Passive protocol.  For the protocol URL you need to enter the Url for the SharePoint web applictation’s root site, and include the “_trust” subdirectory.  In this example, the Url to my SharePoint web application is https://seo14, so the WS-Federation Passive protocol Url is https://seo14/_trust/.  After entering your Url click the Next button.

For the relying party trust identifier you need to enter a realm that your web application will pass to ADFS when users log into the web application.  The realm is generally created in the format of urn:foo:bar.  The realm is associated with a web application and is how ADFS can map the login request that’s come in to the relying party trusts it has.  When used with SharePoint, ADFS sees the realm associated with the login request, it looks that up to find the relying party trust, and then after it authenticates the user it looks to that WS-Federation Passive protocol Url to know where to redirect the user afterwards.  So in this case, I’ve entered a realm of urn:seo:sharepoint.  When I try navigating to my SharePoint site at https://seo14 I’ll be redirected to ADFS and I’ll configure SharePoint to use the realm urn:seo:sharepoint for that request.  Once ADFS has authenticated me it will redirect me again to https://seo14/_trust/ because that’s the passive protocol Url for that relying party.  Add whatever realm you want to use here and make a note of it because you will need to enter it again when you configure SharePoint.  Then click the Next button.

In most cases you will want all of your users to be able to use this relying party.  We’ll assume that’s the case for this scenario so just accept the default choice and click the Next button.

If you needed to make any other configuration changes at this time to the relying party trust you could do it here.  For this scenario we don’t need to so just click the Next button to continue.

We’re done configuring the relying party trust but we still need to create a claim rule to tell ADFS what claims to send back to SharePoint.  So leave the box checked to Open the Edit Claim Rules dialog and click the Close button.

Now we are going to create a new rule, so click the Add Rule… button.

We are going to send LDAP attributes as claims because we are getting information from Active Directory in this case, meaning we will authenticate at ADFS and ADFS is going to use the corporate Active Directory to authenticate us and determine what our attributes are.  So leave the default value selected and click the Next button to continue.

Start out by typing in a Claim rule name; it can be whatever you want.  Next, in the Attribute store drop down select Active Directory.  Next, for our scenario we want to send email address and the groups to which the user belongs back to SharePoint.  We are going to use email address as the identifier for the person, and we want all the groups a user belongs to sent over in the Role claim.  To do the mapping, select the attribute you want from the drop down on the left side, and then select the claim that it will be sent out as in the drop down in the right pane.  In this case we want the E-Mail-Addresses attribute from Active Directory to be sent out in the standard E-Mail Address claim.  We want the groups to which a user belongs to be sent out in the standard Role claim.  In this case I’ve selected Token-Groups – Unqualified Names because it sends the group name out as a simple string – the name of the group.  You could send out the SID of the groups but that becomes more difficult to use when you are trying to assign a Role claim to a SharePoint group.  After you’ve finished configuring this rule as described here, click the Finish button to complete the rule. 

Click the OK button to complete the process of creating your relying party trust in ADFS.  From a configuration standpoint in ADFS there’s nothing else we need to do.  However there is one other thing we need to get from it.  ADFS uses a certificate to sign the tokens it sends out.  This ensures the consumer of the token that it has not been tampered with since it was created.  To configure SharePoint we need a copy of this certificate because we’ll use it when configuring it to use ADFS as the IP-STS.  To get this token signing certificate from ADFS, expand the Service node and click on the Certificates node.

There is a section there for Token-signing certificates.  You may have one to many token-signing certificates, but there will always be ONLY one Primary token signing certificate.  Click on that certificate, and then click on the View Certificate link in the right pane.

In this particular case I chose to use the certificate I created for SSL on the ADFS web site.  I’m not suggesting that this is needed or even recommend; it’s just what I chose to do.  Now that you are viewing the certificate, click on the Details tab at the top of the dialog.

Click on the Copy to File… button.  That will start a wizard to save a copy of the certificate to disk.

Click the Next button to continue.

You don’t need the private key, so accept the default settings and click the Next button.

The default format is fine so click the Next button to continue.

Pick a location to save the certificate and click the Next button.  Make sure you remember this location because you will need to copy the certificate from where you save it over to the SharePoint server.

All the information needed to copy the certificate locally has been captured now so click the Finish button to complete the wizard and save the certificate to a local file.  Copy this file to the SharePoint server and then we are finished with the ADFS server.

Switch over to the SharePoint server and we will begin configuring it.  Before we start configuring SharePoint I recommend that you create a new web application now.  Create it to use claims authentication, but select Integrated Windows authentication – NTLM for the Authentication Settings.  Make sure you configure the web application to use Port 443 and you select the radio button that says Use Secure Sockets Layer (SSL).   Once you’ve created your web application remember to go into the IIS Manager and edit the bindings for the new virtual server so you can assign the appropriate SSL certificate.  These steps are outside the scope of this posting, but are well-documented in many places around the Internet.  To recap, for our scenario then there is a web application I’ve created that uses Port 443 and SSL and the Url for that web application is https://seo14.

The first thing I’m going to do on the SharePoint side is to add the token signing certificate I copied from the ADFS server.  Before I do that though, I need to look at the certificate.  The token signing certificate may have one or more parent certificates in its chain.  If it does, I need to add every certificate in that chain to SharePoint’s list of trusted root authorities.  To figure that out, I’ll find the token signing certificate I copied over from ADFS and double-click on it; that brings up the certificate properties window.  If you click on the Certification Path tab you can see if there are any other certificates in the chain.  In my scenario my token signing certificate DOES have a parent – it is the root certificate authority certificate.

What I need to do now, is for each certificate in the chain above my token signing certificate, I need to save a copy of each one locally.  I can do that by clicking on the certificate, which enables the View Certificate button in the dialog.  If I click on that it will open a separate properties dialog for that certificate.  I can then follow the same process I described earlier to save a copy of the certificate to disk:  click on the Details tab, click on the Copy to File… button, then save the certificate locally as a .CER file.  In my case I did this and saved it to C:\adfsParent.cer.  So now on my SharePoint server I have two certificates: 

·         C:\adfs.cer, which is the token signing certificate I copied from my ADFS server

·         C:\adfsParent.cer, which is the parent certificate to my token signing certificate

Now that I have both of these certificates, I need to add them to my list of trusted root authorities.  I’m going to do that in PowerShell with this script:

$root = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\adfsParent.cer”)

New-SPTrustedRootAuthority -Name “Token Signing Cert Parent” -Certificate $root

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\adfs.cer “)

New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $cert

After I execute those commands in PowerShell the output looks something like this:

Next I’m going to create the claim mappings that SharePoint is going to use.  If you recall from earlier in this article I said that I was going to use email address and role claims in SharePoint.  Here’s the PowerShell that I’ll use to create those mappings:

$map = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221; -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming

$map2 = New-SPClaimTypeMapping -IncomingClaimType “http://schemas.microsoft.com/ws/2008/06/identity/claims/role&#8221; -IncomingClaimTypeDisplayName “Role” -SameAsIncoming

Next I’m going to create a variable for the realm that I want SharePoint to use.  For this scenario I said I was going to use the realm urn:seo:sharepoint.  Here’s the PowerShell to create my realm variable:

$realm = “urn:seo:sharepoint”

Now I’m ready to create my SPTrustedIdentityTokenIssuer.  This is where I tie together all of the configuration information so SharePoint knows how to connect and work with the IP-STS.  I’ll show the PowerShell here and then explain the important parts:

$ap = New-SPTrustedIdentityTokenIssuer -Name “SAML Provider” -Description “SharePoint secured by SAML” -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl “https://congen1.contoso.local/adfs/ls&#8221; -IdentifierClaim “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress&#8221;

The “Name” attribute is what is going to show up in your web application when you configure what authentication provider it should use.  The “realm” attribute is where we plug in the realm that we want SharePoint to use with this trusted identity token issuer.  The “ImportTrustCertificate” attribute is where we pass it the token signing certificate that we copied from the ADFS server.  The “ClaimsMappings” attribute is where we tell it what the claims are that we want this trusted identity token issuer to use.  The “SignInUrl” is the Url that users should be redirected to in order to authenticate with the IP-STS.  In this case we want users to authenticate with the ADFS server using Windows integrated security, so we send them to the /adfs/ls subdirectory.  Finally, the “IdentifierClaim” attribute tells SharePoint which of the claims is going to be thee claim that is used to identify users.  In this case we’re saying email address is how you identify a person.

Once that last PowerShell command has executed, we have an SPTrustedIdentityTokenIssuer that can be used with our SharePoint web application.  So now we’ll open up the browser and navigate to Central Administration. Click on the Manage Web Applications link, then click on the web application in the list that’s going to use ADFS to authenticate, then click the Authentication Providers button in the ribbon.  Click the link in the dialog that corresponds to the zone in which you are going to use ADFS to authenticate.  Scroll down to the Authentication Types section.  You can now de-select NTLM, and you should see a new provider called “SAML Provider” in the list of trusted providers. 

Check the box next to it and click the Save button to save your changes.  Now you can go and create a site collection for the web application.  Again, describing that process step-by-step is not in scope for this posting, but there is one important thing to remember when you do this.  When you add the Site Collection Administrator, remember to enter the name in the format of your identity claim.  For example, in this scenario the identity claim is email address.  So when I added the Site Collection Administrator the name I used was administrator@contoso.local, because that’s the email address of the person I want to be the Site Collection Administrator.

Now I’m ready to try and go to my new site collection.  I open up the browser and type in https://seo14  and hit enter.  The first thing that happens is my redirected to the SignInUrl for the SPTrustedIdentityTokenIssuer that’s associated with my web application.  If you recall from the PowerShell that was used to create the SPTrustedIdentityTokenIssuer, that Url is  https://congen1.contoso.local/adfs/ls.   So here’s what I see after typing the Url to my SharePoint site in the browser:

You can see the Url in the browser window now points to my ADFS server and you can see the graphic in the background behind the login dialog is for the ADFS server.  You may also notice that I’m signing in using my Windows credentials, i.e. domain\user.  Remember I’m able to do this because I’m authenticating on the ADFS server, not on SharePoint.  SharePoint is configured to use email address as my identity, but what is going to happen is that I’ll authenticate over on ADFS, and then it will use the claim rule we created to pull out my email address and groups and put them into claims that will be sent back to SharePoint.  So then after I’ve authenticated I’m redirected back to SharePoint at https://seo14/_trust/, as I configured in the relying party I set up in ADFS.  At that point SharePoint will complete the authentication process on its side as it takes the claims it got in the SAML token and converts it into an SPUser.  Then I finally arrive at the home page for the site:

You’ll notice the login control in the upper right-hand part of the page is displaying my identity as email address, since that is my identity claim.

That’s the complete end-to-end process with a little explanation on the side.  You should be able to use it to get your sites configured and running by following these instructions.

You can download the attachment here:

Signout With SharePoint 2013 and SAML

Today’s topic is one for which I deserve zero credit, I’m just putting out info that one of our crack engineers, Chad Ray, managed to dig up.  I wanted to publish it here because I’ve worked with and talked to so many folks in the past who have struggled with getting a truly complete signout experience from SharePoint when using SAML authentication.  Chad was doing some digging and ran across a new property (in SharePoint 2013) on the SPTrustedIdentityTokenIssuer called ProviderSignOutUri.  As Chad explained to me, you just need to set it to the authentication endpoint of your IdP.  So for example, if you are using ADFS as your IdP and the ADFS host name is adfs.contoso.com, then the value you would set this property to is https://adfs.contoso.com/adfs/ls.

Not only will this log you out of your SAML session, it will also invalidate the fedauth cookie that you have locally so you really have to sign in again if you want to access content.  Kudos to Chad for finding this and sharing it.