Most organizations have certain data that is designated for "authorized users only." Whether this is critical sales data, engineering and design samples, market research, human resources information, or other privileged information, it's important to make sure that the correct users are allowed access.

This process of validating a user is called authentication. The authentication process takes the credentials submitted by a user and checks them against some sort of user account database. A user account database, in this context, is referred to as the authentication provider, and it can be an active directory, an LDAP, Azure Active Directory, or some other directory or database structure.

In this chapter, we will examine the various authentication aspects of SharePoint Server, including the following:

• Selecting and implementing an authentication method
• Configuring web apps with multiple authentication methods
• Monitoring and maintaining authentication
• Troubleshooting authentication issues

After you've completed this chapter, you should be able to identify the methods to authenticate users and be familiar with the processes of configuring various authentication mechanisms and troubleshooting authentication issues.

Selecting and implementing an authentication method

During the authentication process, a user asserts their identity. Once their identity is validated, the authentication provider's proof of the user's assertion is returned (usually as some sort of a token). The result of this claims-based authentication system is a claims-based security token, issued by the SharePoint security token service. SharePoint Server utilizes this claims-based authentication process to provide access to resources.

When planning and configuring authentication methods, you'll need to determine which types you'll use for which web applications, which identity store will host the user identities, and the necessary supporting infrastructure for identity management.

SharePoint Server supports Windows, forms, and Security Assertion Markup Language (SAML)-based claims authentication. SharePoint also supports Kerberos-based authentication.

In the following sections, we'll discuss some of the authentication methods and terminology.

Authentication methods

The MS-301 exam primarily focuses on the various forms of claims-based authentication. Microsoft recommends using claims-based authentication for all web applications and zones in a SharePoint farm. The following diagram shows an overview of how authentication works in a SharePoint farm:

The steps are as follows:

1. The client requests a SharePoint resource.
2. The request is routed to the authentication components based on the settings for the zone.
3. The request is processed by the authentication components. If more than one authentication method is configured, the user selects an authentication method.
4. The user is authenticated by the identity provider.
5. If the authentication is successful, the SharePoint security token service generates a claims-based token for the user.
6. The claims-based token is sent back to the authentication components.
7. The authentication components redirect the request back to the resource with the claims-based token attached.
8. The request is completed and sent back to the user.

We'll now look briefly at the features of each of the other authentication types.

Windows

One of the advantages of Windows authentication is that it can use the existing Active Directory Domain Services (AD DS) authentication provider infrastructure in your environment. Windows authentication supports the following protocols:

• NTLM
• Kerberos
• Digest
• Basic

NTLM and Kerberos are both integrated into the Windows platform and allow users to access SharePoint services without providing additional credentials. NTLM is the simplest form of Windows-based authentication and typically requires no additional configuration. An overview of NTLM authentication is shown in the following diagram:

Kerberos is also integrated into the Windows platform but does require additional configuration, such as registering Service Principal Names (SPNs) before configuring a web application. Kerberos also requires the client computer to have connectivity to both a domain controller and the Kerberos key distribution center, reducing its usability for internet-facing scenarios. The following simplified diagram illustrates the Kerberos process:

The following steps need to be taken to set up Kerberos:

1. Ensure that the name resolution for the web app to be configured exists. When configuring a web app, such as portal.contoso.com, you must be able to resolve that name in the DNS. If no record exists, create one that points to the server that will host the web app.
2. Configure HTTP service principal names for the web app URL and the application pool service account. From the command prompt, while logged in as a domain administrator, run the following commands:

          SetSPN -S HTTP/<webapp> <DOMAINServiceAccount>
          

          SetSPN -S HTTP/<webapp.fqdn> <DOMAINServiceAccount>
        

For example, if your service account is SPWebApp and your new web app is portal.contoso.com, the command will be as follows:

          SetSPN -S HTTP/portal CONTOSOSPWebApp
          

          SEtSPN -S HTTP/portal.contoso.com CONTOSOSPWebApp
        

3. Trust the server for delegation (which is optional if only local users will be using local applications; if you are going to use report services or other things that reside outside of the SharePoint environment, you'll need to configure Delegation):
   • Launch Active Directory Users and Computers and locate the SharePoint server.
   • Right-click and go to Propertieson the server object.
   • From the Delegationtab, select Trust the computer for delegation to any service (Kerberos only).
4. Edit the authentication providers in the web application (as seen in Chapter 3, Manage and Maintain a SharePoint Farm) and select Enable Windows Authentication and the sub-checkbox Integrated Windows Authentication. Select Negotiate (Kerberos) from the list.
5. Update or verify the configuration for the IIS web app:
   • Launch IIS Manager, locate the website for the web application, and select Authentication from Features View.
   • Select Windows Authentication, and then select Providers.
   • Verify that Negotiateand NTLMare listed (in that order). Click cancel.
   • Click Advanced Settings... and under Extended Protection, ensure the selection is set to Off, and then ensure Enable Kernel-mode authentication is unchecked. Click Cancel.

The digest and basic authentication methods are older and less secure. Digest authentication sends user credentials as an MD5 digest to the web server; basic authentication sends credentials in cleartext and should be avoided unless traffic is secured with an SSL certificate.

Forms

Most users are familiar with forms-based credentials—they're used when the client computer doesn't have an integrated or secure relationship with the host computers. These are frequently used in internet scenarios. A forms-based authentication system frequently uses a membership directory or provider that is outside of AD DS.

In a forms-based authentication flow, the following process occurs:

1. The user requests a SharePoint resource.
2. SharePoint redirects the user to the forms-based authentication logon page.
3. The user's credentials are submitted to the SharePoint security token service.
4. The credentials are validated with the identity and membership provider. If successful, the appropriate claims are added to the user's token.
5. The token is issued to the user.
6. The request is sent to any other components in the authorization pipeline for the web app.
7. The response is sent back to the user.

This authentication flow is common for users that are members of an ASP.NET membership database or other database structures.

SAML

SAML-based configurations are alsosupported and require additional work to configure. You might use a SAML-based authentication framework if you're connecting with a partner organization that has its own identity provider.

SAML frameworks require and utilize several components:

• Realm: The URL or URI of a web application.
• The SharePoint security token service: The security token service is used to create and manage tokens for server-to-server authentication and claims for Windows, forms, and SAML authentications.
• Identity Provider Security Token Service (IP-STS): A secure token service that issues SAML tokens on behalf of users in the associated directory.
• Relying Party Security Token Service (RP-STS): Each web application is registered in the IP-STS server as an RP-STS entry.
• SPTrustedIdentityTokenIssuer: A special farm object that governs the communication to create and receive tokens from the IP-STS.
• Token-signing certificate: A certificate exported from IP-STS that is then used to create SPTrustedIdentityTokenIssuer.

• Identity claim: A SAML token claim that represents the unique identity of the user.
• Other claims: Additional claims that describe users, such as roles, groups, or other information.

SAML-based authentication takes the following process:

1. The user requests a SharePoint resource.
2. SharePoint redirects to the SAML authentication page.
3. Depending on the login provider, the request is redirected to the enterprise or federated STS login page.
4. The user provides credentials. If successful, the STS issues a SAML claims-based token.
5. A claims-based token is requested from the SharePoint STS, using the claims-based token from the external STS as authentication proof.
6. The SharePoint STS issues a claims-based token and any other additional claims if another claims provider is registered for the web application or zone.
7. The request is processed by any other authentication and authorization components configured in the pipeline.
8. The response is sent back to the user.

Let's talk about zones in the next section.

Zones

Zones are logical constructs that are used to gain access to sites in a web application. Each web application has a default zone, but can be extended to support up to five zones. You can implement multiple authentication providers in a single zone; you can also use multiple zones with different authentication providers.

Microsoft generally recommends implementing multiple authentication methods on the default zone, resulting in a single URL for all users. If you choose to implement multiple zones, keep the following design constraints in mind:

• You can only deploy one instance of forms-based authentication on a zone.
• At least one zone must have NTLM as an authentication method for content crawling.

In the next section, we'll look at configuring authentication for internal and external users and assigning multiple authentication methods to a web application.

Configuring web apps with multiple authentication methods

As mentioned in the previous section, a web application can have multiple authentication providers. Additionally, authentication providers can get their user databases from a number of different places, including from Active Directory, a SQL database, or another federated environment.

In this example, we're going to create a new web application (although this process can also be used for an existing web application) and connect it to both an internal authentication provider (NTLM) as well as an external identity provider that's been configured (the ASP.NET IIS authentication database).

To configure a web app to use multiple providers, follow these steps:

1. Launch Central Administration and navigate to Application Management | Manage Web Applications.
2. From the Contribute group on the ribbon, select New.
3. In this example, create a new IIS website for the web application. Specify a site name, port, and path. Leave anonymous access off (as well as SSL).

4. Since the goal is to configure multiple authentication providers, select the Enable Windows Authentication checkbox:

5. Select the Enable Forms Based Authentication (FBA) checkbox. Enter the Forms-Based Authentication membership and role providers of your application.
6. Specify a URL, application pool, and security settings (refer to Chapter 3, Manage and Maintain a SharePoint Farm, for more details).

7. Specify the database settings.
8. When you have finished, click OK.
9. After the web application has been configured, click on Create Site Collection.
10. Under Web Application, select the newly created web application.
11. Enter a title and description.
12. Select a website address path, a template, and the administrators. Click OK.
13. After the site collection has been created, click the site link to open the site:

14. Click OK to close the window.

Once the web app has been provisioned, you can navigate to it. You should be prompted for an authentication mechanism:

Selecting either Forms Authentication or the Windows Authentication selection will direct you to the appropriate mechanism.

Next, we'll look at monitoring authentication.

Monitoring and maintaining authentication

If applications are unable to authenticate users, you can configure additional details for login capture. Following the process that we covered in Chapter 3, Manage and Maintain a SharePoint Farm, you can specifically target authentication logging to help determine the source of errors.

To configure SharePoint Server with increased diagnostic logging for authentication, follow these steps:

1. Launch Central Administration, click on Monitoring, and then under Reporting, select Configure diagnostic logging.
2. Expand All Categories | SharePoint Foundation and select Authentication Authorization:

3. Under Least critical event to report to the event log, choose Verbose.
4. Under Least critical event to report to the trace log, choose Verbose.
5. Click OK.

Tracing events will be captured in the logs specified in the tracing folder. Event log data will be captured in the application log under the SharePoint Foundationsource. To view the trace logs, you'll need to use theUnified Log Service(ULS) viewer from https://www.microsoft.com/download/details.aspx?id=44020.

When you have finished with the tracing and event log-capturing activities, return to the diagnostics logging area, clear any checkboxes that were set, and reset the log detail levels to report to the event log to Information and to Medium for the trace log.

Next, we'll look at some steps to troubleshoot authentication.

Troubleshooting authentication issues

When troubleshooting authentication, you'll likely need to follow the steps in the previous section to enable detailed logging and review the entries with the ULS Viewer application. You can search for theClaims Authorizationor Authentication Authorization categories.

Depending on the types of errors discovered in the logs, it may also be a good idea to verify the authentication configuration for a web application or a zone. To verify or update the authentication configuration, follow these steps:

1. Launch Central Administration, then go to Application Management | Manage web applications.
2. Select the name of the web application for which you're experiencing problems, and then on the ribbon, under the Security group, select Authentication Providers.
3. Select a zone to edit (all web applications have a Default zone; if you have additional zones, you should check through each methodically).
4. On the Edit Authentication page, verify (and update, if necessary) the settings for the claims authentication:
   
   • For Windows claims, ensure Enable Windows Authentication and Integrated Windows authentication are selected and that either NTLMor Negotiate (Kerberos) is selected. If Kerberos is selected, remember that additional configuration steps are required. Select the Basic authentication option if it is required, and ensure an SSL certificate is installed.
   • For forms-based authentication, verify that Enable Forms Based Authentication (FBA) is selected and that the values for ASP.NET Membership provider nameand ASP.NET Role manager name match the names specified in the web.config files for Central Administration, the web application, and SecurityTokenServiceApplication. For more information about editing these files, refer to https://docs.microsoft.com/en-us/previous-versions/office/sharepoint-server-2010/ee806890(v=office.14).
   • For SAML-based authentication, verify that Trusted identity provider and the correct trusted provider name are selected.
   • Under theSign in Page URL section, verify the option for the sign-in page. If you are using a custom sign-in page for forms or SAML authentication, verify its URL. You may want to switch to the default sign-in page to determine whether the problem is with the sign-in page or some other part of the configuration.

5. Click Save.
6. Repeat the authentication attempt.
7. If the sign-in fails, review the ULS logs to determine whether the error messages are the same or different from this new authentication attempt.

Depending on the type of authentication being performed, you should also check the following items:

• Verify that the client web browser supports claims.
• If you are using Windows claims, verify that the client computer can access a domain controller (you can launch a command prompt and run nltest /dsgetdc: /force to force the discovery of an Active Directory domain controller).
• If you are using Windows claims, verify that SharePoint Server can communicate with Active Directory using nltest /dsgetdc: /force from a command prompt.
• If you are using forms-based authentication, verify that the ASP.NET role provider is configured correctly.
• If you are using SAML-based authentication, verify that both the federation provider (such as Active Directory Federation Services) and the identity provider (such as Active Directory) are reachable on the network.

• Consider using a network monitoring or tracing tool, such as Fiddler (http://www.telerik.com), to capture the authentication traffic:
  • For Windows-based authentication, check for traffic between SharePoint and the domain controller, as well as between the client computer and SharePoint Server.
  • For forms-based authentication, check for traffic web client computer and the SharePoint server, as well as the traffic between SharePoint Server and the server hosting the ASP.NET membership and role provider services.
  • For SAML-based authentication, check for traffic between the client computer and the federation endpoint, between the client computer and the identity provider (such as Active Directory), and the client computer and the SharePoint server.

These troubleshooting strategies will help you identify and resolve issues in your SharePoint authentication environment.

Summary

In this chapter, you learned about the different authentication methods available for SharePoint—Windows authentication, forms-based authentication, and SAML-based authentication. Each authentication method has its advantages, and its usefulness depends on both the client/server infrastructure (for example, using domain-based services and web applications for internal users) and the type of identity providers that are used (Active Directory, a database of some sort, or another organization's identity store). You also learned about the different monitoring and troubleshooting procedures to help you resolve issues.

In the next chapter, we'll learn about how to plan for and configure site collections in the SharePoint environment.

Questions

Use the following questions to test your knowledge of the information learned in this chapter. You can find the answers in Chapter 16, Assessment Answers:

1. When troubleshooting Windows authentication issues, which command-line utility is most useful?
   1. netstat
   2. nbtstat
   3. winnbns
   4. nltest
2. You want to configure a web application to authenticate users from a local SQL database. Which authentication method would you likely use?
   1. Windows authentication
   2. Integrated Windows authentication
   3. Forms-based authentication
   4. SAML-based authentication
3. You manage a SharePoint environment. You have configured a web application for the HR department with forms-based authentication. The HR department informs you that they need the content crawled every 15 minutes and the results visible in search. What should you do?
   1. Update the authentication method to include NTLM authentication.
   2. Update the authentication method to SAML-based authentication.
   3. Change the forms-based ASP.NET role provider to match the name of the farm service account.
   4. Add a new index component to the SharePoint search service.
4. You manage a SharePoint environment. A partner company uses Microsoft 365. You need to provide the partner company with access to resources inside your farm. Which authentication method should you use?
   1. Single sign-on
   2. SAML-based authentication
   3. Classic mode authentication
   4. NTLM authentication
   5. Kerberos authentication

5. You manage a SharePoint environment. You are planning authentication for a web application that will be used for internal users, external users who will have their own accounts in your environment, and partner company users on an Active Directory domain who will be using their own identity. Which authentication methods should you configure for each type of user?
   1. Internal users:
      • Forms-based authentication
      • SAML-based authentication with Active Directory Federation Services
      • Windows authentication
   2. External users:
      • Forms-based authentication
      • SAML-based authentication with a Windows Live ID
      • Windows authentication
   3. Partner company users:
      • Forms-based authentication
      • SAML-based authentication with Active Directory Federation Services
      • Windows authentication