Samstag, 5. November 2011

SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide

SharePoint 2010 and ADFS 2.0 the complete Step-by-Step guide

A short intro.
As you know by now SharePoint 2010 comes with claims based authentication. It has a built in Identy Provider (security token service) which is working out of the box. It’s also possible to configure the SharePoint STS as a relying party for an other Identity Provider.
The purpose of the blogpost is to write a complete walkthrough for using SharePoint 2010 with ADFS 2.0 as an Identity provider in an production environment. No single server scenario or local service accounts, but a scalable 3 tier SharePoint environment and a scalable ADFS 2.0 farm with a Federation Server Proxy in a dmz.
This post will contain the index More content will be added once i have the documentation complete in the next few days. A lot of documentation concerning Sharepoint installation is already up for grabs on technet, so i’ll reference that when necessary.
The complete Step-by-Step contains the following steps
  1. Infrastructure
  2. Dns
  3. Adfs Service Account
  4. ADFS 2.0 installation
  5. Certificates
  6. Configuration wizard ADFS 2.0
  7. Add Token Signing Certificate
  8. Private key permissions
  9. Trusted relying partner
  10. Export Token Signing Certificate
  11. SpTrustedIdenityTokenIssuer
  12. Trusting Certificate Chain
  13. Create Web Apps
  14. Site collection administrators
  15. Site permissions All Authenticated Users
  16. User Profile Import
  17. What’s next?

1. Infrastructure

For this example i’m using the following infrastructure.
Naming convention
  • Domain fqdn : lan.contoso.com
  • Domain netbios : contoso
  • Intranet url : https://portal.contoso.com
  • MySite url : https://mysite.contoso.com
  • ADFS url : https://logon.contoso.com
Servers
  • VSrvDc : Windows 2008 R2 DC / Certificate Authority
  • VSrvSql : Windows 2008 R2 Member / Sql 2008 R2
  • VSrvSpW : Windows 2008 R2 Member / SharePoint Server 2010 Web Server
  • VSrvSpA : Windows 2008 R2 Member / SharePoint Server 2010 Application Server
  • VSrvFs : Windows 2008 R2 Member / ADFS 2.0
  • VSrvFsp : Windows 2008 R2 workgroup / ADFS 2.0
Already configured
  • All servers are installed with the mentioned OS and are member of the contoso domain (exept the Federation Server Proxy).
  • On the domain controller the Certificate Authority role is installed (with the web enrollment pages).
  • SharePoint Server 2010 is installed on both the SharePoint application server and the SharePoint web server.
  • The SharePoint 2010 Products configuration wizard has took place on the SharePoint application server.
  • Finally the SharePoint web server was added to the farm by running the SharePoint 2010 Products configuration wizard on the web server.
  • On the SharePoint application server the Configuration wizard has run using the default settings (with a dedicated service account)
  • The Federation Server Proxy is placed in a DMZ and remains in a workgroup

2. Dns

In this configuration i’ll configure a web sso for internal and external use. So i’ll have to create records in two dns zones.
External DNS zone
  • logon.contoso.com A record <public (NATed) ip address of Federation Server Proxy>
  • portal.contoso.com A record <public (NATed) ip address of SharePoint web server>
  • mysite.contoso.com A record <public (NATed) ip address of SharePoint web server>
Internal DNS zone
If your domain fqdn is not the same as your public domain, then you’ll have to create a DNS zone for this external domain in your internal DNS config. So in this example our domain fqdn is lan.contoso.com and our public domain is contoso.com. So i’ll first have to create a DNS zone with the fqdn contoso.com in our DNS.
Once i have the correct zone internally (matching the external domain) you create the same three A records in this zone.
  • logon.contoso.com A record <private ip address of Federation Server>
  • portal.contoso.com A record <private ip address of SharePoint web server>
  • mysite.contoso.com A record <private ip address of SharePoint web server>

3. Adfs Service Account

When you install ADFS 2.0 you have the possibility to choose between a single server ADFS or a ADFS farm (can add servers to). It’s a good idea to configure a farm (even if you’re going to use a single server scenario, because it provides flexibility for the future). The difference with configuring is that for the farm config you’ll need an AD service account that has an SPN configured on it. That’s all!
So in this step we’ll create the service account and register the SPN.
  • Open AD user and computers and create a user (in this example AdfsSvc)
There a two possible ways to add the SPN to the user
  • command line : setspn -a host/logon.contoso.com AdfsSvc
  • GUI : Enable Advanced Features view on AD users and computers. Rightclick the Service account. Select the Attribute Editor tab and scroll to servicePrincipalName and select edit. Add the SPN host/logon.contoso.com

4. ADFS 2.0 installation

Logon to the server which will function as Federation Server (VSrvFs). Download ADFS 2.0 RTW and start the installation by running AdfsSetup.exe. Choose Federation Server.
The installation wizard will also install some additional features (.net Framework, IIS). Once installation is complete the ADFS 2.0 console will open. Do not run the configuration wizard yet.

5. Certificates

Besides the certificates needed for SharePoint we’ll need two certificates for ADFS 2.0 web SSO
  1. Service communications certificate.
    • This certificate is used for the logonpage provided by ADFS 2.0 (in this example it’s logon.contoso.com).
    • This certificate should be a public certificate since you’ll be using it for employees accessing the loginpage from externally
    • This should be an default SSL certificate
  2. Token signing certificate.
    • This certificate is used for signing the tokens which will be provided to SharePoint. (in this example i used tokensigning.constoso.com issued by my internal CA)
    • This could be a public certificate or a certificate issued by your internal Certificate Authority
    • This could be any kind of certificate. I used an SSL certificate.
    • This should be an 2048-bits certificate. 1024-bits is possible but generates a warning in ADFS 2.0
If you’re configuring a Federated Web SSO you’ll need a thrid certificate for decrypting (outside the scope of this post)
Since the ADFS 2.0 wizard also installed IIS you can generate certificate request from the IIS console and request your certificates.
!! Note. Always export your certificates with their private keys and save them for future issues.
Once you have your certificates installed (they should show up in IIS) you’re ready to run the ADFS 2.0 configuration wizard.

6. Configuration wizard ADFS 2.0

Open the ADFS 2.0 management console on the Federation Server (VSrvFs) and click ADFS 2.0 Federation Server Configuration Wizard.
  • Create a new Federation Service
  • New federation server farm
  • Certificate : logon.contoso.com
  • Service Account : Use the AD service account created in step 3 (contoso\AdfsSvc)

7. Add Token signing certificate

To add certificates to ADFS 2.0 we need to disable the AD FS automatic certificate rollover feature.
Open a powershell on the Federation Server (VSrvFs) and run the following commands
Add-PsSnapin Microsoft.Adfs.PowershellSet-ADFSProperties -AutoCertificateRollover $false
Next, select ADFS 2.0 management console Service > Certificates > Add Token-Signing Certificate
Select the tokensigning.constoso.com certificate and mark it as primary.

8. Private key permissions

The account we specified in step 3 needs permissions on the private key of the Token signing certificate.
Open an mmc on the Federation Server (VSrvFs) and add the certificates snap-in (connect to local computer)
Browse to personal > certificates. Rightclick tokensigning.contoso.com > All Tasks > Manage Private Keys
Give the service account (contoso\AdfsSvc) read permissions

9. Trusted relying partner

In this step we’ll also specify the claims we will sent to SharePoint. For SharePoint there is one unique claims identifing the user. You can send additional claims, but the unique identifier is required. All the documentation i could find on the internet used the emailaddress as the unique identifier. So i’ll use a different claim as unique identifier so you can see the difference.
I’ll use WindowsAccountName as unique identifier. It’s referenced as http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname
You can search this blog to see where i used this unique identifier (and optionally replace it with your own, if you do you’ll need to adjust the claim mapping described in this step as well)
Open the ADFS 2.0 management console on de Federation Server (VSrvFs).
portal.contoso.com
Select Trust Relationships. Rightclick Relying Party Trusts and select Add Relying Party Trust.
Use the following settings in the wizard :
  • Select Data Source : Enter data about the relying party manually
  • Specify Display Name : portal.contoso.com
  • Choose Profile : AD FS 2.0 profile
  • Configure certificate : next (do not select a certificate)
  • Configure URL : Enable support for the WS-Federation Passive protocol
  • Relying party WS-Federation Passive protocol URL : https://portal.contoso.com/_trust/
  • Relying party trust identifiers :
    • https://portal.contoso.com
    • urn:sharepoint:portal
    • Choose Issuance Authorization Rules : Permit all users to access this relying party
    • Review settings
    • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes
Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
Use the following settings in the Add Transform Claims Rule wizard :
  • Select Rule Template : Send LDAP Attributes as Claims
  • Configure Rule :
    • Claim Rule Name : Pass-through LDAP Claims
    • Attribute Store : Active Directory
    • Ldap Attribute : SAM-Account-Name | Outgoing Claim Type : WindowsAccountName
Next we need to create a seconds Relying Party Trust
mysite.contoso.com
Select Trust Relationships. Rightclick Relying Party Trusts and select Add Relying Party Trust.
Use the following settings in the wizard :
  • Select Data Source : Enter data about the relying party manually
  • Specify Display Name : mysite.contoso.com
  • Choose Profile : AD FS 2.0 profile
  • Configure certificate : next (do not select a certificate)
  • Configure URL : Enable support for the WS-Federation Passive protocol
  • Relying party WS-Federation Passive protocol URL : https://mysite.contoso.com/_trust/
  • Relying party trust identifiers :
    • https://mysite.contoso.com
    • urn:sharepoint:mysite
    • Choose Issuance Authorization Rules : Permit all users to access this relying party
    • Review settings
    • Check : Open the edit Claims Rules Dialog for this relying party trust when the wizard closes
Next start the Edit Claims Rules Dialog. Select the tab Issuance Transform Rules and choose Add Rule
Use the following settings in the Add Transform Claims Rule wizard :
  • Select Rule Template : Send LDAP Attributes as Claims
  • Configure Rule :
    • Claim Rule Name : Pass-through LDAP Claims
    • Attribute Store : Active Directory
    • Ldap Attribute : SAM-Account-Name | Outgoing Claim Type : WindowsAccountName

10. Export Token signing certificate

In the next steps we’ll need the token signing certificate to create a SpTrustedIdenityTokenIssuer in SharePoint.
Open IIS 7 manager on the Federation Server. Select the servername in the console and doubleclick the certificates feature. You shlould see the two certificates you configured earlier. Doubleklick the tokensigning.contoso.com certificate and select the details tab. Select copy to file.
  • No do not export the private key
  • DER encoded binary X.509 (.CER)
  • save the file as c:\TokenSign.cer

11. SpTrustedIdenityTokenIssuer

Logon to the server running the Central Administration (VSrvSpA)
Copy the tokensign.cer you exported in the previous step to c:\ (of the current server)
Open the SharePoint 2010 Management Shell (powershell) and run the following powershell script
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“c:\tokensign.cer”)
$map1 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname” -IncomingClaimTypeDisplayName “Login” -SameAsIncoming
$realm = “urn:sharepoint:intranet”
$signinurl = “https://logon.contoso.com/adfs/ls/”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20″ -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
$uri = new-object System.Uri(https://mysite.contoso.com)
$ap.ProviderRealms.Add($uri, “urn:sharepoint:mysite”)
$ap.Update()

Once completed you can request your changes with the following command
  • get-SpTrustedIdentityTokenIssuer

12. Trusting Certificate Chain

In the example we used an certificate issued by an internal CA for the token signing. Because the SharePoint STS doesn’t trust the root of this CA we’ll need to add the Root certificate.
Get the root certificate from you’re internal CA and copy it to the c:\ of the SharePoint application server (VSrvSpa). Open the central administration website > Security > Manage Trust > Add
Give the Trust a name (contoso RootCA) and add the Root certificate from the c:\

13. Create Web Application

Create two web applications
  • https://portal.contoso.com
  • https://mysite.contoso.com
Configure the web applications with the following settings
  • Authentication : Claims Based Authentication
  • Create a new IIS website : portal.contoso.com (or mysite.contoso.com)
  • Port : 443
  • Host header : portal.contoso.com (or mysite.contoso.com)
  • Path : <default>
  • Allow anonymous : No
  • Use Secure Socket Layers (SSL) : Yes
  • Claims Authentication Types : Trusted Identity Provider (ADFS20)
  • Configure the remaining settings as usual
Create a site collection on a template of your liking for https://portal.contoso.com
Create a site collection based on the MySite host for https://mysite.contoso.com
Enable self service site creation for the MySite web application and create a managed path with a wildcard inclusion as specified in the mysite setting (configured in the service app User Profile Service).

14. Site collection administrators

When you created the site collection you have configured a site collection administrator. Make sure you used a claim here. When you open the people picker and want to specify (for example) the domain administrator and you type administrator you get two results. Select the administrator provided by ADFS20

15. Site permissions all authenticated users

Before any other user can login you must specify the permission based on claims. To get you started you can give the all authenticated users read permissions. Login on the site collection with the site collection administrator. Go to the site permissions and add permissions, when the people picker opens, click on authenticated users on the left menu and select all authenticated users (this is a claim).

16. User Profile Import

Configure the user profile import as specified on technet. I’ll create a blogpost on this later. There a a few things to adjust when working with ADFS 2.0
Central administration > Service Apps > User Profile Service Application > Configure synchronization connection
Use the following settings :
  • Connection name : Use your own
  • Type : Active Directory
  • Connection Settings
    • Forest name : lan.contoso.com
    • Auto discover domain controller
    • Authentication provider type : Trusted Claims Provider Authentication
    • Authentication provider instance : ADFS20
    • Account name : contoso\UseraccountConfiguredForProfileImport
    • Password : ********
    • Port :389 (or use LDAPS if you like)
  • Select the OU you like to import
When you have created the connection you need to adjust one user profile mapping
Central administration > Service Apps > User Profile Service Application > Manage User Properties
You will see three properties with claims settings.
  • Claim User Identifier
  • Claim Provider Identifier
  • Claim Provider Type
With the configuration of the synchronization connection the last two properties are populated.
The only thing we’ll need to change is the Claims User Indentifier. Select to edit the property. Scroll down to add new mapping and select the following settings:
  • Source data connection : Use the synchronization connection you specified before in this step
  • Attribute : samAccountName (since i used this as the unique identifier in step 11.)
  • Direction : Import
Click add and OK.
Now import the user profiles. When done login to https://mysite.contoso.com and you’ll see that your profile is mapped to you’re spuser object.

17. What’s next

So now you’ve got web sso with ADFS 2.0, why use NTLM anymore you say. We’ll the are some disadvantages to this scenario as well.
  • Exchange (up to 2010 sp1) is claims aware but only with the Microsoft Federation Gateway. So no web sso for OWA with SharePoint ;-(
  • Since the People picker will accept any claim and validate it, there is no name resolution available in the people picker. This isn’t a problem if you only want to use it to set permissions on a high level, but assign a simple task to a user can create great confusion since it will accept anything and validate it. There are some blogpost by speschka on how to write a custom provider to do some name resolution on claims, but it’s still not possible to resolve usernames.
Microsoft is making some huge steps in the (right) claims based auth direction. It’s probably the auth scenarion for the future. But we’re implementing SharePoint now…. Depending on your scenario it might be just what you need

Twitter Delicious Facebook Digg Stumbleupon Favorites More

 
Design by Free WordPress Themes | Bloggerized by Lasantha - Premium Blogger Themes | Free Samples By Mail