Claims-based authentication "Cheat Sheet" Part 1

  • Article

 

This is the first part of a series of blog articles that talks about configuring claims-based authentication in SharePoint 2010 beta, on this first part, we will cover the following authentication scenarios:

 

  • Asp .NET membership / role provider (aka forms based authentication)
  • Anonymous access

 

We will keep posting blogs to cover additional claims-based authentication scenarios, meanwhile try these scenarios and send us your feedback.

 

For those that want to learn more about what is claims-based authentication and the benefits of this new feature, I recommend the following links:

 

 

Scenario Pre-requisites

First, and before we drill down into claims-based authentication details, install a SharePoint 2010 beta and run the configuration wizard. You can find more information about installing and configuring SharePoint 2010 in TechNet and the SharePoint team blog:

 

TechNet: https://technet.microsoft.com/en-us/library/cc262957(office.14).aspx

SharePoint team blog: https://blogs.msdn.com/sharepoint/

 

Steps to configure claims-based authentication in SharePoint 2010 beta

 

You can use SharePoint Central Administration or PowerShell cmdlets to configure claims-based authentication. For the later, we included a sample script that will make this path much easier. This is also a great way to learn how to use PowerShell in SharePoint 2010.

 

PowerShell sample script instructions:

We created a PowerShell script that you can use to deploy these scenarios in a very easy way, below we will discuss how to use this script in the different scenarios. Feel free to play with the script to accommodate your specific requirements, it is also a great tool to learn how to use our new SharePoint 2010 beta PowerShell cmdlets.

 

The sample script can be found  attached to this blog post.

 

Note: In order to use the script, copy the files from the above link to where the SharePoint 2010 beta is installed, you will need to create a directory (in any location) to place the files.

 

Pre-requisite step - Defining which membership provider to use and how to setup

 

In order to configure the web application with forms based authentication, we first need to have a ASP.net membership / role provider. If you don't have your own membership provider, you can use any of these two options:

 

  1. Use the SQL Membership / role provider (which is installed by IIS, click here for more info)
  1. Use the LDAP Membership provider (which is part of the SharePoint 2010 Beta Server product, click here for more info)

 

Depending on which membership provider was chosen, you will need to modify / update the values used in the sample script, this will be covered in step 1 below.

 

Step 1 - Modify the script to use values that adapt to your environment (Only if using PowerShell route)

 

Note: This step only applies if you want to use the script mentioned above

 

For configuring the settings required in the Asp .NET membership provider scenario, the script pulls the membership and role provider settings from the file WEBConfigs.xml

 

The default setting we provide in this file, configure the LDAPprovider which connects to a domain controller in order to authenticate the user and get the user security groups it belong. You can change them to use your own membership provider or the SQL membership / role providers.

 

Open the file  WEBConfigs.xml using the editor of your preference (notepad will work) and change the value of the "server" attribute to point to your domain controller. You will also need to modify the "userContainer" element with the information of your domain controller:

 

 <add name="LDAPmembership" type="Microsoft.Office.Server.Security.LdapMembershipProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="yourdomain.corp.contoso.com" port="389" useSSL="false" userDNAttribute="distinguishedName" userNameAttribute="sAMAccountName" userContainer="OU=UserAccounts,DC=yourdomain,DC=corp,DC=contoso,DC=com" userObjectClass="person" userFilter="(&(ObjectClass=person))" scope="Subtree" otherRequiredUserAttributes="sn,givenname,cn" />

 

<add name="LDAProlemanager" type="Microsoft.Office.Server.Security.LdapRoleProvider, Microsoft.Office.Server, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" server="yourdomain.corp.contoso.com" port="389" useSSL="false" groupContainer="DC=yourdomain,DC=corp,DC=contoso,DC=com" groupNameAttribute="cn" groupNameAlternateSearchAttribute="samAccountName" groupMemberAttribute="member" userNameAttribute="sAMAccountName" dnAttribute="distinguishedName" groupFilter="(&(ObjectClass=group))" userFilter="(&(ObjectClass=person))" scope="Subtree" />

 

Note that these changes needs to be done for both nodes: membership node and roleManager node.

 

To learn more about LDAPprovider go to here: https://technet.microsoft.com/en-us/library/cc262069.aspx#section3

 

Remember that you can also use your own membership / role provider or the SQL membership / role provider. More information about this can be found in TechNet and MSDN.

 

There are other parameters that need customization in the script, but we will be cover them in the upcoming blog articles that talks about other claims-based authentication scenarios, for the scenarios described in this article, you can leave them "as is".

 

Step 2 - Create a claims enabled web application

 

Via central admin (Does not apply for PowerShell path)

  • Got to central admin -> Manage web applications
  • Click on "New" web application
  • Click on "Claims based authentication"
  • Enter the values for the web application as directed in the page
  • (Optional) If you only want to have forms based authentication, then uncheck the "Enable Windows Authentication option"
    • Note1: If you leave Windows authentication, then during sign-in, the user will be redirected to the "authentication selection" page. In this page the user can chose between windows and forms based authentication
    • Note 2: Windows authentication is disabled, then SharePoint search service won't crawl content on that web application, one alternative to this is to create a second extended web application and enable Windows authentication.
  • Click on Asp .NET membership / role provider (Forms auth) to enable this authentication option
    • Enter the name of the membership provider and the role provider
    • These values will be used later on and should match the name set in the web.config file
  • Once the web application has been created, you will need to manually add the membership and role provider configuration sections in the following web.config files:
    • Your newly created web application
      • To get to the place where the web.config file resides, in IIS management console, click on the newly created "web application" node, then "browse"
    • Central administration web application
      • To get to the place where the web.config file resides, in IIS management console, click on the "central admin web application" node, then "browse"
      • Just in the case of this web.config, you need to add a <clear/> entry before the <providers> node
    • Security Token Service web application
      • To get to the place where the web.config file resides, in IIS management console, click on the "SharePoint Web Services" node, then on the "SecurityTokenServiceApplication" node, then "browse"
  • You need to find the <membership> <providers> node and add the entry with the settings of you membership provider, same for the role provider (in <providers> <roleManager>)

 

 

 

Via sample script for PowerShell (Does not apply for Central Admin path)

  • Launch a the SharePoint 2010 beta Management Shell
  • Switch to the location where you copied the script files
  • Open the SharePoint 2010 management shell (Start -> Microsoft SharePoint 2010 Products -> SharePoint 2010 Management Shell)
    • NOTE: Make sure you run the shell console as administrator
  • Execute the script with the appropriate parameters depending on the authentication type you want to configure:
    • Forms: claimswa.ps1 FBA
      • NOTE: This will create the FBA web application in port #201, to specify a different port, just add the port number after the "FBA" parameter
    • Anonymous: claimswa.ps1 ANON
      • NOTE: This will create the anonymous web application in port #201, to specify a different port, just add the port number after the "ANON" parameter
    • NOTE: If you run the script for a second time in order to create a new web application, you must specify the port number. This parameter is only optional the first time the script is used.

 

Step 3 - Assign the site collection administrators

 

NOTE: This is only needed if during web application creation you didn't created a site collection, you can check via central administration console if the web application you created has or not a site collection already configured.

 

Via Central Administration Console:

  • Go to Central Administration -> Application Management
  • Click on Create Site Collection (if not done during the web application creation)
  • Enter the users that will be the site collection administrators, if site collection was created during web application configuration, then you will need to click on Change Site Collection Administrators in order to access this configuration section

 

 

You should be able to browse to the newly created web application and use the configured membership provider in order to authenticate. Notice that all sites in this web application, the people picker can resolve the users from the configured membership provider.

 

Don't forget to send your feedback, and stay tuned for the upcoming posts of this guide with the steps to configure other authentication scenarios.

 

More information can be found on TechNet:

 

Article on configuring Asp .NET membership / role provider can be found here: https://technet.microsoft.com/en-us/library/ee806882(office.14).aspx

 

Additional TechNet resources can be here: https://technet.microsoft.com/en-us/library/ee806881(office.14).aspx

ClaimsScript_v1.5c.zip

Comments

  • Anonymous
    April 29, 2010
    Hey guys starting to step through this, but noticed that on the Pre-requisite steps 1 and 2: Use the SQL Membership / role provider (which is installed by IIS, click here for more info) Use the LDAP Membership provider (which is part of the SharePoint 2010 Beta Server product, click here for more info) The click here for more info aren't hyperlinks. Thanks for all of the info!

  • Anonymous
    May 02, 2010
    The comment has been removed

  • Anonymous
    May 04, 2010
    Somewhere in step 2, under "Via sample script for PowerShell (Does not apply for Central Admin path)" you might want to mention that the user running the claimswa.ps1 command (whether it defaults to the logged in user or one specifies a user) should be a managed account. Probably obvious to you guys living in the SP 2010 world, but not so obvious to us getting familiar with it. That got the script to run and resolved my error from above. Thanks