Jump to content


3
[Tutorial]

SharePoint 2010 and ADFS 2.0 Setup



8 replies to this topic

#1 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38396 thanks
  • LocationActive Directory Inside

Posted 17 May 2011 - 10:09 PM

Part-1


I've had a few cases that involved customers using ADFS, SharePoint and Reporting Services. When going through this, one of the big struggles was just getting ADFS up and running with SharePoint 2010 so we could focus on the customer's issue. I did find a few items out there that got me pointed in the right direction, but they were all missing a few pieces that connected the dots. I thought I would share out my experience and try to be as complete as possible. I'll also say, that I do not consider myself an expert in ADFS, but I did have to run though this multiple times.

One thing this blog post will not go into is normal Active Directory (AD) setup or setting up a Certificate Server. I will be using the Certificate Server that comes with Windows Service for use with this setup. This is not a requirement, but made it easy for me to get this working in a complete manner as opposed to using self generated certificates, or getting trial certs for a demo purpose.

Certificates

During this course of this setup, there will be multiple points where we will need a certificate for one reason or another. Either ADFS or SharePoint/IIS. Because I have a Certificate Server setup, it is pretty easy to get a new cert. Which is also why I'm using it. You can also create a Self generated cert.

Within IIS Manager, highlight the server itself. There you will see an item labeled "Server Certificates". Make sure you are not on the Site, but the actual Server.

Posted Image

From there you have a few options. You can "Create Domain Certificate…" which will base it off of the Certificate Server bound to your Domain. You can also "Create Certificate Request…", which will go through the normal request for a Certificate Authority (CA) not bound to Active Directory. This could be a 3rd party CA like Verisign, or a CA that you have in your environment that isn't bound to your AD environment.

The last option is "Create Self-Signed Certificate…". This allows IIS to create a temporary certificate for use. While this can be used for your situation, it complicates things a little when it comes to moving the certificate around. When we get to the SharePoint integration, there will be times where we need to export and import some certificates. This is much easier to do when we have a known CA.

Posted Image

ADFS 2.0 Setup

When I first started on this, I recall seeing ADFS within the Roles for Windows Server, and thought: "Sweet, this will just be a quick wizard and I will be on my way!" Yeah, I was wrong.

Posted Image

What is listed in the Role selection is considered ADFS 1.0. What we really want is ADFS 2.0. This can be downloaded from the Microsoft Download center here.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=118c3588-9070-426a-b655-6cec0a92c10b&displaylang=en
And here is a quick link to the Documentation on ADFS 2.0.
http://technet.microsoft.com/en-us/library/adfs2%28WS.10%29.aspx
This will grab AdfsSetup.exe. Before I ran this, I made sure that I had Certificate Server setup as it will be needed.

From the install perspective, I choose "Federation server". From a quick test environment, this works fine, but if you are deploying this into a production environment you may need to have a different configuration depending on what you are doing.

Posted Image

Of note, I installed this on my Domain Controller, as I had a limited number of machines. This requires that PowerShell, IIS and some .NET items be installed for this to work as the ADFS items are basically a .NET Web Service. It will also install Windows Identify Foundation (WIF). I've talked about the Claims to Windows Token Service (C2WTS) before, and that is also part of WIF.

That's pretty much it from the install wizard that I encountered. After setup is done, I went into the ADFS Snap-in. From there it has a link to start the "ADFS 2.0 Federation Server Configuration Wizard".

ADFS 2.0 Federation Server Configuration Wizard

Posted Image

I then choose "Create a new Federation Service". Hit Next.

Posted Image

Because this is a test server, I choose "Stand-Alone federation server". Of note, this will also make use of SQL Server Express Edition for the ADFS data store. Which goes on the DC. Definitely not recommended on a Domain Controller if you are deploying this to production. It does mention that you can set this up with a full blown SQL Server from a command line, but I think SQL Express will still be laid down initially and you can just switch it over to full blown SQL Server. I'm not sure if there is a workaround to prevent SQL Express from being laid down. It may be that once you switch it over to the full blown SQL Server install, that you can just uninstall SQL Express.

It may also be that the "New federation server farm" option gives you some options for this, but I didn't have a look at that.

Posted Image

The next piece is where the Certificate Server first comes into play.

Posted Image

The certificates listed here are what are in the local Certificate Store. As this is the cert that will be bound to the Web site, the name will be derived from the Certificate itself. Meaning that the URL for the site should match the Certificate name. If the name listed isn't one you want, you can go to IIS and create a new Cert. Refer back to the Certificates section at the beginning of this blog which talks about how to create a new certificate.

That's pretty much it for that Wizard.

Claims/SAML

One thing to keep in mind is that ADFS will generate a SAML token which is what we use for Claims. When you setup a trust relationship (which we will get into in the next post), you are really setting up what claims you want in your token. As a result, when you setup a Trust Provider, which is what ADFS will be, within SharePoint 2010, it will be Claims based authentication.
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 3 Members:
c3rtifier , Bevis , harry817

#2 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38396 thanks
  • LocationActive Directory Inside

Posted 17 May 2011 - 10:19 PM

Part-2


In Part 1, we looked at getting ADFS actually installed, for Part 2, we will see what we need to do to get it working with SharePoint 2010. Being that I focus on Reporting Services, the end goal here is to see how it work with Reporting Services. However, RS will be for another post.

To get this working with SharePoint, there are a few things that we need to do.

Token-Signing Certificate

The ADFS 2.0 Service has what is called a token signing certificate.

Posted Image

Step 1 - Install to local Trusted Root

The first thing we want to do with this cert is to install it into the trusted root for the computer. This cert happens to be auto generated. You could also change the cert to be generated from the Certificate Server, but I'm not going to do that for this example. To install it into the trusted root, we can right click and view the certificate.

Posted Image

Click on "Install Certificate…". Go through the wizard and choose to "Place all certificates in the following store". We then want to be sure we select "Show physical stores" and select "Trusted Root Certification Authorities\Local Computer". This will ensure that the certificate goes into the Local Computer Trusted Root as opposed to the User's Trusted Root which would be problematic.

Posted Image

Posted Image

If we look at the Trusted Root for the local computer, we should see the certificate now.

Posted Image

Step 2 - Export the Token Signing Cert

We want to export the Certificate so that we can import it into SharePoint and the Trusted Root of the SharePoint machine. I just put these certs into a Certificate folder on the C drive. To Export, just right click on the cert, go to Tasks and choose Export.

We won't be able to export the private key, so we can just go with DER Encoded binary X.509.

Posted Image

Posted Image

Step 3 - Grab the Web Cert for ADFS as well

While we are here, lets grab the ADFS Web Certificate as well, as we will need that. This certificate happens to be in the Personal store.

Posted Image

We can just do the same thing that we did with the Token Signing Certificate.

Step 4 - Install the Certs into the SharePoint Box Trusted Root

We will want to install both Certificates into the Trusted Root for the SharePoint box. Within MMC, add the Certificates Snap-In for the local computer. Go to "Trusted Root Certification Authorities" and then right click on Certificates. Go to "All Tasks" and then "Import…".

After you have imported both Certificates, you should see them listed.

Posted Image
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 2 Members:
Bevis , harry817

#3 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38396 thanks
  • LocationActive Directory Inside

Posted 17 May 2011 - 10:25 PM

Part-3


SharePoint Trusted Provider

Now that the certs are in place, we can setup the SharePoint Trusted Provider. This is done through PowerShell. Here is the script:

	$certPath = “C:\Certificates\TokenSigningCert.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://dsdcontosodc.dsdcontoso.local/adfs/ls/”
	$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20Server” -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
Lets break this down.

$certPath = “C:\Certificates\TokenSigningCert.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
This gets the cert that we exported, and sticks it into the $cert variable.

	$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
This sets up our Claim mapping that we will use to identify users. Basically off of the Email address. We will have to set this up on the ADFS side as well a little later.

$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://dsdcontosodc.dsdcontoso.local/adfs/ls/”
The first item here identifies the Realm that we will use for the ADFS communication. This is also defined on the ADFS side as well. It is important that you keep these the same on the SharePoint side and the ADFS side. It doesn't have to be call this, but it needs to match what you will later define on the ADFS side. The second item is the URL to ADFS itself. In my case, it is on my domain controller, but this may be different in your case. It is important that the URL you use matches the Certificate in place with regards to whether you use the machine name or FQDN. They need to match.

	$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS20Server” -Description “ADFS 2.0 Federated Server” -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
The last command is what pulls all of this together and creates the Trusted Provider within SharePoint. To run the above PowerShell script, make sure you use the "SharePoint 2010 Management Shell" and that you run it as Administrator.

Posted Image

After that is done, we then want to add the Token Signing Cert to SharePoint's Trusted Root with the following command which will use the same $cert that we defined.

	New-SPTrustedRootAuthority “Contoso ADFS Token Signing Trusted Root Authority” -Certificate $cert
Posted Image

ADFS Web Cert

I found, when going through this, that any certificate that SharePoint interacts with needs to reside within SharePoint's trusted root. Even if the cert is in the computer's trusted root, it also needs to be in SharePoint's trusted root. This was the cause of a big headache for me. So, when dealing with Certs, I made sure if I added it to the Machine's local Trusted Root that I also added it to SharePoint's Trusted Root.

$certPath = “C:\Certificates\ADFSWebCert.cer”
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
New-SPTrustedRootAuthority “DSDContosoDC web server” -Certificate $cert
Posted Image

SharePoint should be good to go from an ADFS perspective at this point. We just need to finish up the ADFS portion.
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 2 Members:
Bevis , harry817

#4 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38396 thanks
  • LocationActive Directory Inside

Posted 17 May 2011 - 10:34 PM

Part-4


ADFS Relying Party Trust

The Relying Party Trust is the ADFS setup to know that SharePoint will be coming into it. This allows the ADFS provider to trust the SharePoint requests coming in.

Posted Image

We can just right click on "Relying Party Trusts" within the ADFS 2.0 window and select "Add Relying Party Trust...". This will spawn yet another wizard. Within that wizard we want to select "Enter data about the relying party manually".

Posted Image

The Display name can be whatever you choose. I choose "SharePoint ADFS Provider". We then want to select "AD FS 2.0 profile" on the "Choose Profile" landing page. For the "Configure Certificate" landing page, we can skip that.

For the URL, we want to select "Enable support for the WS-Federation Passive protocol" and enter the SharePoint Trust URL. In my case, this is https://dsdcontososp:5556/_trust/. Two things to note. First, the HTTPS on the url. HTTPS is required for this to work. Also the ending / after trust. Don't forget the trailing slash. The Port 5556 is what I will set my SharePoint Site to be.

Posted Image

For the "Configure Identifiers" landing page, you will notes that the URL we entered for the URL landing page is listed here. We want to remove this and add the Identifier that we used in our PowerShell Script. It is important that these match! Outside of that, you can make it the URL if you want, they just have to be the same on this screen and in the PowerShell Script. NOTE: The identifier is case sensitive.

Posted Image

For the "Choose Issuance Authorization Rules" landing page, you can select "Permit all users to access this relying party". Then finish out the wizard. At then end, be sure to leave the Edit option selected as we do want to edit the trust.

Edit Claim Rules

On the Edit Claim rules window, we want to Add a Rule. For the Rule, we can choose "Send LDAP Attributes as Claims". Then hit Next.

Posted Image

We will setup the attributes as follows:

Posted Image

This will send across the Email Address, their Account Name and the groups that they belong to in Active Directory. Once that is done, we can hit Finish and then OK.  Note:  The accounts in AD need to have an email address defined for this to work properly.

Posted Image

Setting up the SharePoint Site

I already have a Windows Claims site setup on Port 5555. To keep things a little separate, I will Extend this site to create a port that will be dedicated for ADFS.

Posted Image

This site will go on Port 5556 too match our Relying Party Trust in ADFS. It will make use of SSL, of which I already have a Certificate setup.

Posted Image
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 2 Members:
Bevis , harry817

#5 mashti

mashti

    Microsoft TE

  • Technical Expert
  • PipPipPipPipPipPip
  • 1,552 posts
  • 38396 thanks
  • LocationActive Directory Inside

Posted 17 May 2011 - 10:38 PM

Part-5


For the Authentication for this site, I will not choose Windows Authentication, but will select our newly created ADFS20Server provider that was made with the PowerShell script.

Posted Image

The URL for this site is not the FQDN in my case. The URL will really be based on what the Certificate you have, as they need to match. In my case, I created a cert just off of the machine name and not the FQDN.

Posted Image

Once all of that is done, click on OK and let SharePoint do it's thing. Once that is done there are a few other loose ends that I had to shore up.

First was disabling Anonymous access to the 5556 site within IIS. Not sure why it is enabled, but I turned it off. Another is making sure a user has access to the site. My Windows credential does not work and give me access when I come in on the ADFS side. I think this is due to the fact that my identify is different at that point and I'm being represented by my email address and not my SAM name. I didn't try switching it around to prove that point, but to get around it I did the following.

Within Central Admin, go to Application Management -> Site Collections -> Change Site Collection administrators

Posted Image

From here we can see that the ADFS20Server provider is available to search from. If I had tried this from my Windows Claims site, that provider wouldn't have been visible, which is why I can't just add users from that site.

Posted Image

Posted Image

Be sure to use the full email address and not just the account name. Once all of that is done, the site should come up with your ADFS Login displayed.

Posted Image

Hopefully this helps with setting up and configuring ADFS. This is not an exhaustive look at all of the features and capabilities, but should be helpful for at least getting your hands on the technology and playing around with it. This is what I had to go through to get a local repro up and running.
Whenever death may surprise us, let it be welcome if our battle cry has reached even one receptive ear and another hand reaches out to take up our arms.
I know you are here to kill me. Shoot, coward, you are only going to kill a man.


Che Guevara

Thanked by 3 Members:
Bevis , SunChero , harry817

#6 pemiwhariaSem

pemiwhariaSem

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 0 thanks

Posted 17 December 2011 - 05:14 AM

How to get multiple C category IP addresses?

#7 zeplynne

zeplynne

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 0 thanks

Posted 30 May 2012 - 06:27 PM

Great step by step, thanks!

I set everything up and I get all the way to the last step, a Windows auth prompt, after I select one of my domains from the ADFS Home Realm discovery page's dropdown.  However, no matter what credentials I enter the windows auth box keeps popping up for credentials.  All the users have email addresses in AD.  I tested and did a dual-auth provider and added windows NTLM as an auth option in SharePoint.  If that is selected the current user can get into the site.  Can't via ADFS.  I believe ADFS is setup correctly because I have another ASP.NET web application that is setup as a relying party on the same server and that works just fine.

Have you seen this behavior before?  Any suggestions?  I see nothing that jumps out in any logs in either server.

Thanks,
Steve

#8 ronansk

ronansk

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 0 thanks

Posted 20 June 2012 - 03:47 AM

Hi, I got a problem while choosing ADFS20Server, it prompts me to enter user credential, while I enter correct credential, it gave me a error page like this. http://www.freeimagehosting.net/5cbwm , how to solve it.

Thanks in advance.

#9 Bevis

Bevis

    Junior Member

  • Members
  • PipPip
  • 1 posts
  • 1 thanks

Posted 07 February 2013 - 08:54 PM

Good guide!  I actually used it to setup ADFS, since I didn't know ADFS, but do know SharePoint.  Just want to clarify a few things.  
  • 1st...SharePoint has it's own cert store, so there is no need to import the certificate into the local machine certificate store.  Not that it hurts anything, but it is simply an unneeded step.  That is why you ran into issues until you imported the certificates into SharePoint.  If you watch ULS logs, you will see SharePoint importing those certs during the login process.
  • 2nd...The reason you had to add you user name again as a site collection administrator is to SharePoint you are a different user to SharePoint since you are coming in on a different identity provider.  SharePoint identifies claims users similar to a Windows Active Directory user.  Just like domaina\bobsmith is a different user that domainb\bobsmith, a user on a different identity provider is a different user to SharePoint, even if they ultimately resolve to the same user account.  Since your ADFS identity provider and Windows Authentication identity provider are separate in SharePoint, so are their user stores.  Therefore, when assigning permissions, you should only assign permissions to a single user from a single identity provider, with the exception being crawl accounts (needs Windows auth to work, so it should only be there) and I put all my SharePoint service account in the Windows auth zone as well as my own personal account for administrative purposes.

Also note the following for user profile services when using trusted identity provider authentication.  Whatever account you are using to run your sync (not to be confused with the account starting the service, which should be the farm account) you should select the same identity provider you users will log in to, ie your ADFS provider.  Otherwise, it will sync the Windows account if you accept the defaults, which again, are different users to SharePoint.

Thanked by 1 Member:
Subramanian



0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

Organization

Community

Downloads

Test Providers

Site Info


Go to top