Share via

Using Integrated Windows Authentication with Windows SharePoint Services 2.0

  • Article

Microsoft Integrated Windows Authentication supports two protocols to provide challenge/response authentication:

  • NTLM   A secure protocol based on encrypting user names and passwords before sending them over the network. NTLM is required in networks where the server will get requests from legacy clients that do not support Kerberos authentication.

  • Kerberos   A protocol based upon ticketing. In this scheme a user must first provide a valid user name and password to an authentication server. This server grants the user a ticket, which can then be used on the network for requesting other network resources. To use this scheme, both the client and server must have a trusted connection to the domain Key Distribution Center and be compatible with Microsoft Active Directory directory services.

Kerberos also provides a method for creating trust relationships between network domains. These trust relationships can be transitive, mono-directional, or bidirectional. For more information on Kerberos authentication, see Microsoft Internet Information Services (IIS) documentation in Windows Server 2003.

Both NTLM and Kerberos enhance security by encrypting user names and passwords before sending them over the network. By default, virtual servers extended with a version of Windows SharePoint Services earlier than Windows SharePoint Services Service Pack 2 enabled NTLM authentication by default because it is compatible with more clients. Windows SharePoint Services Service Pack 2 and later do not automatically enable NTLM authentication. However, if you choose to use Kerberos authentication, and the application pool account used by Windows SharePoint Services on the virtual server is not the default Network Service, you must complete these steps:

  • Configure a service principal name for the application pool identity used by the virtual server running Windows SharePoint Services

  • Configure trust for delegation for Web Parts that access remote resources

  • Additionally, if the virtual server was extended with a version of Windows SharePoint Services earlier than Windows SharePoint Services Service Pack 2, you must edit the IIS metabase to enable both NTLM and Kerberos authentication.

Configure a service principal name for the application pool identity

Note

You must be a domain administrator to complete the steps in this section.

If the application pool identity for the Windows SharePoint Services site is configured to use a built-in security principal (such as NT Authority\Network Service or NT Authority\Local System), you do not have to perform this step. The built-in accounts are automatically configured to work with Kerberos authentication. However, if you use a remote Microsoft SQL Server database it is not recommended that you use a built-in security principal or an account such as domain/computername$.

If you use a remote server running Microsoft SQL Server 2000 and you want to use NT Authority\Network Service as the domain account, you must add the Domain\ComputerName$ entry and configure it with Database Creators and Security Administrators permissions. Doing so allows Windows SharePoint Services to connect to the remote SQL Server computer to create the configuration and content databases.

If the application pool identity is a domain user account, you must configure an service principal name (SPN) for that account. To configure an SPN for the domain user account, follow these steps:

  1. Download and install the Setspn.exe command-line tool from the Setspn.exe download page (https://go.microsoft.com/fwlink/?LinkId=82039\&clcid=0x409).

  2. Use the Setspn.exe tool to add an SPN for the domain account. To do this, type the following line at the command prompt:

    **setspn -A HTTP/ServerNameDomain\**UserName

    where ServerName is the fully qualified domain name (FQDN) of the server, Domain is the name of the domain, and UserName is the name of the domain user account.

Configure trust for delegation for Web Parts that access remote resources

Note

You must be a domain administrator to complete the steps in this section.

You do not have to follow these extra steps if you do not have Web Parts that are accessing remote resources.

If you are developing Web Parts for Windows SharePoint Services that access remote resources, you must follow the steps that are listed in the "Configure a Service Principal Name for the Domain User Account" section and configure both the computer and the application pool account to be trusted for delegation as described in the following sections.

Configure the IIS server to be trusted for delegation

Note

You must be a domain administrator to complete the steps in this section.

  1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. In the left pane, click Computers.

  3. In the right pane, right-click the name of the IIS server, and then click Properties.

  4. Click the General tab, click to turn on Trust computer for delegation, and then click OK.

Configure the application pool domain account for trusted delegation

  1. Click Start, point to Administrative Tools, and then click Active Directory Users and Computers.

  2. In the left pane, click Users.

  3. In the right pane, right-click the name of the user account used by the application pool, and then click Properties.

  4. Click the Account tab, under Account Options, click to turn on Account is trusted for delegation, and then click OK.

Edit the IIS metabase

You can edit the IIS metabase by using Microsoft Notepad or a script. The script method is the preferred method if you are updating multiple servers. The following sections tell you how to use both methods.

Edit the IIS metabase by using Notepad

Note

You only need to complete this step on virtual servers that were extended with a version of Windows SharePoint Services prior to Service Pack 2.

  1. On the server running Windows SharePoint Services, Click Start, point to All Programs, point to Accessories, and then click Notepad.

  2. Click File, click Open, and then open the file %Systemroot%\System32\Inetsrv\Metabase.xml, where %Systemroot% is the path and folder name where Microsoft Windows is installed.

  3. In the <IIsWebServer> section, locate the line: NTAuthenticationProviders="NTLM"

  4. Change the line to: NTAuthenticationProviders="Negotiate,NTLM"

  5. Click File and then click Save.

  6. Click File and then click Exit.

  7. Restart IIS:

    1. Click Start, and then click Run.

    2. In the Run window, type cmd, and then click OK.

    3. At the command prompt, type iisreset, and then press ENTER.

    4. Type exit, and then press ENTER to close Command Prompt window.

Edit the IIS metabase by using scripts

Note

You only need to complete this step on virtual servers that were extended with a version of Windows SharePoint Services prior to Service Pack 2.

  1. Click Start, and then click Run.

  2. In the Run window, type cmd, and then click OK.

  3. Change to the Inetpub\Adminscripts folder, type: cd Drive:\inetpub\adminscripts where Drive is the disk drive where Windows is installed.

  4. Type the command: cscript adsutil.vbs get w3svc/xx/NTAuthenticationProviders where xx is the virtual server ID number. The virtual server ID of the Default Web site in IIS is 1. If the virtual server has been extended with Windows SharePoint Services, the following string is returned:

    ntauthenticationproviders: (STRING) "NTLM"

  5. To enable Kerberos on the virtual server, type: cscript adsutil.vbs set w3svc/xx /NTAuthenticationProviders "Negotiate,NTLM" where xx is the virtual server ID number.

  6. Restart IIS:

    1. Click Start, and then click Run.

    2. In the Run window, type cmd, and then click OK.

    3. At the command prompt, type iisreset, and then press ENTER.

    4. Type exit, and then press ENTER to close Command Prompt window.