During the beta release, I worked with Clayton Cobb to get Claims Based Authentication CBA up and running.  He had gone through the pain of setting it up once before and provided outstanding guidance to help me get my environment up and running.  Once RTM was available, I decided to try and tackle the solution solo, but the effort was a little to brutal for one person, so I called on my buddy Clay to help get me through the hurdles once again. So, to help others learn from my countless hours of Claims configuration, I present the following …

Hopefully you do not need to read this after using my Configuring Claims Based Authentication for SharePoint, but if you do, let me know what issues you had, and I will try to pinpoint them in the walkthrough.  With that being said, all it takes is one typo in your configuration, and you can spend hours trying to find it.  Here, I will outline some critical pieces and explain what they do so that you will have a better understanding of the processes that are taking place.  We will investigate my current setup.  This will give us a working environment to use as a reference.

Kerberos

Kerberos is a critical piece in the configuration of claims and will be the first area we focus on.  If you are unfamiliar with how to configure Kerberos, check out Configuring Kerberos.  You may have several different accounts, so I will pinpoint the ones that I used in my configuration.  I have one for the ADFS Services for my internal network and one for my ADFS Services for my external network. 

Open up an administrative command prompt and type: SetSPN –l {Your Claims Service Domain Account}. This will list all the SPNs set for the specified account.

This first illustration is showing the results of the command on my internal AD FS 2.0 server (mcm-adfs).  You will notice that it returns ‘http/mcm-adfs.mcm.lab.internal’.  It is important to note that it should say ‘http’ and not ‘https’ even though your site may be using ‘https’.  Notice also that we are using FQDNs and not just the server. 

Figure 1

 

The next illustration shows the same example, but executed on my external domain (company-adfs). 

Figure 2

 

Note:  ADFS Locations

  • mcm-adfs.mcm.lab.internal
  • co-adfs.company.lab.external

 

SharePoint Trusted Identity Token Issuer and AD FS Settings

 

The SharePoint Trusted Identity Token Issuer is our next area to focus on.  By running the PowerShell command to retrieve this information, we will be able to review our set up for any typos or misconfigurations.  Execute the ‘get-SPTrustedIdentityTokenIssuer’ cmdlet inside the SharePoint 2010 Management Shell located on your SharePoint server (mcm-sps).

The token issuer illustrated below was created using the following PowerShell script lines:

  • $certPath = “C:\Certificates\TS_mcm_labs_internal.cer”
  • $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
  • $map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
  • $realm = “urn:” + $env:ComputerName + “:adfs”
  • $signinurl = “https://mcm-adfs.mcm.lab.internal/adfs/ls/
  • $ap = New-SPTrustedIdentityTokenIssuer -Name “MCM ADFS20” -Description “MCM ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

 

To put the certificate into the SharePoint Trusted Root, run the following PowerShell script:

  • New-SPTrustedRootAuthority “MCM Lab ADFS Token Signing Trusted Root Authority” -Certificate $cert

 

Figure 3

There is a ton of information in here we need to look at.  First, take note of the ProviderURI.  We will need to make sure that this matches the endpoint on your AD FS server.  The URL should be the same FQDN that we saw in the Kerberos check above with ‘/adfs/ls/’ appended to it.  Let’s examine the endpoints on the AD FS server. The /adfs/ls/ location is the WS-Federation Passive Endpoint that SharePoint will use to get a token from MCM-ADFS, so “ProviderURI” is supposed to point to the endpoint for receiving a SAML or WS-Federation token.

Figure 4

 

Next, take a look at the Default Provider Realm.  Inside the Relying Party Trusts location, we are referring to urn:{SharePoint server name}:adfs.  Our example here is showing ‘urn:mcm-sps:adfs’.    This is the relying trust identifier which tells the ADFS server where to send the augmented token too.  On the AD FS server, click Relying Party Trusts folder.

Figure 5

 

Notice that the identifier matches the Realm attribute of the trusted identity provider in SharePoint..  Now double click the trust to dig into the details. Then, select the endpoint and click ‘Edit’.

Figure 6

 

Figure 7

Make sure you have a ‘/’ at the end of your url.  This can be a little misleading because the example underneath it does not have one. The Key point here is that the location specified here is SharePoint’s equivalent to the /adfs/ls/ directory on the ADFS 2.0 servers.

Now take a look at the claim description.  This is the mapping line added with the PowerShell script above: Figure 3.

Figure 8

 

Review the code and make sure that it matches the Claim Type you are looking for.  The code used above was ‘http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress’. 

We will now take a look at the Signing Certificate information.  The certificate will need to be in the Trusted Root Certification Authority folder.

Figure 9

Notice that the thumbprint information matches the thumbprint value in the PowerShell results above.  This tells me that I have the same certificate I used in my PowerShell script in my Trusted Root.  This one is not a show stopper, but will give you a red indication in the URL as depicted here.

Ok, so if all of that checks out, then it’s time to examine the ADFS settings.  Open up your AD FS snap-in.  We will start from the top.  In the Federation Service properties, you should see something similar to:

Figure 10

This information gets populated based off of the wizard you ran when configuring AD FS the first time.  The Federation Service name should be your FQDN for your ADFS server.  The Federation Service identifier is a critical piece of information that we will refer to in the external configuration piece in the next article.  TAKE NOTE that the Federation Service ID is http and not https, because when ADFS 2.0 servers reference each other, they use this value as the Identifier.

Let’s take a look at the certificates. You should have at least three certificates here.  From here, you will export the certificates for use on the other servers.

Figure 11

 

We will now take a look at the claim types.  In this example, I am only returning the email address out of Active Directory.  Every person who is given access to SharePoint through this claims provider will need to have an email address assigned to them or you will get an error!!!  Let’s look at the Claim Provider Trust information inside ADFS.

Figure 12

You will notice I have two entries here.  One is for my internal forest\domain; one is for the external.  I will focus on the internal farm and come back to the configuration settings for the external farm after we make sure everything is up and running.

If you use the script provided earlier in this article, then you should escape this next issue:

“The security certificate presented by this website was not issued by a trusted certificate authority”.

If you encounter this error, run the following PowerShell commands:

  • $certPath = “{Path-to-TokenSigningCertificate} (The .cer file exported from the ADFS 2.0 server)”
  • $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
  • New-SPTrustedRootAuthority {“Name String of Your Choice”} -Certificate $cert

     

 

Figure 13

You can now verify this by going into SharePoint and opening up your Central Administration site.  Notice ‘Manage trust’ under General Security.

Figure 14

 

Notice the ‘MCM Lab ADFS Token Signing Trusted Root Authority’ in the Trusted Relationships section. You should use the Get-SPTrustedRootAuthority command to verify the information is exact.

 

Figure 15

 

Figure 16

 

While we are inside Central Administration, let’s make sure we have what we expect in the authentication provider.  Notice we have ‘MCM ADFS20’ and it is selected.

Figure 17

 

Not So Random Errors

 

This one is definitely the easiest out of the bunch.  If you get ‘This CA Root certificate is not trusted’, click the Install Certificate and import it into the Trusted Certificate folder.

 

Figure 18

If you see Server Error in “/” Application Runtime Error when you are testing your claims implementation, you will need to review the AD FS logs to find the issue. The logs, by default, are located at %SystemRoot%\System32\Winevt\Logs\AD FS 2.0%4Admin.evtx. You may also review the logs using the Server Manager tool. They are located in the Diagnostics area, under Applications and Services Logs.

Figure 19

 

Figure 20

 

There was a problem accessing the site.  Try to browse to the site again.  If the problem persists, contact the administrator of this site and provide the reference number to identify the problem.  Reference number: …

Figure 21

 

This is another error that will send you to the AD FS error logs.  It can be anything from a bad certificate to a typo in the AD FS configuration.  Below is an example showing the ADFS log.

Figure 22

 

The root of the certificate chain in not a trusted root authority.

The issuer of the token is not a trusted issuer.

An exception occurred when trying to issue security token: The trusted login provider did not supply a token accepted by this farm.

Figure 23

The address needs to be a FDQN.  Instead of having mcm-adfs, it should be mcm-adfs.mcm.lab.internal. Whatever you see in the address bar here is what your ProviderURI is set to in the SharePoint trusted identity provider.

I saw this error a few time while setting up CBA: “AD FS Configuration Database Load Error”.

Figure 24

 

Figure 25

Make sure the Windows Internal Database is started and then check the ADFS service.

If the internal AD FS farm is working correctly, and you are having issues with an external farm, review the next article where we will discuss the configuration of the external forest.

Hopefully, by now, you have resolved your problem.  If you encounter a problem that isn’t covered here, I would love to hear about it.  Configuring

Advertisements

4 thoughts on “Debugging Claims Based Authentication: SharePoint 2010

  1. I am continually getting the Figure 21/23 error. Unable to check reference and neither it show up in adfs logs. (is there anything particular setting to see the error using the reference number ?)

    I also tried setting up FQDN as mentioned.

  2. I’m having a very unique problem with CRM 2011 where I have configured claims-based authentication internally and it works for most users but there are a handful of users over a variety of clients (Windows XP, Windows 7) for whom they get prompted for a login.
    Any ideas?

    1. The first thing that pops into mind is that it sounds more like a problem with authenticating to the backend datasource than with Claims. Since the identity is a claim, you may need to configure the C2WTS (Claims to Widows Token Service) to convert the claim to a Windows ID. Furthermore, you may also need to configure Kerberos with Delegation to pass those credentials to the backend system. Shoot me an email if you would like to discuss it further. 🙂

      email: sbray@go-planet.com
      twitter: @noidentity29

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s