Update on configuring MOSS as a claims aware application

Article
07/30/2007

======================================================================================

UPDATE:

I'm not going to remove this blog or the original blog on the web.config entries - but I do want to make note that these web.config files should not be modified directly anymore. Please use the SetupSharePointADFS.vbs file to configure the MOSS applications for the SSO Provider. The script eliminates the possiblility of typo's, etc from these config files. I have used the script many times and it works great. If you open the help file included and go to the end - scenario 2 covers is the syntax you will use if you follow my other blog posts.

======================================================================================

It's been a few months since I posted the steps for configuring the WebSSO provider in MOSS. Recently, we have seen a spike in cases involving this configuration. In almost all of these cases, the problem has been with the web.config files. I'm going to try to highlight a couple of key points when setting this configuration up. I've also made some minor changes to the original post to eliminate some confusion.

First item - there are three web.config files you will edit, the central admin file, the intranet file which uses Windows Integrated Authentication, and the extranet site web.config. You will make the same changes to the central admin and intranet files. I'm going to put the section needed here. I recommend a copy/paste operation to notepad, change the fs-server to your actual server name, indent it how you like it, then modify the actual web.config files by copy/paste from your notepad file to the web.config file.

In the intranet and the central admin web.config files add this section directly below the <authentication mode> section

</providers>
</membership>
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
<providers>
<remove name="AspNetSqlRoleProvider" /> <add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</roleManager>

Now - on to the web.config file for the extranet. Add these entries:

Add the following entry within the <configSections> node

Add the following entry to the <httpModules> node

The ADFS authentication module should always be specified after the sharepoint SPRequest module in the in the <httpModules> section of the web.config file. It is safest to add it as the last entry in that section.

Add the following entry to the directly after the <authentication mode> node

<membership defaultProvider="SingleSignOnMembershipProvider2">
<providers>
<add name="SingleSignOnMembershipProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnMembershipProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</membership>
<roleManager enabled="true" defaultProvider="SingleSignOnRoleProvider2">
<providers>
<add name="SingleSignOnRoleProvider2" type="System.Web.Security.SingleSignOn.SingleSignOnRoleProvider2, System.Web.Security.SingleSignOn.PartialTrust, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" fs="https://fs-server/adfs/fs/federationserverservice.asmx" />
</providers>
</roleManager>
<websso>
<authenticationrequired />
<auditlevel>55</auditlevel>
<urls>
<returnurl>https://your_application</returnurl>
</urls>
<fs>https://fs-server/adfs/fs/federationserverservice.asmx</fs>
<isSharePoint />
</websso>

I've tried to clean up the trailing spaces and line it up with the technet documentation for my friends down in Houston ;)

Last - the latest issue we have seen is that we couldn't add a user by their UPN address to the SharePoint site. It turned out that an account store was not present on the FS-R. Here is the explanation on why this matters.

<snip>

The people picker will look up a user based on the email name(note: not the UPN) by successively calling ADFS MembershipProvider methods. During invitation time, the ADFS membership provider will call web method GetTrustedRealmUri() to FS and return the appropriate results.

If the input names are of valid email syntax, in either of the following 3 cases, the people picker can successfully resolve the user (which means the GetTrustedRealmUri() web method will return TRUE):

1. The user’s email suffix is accepted from one of the Federation trust partners.

2. There is a Windows Trust setup in the Policy with the account partner and is set to accept all domain suffixes.

3. There are account stores configured in the Trust Policy.

</snip>

Comments

Anonymous
November 22, 2007
How would you go about the following scenario: User signing into sharepoint using integrated login, user clicking a federated site link, user gets redirected to adfs, user gets authenticated by adfs via integrated login (possible?), token is created for user, users gets redirected to the federeted partner site with token and gets access. the question is. can adfs generate the token for a user without requireing the user to type in the user/password (using integrated login to generate the token?)?
Anonymous
February 24, 2011
Hi Kristoffer - could u get a solution for ur question - "Can adfs generate the token for a user without requiring the user to type in the user/passwd ?"

Partager via

Update on configuring MOSS as a claims aware application

Comments

Ressources supplémentaires