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:
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:
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:
SharePoint team blog: http://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:
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=22.214.171.124, 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=126.96.36.199, 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: http://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)
Via sample script for PowerShell (Does not apply for Central Admin path)
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:
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: http://technet.microsoft.com/en-us/library/ee806882(office.14).aspx
Additional TechNet resources can be here: http://technet.microsoft.com/en-us/library/ee806881(office.14).aspx