In less than 9 days, I will be attending Rotation 6 of the SharePoint Microsoft Certified Master’s program. I built this post as a “cheat sheet” to help me remember some of the key areas on claims configuration. This post is in multi parts. Part one is a guided step through on configuring CBA inside your farm. Part two will add an external farm’s ADFS server to the rotation.

 

My lab environment is broken down into three farms. For the purpose of this article, only two are necessary. Both of these farms are consuming services from another farm, but that is an entirely different story. Here, we will focus on getting Kerberos up and running and then setting up CBA.

 

Many of the blog posts that I have seen are great as far as setting up the ADFS wizards or giving you the PowerShell scripts you need to get Claims working, but those solutions only appear to work on a single server. Each farm has three servers: Domain Controller, SharePoint and SQL, and an ADFS 2.0 server. I have combined the SQL and SharePoint 2010 server together only because of the lack of resources. My lap top has 16 gigs of RAM and I have 3 farms running at all times. By combining SQL Server 2008 R2 and SharePoint 2010, I put my most resource intensive servers together and give them 3.5 Gigs of RAM. The other two servers are starved down to 512 K. This seems to work great for tinkering and testing to see how things work.

 

I have included the server names along with their IPs. While it is not important that your environment be set up exactly like mine, I would encourage you to stick to the script as much as possible for your first or second run. I have gone through these steps three times to ensure that you will have success in implementing your environment. There may be a step or two here that may be unnecessary, and as I find those, I will remove them.

 

This first part is broken up into 6 parts: Account Set Up, Creating a Claims Aware SharePoint Site, Creating a Site Collection, SSL Certificates, ADFS 2.0, and Configuring SharePoint to use Claims. To keep this post small and easier to read, I have left out many of the screen shots and have only kept in the main options. The intent is not to explain how and why Claims Based Authentication works, I focus on more how to help get it set up so that you can either get your first environment up and running or debug your current situation. My previous post on Claims goes through many of the wizards, but I have found that going through it step by step, I ended up with missing certificates and did not set up Kerberos delegation. Without Kerberos delegation, these steps will return at Not Authorized – HTTP Error 401. The request resource requires user authentication.

    With that, let’s get into it.

 

 

 

Account Set Up

  • Create a new service account (labs\adfsservice)
  • Create a new service account (labs\spcontent)
  • SetSPN -A http/labs-adfs.labs.com labs\adfsservice
  • SetSPN -A http/intranet.labs.com labs\spcontent
  • Modify the properties of both accounts (adfsservice & spcontent)
    • Trust this user for delegation to any service (Kerberos only)
  • Modify the properties of the Labs-ADFS & Labs-SPS computers
    • Trust this computer for any delegation to any service (Kerberos only)
  • On Labs-DC (DNS Server), add a Host A Record (intranet.labs.com) pointing to Labs-SPS
  • Make sure all of your users who will access the system have email addresses!!!!

Create a Claims aware web application using SharePoint 2010

  • Add labs\spcontent as a managed account in SharePoint
  • Authentication – Claims Based Authentication
  • Port – 443
  • Host Header – intranet.labs.com
  • Allow Anonymous – Yes
  • Use Secure Sockets Layer (SSL) – Yes
  • Integrated Windows Authentication – Negotiate (Kerberos)
  • Application Pool
    • Application Pool Name – SharePoint Content
    • Configurable – LABS\spcontent
  • Database Name – LABS_Content_Intranet

Create a Site Collection

  • Title – LABS Intranet
  • Enterprise Wiki
  • User Name(s) – Labs\Administrator & Labs\Fred

SSL Certificate

  • Download and Install SSLDiag.exe – Version 1.1 (x64)
  • Open up Internet Information Services (IIS) Manager
  • Click Sites, make note of the ID for SharePoint – intranet.labs.com443 (1771713514)
  • Open command window (cmd) and enter “CD c:\Program Files (x86)\IIS Resources\SSLDiag”
  • SSLDiag /selfssl /N:CN=intranet.labs.com /K:1024 /V:730 /S:1771713514 – Hit Enter
  • You can verify that you now have a SSL certificate by checking the bindings of your site
  • Visit your site and verify it works – https://intranet.labs.com
  • Verify the Security Logs have your account signing in as Kerberos

ADFS 2.0

  • Install the correct version for your OS
  • Open Internet Information Services (IIS) Manager
    • Create a Self-Signed Certificate using the wizard
    • Friendly name labs-adfs.labs.com
  • Server Configuration Wizard
    • Create a new Federation Service
    • New federation server farm
    • Labs-adfs.labs.com
    • Service account: labs\adfsservice
    • Let Wizard complete configuration
      • Ignore Configure service settings warming
  • Add a Trusted Relying Party (RP)
    • Enter data about the relying party manually
    • Display Name – Labs SharePoint Server
    • AD FS 2.0 Profile
    • Enable support for the WS-Federation Passive protocol
    • https://intranet.labs.com/_trust/
    • Relying party trust identifier
    • Permit all user to access this relying party
    • Keep the check box for ‘Open the Edit Claim Rules…”
  • Edit Claim Rules for Labs SharePoint Server
    • Add Rule
    • Send LDAP Attributes as Claims
    • Claim Rule
      • Name: Email Address
      • Attribute Store: Active Directory
      • LDAP Attribute: E-Mail-Addresses
      • Outgoing Claim Type: E-Mail Address
  • Export the STS Certificate for use on the SharePoint Server
    • Open the ‘Certificates’ node in the AD FS 2.0 Management Console
    • View the Token-Signing Certificate
    • Install the Certificate
    • Copy To File …
    • DER encoded binary X.509 (.CER)
    • Save – C:\Certs\adfssts.labs.com
    • Install the Token-Decrypting Certificate

     

Configure SharePoint to Use the Claim

  • Open PowerShell Window
  • Copy adfssts.labs.com to local machine
  • Import certificate into the ‘Trusted Root Certification Authorities’
  • Add the PowerShell script highlighted below

     

    $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\Certs\adfssts.labs.com.cer”)
    $map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
    $realm = “urn:” + $env:ComputerName + “:adfs”
    $signinurl = “https://labs-adfs.labs.com/adfs/ls/”
    $ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS 2.0” -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType

    New-SPTrustedRootAuthority “Labs ADFS Token Signing Trusted Root Authority” -Certificate $cert

 

  • Inside Central Administration, click Security, Manage trust, and verify “Labs ADFS…” is there
  • Specify Authentication Providers, Default, Check Trusted Identity Provider, Check ADFS 2.0
  • Log in using Windows Authentication and add a Claims users
  • Close your browser
  • Sign-In as a CBA user

Advertisements

7 thoughts on “Claims Based Authentication: Made Simple

  1. Hi Shannon

    Best of luck on the MCM! MCM DS used to have ADFS as a key component usually trained by Laura Hunter, ADFS Legend. Unfortunately, this was removed from MCM DS. When in doubt, blame it on PKI.

    Best of luck, and keep a good supply of Red Bull

    Rob Silver,
    MCM DS

  2. Perfect!!, stumbled upon all other blogs for 2 days without success and ran into this and got success in under an hour. Good detailed steps for non single server scenario, looks like all other blogs include lot of assumptions and do not document complete steps, thereby not getting you success unless you are lucky enough to have your environment running true on those assumptions (rare!).

  3. This guide worked perfectly up until I tried logging in with the claims user that I added in the last few steps. When I hit the landing page I get the drop down to select Windows or ADFS 2.0. When i select ADFS 2.0 I get a Webpage cannot be displayed error. The URL doesn’t appear to be changing after selecting ADFS 2.0. Any idea what might cause this? Thanks.

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