Archive for August, 2012

AD FS next steps…

Once you have AD FS setup with SharePoint there are some other considerations that you may want to consider, these are the ones that I have considered when installing for a client recently.


When the user logs out from the SharePoint site the user is not logged out of AD FS.  This may or may not be a problem but needs to be considered.  There are two options:

1. Disable Single Sign-on in AD FS.  To do this you will need to modify the web.config for the AD FS installation, see SharePoint and AD FS Part 2, and look for the microsoft.identityServer.web node.  In there you will find a singleSignOn property.  Change this value to false.  This method has the disadvantage of then not being able to sign on once to the organisation if there are multiple web sites the user can browse.  This may or not be an issue.

2. Modify the logout in SharePoint so it logs out of AD FS.  Shailen Sukul has an excellent example of this method here.

Adding another Web application

The point will invariably come when another web application from the SharePoint farm will need to use the same AD FS instance.  Steve Peschka has an excellent blog post “How to Create Multiple Claims Auth Web Apps in a Single SharePoint 2010 Farm” explaining how to do this.  The only thing that isn’t clear in his post is how to get the $ap variable populated if you already have it registered.  This is simple though, if you have only one token issuer registered then the following line will get it for you.

$ap = Get-SPTrustedIdentityTokenIssuer

If you have more than one you can use

$ap = Get-SPTrustedIdentityTokenIssuer –Identity "name of issuer"

to the end of the line to resolve it.

Categories: SharePoint Tags: , ,

SharePoint 2010 and AD FS – Part 3

In the first part of this series we looked at the problem we were trying to solve by using these products together. In the second part we installed the AD FS server.  Now we need to register our AD FS as a token issuer in SharePoint and configure SharePoint as a relying party in AD FS.

We will start on the AD FS Server creating the Relying party since if you are following this series in sequence you will already be on the AD FS Server.

Relying party trust

1. From the AD FS 2.0 Management application expand the Trust Relationships node and click on the Relying Party Trusts node.  Then click the Add Relying Party Trust link to start the wizard.


2. Press start to start the wizard.

3. Select “Enter data about the relying party manually”, and click “Next”

4. Enter a display name and a description if you want to, and press the “Next” button.

5. Select the option to use the AD FS 2.0 profile and click the “Next” button.

6. We won’t use a certificate to encrypt the SAML token so leave this step as is and press the “Next” button.

7. On the Configure URL screen check “Enable support for the WS-Federation Passive protocol” and enter the URL to the SharePoint web application’s root site, and then include the “_trust” subdirectory.  i.e.

8. After entering the URL press the “Next” button.

9. Under Configure Identities enter a realm in the form of a URN.  This is generally created in the format of urn:foo:bar.   This realm we will associate with a web application in SharePoint.  This means that SharePoint can tell AD FS which relying party to use.  I’m going to use urn:seo:portal for my application.  Then click the “Next” button.

10. Permit all users to access this relying party, and then press the Next button.

11. Click the Next button again and then click Close.

This will close the wizard and open the Edit Claim Rules dialog box.


12. Click the “Add Rule…” button.

13. Select “Send LDAP Attributes as Claims” and click the Next button.

14. Start by giving the rule a name, it can be anything you like.  Then select Active Directory from the Attribute store drop down.

15. I am going to use the email address as the identifier for the person and pass through all groups a user belongs to as a Role claim.  To do this mapping, select the attribute from the left hand side and the corresponding one from the drop down on the left hand side.

This is what you should end up with.


16. Click Finish, and then OK.

You have now configured the Relying party for SharePoint.  We now need to grab the token signing certificates from the AD FS manager and configure AD FS as a Token Issuer in SharePoint.

Copying certificates

Extract from AD FS

AD FS 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. To get this token signing certificate from AD FS, 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.


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 AD FS server.

These steps should be completed for all certificates in the chain.

Register with SharePoint

On the SharePoint server, run the following PowerShell script for each certificate exported above, changing the Name as required.

  $cerFile = "C:\ADFSParent.cer"
  $X509 = [System.Security.Cryptography.X509Certificates.X509Certificate2]
  $root = New-Object $X509($cerFile)
  New-SPTrustedRootAuthority -Name "Token Signing Cert Parent" -Certificate $root

Register the provider in SharePoint

Now we have the token signing certificates on the SharePoint server we need to create a Trusted Identity Token Issuer for AD FS and register in SharePoint.

To do this we will need some more PowerShell.  Here is the PowerShell, I’ll explain it below.

  $cerFile = "c:\TokenSigning.cer"
  $cert = New-Object $X509($cerFile)
  $map = New-SPClaimTypeMapping -IncomingClaimType
	                        -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
  $map2 = New-SPClaimTypeMapping -IncomingClaimType
                                -IncomingClaimTypeDisplayName "Role" -SameAsIncoming

  $realm = "urn:seo:portal"

  $ap = New-SPTrustedIdentityTokenIssuer -Name "AD FS Login Provider" -Description "SharePoint secured by AD FS" -realm $realm
                                -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 
                                -SignInUrl https://logon.example.coml/adfs/ls
                                -IdentifierClaim $map.InputClaimType


The first two lines load the token signing certificate from wherever you saved it.  Make sure you update the file path.

The next two lines specify the equivalent mappings to what we provided above when creating the Relying party.

Next the Realm is defined, which we entered above for the Relying party.

The last line creates the Trusted Identity Token Issuer in SharePoint.  The Name attribute is shown to your users if they need to select an authentication provider so don’t make it too cryptic.  The SignInUrl is the location of the AD FS Server instance.  The last attribute, IdentifierClaim, is the claim we are using to identify the users, this will show as their display name.

At this point you should be able to select this provider as a token issuer in the web applications authentication options.


And that is the end of the series.

Categories: SharePoint Tags: , ,