SECURITY

SharePoint Server 2010 is a distributed application that is logically divided into three tiers:

- the front-end web server tier,

- the application server tier,
- and the back-end database tier.

SharePoint can also interact with external systems—for example, by presenting data stored in

an external database in a list. Each tier or system is a trusted subsystem, and authentication

is required by default. Authentication is the process of verifying the identity of a user making

a request to an application. The application must be assured that the user is authentic

before the system performs authorization, which is the process of verifying that the user has

permission to make the request, and personalization, which determines how the application

interacts with the user.

Authentication = Verification of a Claim, it validates who I am.

Supported Authentication:

- Windows (NTLM,Kerberos,basic,anonymous,digest)
- Forms – based(LDAP,Microsoft SQL Server,ASP.Net membership & role providers)
- SAML Token – based(ADFS, 3rd party identity provider,LDAP and Azure ACS)
- OAuth(App Development TRUST Model)

Authentication in active Directory

It allow us to work with security groups that can be added to sharepoint site groups.

Configure Anonymous Access

Anonymous access is disabled by default. To configure the level of access that anonymous users have to

content, you must manage three settings:

- Anonymous authentication for the web application

- Permissions assigned to anonymous users for sites, lists, and libraries
- Anonymous access restriction policies for the web application’s zones

ENABLE OR DISABLE ANONYMOUS ACCESS ON AN EXISTING WEB APPLICATION

1. In the Central Administration Quick Launch, click Application Management.

2. In the Web Applications section, click Manage Web Applications.

3. On the Web Applications Management page, click the name of the web application for

which you want to enable or disable anonymous access.

4. On the ribbon, click Authentication Providers.

5. On the Authentication Providers page, click the name of the zone for which you want

to enable or disable anonymous access. For example, click Default.

The Edit Authentication page opens.

6. On the Edit Authentication page, select or clear the Enable Anonymous Access check

box, and then click Save.

When you enable anonymous access, SharePoint enables anonymous authentication for

the IIS Web site.

CONFIGURE ANONYMOUS ACCESS FOR A SITE

1. Click Site Actions, and then click Site Permissions.

The Permissions page opens.

2. On the ribbon, click Anonymous Access.

If you are not in the top-level site of a site collection, but rather are in a subsite, and if

the top-level site does not allow anonymous access, you will not see the Anonymous

Access button on the ribbon. This is because the subsite inherits the permissions from

its parent site. Click Stop Inheriting Permissions to block inheritance, and then you can

configure anonymous access permissions for the subsite.

The Anonymous Access page opens.

3. In the Anonymous Users Can Access group, choose one of the following options:

n Entire Web Site Anonymous users can view content on the entire Web site.

n Lists And Libraries Anonymous users can view content in certain lists or libraries.
n Nothing Anonymous users have no access to the site.

4. Click OK.

CONFIGURE ANONYMOUS ACCESS TO A LIST OR LIBRARY

1. Navigate to a list or library for which you want to configure anonymous access.

2. On the ribbon, click the List or Library tab.

3. Click the List Permissions or Library Permissions button.

The Permissions page opens.

4. Click Stop Inheriting Permissions.

5. Click Anonymous Access.

The Anonymous Access page opens.

6. In the Anonymous Users Can list, select the check boxes for the permissions you want

to assign to anonymous users.

In a document library, anonymous users can, at most, view items. Anonymous users

cannot be granted add, edit, or delete item permission.

7. Click OK

NTLM

Introduced more than a decade ago, NTLM is the most established form of authentication in

Microsoft products.

When a user logs on to his or her computer, the user is prompted for a user name and
password. The user name is sent to the domain controller, but the password is never sent over

the network. Instead, there is an encrypted challenge/response protocol through which a

hash of the password is passed through a one-way hashing algorithm (the challenge) by both

the client and the domain controller. The client sends the result (the response) to the domain

controller. If the result matches what the domain controller obtained as a result, the password

entered by the user must have been correct, and the user is authenticated

http://blog.morg.nl/2011/08/step-by-step-forms-based-authentication-fba-on-sharepoint-2010/

Step-by-step Forms-Based Authentication (FBA) on SharePoint 2010

Posted on August 25, 2011

This is an A-Z guide that helps you setup a web application with Forms-Based Authentication
(FBA) in SharePoint Foundation 2010, using Claims-Based authentication. It uses MS SQL
Server to store users. The SharePoint server is running in Windows Server 2008 R2. Although
this guide uses SharePoint Foundation 2010, the same steps apply to SharePoint Server 2010.

In this guide, you’ll create a SQL Server database to hold users and roles, create a SharePoint
Web Application that uses FBA, configure IIS and the web.config files for the Web App, Central
Admin and the Security Token Service, create a test user in the database and test your setup.

Contents

1. Setting up the ASP.NET Membership Provider database

2. Creating the Web Application
3. Modify IIS settings
4. Add ConnectionString and Providers to STS and Central Admin.
5. Creating a test user
6. Test in Central Administration
7. Create Site Collection and test

Setting up the ASP.NET Membership Provider database

Before we make any changes to SharePoint, let’s first create the database to store our users and
groups.
Log on to your SharePoint server with a SharePoint admin account. Make sure this account has
the DB creator server role on the SQL server that’ll hold the FBA users DB.

Navigate to the .NET v2 folder. The default location is: C:\Windows\Microsoft.NET\

Framework\v2.0.50727

Here, locate the file aspnet_regsql.exe and run it.

You’ll be presented with the ASP.NET SQL Server Setup Wizard.

Click Next to continue to the Select a Setup Option step.

Select Configure SQL Server for application services. This is the default option.

Click Next to advance to the Select the Server and Database step.
Specify the SQL Server name and instance where you want to create the database. Also specify
the database name.

Click Next to advance to the Confirm Your Settings step.

Check if you’ve specified the correct SQL Server name and instance and DB name. Click Next
to create the database.
If all went well, you’ll see the success screen displayed above. Let’s check if the database was
created as intended.

Start Microsoft SQL Server Management Studio and connect to the database server instance.
If all went well, you’ll find your new database has been created, along with a bunch of tables to
hold our users:
If you’re using Integrated Security, you’ll need to provide access to the database for the
following service accounts in SharePoint:

 Service Account that’ll be used for the application pool for the SharePoint Web Application using
FBA.
 Service Account used for the Security Token Service.
 Service Account used for the Application Pool of SharePoint Central Administration.

In this case, we’ll be using SQL Server authentication.

So create a new Login on the SQL Server. From SQL Server Management Studio, use the Object
Explorer to navigate to the Security → Logins folder. Right click on the Logins folder to open
the context menu and choose the menu item New Login…

This will open the Login – New dialog. Here, you specify a Login name, i.e. FBAService and a
SQL Server authentication password, i.e. pwd. You can set your membership provider database
as the Default database. Click OK to add the user. It will now show up in the list of logins.

To give the login access to the database, locate the

database in the Object Explorer, under the Databases folder and expand the folder Security. Open
the context menu from the Users folder and choose the option New User…

This opens the Database User – New dialog.

In this dialog, specify a name for the user and insert the login name that you created earlier (i.e.
FBAService) in the Login name text field.

Assign the following Database roles to the user:

 aspnet_Membership_FullAccess
 aspnet_Roles_FullAccess

Click the OK button to add the user to the database.

Creating the Web Application

Now that the DB has been created, we’ll create a new Web Application on the SharePoint 2010
server.

Open Central Administration as a SharePoint Farm administrator user.

Under Application Management, select Manage Web Applications.

You’ll see a list of current Web Applications, Click the New button in the Contribute section of
the Ribbon to create a new Web Application.

After a few seconds, you’ll see the Create New Web Application Modal window.

First, change the authentication mode to Claims Based Authentication.

Next, Specify the Name, Port and Host Header of your new IIS web site.
Leave the Security Configuration settings as default (no anonymous and no SSL).

Under Claims Authentication Types, leave the default settings for now (Enable Windows
Authentication, using Integrated Windows Authentication via NTLM). We’ll modify these
settings for FBA later.

Set the remaining settings for the new Web Application as you see fit.

Click OK button to create the new Web Application. Wait a few moments until the Application
Created dialog is shown, and click the OK button to close it (don’t create a site collection just
yet). The new Web Application will now show up in the list of Web Applications.

Modify IIS settings

In your SharePoint 2010 Foundation server, start Internet Information Services (IIS)

Manager.

Under your Web Server, navigate to the IIS site that we created in the previous step and double
click on Connection Strings
You’ll see a list of Connection Strings. In the Actions Pane, click Add… This opens the Add
Connection String dialog.
Here, specify a name for the connection string and give the SQL Server name and instance, and
database name of the DB that we created earlier. Use the Set… button to specify the SQL Server
authentication credentials for the SQL Server user that will access the database.

Click the OK button to add the connection string.

Go back to the IIS site screen and double click Providers.

Under Feature:, select .NET Users and in the Actions Pane, click Add…

The Add Provider window opens…

Here, we’ll modify a few settings:

 First of all, select SqlMembershipProvider from the Type dropdown listbox.

 Next, specify a name for the Provider, i.e. “FBA”.
 Under the Behaviour section, specify the desired behaviour for the SqlMembershipProvider.
 Under Data, select the Connectionstring we created in an earlier step.
 For the ApplicationName, enter “/”.

Click the OK button to add the provider. The new .NET Users provider will be visible in the list
of Providers.

Now, Change the feature to .NET Roles and in the Action pane, click Add…
The Add Provider window opens…

Here, set the following items:

 Under Type, select SqlRoleProvider

 Specify a name for the SqlRoleProvider, i.e. “FBARoles”
 Under Data, select the Connectionstring we created in an earlier step.
 For the ApplicationName, enter “/”.

Click the OK button to add the provider. The new .NET Roles provider will be visible in the list
of Providers.

The changes we’ve made to the IIS settings so far, have actually been made in the ASP.NET
Web.Config file.

In the IIS Manager, Switch to Content View, Open the Context menu by clicking below the
list of files and folders and choose Explore to open Windows Explorer.

From the new Windows Explorer window, open the web.config file in Notepad to view the
changes.

The highlighted rows were added with our previous actions:

1 <configuration>
2     [...]

3     <system.web>
        [...]
4
        <membership defaultProvider="i">
5
            <providers>
6
                <add name="i"
7 type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthMembershipProvi
der, Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral,
8 PublicKeyToken=71e9bce111e9429c" />

9                 <add name="FBA"
type="System.Web.Security.SqlMembershipProvider, System.Web,
1 Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
0 connectionStringName="ontw-spf2010 FBA DB" enablePasswordReset="true"
enablePasswordRetrieval="false" passwordFormat="Hashed"
1
requiresQuestionAndAnswer="false" requiresUniqueEmail="true"
1
applicationName="/" />
1
            </providers>
2
        </membership>
1
3         <roleManager defaultProvider="c" enabled="true"
cacheRolesInCookie="false">
1
            <providers>
4
                <add name="c"
1 type="Microsoft.SharePoint.Administration.Claims.SPClaimsAuthRoleProvider,
5 Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" />
1
6                 <add name="FBARoles"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0,
1 Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
7 connectionStringName="ontw-spf2010 FBA DB" applicationName="/" />

1             </providers>
8
        </roleManager>
1
        [...]
9
    </system.web>
2
0
2     [...]
1
    <connectionStrings>
2
        <add connectionString="Server=ontw-sql2010\test;Database=FBA-ontw-
2
spf2010;User ID=FBAService;Password=pwd" name="ontw-spf2010 FBA DB" />
2     </connectionStrings>
3
    [...]
2
4 </configuration>

As you can see, there are also other providers there, named ”i” and “c”. These are there
by default and required for Claims Based Authentication. Be sure not to modify them!

The membershipprovider also supports additional settings, such as the minimum required
password length and number of non-alphanumeric characters required in a password. For a full
list of properties that can be set, see
http://msdn.microsoft.com/en-us/library/9x1zytyd(v=VS.90).aspx

Add ConnectionString and Providers to STS and Central Admin.

In order for FBA to work, the ConnectionString, .NET Roles provider and .NET Users provider
also need to be added to the web.config files of the Security Token Service and the web.config
file of the Central Administration Web Application.

We could do this using the dialogs we used from the previous steps, but we can also make the
changes in the web.config files directly.

First up: the Security Token Service.

From the IIS Manager, locate the web.config file location by following these steps:
Under the SharePoint Web Services IIS site, Select SecurityTokenServiceApplication, open
the context menu by right-clicking the SecurityTokenServiceApplication node and choose
Explore.

This will open a Windows Explorer dialog with the location of the STS web.config file. The
default location is C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\
WebServices\SecurityToken.

Open the web.config in a text editor, like Notepad and make the following changes:

In the <configuration> section, see if there is a <connectionStrings> element present. If not, add
a <connectionStrings> element. Next, add the element containing the connection string to the
FBA database as highlighted in the Web App’s web.config file above, i.e.:

  <connectionStrings>
1
    <add connectionString="Server=ontw-sql2010\test;Database=FBA-ontw-
2
spf2010;User ID=FBAService;Password=pwd" name="ontw-spf2010 FBA DB" />
3  </connectionStrings>
Next, check if there is a <system.web> element, with <membership> and <roleManager>
elements present in the web.config, and add it if not, add them. Now add the membership and
role manager providers, as highlighted in the Web App’s web.config snippet, i.e.

1
  <system.web>
2
    <membership defaultProvider="FBA">
3
      <providers>
4         <add name="FBA"

5               type="System.Web.Security.SqlMembershipProvider, System.Web,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
6
              connectionStringName="ontw-spf2010 FBA DB"
7
              enablePasswordReset="true"
8
              enablePasswordRetrieval="false"
9
              passwordFormat="Hashed"
10              requiresQuestionAndAnswer="false"

11              requiresUniqueEmail="true"

12              applicationName="/" />

13      </providers>
    </membership>
14
    <roleManager enabled="true" defaultProvider="FBARoles">
15
      <providers>
16
        <add name="FBARoles"
17
              type="System.Web.Security.SqlRoleProvider, System.Web,
18Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

19              connectionStringName="ontw-spf2010 FBA DB"

              applicationName="/" />
20
      </providers>
21
    </roleManager>
22
  </system.web>
23
Save your changes to the web.config file.

Return to IIS Manager and locate the web.config file for Central Administration:

Select the SharePoint Central Administration v4 IIS site from the list of sites, open the
context menu for this site and choose Explore.

From the Windows Explorer window, open the web.config file in a text editor like Notepad.

Here, also add the ConnectionString snippet to the <configuration> section and add the .NET
Users and .NET Roles providers, just like you did for the STS site.

Note: the Central Admin’s web.config should already contain the <roleManager> and
<membership> elements in <system.web>. Be sure not to modify any existing providers.

Important: the default provider for the roleManager must be set to

“AspNetWindowsTokenRoleProvider”. (also see the highlighted row below)

1 <membership defaultProvider="FBA">

2   <providers>
    <add name="FBA"
3
          type="System.Web.Security.SqlMembershipProvider, System.Web,
4 Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"

5           connectionStringName="ontw-spf2010 FBA DB"

6           enablePasswordReset="true"

7           enablePasswordRetrieval="false"

8           passwordFormat="Hashed"
          requiresQuestionAndAnswer="false"
9
          requiresUniqueEmail="true"
10
          applicationName="/" />
11
  </providers>
12
</membership>
13
<roleManager enabled="true" defaultProvider="AspNetWindowsTokenRoleProvider">
14  <providers>

15    <add name="FBARoles"

          type="System.Web.Security.SqlRoleProvider, System.Web,
16
Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
17
          connectionStringName="ontw-spf2010 FBA DB"
18
          applicationName="/" />
19
  </providers>
20
</roleManager>
21

To enable wildcards in the people picker, locate the <PeoplePickerWildCards> element (inside
the <SharePoint> element), and add a key with the name of your Membership provider and
value “%”. It will look like this (the highlighted line is the key we added):

1<PeoplePickerWildcards>

2  <clear />

3  <add key="AspNetSqlMembershipProvider" value="%" />

4  <add key="FBA" value="%" />

</PeoplePickerWildcards>
5

Creating a test user

It’s hard to test FBA if you don’t have any users, so we’ll add a test user first. One way of doing
this is via the IIS manager.

First, we add a role to assign to the users. In IIS Manager, select the Web Application that will
use FBA and from the Features View, double click on .NET Roles.
You’ll receive an error message, saying the the feature cannot be used, because the default
provider is not a trusted provider. The default provider is “c”, which is the
SPClaimsAuthRoleProvider. Click on the OK button to close the dialog.

We’ll temporarily set the default provider to our FBARoles provider. Click Set Default
Provider… from in the actions pane and select the RoleProvider you created earlier (i.e.
FBARoles). Click the OK button.

Click the Add… link in the Actions pane. In the Add .NET Role dialog, enter a name for a role,
i.e. FBAUsers. Click the OK button to add the role. The new role is now visible, with 0 users.

We’ll leave the default roles provider this way for now, otherwise we’d not be able to add
a .NET user via IIS Manager.

Now, let’s add a user. Go back in IIS Manager to the Features View for your Web Application
and double click on .NET Users.
You’ll receive a similar error message, because the default provider (“i”) is not trusted. Click the
OK button to ignore.

Now click the Set Default Provider… link in the Actions pane and change the default provider
to the Membership Provider you created earlier (i.e. FBA).

Click the Add… link in the actions Pane, to add a new user.

The Add .NET User wizard appears. Enter the credentials for your test user (i.e. a User Name
FBAtest). Click Next to advance to the next step.

Now assign a role to the new user by clicking the checkbox(es) for the role(s). Click Finish to
add the user.

Important: Return the Default Provider for the .NET users to “i”  and for the .NET Roles to “c”.

Test in Central Administration

Now that we have the membership and roles provider set up in the Web Application, Central
Admin and STS, we can test if it works.
In Central Administration, go to Application Management → Manage web applications.

Select the Web Application you created earlier by clicking on it in the list. Its row will highlight
Now click the Authentication Providers button.

 The
Authentication Providers modal dialog will open. Click on the Default zone.

Scroll down to the Claims Authentication Types section. Here, deselect Enable Windows
Authentication and select Enable Forms Based Authentication (FBA).
Fill the ASP.NET Membership provider and ASP.NET Role manager names text boxes,
with the names you defined earlier (i.e. FBA and FBARoles).

Note: you can also use both Windows Authentication and FBA simultaneously, should you want
to.

Leave the other settings and scroll down to click the Save button.

After a few seconds, you’ll see the Authentication Providers modal dialog again. Close the
dialog. You’ll return to the Web Applications list.

With the FBA Web Application still selected, click the User Policy button in the ribbon.
The Policy for Web Application modal dialog opens. Click on the Add Users link.

The Add Users wizard opens, click Next >.

In the next page, the cursor will show up in the people picker field. Click the Browse button to
open the Select People and Groups dialog.
In the select People and Groups dialog, type (a part of) the name of the FBA test user you added
from IIS Manager in the Find text box and press the search button. You should find the user in
the Forms Auth search results.
This verifies that the FBA membership provider works from Central Admin. As we don’t want to
add this user, press the Cancel button and Close the Add Users dialog.

Create Site Collection and test

So far, we only created and configured the Web Application. To test FBA in the SharePoint site,
we need to create a site collection.

In Central Administration, go to Application Management → Create site collections.

Make sure you select the right Web Application, and specify a Title and Template for the top-
level site.

Select a Primary Site Collection Administrator, i.e. the FBA user you created earlier.
Click the OK button to create the site collection.
Now navigate to the newly created Site Collection. You’ll see a login page for the FBA
credentials.

Note:
if you chose to use multiple authentication methods for the Web Application’s Authentication
Providers, you’ll be asked to select an authentication method from a dropdown listbox first.

Sign in the the FBA user you declared as the Site Collection Administrator.

If all went well, you’ll see the name of the FBA user in the upper right corner!