Admins

Monday 6 July 2015

Forms Based Authentication with custom Login page in SharePoint 2010

Step1: Create web app with Claims Based Authentication

From Central Administration
Application Management
Click Manage Web Applications
Select New
Now we are in “Create web application” page
Select Authentication mode to “Claims Based Authentication”
Give the name of Web app, Port number & Path
Chose Security configuration
From Claims Authentication Types, enable both WA and FBA
FBA section, give ASP.NET Membership provider name (“SQLMembershipProvider”)
Give Role Manager Name (“SQLRoleManager”)
Enter Sign in page URL [default], public URL and other information
click OK
Then, create a site collection
Go to Manage Web application
From the list of web applications chose “Authentication Providers”
From the dialog box you will see the Default zone
Set to the Claims authentication mode
Click the Default zone link where you can see the settings
Now the Application is ready
Browse the application, we can see the default screen

Step2: Create ASPNETDB to configure membership and Role providers

Login to the server where SQL Server is installed
Open command prompt
navigate to location “%Sysroot%\Microsoft.NET\Framework\v2.0.50727”
Run the “aspnet_regsql.exe“ (ASP.NET SQL Server setup wizard)
Click “Next”
chose the option “Configure Sql server for application services”
Click “Next”
Give the SQL Server name and authentication information
by default it shows <default> means the name will be ASPNETDB, but you can change the name here if you want
Click “Next”
Finish the wizard

Step3: Fill some data to this DB

Their is some tools available in Codeplex
Go to this site and download “Membershipseeder.zip”
Extract it and run it
Create some of users and roles
Now, we are ready with DB with all some data

Step3: Modify web.config of web application we created
Note: Before making any changes to the web.config file of any app, please take the backup

Add Connectionstring just above <System.Web> starts or just below </Sharepoint> ends

<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />
</connectionStrings>

Add Providers for Membership and Role
Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
Make sure that you are not doing any changes to the existing providers.
By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
Finally the <rolemanager> section and <membership> section as shown below:
(new entries is in bold-italic):

Save all your changes

Step4: Modify web.config of of Central Administration site
Note: Before making any changes to the web.config file of any app, please take the backup

Add Connectionstring just above <System.Web> starts or just below </Sharepoint> ends

<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog= ASPNETDB ” />
</connectionStrings>

Add Providers for Membership and Role
Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
Make sure that you are not doing any changes to the existing providers
By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
Finally the <rolemanager> section and <membership> section as shown below:
(new entries is in bold-italics):

Save the web.config file

Step5: Modify web.config of Security Token Service Application

Open IIS
From the list of sites available expand “SharePoint Web Services” and find SecurityTokenServiceApplication
Right click on the application and explore, which will opens the file system file location of the application. By default it will be in “%programfiles%\common files\Microsoft Shared\web server extensions\14\WebServices\SecurityToken”
Find the web.config of the application and modify it

Note: Before making any changes to the web.config file of any app, please take the backup

Just above <System.Web> starts, add the connection strings tag

<connectionStrings>
<add name=”SQLConnectionString” connectionString=”data source=MSSQL;Integrated Security=SSPI;Initial Catalog=ASPNETDB” />
</connectionStrings>

Add Providers for Membership and Role
Before you add any providers find are there any membership or rolemanager tags in the web.config file and add the providers [<rolemanager> and <membership>] to the <System.Web> tag
Make sure that you are not doing any changes to the existing providers
By default there are providers with name “C” and “I”. So, do not touch them and add only the providers which we are adding like “SQLRoleManager” and “SqlMembershipProvider”.
Finally the <rolemanager> section and <membership> section as shown below:
(new entries is in bold-italics):

Save the web.config file

If everything is OK, then from central administration site and your FBA application, we can able to find the users from ASPNETDB (using people picker), and you can successfully logged-in to the site without any issue
Step6: Create custom Login Page

Start Visual Studio 2010
Create a new SharePoint 2010 project using the “Empty SharePoint Project” template.
Choose Farm Solution (We are going to deploy files to the SharePoint root, also known as the 14 hive, so we cannot use the sandbox here)
Add a new item to the project. Choose to use the Application Page template and name the new page Login.aspx
Add a reference to the assembly “Microsoft.SharePoint.IdentityModel” ( It does not show up in the list of assemblies in the Add Reference dialog, you need to browse to it using the path “C:\Windows\assembly\GAC_MSIL\Microsoft.SharePoint.IdentityModel \14.0.0.0__71e9bce111e9429c\Microsoft.SharePoint.IdentityModel.dll”
Add the code from the following site:
http://tomaszrabinski.pl/wordpress/2011/06/23/sharepoint-2010-custom-login-page/
Publish
To configure your custom login page, Go to Central Administration
Click on “Manage web applications”
Click your web site, This lights up the “Authentication Providers” ribbon button
Click the Authentication Providers ribbon button
Choose the zone that you want to configure (this should be the zone that was extended for FBA, or the default zone).
Scroll down a bit and you’ll see where to configure the Sign In Page URL

Once that is done, our new sign-in page is now available and works as expected

Configuring Forms Based Authentication in SharePoint 2013

Configuring forms based authentication (FBA) in SharePoint 2013 is very similar to SharePoint 2010, but there are some differences due to SharePoint 2013 using .Net 4.0. The web.config entries entries are slightly different. As well, IIS doesn’t support editing .Net 4.0 membership provider configuration through the IIS interface, so all of the configuration has to be done directly in the .config files. I’ll go through all of the steps required to setup FBA for SharePoint 2013, from start to finish.

1. Creating the Membership Database

The first thing you need when configuring FBA for SharePoint is a place to keep all of the usernames and passwords. ASP.Net comes with a tool that we’ll use to create a membership database to store the logon information.

Navigate to c:\windows\Microsoft.NET\Framework64\v4.0.30319\
Run “aspnet_regsql.exe”
A welcome screen will appear. Click Next.

Select “Configure SQL Server for application services” and click Next.

Enter the name of your server and your authentication information. In this case SQL Server is installed on the same server as SharePoint 2013 and I am logged in as an administrator and have full access to SQL Server, so I choose Windows Authentication.For the database name, I just leave it as <default>, which creates a database called “aspnetdb”.

A Confirm Your Settings screen will appear. Click Next.

A “database has been created or modified” screen will appear. Click finish and the wizard will close.

Now that the database has been created, we’ll have to give SharePoint permissions to read and write to it. We’re going to connect to the database with Windows Authentication, so we’re going to have to give those permissions to the service account that is being used to run SharePoint.First, let’s find out the service account that’s being used to run SharePoint. Open IIS, go to “Application Pools”. Take a look at the “Identity” that is being used to run the SharePoint application pools. On my test server, it happens to be my administrator account that is being used, but it will probably be different on your machine. Make note of the identity used.

Now that we know what account is being used to run SharePoint, we can assign it the appropriate permissions to the membership database we created. Open up SQL Server Management Studio and log in as an administrator.
Under Security/Logins find the user that SharePoint runs as. Assuming this is the same database server that SharePoint was installed on, the user should already exist.Right click on the user and click ‘Properties’.
Go to the “User Mapping” Page. Check the “Map” checkbox for the aspnetdb database. With the aspnetdb database selected, check the “db_owner” role membership and click OK. This user should now have full permissions to read and write to the aspnetdb membership database.

2. Adding Users to the Membership Database

Now that we’ve created an empty membership database, we need to add some users to it that can be used to login. You have a couple of options for doing this. If you’d like to do all of your user management in SharePoint, then you can install the SharePoint 2013 FBA Pack and skip to Part 3. If you’d like to be able to manage the users outside of SharePoint, and setup some inital users, then continue on to learn how to manage the FBA users with IIS.
To manage users in IIS, we’re going to create a dummy site just for managing users. In SharePoint 2010 and earlier it was possible to edit the users directly from a SharePoint web application site, as long as the default membership provider was set to the membership provider you were going to edit. This is no longer possible, as previous versions of SharePoint ran against ASP.NET 2.0 (3.5), but SharePoint 2013 runs on ASP.NET 4.0. IIS does not support editing users and roles for ASP.NET 4.0 applications. To get around this, we’ll create a dummy/blank ASP.NET 2.0 web site just for editing users. The asp.net 2.0 and 4.0 membership databases are exactly the same, which makes this possible.
NOTE: These directions were created on Windows 2008 R2. On Windows 2012 they have reversed things and the .Net Users and .Net Roles options are only available for .Net 4.0 and are not available for .Net 2.0 – So on Windows 2012 please use .Net 4.0 where 2.0 is mentioned in the directions.

Open IIS.
Right click on Sites and select “Add Web Site…”
A configuration dialog will appear. Just give it a meaningful name, point it to an empty folder and give it a random unused port number and click OK.
Click on “Application Pools”. An application pool of the same name should have been created. The .Net Framework for that application pool should show as “2.0”. If it doesn’t, you’ll need to modify it’s settings and change it to “2.0”.
You’ll also have to set the identity the account runs as to the same as SharePoint, so that it will have permissions to read and write to the membership database. Select the application pool and click “Advanced Settings…” in the right panel. In the dialog that comes up, click on the Identity to change it. Choose “Custom account” and enter the SharePoint service account username and password. Click OK on all of the open dialogs to close them.
The identity should now match the identity used for the SharePoint application pools.

We’re now going to create a database connection to the membership database. Select your new site and open the “Connection Strings” page from the Features view.

From the Connection Strings page, click “Add…” on the right side panel. On the Add Connection String dialog that appears, give it a name (I used “FBADB”), enter your server name and enter “aspnetdb” for your database name. Select “Use Windows Integrated Security” and click OK. We’ve now created the database connection.

We’re now going to create the membership provider, that will let us edit users in the membership database. From the site Features view, click “Providers”. (If “Providers”, “.Net Users” and “.Net Roles” is missing from the features view, then the associated application pool is configured for .Net 4.0. Go back and configure it for .Net 2.0).

From the Providers page, select “.Net Users” under Feature. Click “Add…” in the right side panel. In the dialog that appears, chose “SQLMembershipProvider” for type. Give it a name. For this example I used FBAMembershipProvider_2_0. I added the _2_0 so as not to confuse it with the “FBAMembershipProvider” entry we will be creating when we set it up for SharePoint. Select the different options you want associated with your membership provider. I have some more detail on the options available in the next section when we setup the membership provider for SharePoint. One thing I must stress though is that the options you pick here MUST match the options you use when you setup the membership provider for SharePoint. If they don’t, the users you create here will not work properly.For options, I chose:

Option	Value
EnablePasswordReset	True
EnablePasswordRetrieval	False
RequiresQuestionAndAnswer	False
RequiresUniqueEmail	True
StorePasswordInSecureFormat	True
ConnectionStringName	FBADB (This must match the database connection we setup earlier)
ApplicationName	/

Click OK to close the dialog and create the membership provider.

We’re now going to add users to the membership database. Click “.Net Users” from the Features view.

The first thing we have to do before we can create users is configure the default membership provider. Click “Set Default Provider…” in the right side panel. When the dialog appears, choose the membership provider we just created and click OK.

Now that the default membership provider is selected, we’re presented with an empty .Net Users page, as there are not yet any users in the database. Click “Add…” in the right side panel to add a user.

From the “Add .Net User” dialog, give the user a name, email and password. In this example i’m creating an admin user that i’m going to use as the SharePoint Site Collection administrator.The password needs to be at least 7 characters long and must contain at least 1 non-alphanumeric character. Since we set RequiresQuestionAndAnswer to false when configuring the membership provider, the Question and Answer fields can be left blank.Click OK to create the user and close the dialog.

Now the .Net Users page lists the one user you have created. You can use this page to add and edit users in the future.

If you are going to use Roles in SharePoint, you can create a Role provider from the Providers page, and then use the .Net Roles page to add roles – very similar to how we added the membership provider and added users.

Now that we’ve added a user to our membership database, you can continue on to Section 3 to learn how to configure the membership provider for SharePoint.

3. Editing the Web.Config Files

The next thing that has to be done to get forms based authentication working with SharePoint is setting up the membership provider. A membership provider is an interface from the program to the credential store. This allows the same program to work against many different methods of storing credentials. For example you could use an LDAPMembershipProvider to authenticate against Active Directory, or a SQLMembershipProvider to authenticate against a SQL Server database. For this example we’re using the SQLMembershipProvider to authenticate against a SQL Server database.
SharePoint is actually divided up into several web applications – Central Administration, the Security Token Service and all of the SharePoint web applications that you create. Each of those web applications needs to know about the membership provider. Most tutorials have you adding the membership provider settings over and over again in each web config (as well as every time you setup a new SharePoint web application). I prefer to add the membership provider settings directly to the machine.config. By adding it to the machine.config, the configuration is inherited by all of the web.config files on the machine – so you only have to make the changes once, and don’t have to remember to make the changes every time you create a new SharePoint web application.
If you don’t have access to the machine.config, or prefer not to edit it, you will have to make all of these changes to the following web.config files:

SharePoint Central Administration
SecurityTokenServiceApplication
Every SharePoint web application you create that you would like to access via FBA.

BEFORE EDITING ANY .CONFIG FILE – MAKE A BACKUP OF IT. It’s very easy to make a typo.

Navigate to “C:\Windows\Microsoft.Net\Framework64\v4.0.30319\Config” and open “machine.config”.
In the <ConnectionString> section, add the following line:
```
<add connectionString="Server=WIN-C6ES927TE58;Database=aspnetdb;Integrated Security=true" name="FBADB" />
```
Be sure to replace the value for Server with the name of your SQL Server.

In the <membership><providers> section add the following:

<add name="FBAMembershipProvider"
 type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
 connectionStringName="FBADB"
 enablePasswordRetrieval="false"
 enablePasswordReset="true"
 requiresQuestionAndAnswer="false"
 applicationName="/"
 requiresUniqueEmail="true"
 passwordFormat="Hashed"
 maxInvalidPasswordAttempts="5"
 minRequiredPasswordLength="7"
 minRequiredNonalphanumericCharacters="1"
 passwordAttemptWindow="10"
 passwordStrengthRegularExpression="" />

You can customize the authentication by modifying each of these options. The most important thing to remember though is that if you define a membership provider in multiple locations for the same database, they MUST ALL USE THE SAME OPTIONS. Otherwise you’ll run into all kinds of problems with users created with one set of options, and later being authenticated against with a different set of options.
Here’s a description of the different options available:

Option	Description
connectionStringName	The name of the database connection to the aspnetdb database.
enablePasswordRetrieval	true/false. Whether the user’s password can be retrieved. I suggest setting this to false for security purposes.
enablePasswordReset	true/false. Whether the user can reset their password. I suggest setting this to true.
requiresQuestionAndAnswer	true/false. Whether accounts also have a question and answer associated with them. The answer must be provided when resetting the password. I suggest setting this to false, as setting it to true prevents an administrator from resetting the user’s password.
applicationName	Setting the application name allows you to share a single membership database with multiple different applications, with each having their own distinct set of users. The default applicationName is /.
requiresUniqueEmail	true/false. Determines if multiple users can share the same email address. I suggest setting this to false, in case you ever want to implement a login by email system.
passwordFormat	Clear, Hashed or Encrypted. Clear stores the password in the database as plain text, so anybody with access to the database can read the user’s password. Encrypted encrypts the user’s password, so although the password isn’t human readable in the database, it can still be decrypted and the user’s actual password retrieved. Hashed stores a one way hash of the password. When a user authenticates, the password they enter is hashed as well and matched against the stored hashed value. Using this method, the user’s password can never be retrieved (even if your database is stolen), only reset. I always recommend using “Hashed” as it is the most secure way of storing the user’s password.
maxInvalidPasswordAttempts	The number of times in a row that a user can enter an invalid password, within the passwordAttemptWindow, before the user’s account is locked out. Defaults to 5.
passwordAttemptWindow	The number of minutes before the invalid password counter is reset. Defaults to 10.
minRequiredPasswordLength	The minimum password length. Defaults to 7.
minRequiredNonalphanumericCharacters	The minimum number of non-alphanumeric characters required in the password. Defaults to 1.
passwordStrengthRegularExpression	A regular expression that can be used to validate the complexity of the password.

In the <roleManager><providers> section add the following:

<add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
 type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />

Save and close the machine.config file.

I mentioned that if you modified the machine.config, you’d only have to put the config in a single place. I wasn’t being completely truthful. The SharePoint Web Services configuration overrides the machine.config and clears the entries we created. For that reason, the membership and role providers also need to be added to the SecurityTokenService (But only there – you won’t have to add them to the central admin or other SharePoint web app web.configs.First we need to find the web.config for the SecurityTokenService. Open up IIS. Under sites, SharePoint Web Services, right click on SecurityTokenServiceApplication and click on Explore. Edit the web.config in the folder that opens.

Add the following to the web.config, just before the closing </configuration> tag:

<system.web>
 <membership>
 <providers>
 <add name="FBAMembershipProvider"
 type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
 connectionStringName="FBADB"
 enablePasswordRetrieval="false"
 enablePasswordReset="true"
 requiresQuestionAndAnswer="false"
 applicationName="/"
 requiresUniqueEmail="true"
 passwordFormat="Hashed"
 maxInvalidPasswordAttempts="5"
 minRequiredPasswordLength="7"
 minRequiredNonalphanumericCharacters="1"
 passwordAttemptWindow="10"
 passwordStrengthRegularExpression="" />
 </providers>
 </membership>
<roleManager>
 <providers>
 <add name="FBARoleProvider" connectionStringName="FBADB" applicationName="/"
 type="System.Web.Security.SqlRoleProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
 </providers>
 </roleManager>
 </system.web>

Remember to match all of the options with what was entered in the machine.config.Save and close the file.

The role and membership providers have now been setup for SharePoint. Continue on to Section 4 to configure SharePoint to use the membership provider we just setup.

4.Configuring SharePoint

Now that the membership and role provider have been configured, we can configure SharePoint to use them. For this example i’m going to create a new SharePoint web application. The same settings can be applied to an existing web application through the Authentication Providers dialog.

Open SharePoint Central Administration -> Application Management -> Manage Web Applications.
Click “New” to create a new Web Application.
Name the web application and adjust any other options to your preferences.
Check “Enable Forms Based Authentication (FBA)”. Enter the ASP.Net Membership Provider Name and ASP.NET Role Provider Name that you configured in the web.config. For this example we used “FBAMembershipProvider” and “FBARoleProvider” (Without the quotation marks).Also, for this example we left “Enable Windows Authentication” checked. This allows us to login either via Windows Authentication or Forms Based Authentication (SharePoint will prompt you when you login for which method you’d like to use).Click OK.
An Application Created dialog will appear. Click the “Create Site Collection” link to create the first site collection for this web application.
From the Create Site Collection dialog, give the site collection a name and URL and select a template.
For the Primary Site Collection administrator, i’ve left it as my Windows administrator account, so that I can login without FBA. For the Secondary Site Collection Administrator i’ve set it to ‘fbaadmin’ – the FBA account we setup in Part 2 (If you skipped Part 2 because you’re using the SharePoint 2013 FBA Pack, then you can just leave this blank for now and use your domain account to login to SharePoint and create your FBA users). You can set these to whatever is appropriate for your setup. Click OK.
You’ll get the “Top-Level Site Successfully Created” dialog. You can click on the URL to visit the new site collection you just created.
When authenticating to the site collection, if you enabled both Windows Authentication and Forms Based Authentication, you’ll be prompted for which method you’d like to use to authenticate. I’m going to choose to authenticate with Forms Authentication.
You’ll be prompted for a username and password. Enter the username and password that we created in Part 2, and also set as the Secondary Site Collection Administrator.

You’re now logged into the site as a site collection administrator.

That’s it!

Be sure to check out the SharePoint 2013 FBA Pack, which will allow you to manage your forms based users directly within SharePoint, as well as provide methods for users to register, change their password and recover their password.

Thursday 18 June 2015

Create a classic-mode web application by using Windows PowerShell

Use the procedure in this section to create a new classic-mode SharePoint 2013 web application using Windows PowerShell.
To create a classic-mode web application by using Windows PowerShell

Verify that you have the following memberships:
- securityadmin fixed server role on the SQL Server instance.
- db_owner fixed database role on all databases that are to be updated.
- Administrators group on the server on which you are running Windows PowerShell cmdlets.
- You must read about_Execution_Policies.

From the Windows PowerShell command prompt, type the following:

New-SPWebApplication -Name <Name> 
-ApplicationPool <ApplicationPool>
-AuthenticationMethod <WindowsAuthType>
-ApplicationPoolAccount <ApplicationPoolAccount>
-Port <Port> -URL <URL>

Where:

<Name> is the name of the new web application that uses classic-mode authentication.
<ApplicationPool> is the name of the application pool.
<WindowsAuthType> is either “NTLM” or “Kerberos”. Kerberos is recommended.
<ApplicationPoolAccount> is the user account that this application pool will run as.
<Port> is the port on which the web application will be created in IIS.
<URL> is the public URL for the web application.

Note:
For more information, see New-SPWebApplication.

Note:
After you successfully create the web application, when you open the Central Administration page, you see a health rule warning that indicates that one or more web applications is enabled with classic authentication mode. This is a reflection of our recommendation to use claims-based authentication instead of classic mode authentication.

Create a claims-based web application by using Windows PowerShell

Use the procedure in this section to create a new claims-based SharePoint 2013 web application using Windows PowerShell.
To create a claims-based web application by using Windows PowerShell

Verify that you have the following memberships:

securityadmin fixed server role on the SQL Server instance.
db_owner fixed database role on all databases that are to be updated.
Administrators group on the server on which you are running Windows PowerShell cmdlets.
You must read about_Execution_Policies.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 15 Products cmdlets.

Note:
If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For additional information about Windows PowerShell permissions, see Permissions and Add-SPShellAdmin.

To create a claims-based authentication provider, from the Windows PowerShell command prompt, type the following:
Copy
$ap = New-SPAuthenticationProvider
To create a claims-based web application, from the Windows PowerShell command prompt, type the following:
Copy
New-SPWebApplication -Name <Name> -ApplicationPool <ApplicationPool> -ApplicationPoolAccount <ApplicationPoolAccount> -URL <URL> -Port <Port> -AuthenticationProvider $ap
Where:
- <Name> is the name of the new web application that uses claims-based authentication.
- <ApplicationPool> is the name of the application pool.
- <ApplicationPoolAccount> is the user account that this application pool will run as.
- <URL> is the public URL for this web application.
- <Port> is the port on which the web application will be created in IIS.
Note:

For more information, see New-SPWebApplication.

The following example creates an https claims-based web application, using the current user credentials and the current machine name:
Copy
$ap = New-SPAuthenticationProvider New-SPWebApplication -Name "Contoso Internet Site" -URL "https://www.contoso.com" -Port 80 -ApplicationPool "ContosoAppPool" -ApplicationPoolAccount (Get-SPManagedAccount "DOMAIN\jdoe") -AuthenticationProvider $ap -SecureSocketsLayer
Note:

After you have created the web site, you must configure SSL in IIS for this newly created web site. For more information about how to set up SSL, see How to Setup SSL on IIS 7.0.

Note:
After you have created the web site, you must configure SSL in IIS for this newly created web site. For more information about how to set up SSL, see How to Setup SSL on IIS 7.0.

Create a claims-based web application by using Central Administration

Use the procedure described in this section to create a new claims-based SharePoint 2013 web application using the Central Administration.
To create a claims-based web application by using Central Administration

Verify that you have the following administrative credentials:
- To create a web application, you must be a member of the Farm Administrators SharePoint group.
Start SharePoint 2013 Central Administration.
- For Windows Server 2008 R2:
  - Click Start, click Microsoft SharePoint 2013 Products, and then click SharePoint 2013 Central Administration.
- For Windows Server 2012:
  - On the Start screen, click SharePoint 2013 Central Administration.
    If SharePoint 2013 Central Administration is not on the Start screen:
  - Right-click Computer, click All apps, and then click SharePoint 2013 Central Administration.
For more information about how to interact with Windows Server 2012, see Common Management Tasks and Navigation in Windows Server 2012 R2 and Windows Server 2012.
On the Central Administration Home page, click Application Management.
On the Application Management page, in the Web Applications section, click Manage web applications.
In the Contribute group of the ribbon, click New.

On the Create New Web Application page, in the IIS Web Site section, you can configure the settings for your new web application by selecting one of the following two options:

Click Use an existing IIS web site, and then select the web site on which to install your new web application.
Click Create a new IIS web site, and then type the name of the web site in the Name box.
In the Port box, type the port number you want to use to access the web application. If you are using an existing web site, this field contains the current port number.

Note:

The default port number for HTTP access is 80, and the default port number for HTTPS access is 443.

Note:
The default port number for HTTP access is 80, and the default port number for HTTPS access is 443.

Optional: In the IIS Web Site section, in the Host Header box, type the host name (for example, www.contoso.com) that you want to use to access the web application.

Note:
You do not need to populate this field unless you want to configure two or more IIS web sites that share the same port number on the same server, and DNS has been configured to route requests to the same server.

In the Path box, type the path to the IIS web site home directory on the server. If you are creating a new web site, this field contains a suggested path. If you are using an existing web site, this field contains the current path of that web site.

In the Security Configuration section, choose whether or not to Allow Anonymous access and whether or not to Use Secure Sockets Layer (SSL).

Important:
Secure Sockets Layer (SSL) is a requirement for web applications that are deployed in scenarios that support server-to-server authentication and app authentication. In general, we strongly recommend using SSL for web applications.

In the Security Configuration section, click Yes or No for the Allow Anonymous options. If you choose to Yes, visitors can use the computer-specific anonymous access account (that is, IIS_IUSRS) to access the web site.

Note:
If you want users to be able to access any site content anonymously, you must enable anonymous access for the entire web application zone before you enable anonymous access at the SharePoint site level. Later, site owners can configure anonymous access for their sites. If you do not enable anonymous access at the web application level, site owners cannot enable anonymous access at the site level.

In the Security Configuration section, click Yes or No for the Use Secure Sockets Layer (SSL) options. If you choose Yes, you must request and install an SSL certificate to configure SSL. For more information about how to set up SSL, see How to Setup SSL on IIS 7.0.

In the Claims Authentication Types section, select the authentication method that you want to use for the web application.

To enable Windows authentication, select Enable Windows Authentication and, in the drop-down menu, select NTLM or Negotiate (Kerberos). We recommend using Negotiate (Kerberos).
If you do not want to use Integrated Windows authentication, clear Integrated Windows authentication.

Note:

If you do not select Windows Authentication for at least one zone of this web application, crawling for this web application will be disabled.

Note:
If you do not select Windows Authentication for at least one zone of this web application, crawling for this web application will be disabled.

If you want users' credentials to be sent over a network in a nonencrypted form, select Basic authentication (credentials are sent in clear text).

Note:
You can select basic authentication or integrated Windows authentication, or both. If you select both, SharePoint 2013 offers both authentication types to the client web browser. The client web browser then determines which type of authentication to use. If you only select Basic authentication, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.

To enable forms-based authentication, select Enable Forms Based Authentication (FBA), and then enter the ASP.NET Membership provider name and the ASP.NET Role manager name.

Note:

If you select this option, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.
If you have set up Trusted Identity Provider authentication by using Windows PowerShell, the Trusted Identity provider check box is selected.

In the Sign In Page URL section, choose one of the following options to sign into SharePoint 2013:
- Select Default Sign In Page URL to redirect users to a default sign-in web site for claims-based authentication.
- Select Custom Sign In page URL and then type the sign-in URL to redirect users to a customized sign-in web site for claims-based authentication.
In the Public URL section, type the URL for the domain name for all sites that users will access in this web application. This URL will be used as the base URL in links that are shown on pages within the web application. The default URL is the current server name and port, and it is automatically updated to reflect the current SSL, host header, and port number settings on the page. If you deploy SharePoint 2013 behind a load balancer or proxy server, then this URL may need to be different than the SSL, host header, and port settings on this page.
The Zone value is automatically set to Default for a new web application. You can change the zone when you extend a web application.
In the Application Pool section, do one of the following:
- Click Use existing application pool, and then select the application pool that you want to use from the drop-down menu.
- Click Create a new application pool, and then type the name of the new application pool, or keep the default name.
- Click Predefined to use a predefined security account for this application pool, and then select the security account from the drop-down menu.
- Click Configurable to specify a new security account to be used for an existing application pool.
  
  Note:
  
  To create a new account, click the Register new managed account link.

Note:
If you select this option, ensure that SSL is enabled. Otherwise, a malicious user can intercept credentials.

Note:
To create a new account, click the Register new managed account link.

In the Database Name and Authentication section, choose the database server, database name, and authentication method for your new web application, as described in the following table.

Item

Action

Database Server

Type the name of the database server and SQL Server instance you want to use in the format <SERVERNAME\instance>. You can also use the default entry.

Database Name

Type the name of the database, or use the default entry.

Database Authentication

Select the database authentication to use by doing one of the following:

To use Windows authentication, leave this option selected. We recommend this option because Windows authentication automatically encrypts the password when it connects to SQL Server.

To use SQL authentication, click SQL authentication. In the Account box, type the name of the account that you want the web application to use to authenticate to the SQL Server database, and then type the password in the Password box.

Note:
SQL authentication sends the SQL authentication password to SQL Server in an unencrypted format. We recommend that you only use SQL authentication if you force protocol encryption to SQL Server to encrypt your network traffic by using IPsec.

If you use database mirroring, in the Failover Server section, in the Failover Database Server box, type the name of a specific failover database server that you want to associate with a content database
In the Service Application Connections section, select the service application connections that will be available to the web application. In the drop-down menu, click default or [custom]. You use the [custom] option to choose the service application connections that you want to use for the web application.
In the Customer Experience Improvement Program section, click Yes or No.
Click OK to create the new web application.