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 "" -IncomingClaimTypeDisplayName "EmailAddress" -SameAsIncoming
$map2 = New-SPClaimTypeMapping -IncomingClaimType "" -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" -IdentifierClaim ""
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.

ADFSv2 and SharePoint Configuration Blog.docx

Comments (67)

  1. Anonymous says:

    Not sure why that is…I'm seeing them all so I'm not sure how to troubleshoot.  But you can always download the docx that is attached to the post.  It's the Word doc format of this post, including pix.


  2. Anonymous says:

    First a very good post. I've been experimenting with ADFS previously, and now we are trying to integrate with Sharepoint. So, this post was extremely helpful.  A couple of things that happened to me:

    1.) I never got a logon screen when redirected to my ADFS server, I just got logged in. In fact, I can't switch users, just logs me back in.  I'm thinking it is related to my ADFS setup, but unsure – any clues?

    2.) Any info on how to use claims sent back by the ADFS server. Is this where I'd need to provide custom code in Sharepoint to inspect the SP model – i'm assuming there's a Claims object?


    Steve Kumbsky

  3. Anonymous says:

    Hi Steve,

    Thanks a lot for this very clear Deployment Guide. After building it as a demo I feel very confident now to go out into the real world with "living" customers.

    Grtz, Jasper Kraak MCT/Consultant

  4. Anonymous says:

    HI Steve,

    Thank you for great post.

    At the Add Transform Claim Rule Wizard(pic number 14 from above), emaillAddress claim should map the sAMAccountName LDAP attribute instead of emailAddress attribute.

    Because we can use people picker and set access rights easily.

  5. alexandrad9x says:

  6. Anonymous says:

    Hi Steve,

    I cannot view anything on this post.  I have tried viewing the Blog Post using IE 9, Firefox 7 and Google Chrome 13.  The only viewable content on this post is the Comments area.  Is there a way to view the original posting again?


  7. Anonymous says:

    Oh interesting.

    If I click directly on the Smart Tag for ADFS and navigate to the posting, I cannot view the post (only the comments), but if I navigate by the date for the Blog Post, I can see the entirety of the Blog Post.  Is this some type of unusual feature in the MSDN Technet Blogs??

  8. Anonymous says:

    @TC100Years & @game2011 i got this error when the certificate was already used by another SPTTrustedIdentityTokenIssuer, you can either use another certificate or delete other SPTTrustedIdentityTokenIssuer

    @TC100Years your sign in url ans identifier claim contains a space at the end

  9. Anonymous says:


    thank you for the suggestion, I'll try tinkering with it. And sorry for hijacking your blog a bit 🙂



  10. Anonymous says:

    Thank you – these instructions were very helpful in our environment!

  11. Anonymous says:

    PS command keeps failing:

    error :

    New-SPTTrustedIdentityTokenIssuer : Exception of type 'System.ArgumentException' was thrown.  

    Parameter name:  newObj

    At line:1 char:39…

    how to rectifiy this error, what went wrong?

  12. Anonymous says:

    Very good content, congratulations.

  13. Anonymous says:

    @ Steve Kumbsky

    Steve – regarding your first question, ADFS 2.0 uses Windows Integrated authentication by default. If you set this up following Steve’s (:)) post you can change the authentication type used by modifying the web.config in /adfs/ls folder. The directions for
    doing that can be found here:…/ad-fs-2-0-how-to-change-the-local-authentication-type.aspx

    Also ADFS 2.0 respects the wauth parameter if used in authentication request URL, and that allows you to change from default authentication type per requestor. Here’s the link on wauth values that are accepted by ADFS:…/77c337e9-e11c-4747-a3cd-ea8faebc9496(v=PROT.10)

    Unfortunately I haven’t figured out yet how to make SharePoint add the wauth parameter to the request (at least without writing my own SharePoint authentication provider). I’ve been looking for a way to modify the SharePoint web.config (both in root and
    _trust folder) or settings of SPTrustedIdentityTokenIssuer to achieve this, but with no success. Interesting enough if you manually edit the ADFS authentication request issued by SharePoint to add wauth paramater – it works – you get the desired authentication.

    I’ve tried to get some help on forums:…/5f9c29db-3908-4fa0-81e8-8bc503c0c691

    but received no answers yet. It leads me to believe that standard SharePoint CBA isn’t capable of using wauth in ADFS requests.



  14. Chen says:

    all the pictures are not available:(

  15. Tajeshwar says:

    Very informative and crisp. You really make claims look so simple. Thanks.

  16. Naveen says:

    How can I map email address claim to SPUser mail so that SharePoint can send mails.

  17. Kanta says:

    Hi there,

    Very helpful post , I followed the steps  to authenticate user from ADFS 2.0 with SharePoint 2010 web Application .

    I got this problem not able to find the couse of it.  I have given read permission to serviceaccount and App pool acount. still I get this error.  Any suggestion is appreciated.

    Server Error in '/_trust' Application.


    The trusted login provider did not supply a token accepted by this farm.

    Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

    Exception Details: System.ServiceModel.FaultException: The trusted login provider did not supply a token accepted by this farm.

    Source Error:

    An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

    Stack Trace:

    [FaultException: The trusted login provider did not supply a token accepted by this farm.]

      Microsoft.IdentityModel.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst, RequestSecurityTokenResponse& rstr) +328

      Microsoft.IdentityModel.Protocols.WSTrust.WSTrustClient.Issue(RequestSecurityToken rst) +36

      Microsoft.SharePoint.SPSecurityContext.SecurityTokenForContext(Uri context, Boolean bearerToken, SecurityToken onBehalfOf, SecurityToken actAs) +19063094

      Microsoft.SharePoint.SPSecurityContext.SecurityTokenForOnBehalfOfContext(Uri context, SecurityToken onBehalfOf) +54

      Microsoft.SharePoint.IdentityModel.SPFederationAuthenticationModule.OnSessionSecurityTokenCreated(SessionSecurityTokenCreatedEventArgs arguments) +357

      Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SetPrincipalAndWriteSessionToken(SessionSecurityToken sessionToken, Boolean isSession) +92

      Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.SignInWithResponseMessage(HttpRequest request) +360

      Microsoft.IdentityModel.Web.WSFederationAuthenticationModule.OnAuthenticateRequest(Object sender, EventArgs args) +247

      System.Web.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute() +80

      System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously) +171

    Thank you


  18. Nedra says:

    Do you have a similar post for MOSS 2007 and ADFS 1.0 or could you recommend a post that is this straight forward?

  19. Trupen says:

    How do i encrypt the STS token from SharePoint WFE ?

  20. Tomislav says:


    great post. It helped me enable ADFS authentication for WP7 Office Hub SharePoint access. Although the SharePoint FBA worked too, ADFS actually enabled me to combine WIA and FBA on same web application and keep a single SharePoint user identity regardless of the authentication method chosen.

    I just wish that WP7 guys actually produced a step-by-step instead of making this a somewhat obscure process. Hope it will be released in days to come.

    I do have a question though. Could you please suggest how I could make a SharePoint IIS site request a specific authentication type from ADFS? Right now I can only influence this by modifying the web.config in /adfs/ls folder, and I'd like the relaying party (SharePoint) to do the choosing instead.



  21. speschka says:

    Hi Tomislav, first thanks for the comments you've been making on the blog site.  You're obviously doing a much better job than me in keeping up with questions.  🙂

    As for your specific question, I believe we are currently stuck here.  I would have suggested that you consider writing an HttpModule and adding a wauth query string parameter with the value you want.  However, in recent testing I found SharePoint to be swallowing any query string parameters I added for authentication purposes (in my case, whr).  You could try it and see if it works differently for you, but I would be surprised if it is.  It's something we're currently investigating.


  22. Sara says:

    This is a much better article than most that I have found, however, I have a few quesitons-

    1. Do you have to set up the cert through powershell, or can you just go to central admin, security, manage trusts, and add the cert there?

    2. I can't figure out whether there is a dedicated web app for sharepoint to talk to the IP-STS, or not.  Some documentation makes it seem like there is.  Your article sounds like you don't need one, that you just take the web app you would normally create to hold your site collections and you point it to the IP-STS.  Can you please clarify this?

    3. Does it matter what the realm is, as long as both sharepoint and the IP-STS realms match?

    4. I think it would be helpful to have an example using an FQDN for the web app, since I don't see the point in using federation for an intranet site- it would just make things a little more concrete.

    In any case, thank you for writing this!

  23. Jaydeep says:

    Can you have ADFS talk to two Domains that have no trust between them for verifying a users identity?

  24. Ryan R says:

    I see that you are bringing over Group information as a Role Claim.  I have done this also and am autheticating users through the "All ADFS Authenticated Users" bucket.  This is certainly not optimal and I wish to push users to groups based on the role claim.  We have not been able to get this worked out.  Any suggestions?

  25. Ryan S says:

    Thanks for this doc.  In the case of reconfiguring an already existing Sharepoint, it now considers the ADFS user account different from their Internal Windows Auth account.  How do we migrate user access?

  26. Capriole says:

    If you get an error "operation is not valid due to the current state of the object", check that you gave the user an email address (or whatever attribute you sleected as the identifier) in AD. I found the error a little cryptic and it took a while to figure out.

    Also to test ADFS is working independently of sharepoint can be helpful to use


  27. TC100years says:

    This PS command keeps failing for me:

    $ap = New-SPTrustedIdentityTokenIssuer -Name "SAML Provider" -Description "SharePoint secured by SAML" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl "congen1.contoso.local/…/ls"
    -IdentifierClaim "…/emailaddress"


    New-SPTTrustedIdentityTokenIssuer : Exception of type ‘System.ArgumentException’ was thrown.  

    Parameter name:  newObj

    At line:1 char:39…

    I’ve tripled checked my typing and the previous steps…any thoughts on what I should look at?

  28. AA says:

    When I enter my site name in browser it goes to IP-STS but it doesn't show any login page or authentication screen like yours. It shows wa=wsignin……in the address bar but I am getting page not found. I am not sure what is wrong. Could you pls help me in this

  29. seshukumar adiraju says:

    HI Steve,

    Great article. It was one of the better guides I could find to implement this.

    One of the issues we are facing right now is that people picker is not able to resolve user properly with ADFS authentication provider. Articles talk of a custom claim provider, but not sure, but dont see any detailed how to on that.

    Do you have any idea on that?

  30. Pratush says:

    We have the same mechanism working end to end for about a year now. (No workflows were being used in this instance)  However last weeks, users started to notice that OOB workflow are not working for external zone users as there was no 'workemail' property for users. Since users are coming from claims based auth – user profile is not populating workemail property.

    Is there a clean workaround to map the login name [identifier claim] to the Email property to ensure workflows don't break?

  31. Jasper says:

    Thanks Author and commenters for this thread.

    There is one question already asked up here but it is no yet answered:

    Can I have multiple external AD FS Claim Issuers (from multiple domains) within one webapplication? or do I need a separate WebApp for each of our customers with who we want to set this up.

    Thanks in advance,


  32. Ebenezer says:

    I cannot get ADFS2.0 to accept SHA-1. After changing in the advanced tab and restarting the server, I still see SHA-256 in the metadata. Any help or ideas?.

  33. John says:

    what are the steps to map Claims identity and windows identity to same sharepoint user profile ?

    is this through user profile sync mapping ?

  34. Yassar says:

    Hello Steve,

    I have a quick question about renewing the certificate. Our Token-decryption and Token-signing certificates had expired and we re-newed both of them. However, this broke Claims authentication on SharePoint.  So we copied the re-newed token certificate and added it to the list of trusted root authority. Do we need to run the Set-SPTrustedTokenIssuer  powershell cmdlt to fix the issue?

  35. Samir Vaidya says:

    Hello Steve,

    I just wanted to let you know that the above steps WILL NOT work on an installed instance of SharePoint 2010 SP1!

    You have to install the June 2011 CU or greater to get the integration to work.  I just spent several hours on the phone with Microsoft support before we were able to resolve this by applying the June 2011 CU.

  36. Rich says:

    Is anyone else not seeing the images on this post?

  37. Vipul says:

    I got page not found 404 error after login.

    Error CreateFromCurrentConfiguration: Unable to read Winhttp configuration. Using direct connection. Exception: System.NullReferenceException: Object reference not set to an instance of an object.

      at Microsoft.IdentityServer.WinhttpProxyConfigurationReader.Read(Uri& httpProxy, Uri& httpsProxy, Boolean& byPassLocalAddresses, List`1& byPassList)

      at Microsoft.IdentityServer.ADFSWebProxy.CreateFromCurrentConfiguration(IProxyConfigurationReader reader)

    In ADFS 2.0 tracing event log

    warning :User Action

    Ensure that the certificate that is identified by thumbprint '' has been added to the Localmachine "My" store and that it is accessible by the service account of the Federation Service.

    in ADFS 2.0 admin event log

    I there any solution for this?

  38. Ronald says:

    Thanks the instructions were very useful.


  39. m_clip says:

    I can see only a few images, and the rest are missing. I found that this is because the URL link to the images are being blocked by our proxy.

    The first image (which works) maps to domain

    The second image (which does not work) is domain (and doesn't do any redirect).

    If I change the domain of the second image to the same as the first image, I can see the image.

  40. Arturton says:

    Is it possible to configure SharePoint 3.0 to automatically save an email to a Document Library when it is forwarded to a particular email address<a href="">Somerton Artur</a>

  41. DubStep says:

    Arturton, yes…out of the box?  No.  You have write a workflow or code it.  The logic is there, you just have to put it together as it is not included in the out of the box functionality or workflows.

  42. Aj says:

    I have extended my web application, but I am unable to allow users to use the same URL as the primary web application zone i.e. default.

  43. DubStep says:

    AJ, that is by design.  When extending, ideally all users internal and external should be using the same URL, IE, the URL you extended to.  The default zone should only be used for administrator purposes (search crawler, farm administrators, etc.) in that model.  The easiest way to accomplish this is federate all users through ADFS and use split-DNS to direct internal users to the internal ADFS federation server and use an ADFS federation proxy for external users.  Optionally, you could setup an external federation server and federate between the two ADFS farms, but that requires additional setup and education of users since they will see multiple ADFS realms and need to know which to select.

  44. Tom Resing says:

    Hi Steve,

    As I learned at MCM, and already knew, you've got some of the best SharePoint Advanced Technical content on the web.

    I've used this step by step to good effect. Everything works but sign out. Do you have any recommendations for that? I read the article below and can get sign out to work if I first sign out from SharePoint then visit https://{DNS_name_of_RP_STS}/adfs/ls/?wa=wsignout1.0 before closing the browser, but that's not super convenient.



  45. Nik Patel says:


    Do check out this..…/adfs-2-sharepoint-2010-signout.aspx

    I would prefer not changing OOB files but create custom custom controls to replace existing welcome control and apply new logout links…

  46. Manoj Kumar says:

    I am getting this issue…any help would be greatly appreciated.

    Issue: In the last part of this setup i am finding problem while running following command (Administrator: SP powershell with SP snapin): $ap = New-SPTrustedIdentityTokenIssuer -Name "ADFS2" -Description "SharePoint secured by ADFS" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2 -SignInUrl $signinurl -IdentifierClaim "…/emailaddress"

    Error: New-SPTrustedIdentityTokenIssuer : The farm is unavailable.

    At line:1 char:40

    + CategoryInfo : InvalidData: (Microsoft.Share…dentityProvider:SPCmdletNewSPIdentityProvider) [New-SPTrustedIdentityTokenIssuer], InvalidOperationException

    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewSPIdentityProvider

  47. J Robinson says:

    All the images for this blog are not loading…..

  48. Dipan says:

    Hi Steve

    Thanks for the article. I have a quick question. I have an ADFS server and federated domains. There is a publicly available Sharepoint site, where users come in and provide a domain login credentials that belong to one domain. The complexity is that there are users who come from outside organizations to login to the site and use the domain credentials. The account they use to login is from the same AD. However the external users will be using machines that are home/office systems, i.e, they will be workgroup machines or domain joined machines from domains that are not part of the federation. How can I implement a SSO solution for this? Should I use a forms based authentication or use a redirect for the external user to get redirected to the ADFS proxy? Will redirecting users to a proxy help with the issue? That is, users who are using a non-domain joined machine, how will their credentials be passed and how will they get issued with the token identifying them as the users that have access when they have logged into their machines using a separate set of credentials? Please help!!! Any documentation will be equally appreciated.



  49. v-annade says:

    This error :

    PS C:UsersAdministrator> $cert = New-object System.Security.Cryptography.X509Certificates.X509Certficate2(“c:CertsFSTokenSigningCert.cer”)
    New-Object : Cannot find type [System.Security.Cryptography.X509Certificates.X509Certficate2]: make sure the assembly containing this type is loaded.
    At line:1 char:19
    + $cert = New-object < <<< System.Security.Cryptography.X509Certificates.X509Certficate2("c:CertsFSTokenSigningCert.cer") + CategoryInfo : InvalidType: (:) [New-Object], PSArgumentException + FullyQualifiedErrorId : TypeNotFound,Microsoft.PowerShell.Commands.NewObjectCommand Is fixed by: --------------- Here's a different way to achieve - ( thanks goes to DavGrand for the fix ) --------------- PS C:UsersAdministrator> $Source = @’
    using System;
    using System.Security.Cryptography;
    using System.Security.Cryptography.X509Certificates;
    using System.IO;
    using System.Text;

    namespace Cert
    public class Utility
    public static X509Certificate2 GetX509Certificate2(String path)
    return new System.Security.Cryptography.X509Certificates.X509Certificate2(path);

    PS C:UsersAdministrator> Add-Type -TypeDefinition $Source -Language CSharpVersion3
    PS C:UsersAdministrator> $cert = [Cert.Utility]::GetX509Certificate2(“C:CertsFSTokenSigningCert.cer”)
    PS C:UsersAdministrator> New-SPTrustedRootAuthority -Name “Token Signing Cert” -Certificate $cert

  50. Anonymous says:

    Where are the screenschots ?

  51. Anonymous says:

    Where are the screenschots ?

  52. Morris says:

    Hello, I followed the steps and I have an issue, under the site user policy and trying to add the users to the default zone I don’t see the SAML provider. Is there something I’m missing here? Morris

  53. Anonymous says:

    Pingback from Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2 | Nik Patel’s SharePoint World

  54. Anonymous says:

    Pingback from Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2 | Nik Patel’s SharePoint World

  55. Anonymous says:

    Pingback from Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2 | Nik Patel’s SharePoint World

  56. Anonymous says:

    Pingback from Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2 | Nik Patel’s SharePoint World

  57. Anonymous says:

    Pingback from Step by Step – Complete Guide to Configure ADFS 2.0 Integration with SharePoint 2013 on Windows Server 2008 R2 | Nik Patel’s SharePoint World

  58. DS says:

  59. Anonymous says:

    Intro to Host Name Site Collections (HNSC)
    First, I know several resources are out there published

  60. Umar says:

    Have you tried these steps with SharePoint 2013 ? will it work ?

  61. m88 says:

    Modern Thai restaurant combines outstanding traditional cuisine and a subtle modern decor with a warm welcoming ambience. Thai Restaurants in Brisbane : , traveller reviews of Brisbane Thai restaurants and search by price, location, and more..

    m88 : offer online sports games Asia, Sports Betting Asia, Sports Betting Sites Asia.

    m88asia : m88asia
    Link to M88BET phone: – Register and Open Betting Account and Membership M88BET.

    m88bet :
    MANSION88 the house is one of the largest and most prestigious. Appeared quite early in the Asian market, the so-MANSION88 currently attracts more players.

    link m88 : m88casino
    Home the M88 is the official sponsor of the football club in the Premier League
    Wish you happy with the new M88
    m88 casino online : m88online

  62. Anonymous says:

    Hey all, on Thanksgiving eve I’ve finally finished something I’ve been wanting to do for a while

  63. Anonymous says:

    Hey all, on Thanksgiving eve I’ve finally finished something I’ve been wanting to do for a while

  64. Anonymous says:

    I had been looking at Windows Azure Access Control Service (ACS) with an interesting eye recently, thinking