Setting Up Extranet - Part 1

Setup SharePoint 2013 Extranet

We have covered all important topics that lay ground work for creating Extranet sites. Here is what is needed for creating Extranets:

1.       Web application and site collection setup

2.       SSL setup – This is optional but highly recommended if you are allowing data exchange with external entities.

3.       Binding SharePoint site with SSL certificate

4.       Setup of users database

5.       Central admin and web.config configurations

6.       Testing

Remember, most of the topics mentioned above are optional. For example, you may not want to have a unique URL for your extranet site. You may be ok with the machine name in the URL but in case, if you want to have a unique URL for your site, read following article:

SharePoint 2013 – Setup DNS and use FQDN to access SharePoint sites (URL for print version: http://blog.walisystemsinc.com/2012/11/sharepoint-2013-setup-dns-and-use-fqdn.html)

This article explains how to setup DNS and  FQDN. So, instead of accessing your site with URL http://sp2013, you can access it using URL like http://www.walisystems.com

If you want to setup separate URLs for different departments in your organization, read following article:

SharePoint 2013: Setup multiple URLs in DNS and configure Alternate Access Mappings (URL for print version: http://blog.walisystemsinc.com/2012/11/sharepoint-2013-setup-multiple-urls-in.html)

If you want to setup SSL for your extranet site, there are three ways which are described in the below articles:

1.       Setup SSL in SharePoint 2013 using commercial certificates (URL for print version: http://blog.walisystemsinc.com/2012/12/setup-ssl-in-sharepoint-2013-using.html)

2.       Setup SSL in SharePoint 2013 using Self-Signed Certificate (URL for print version: http://blog.walisystemsinc.com/2012/12/setup-ssl-in-sharepoint-2013-using-self.html)

3.       Setup SSL in SharePoint 2013 Using Domain Certificate (URL for print version: http://blog.walisystemsinc.com/2012/12/setup-ssl-in-sharepoint-2013-using_16.html)

There are different options for setting up Extranets. You can use LDAP, you can use custom database, or you can use OpenID. In this article, you will learn to use custom database. By default, authentication type in SharePoint 2013 is claims-based. To access custom database or data source like LDAP (Lightweight Directory Access Protocol), forms-based authentication has to be configured in web application settings.  Forms-based authentication is an identity management system that is based on ASP.NET membership and role provider authentication.  SharePoint 2013 supports a variety of authentication methods and authentication providers for the following authentication types:

Ø  Windows authentication

Ø  Forms-based authentication

Ø  SAML token-based authentication

Advantage of using claims-based authentication is that you can setup multiple authentication methods in one zone but there are two restrictions that apply:

Ø  You can implement only one instance of forms-based authentication on a zone.

Ø  Central administration allows you to use both an Integrated Windows method and Basic at the same time.

Setup database

To use SQL Membership Provider, first you need to install ASPNETDB database. ASP.NET includes a tool for installing the SQL Server database used by the SqlMembershipProvider and SqlRoleProvider. The Aspnet_regsql.exe tool is located in the drive:\Windows\Microsoft.Net\Framework64\v4.0.30319. 

If you try to create web application that uses Forms-based authentication using SQL Membership Provider database, you get error message: “Sorry, Something went wrong” and it gives you a correlation ID which when you check in the logs shows several errors, for example, the following:

Microsoft.SharePoint.Administration.Claims.SPClaimEncodingManager.DecodeClaimFromFormsSuffix(String encodedValue)  at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(IClaimsIdentity claimsIdentity, String encodedIdentityClaimSuffix)     at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedIdentityClaimSuffix)     at Microsoft.SharePoint.Utilities.SPUtility.GetFullUserKeyFromLoginName(String loginName)     at Microsoft.SharePoint.ApplicationRuntime.SPHeaderManager.AddIsapiHeaders(HttpContext context, String encodedUrl, NameValueCollection headers)

The error occurs because Membership provider and Role manager have not been configured yet. We can configure web.config first and then create the application but let’s first install the database.

1.       Double-click Aspnet_regsql.exe to start the wizard.

2.       Click Next.

3.       Choose first option Configure SQL Server for application services. You can use same wizard to remove application services information from an existing database. Click Next.

4.       Enter database server name. Default method for accessing database is Windows authentication. If you have set up SQL server user ID and password, you can choose SQL Server authentication. Click Next.

5.       Click Next.

6.       Click Finish.

Adding Users in Database

Database has been installed but it is empty. Next step is to add users in the database. You can use MembershipSeeder application to add users. This application can be downloaded from codeplex:

http://cks.codeplex.com/releases/view/7450

Second option is to build your own .NET application that will provide interface to add data in the database.

Third option, the one I used, is to add data manually in the database.  This is ok if you want to add users for testing may be once or twice but in production environment where adding and removing users is an ongoing task, you need to have an interface to do this easily. Below, I show you how to add some test data so that we can continue with the application setup but before adding test data, we must give permissions to the accounts that will access this database.

7.       Open Microsoft SQL Server Management Studio.

8.       First we need to add account that we will use in new web application to the newly created database. You can use admin account in the new web application but standard practice is to use special service account for SharePoint applications. I have named this service account “spservice” and I will add it to the database permissions. Also you need to check what account STS (SecurityTokenService) uses. Open IIS manager.

Expand server name node, click Application Pools. Check Identity column again SecurityTokenServiceApplicationPool. This account (WALISYSTEMS\Administrator) must be added in the database permissions.

9.       There are two ways to accomplish this. You can add these accounts directly in the ASPNETDB database permissions or you can add them to the sysadmin role, that will automatically give them permissions on all databases. To add these accounts in sysadmin role, do the following:

a.       In management studio, expand Security node.

b.      Expand Server Roles.

c.       Double-click sysadmin.

Part 2
Part 3