Forms Based Authentication in SharePoint site

By: Manoj V | Updated: 2011-07-26 | Comments | Related: > SharePoint Administration

Problem

There are situations when we need to provide access to a SharePoint site for users that are external to our domain. They could be clients, partners or vendors. We do not want to add these users to our Active Directory, so NTLM authentication is not an option, but still we need to somehow provide them access to certain areas on our SharePoint site.

There are scenarios when we do not want these users to virtually know the existence of each other and these are mostly extranet scenarios. In such situations, users should ideally get a sign-in page where they will have to provide their credentials to get access to the SharePoint site.

Solution

The solution is to store the users outside our Active Directory (AD) domain. There are mainly two methods to meet this requirement; store users in Active Directory Application Mode (ADAM for MOSS 2007) and Active Directory Lightweight Directory Services (AD LDS for SharePoint 2010) or in a SQL Server database. Fortunately MOSS 2007 supports authentication providers other than AD. This method of authentication is named Forms Based Authentication or FBA.

FBA can be configured on a standalone web application or on an extended web application. The method we choose depends on the scenario. ADAM is a light weight LDAP directory that offers basic LDAP functions with a subset of Active Directory functionality. ADAM is part of Windows Server 2003 installation and it runs as a non-operating system service.

For the purposes of this tip we will assume that we have a web application and we would extend it using FBA and provide access on certain sites to our partner by creating user accounts on the ADAM directory.

1. Installing and configuring ADAM

I have provided detailed steps for creating and configuring ADAM instance in my previous tip which is available here.

2. Extending Web application

We will first extend our main web application on to the extranet or internet zone.

a. Open Central Administration and navigate to Application Management, click Create or Extend Web Application.

b. Click Extend an existing web application.

c. The next screen is similar to the Create web application page. Key in the details and click OK to extend the web application in the zone we selected. Now we have our web application extended on a new URL.

(Note: An extended web application would use the same content db as the main web application but a separate IIS website.)

3. Configure Authentication Provider

We have to configure this extended web application to use forms authentication. To start with, navigate to Authentication Providers under Application Security on the Application Management page.

Select our main web application from the drop down list and click on the extended zone.

Select Forms in Authentication type and provide a Membership Provider Name. Then click Save.

4. Configure Web Config file

The next step is to make changes to the web.config file of the extended web application and central administration site. We make these changes so that SharePoint people picker searches for our ADAM users. So we would create partner company users in a container in our ADAM instance and they would appear in the people picker search along with our AD users.

Open the web.config file of the extended web application and Central Administration site and enter a value for the membership provider. The web.config file would look similar to this after we make the change:

Once we make this change save the file and do an IISRESET.

5. Configure Users in extended web application and Configure People Picker

When you access the extended web application in a browser we will be redirected to a sign-in page. Though we have created users in the ADAM instance we have not given these users privilege to access our extended site. The work around would be to log in to default site as Admin user (NTLM) and add the ADAM users. But for the ADAM users to list in the default zone web application people picker we will have to make the same web.config changes as we did in previous step.

For the people picker in SharePoint to list the ADAM users, we have to specify a wild card in the web.config file.

6. Limiting People Picker Results

In our case we do not want our AD users to be listed when a Vendor searches for users in People Picker in the FBA site. We have a couple of ways to restrict this, two of which are:

Search only within a site collection.
Non Windows Accounts only via FBA.

Search only within a site collection is suitable to a classic extranet environment where the internal and external user accounts are in the active directory however you do not want the extranet users to be able to search and browse the directory listing. Note that this is not 100% secure, users can still search Active Directory using a fully qualified logon name, regardless of this property setting. To only list users who have been added to a site collection we can run the following command:

stsadm -o setproperty -url http://partner.mycompany.com/sites/partner1 -pn 
peoplepicker-onlysearchwithinsitecollection -pv 
yes

In this case the People Picker would only list users from that Site Collection.

In the second method, the People Picker will not return any users from Active Directory. For example, say we have in our company a user named Bob and a partner has a user named Bobby. If the site admin of the partner site searches in the People Picker for 'Bob', the results will not include Bob in the AD domain. Here is the command:

stsadm -o setproperty -url https://partner.company.com 
-pn peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode 
-pv yes

When we extend a web application on to a zone where the content database is still the same, only a new URL is configured and a new IIS website is created. Therefore, 'Search' will work successfully because 'Crawl' will utilize the URL on the default zone.

In this article we saw how to configure a SharePoint application to use Forms Based Authentication in a tenant or hosting scenario. ADAM is part of the Windows Server 2003 OS and in Windows Server 2008, we have AD LDS. The same principle can be applied to SharePoint 2010 and we can configure it for FBA scenarios, however SharePoint 2010 can have multiple authentication scenarios in the same zone using claims based authentication without extending the web application.