Use Kerberos for Sharepoint Authentication

From: http://technet.microsoft.com/zh-cn/magazine/ee914605.aspx

 

 

Although SharePoint provides multiple authentication options and authentication regions, the two most common options implemented by enterprises in the Intranet solution are NTLM and Kerberos. Both protocols are used to integrate Windows Authentication in a typical question/response solution. NTLM relies on IIS to generate a token during the Query Process, send the token to the client, the client responds with the token, and the domain controller verifies the response. NTLM requires that the user names and passwords must be encrypted before transmission, and re-authentication (new token) must be performed when accessing new network resources ). On the contrary, Kerberos depends on a ticket system. The client and server access a trusted authority named KDC. KDC will respond to client requests, and grant the corresponding ticket. The client can use this ticket to access network resources. Kerberos does not require re-authentication to access multiple resources.

Most of the current documents advocate the use of NTLM unless there is a particularly urgent need, such as the needs of websites with high security service level agreements. Even in this case, using NTLM is still your preferred choice: it is easier to implement, requires no additional steps, and reduces support issues. For example, Knowledge Base Article 832769 wrote: "... Or you cannot configure the service subject name (SPNs). Please select NTLM authentication. If you select Kerberos authentication but cannot configure the SPNs, only the server administrator can pass the authentication of the SharePoint website ." This statement is technically accurate, but it seems to have an implicit meaning: Configuring the SPNs is too complex, and Kerberos should be avoided unless someone requires Kerberos. However, it is not that difficult to implement Kerberos if you understand the principle.

There are many reasonable reasons for us to explain why we should switch to Kerberos, or use Kerberos from beginning to end in the newly implemented system, but in most cases, these can all be attributed to performance or security. As user load or topology complexity increases, NTLM may cause performance problems because in many SharePoint use scenarios (such as accessing SharePoint Web components or custom Web Services web applications)Program), NTLM-based identity authentication must be repeated between IIS and the domain controller. If you access the domain controller through a low-speed or high-latency link, performance problems may occur. In terms of security, a ticket-Based System (Kerberos) explicitly delegates network resources is designed to be more secure than simply encrypting user creden. It is faster because it only uses a single ticket to access multiple network resources.

Many installations initially use NTLM instead of Kerberos, because the planning topology, server scale adjustment, Security Support Provider (SSP), and other complex details are daunting. To further increase complexity, this will make users feel powerless. This view is reasonable. In any case, problems may occur when Kerberos is enabled. Read the Knowledge BaseArticle871179, 962943, and 832769, you can see some possible problems, these problems may be as serious as the blue screen STOP error. Even existing documents, such as Microsoft's Kerberos Detailed Implementation Guide, do not include details about IIS Version 7 or later. These versions enable Kernel Mode authentication, and changed the way to process the SPNs. But don't worry. If you know how to use Kerberos in Sharepoint, it will be easier to implement and configure Kerberos. This article describes the basic architecture components, including configuration details to help you get started. Microsoft has published documents with step-by-step details and knowledge base articles 832769 and 953130, which can provide you with more references.

Authentication components and dependencies

First, we will understand the dependencies in the SharePoint architecture that handles integrated Windows authentication. On the most basic level, whether using NTLM or Kerberos, a client sends a request to the. aspx web page that enables Sharepoint. The web page uses. NET and IIS in the background. At the same time, the web page also depends on SQL Server Configuration and data in the content database.Figure 1Shows how IIS processes Authentication-related requests in the SharePoint 2007 context. When the client browser sends a Web request, a thread is enabled in IIS and the object associated with the request (for example, the token contained in the iidentity object contained in the iprincipal object) will be appended to the thread. From a programming perspective, both iidentity and iprincipal objects are accessed through the httpcontext. User attribute, and both objects and attributes are set by the authentication module included in the. NET pipeline, as shown inFigure 1.

Figure 1Common authentication components and data streams in SharePoint

The following process details the data flow:

1. The client browser initializes the connection to the SharePoint front-end server through an anonymous http get request (handled by IIS with. net ).
2. If anonymous access is configured in the region (for example, in the Internet solution), IIS will continue to process the request. Otherwise, IIS returns error 401.2 and requests authentication from the client browser.
3. The client browser receives the request and authenticates the client based on the region and associated options. The common method is to call acquirecredentialshandle and prompt to enter the user name/password. Then, return the authentication token to SharePoint through IIS.
4. IIS is waiting for a response in an HTTP session and receives the authentication token, and then authorizes or denies access. In this case, IIS passes the request to SharePoint through. net.
5. If the requested page contains Web components that need to access the backend SQL database, Sharepoint performs SQL Server Authentication and accesses the database. The features of SQL authentication vary with configuration options. For example, you can configure SQL Server authentication using NTLM or Kerberos or integrate Windows authentication. The following describes the specific content of Kerberos and NTLM.

The key to the authentication mechanism in Sharepoint is that the following three layers perform their respective functions: client browser, IIS with. net, and SQL Server. To return the compiled. ASPX page, authentication and authorization are performed between the client, IIS, and SQL Server. Sometimes this process is simplified, for example, when SQL Server and IIS are on the same physical server, NTLM is used for authentication. In this case, there is only one hop from the client to IIS. For more information about authentication in. net, see interpretation: Windows Authentication in ASP. NET 2.0.

NTLM and Kerberos

Now you know about Windows Server, IIS, and. net is used to authenticate and authorize users. The following describes how to use NTLM and Kerberos for integrated Windows authentication. As mentioned above, the key difference between NTLM and Kerberos is that NTLM uses the question/response mechanism and requires authentication and authorization when accessing each network resource. Kerberos uses the ticket system, only one authentication is required, and then authorization is performed by delegation. If you do not understand the difference, do not worry. I will describe it in detail below.Figure 2Describes how SharePoint processes requests when using NTLM.

Figure 2NTLM authentication in SharePoint

For exampleFigure 2As shown in, using NTLM requires a domain controller that can authenticate the user. If the domain runs in local mode, a Global Catalog is required by default on the domain controller or another server. In addition to the dual-hop point issue, this is also a potential performance issue, because after you get in touch with the domain controller, if there is no global catalog available locally, the authentication request is sent to the Global Catalog server through a proxy. When the link speed is slow, this may consume a lot of resources and bandwidth. You can try to improve NTLM authentication performance by changing the value of the maxconcurrentapi registry key, but this does not solve the fundamental requirement that NTLM depends on the question/response solution, it cannot solve performance problems under high load.

The details of NTLM authentication for accounts in the same domain are as follows:

1. The process starts as described above. The client browser uses the http get request to initialize the connection with the SharePoint front-end server running IIS with. net, and attempts to perform anonymous authentication.
2. IIS rejects anonymous requests, Returns Error 401.2, and uses NTLM (www-Authenticate: NTLM) for authentication.
3. The client browser receives the request, calls initializesecuritycontext to create an authentication token containing the domain and computer name, and then sends the authentication token to IIS.
4. IIS accepts detailed information and sends an NTLM question to the client.
5. The client uses the encrypted question response (identity authentication token) with the user password to respond.
6. In this case, IIS needs to session with the domain controller. It sends the user name, question, and question response of the client.
7. The domain controller retrieves the user's password hash and compares it with the query response encrypted with user creden. If the two match, the domain controller returns a message indicating that the authentication is successful to IIS. IIS can session with the client browser.
8. In this case, the Web application will authenticate the SQL Server to access the content database containing. ASPX page data.

If you have tried to configure Kerberos for the basic installation on the "Management Center" page, you will know that if you select Kerberos instead of NTLM, the generated message will prompt you to configure the application pool account to explicitly allow Kerberos, unless the application pool is running in the context of network services. This is because SPNs are required for Kerberos-based authentication. In WSS and Moss, web applications are actually allocated to the IIS website of the application pool and run in the built-in or user account context. Multiple websites can be allocated to the same application pool, but this is not the best practice. IIS uses the network service account for the application pool, instead of the unique domain account, unless you make changes. However, to use Kerberos in Sharepoint, you must set a unique SPNs for the application pool account.

In practice, Kerberos-based communication must have a client, a server that supports Kerberos, and a KDC that acts as an intermediate authorizer. In addition, SPNs are also required. Technical details are a little complicated. For example, Kerberos also requires that DNS be integrated with active directory or bind with SRV records, TCP/IP, and time services. If you are using Windows Server 2003 or 2008 integrated with DNS, you already have the required components. You only need to configure these components.Figure 3Displays components involved in Kerberos-based authentication and data streams in Sharepoint.

Figure 3Kerberos Authentication

1. Like NTLM, the client browser uses the Host Name (FQDN or alias) to anonymously send an http get request.
2. The Front-End Server Returns Error 401.2 and the WWW-Authenticate: negotiate header and/or www-Authenticate: Kerberos header (indicating that it supports Kerberos Authentication ). You must explicitly configure this setting on the front-end server in the Management Center. The relevant content will be discussed below.
3. The client contacts KDC on the domain controller, and sends the message in the form of a host name as the SPNs request Ticket Based on the browser client.
4. If KDC finds the matched SPNs, it encrypts the tickets and returns them.
5. The browser client creates an authenticator and sends it along with the service ticket to the IIS server. Then, the IIS server decrypts the ticket, determines its identity, and checks its permissions on the requested resources (Access Control List) to determine whether access is allowed.
6. If access is allowed, IIS will contact SQL server through the Web application service, which will request the SQL Server ticket from KDC.
7. If the SPNs are found, KDC returns the ticket. The web application uses this ticket to query the content database and delegates a simulated user.
8. SQL Server checks a ticket from a Web application and verifies the ticket. After the verification is successful, SQL server sends the data back to the server. net will be able to compile the ASPX page and send it to the browser.

Understand SPNs

SPNs are one of the most difficult parts in Kerberos configuration, because they must be registered to KDC as the unique identifier of the client resources authorized to access specific server resources. In integrated Windows authentication, the client and server must trust KDC, because in almost all cases, KDC is still a domain controller, and it needs a way to determine whether to grant a ticket to the request, this method is SPNs. As described above, when you set a domain user account for the application pool, you must also set an SPNs for the account so that everyone can access the Web application associated with the application pool.

The SPNs are the unique identifier string of the Service Running on the server. It stores the user account name in Active DirectoryService-Principal-name. Multiple services on one or more hosts can be distinguished based on their unique SPNs. Maybe I overemphasized the importance of the SPNs, but there is a good reason for doing so. If the SPNs are improperly configured, Kerberos authentication is broken. If two identical SPNs are set, or you forget to set the SPNs, or if a part of the SPNs is incorrectly configured, authentication fails.

Let's take a look at an example of the SPNs to learn how to use the SPNs in Kerberos. The SPNs consist of three parts: the service class that identifies the service type, the computer name of the host that runs the service, and the port. These parts are combined with the Syntax:Service class/Host: port.For Sharepoint, there are two related names: HTTP and mssqlsvc. The two service names are not arbitrary, but specific service aliases. The host name is the FQDN or NetBIOS name. You can choose whether to include the port. When registering an SPNs, it is best to register the SPNs for both the NetBIOS and FQDN host names so that the client can access resources on the target host no matter what method they use.

As mentioned above, unless you run an application pool under a network service account, you need to explicitly register the SPNs. This is because when a computer is added to an Active Directory domain, it will automatically create an SPNs for the computer account in the format of host/<Netbiosname>And host/<FQDN>. As a computer on the network, the network service account is valid for it. However, for security reasons, adding a local account may damage some schemes, it is not the best practice to use a local network service account. For example, if you want to restore or attach a content database configured using a network service account, you must add the account to the local administrator group on SQL Server, delete the attached database. Domain accounts are recommended for most existing documents.

Backend Configuration

whether you migrate data from an existing farm or install a new farm, you must first configure Kerberos authentication on SQL Server. SQL Server must meet the requirements described above, such as adding to the domain and accessing the domain controller acting as KDC. In most environments, these requirements can be met by default when an Active Directory integrated with DNS is used. If your environment only uses the front-end Sharepoint Server, but does not use the application server (for example, the server that runs Excel services or SQL reporting services), you do not need to explicitly configure Kerberos. For basic frontend/backend connections, the default SPNs created when SQL Server is added to the domain are sufficient.

On SQL Server, Kerberos configuration is relatively simple. First, you need to set the related SPNs, and then verify whether the system uses Kerberos instead of the default NTLM. You should set the NetBIOS Name and FQDN in the format of mssqlsvc/<Netbios_name>: 1433 and mssqlsvc //<FQDN-hostname.domain.local>: 1433. It is assumed that your instance uses the default port 1433. Although you can use setspns or adsiedit to set SPNs, setspns are generally a better choice because they can verify the input syntax to ensure that the input is correct. Instead, when using adsiedit, you need to write the SPNs directlyServiceprincipalnameAttribute. To create two SPNs, runSetsps-a mssqlsvc/<Netbios_name>1433<Domain>\<Username>AndSetsps-a mssqlsvc/<Fqdne>1433<Domain>\<Username>The user name is the SQL Server service account.

To confirm that SQL server traffic uses Kerberos, you can use Wireshark and other data packet analyzer to track traffic, use kerbtray.exe and other tools, or check Event Logs. If you use SQL Server Management studio to connect to the SQL instance, the event ID 540 is displayed in the Security Event Log, where the logon process and authentication data packets use Kerberos. For more information, see configure Kerberos authentication for SQL communication.

Frontend and Application Server Configuration

After kerberos works properly in SQL Server, you can configure Sharepoint, including setting the SPNs for the application pool, enabling Kerberos for the SSP and Web applications, and completing some final configuration steps. The SPNs configuration is similar to the configuration of the SQL Server service account, but more SPNs need to be configured. Looking back, the SPNs are constructed based on the addresses entered in the address bar of the client browser. Therefore, you must set the SPNs for each entry that the user may enter in the address bar to access the website. This includes the FQDN, NetBIOS name, And alias in the Host Header Format.Figure 4Lists Resource Type examples and SPNs that need to be registered for each resource type.

Figure 4SPNs of basic Moss Fields

Note some precautions when setting the SPNs. First, the SPNs must register with the SharePoint-enabled website, just as if they were registered with any IIS website. It is important to specify the correct host name and account, and the application pool of each website runs under this account. If multiple host headers are used, make sure to set the SPNs for all host headers. Second, you do not need to specify HTTP and HTTPS ports, but you should specify any custom ports. Third, you may need to configure other dependencies, such as configuring registry changes for IIS to support the SPNs with custom ports and Configuration updates to support SSPS. You can find more details in configuring Kerberos authentication (Office Sharepoint Server.

If you want Kerberos to work normally in the environment, you should complete the other two important steps. You must configure the computer accounts and service accounts used for delegation, and configure the Kerberos field in the management center. The principle of delegation in Kerberos is: if a user sends a request to the final resource, some intermediary accounts must process the request. These intermediary accounts are trustworthy and can delegate requests on behalf of users. Active Directory users and computers can be used as domain administrators to configure accounts for delegation. Under the user or computer account delegate tab, select trust this user/computer to delegate any service (Kerberos )". You should enable delegation for front-end, application, and SQL server computer accounts, as well as for application pools (sspadmin, mysite, various web applications) and Field Service accounts.

In addition, you need to set permissions in "component service. Under the default attribute, set "simulation level" to "delegate ". Under IIS wamreg Admin Service, go to the Security tab and grant the Local activation permission to the application pool account. For more information, see Knowledge Base articles 917409 and 920783.

After delegation is enabled, you can enable Kerberos as the preferred protocol for SSP and web applications to complete specific configuration work. For new installations, you can perform this operation for the Management Center website in the SharePoint product and Technical Configuration Wizard. Otherwise, go to "verify providers" under "Application Management" in the management center, click "default", and set the method to "Kerberos )". Do not forget to runIisreset/noforce, Apply the changes to the application pool, and enable Kerberos for SSP.

Changes in IIS 7 and Windows Server 2008

So far, we have discussed only SharePoint 2003 on Windows Server 2007 and IIS 6. If you migrate to Windows Server 2008 and IIS 7, there are some changes in the architecture and other configuration steps may be required. Perhaps the most significant change in IIS 7 is that it supports Kernel Mode Kerberos authentication. In Kernel Mode authentication, the network service account (actually the computer account described above) decrypts the ticket unless you specify other settings. When you migrate to IIS 7 or install a new farm, Kernel Mode authentication is enabled by default. As described above, the network service account is a local account. If a single server is running, the decryption is normal. However, in the presence, decryption will fail because you need to use a domain account that can be verified by KDC. This change also means that you can use the network service account for protocol conversion (allow clients to perform non-Kerberos authentication to IIS, and allow IIS to use Kerberos for backend communication ), because the account already has the LocalSystem permission.

To configure Kerberos in a SharePoint farm running IIS 7, manually change the % WINDIR % \ system32 \ inetsrv \ config \ applicationhost. config file-no GUI options currently. The related entries are as follows.

<System. webserver>
<Security>
<Authentication>
<Windowsauthentication enabled = "true" usekernelmode = "true"Useapppoolcredentials = "true"/>
</Authentication>
</Security>
</System. webserver>

Do not forget to runIisreset/noforceApply changes and check the latest updates to discover problems, for example, the blue screen update described in Knowledge Base Article 962943.

If your configuration uses the identity simulation (<identity impersonate = "true"/> in Web. config) and integration mode pipeline, you should also pay attention to another configuration details. In this case, set validateintegratedmodeconfiguration to false, or run the. ASPX page in the Classic Mode pipeline.

Conclusion

Although Kerberos authentication requires some additional configuration steps and more knowledge than NTLM, the current trend is to migrate to Kerberos. Microsoft regards Kerberos as the default selection option in ii7 and provides excellent support for Kerberos because it is an open standard. Use Kerberos. A large number of documents are provided to deploy, verify, and troubleshoot Kerberos, which also provides support for actual use of Kerberos. You do not need to make many changes to avoid performance degradation caused by excessive authentication hops and enjoy the good security of Kerberos.