NTLM Authentication

Using Integrated Windows Authentication with Windows SharePoint Services
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.

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/ServerName Domain\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.

Ref: http://office.microsoft.com/en-us/winsharepointadmin/HA011608071033.aspx

Integrated Windows Authentication (IIS 6.0)

With Integrated Windows authentication (formerly called NTLM, and also known as Windows NT Challenge/Response authentication), the user name and password (credentials) are hashed before being sent across the network. When you enable Integrated Windows authentication, the client browser proves its knowledge of the password through a cryptographic exchange with your Web server, involving hashing.

Important

Integrated Windows authentication is disabled by default if you install Windows Server 2003 Service Pack 1 (SP1) as part of a slipstream installation of a Windows Server 2003 operating system. If you install Windows Server 2003 SP1 by itself, as an upgrade to a Windows Server 2003 operating system, the setting for Integrated Windows authentication is unchanged from its Windows Server 2003 setting. Integrated Windows authentication is enabled by default for Windows Server 2003 operating systems.

Integrated Windows authentication uses Kerberos v5 authentication and NTLM authentication. Kerberos is an industry-standard authentication protocol that is used to verify user or host identity. If Active Directory is installed on a domain controller running Windows 2000 Server or Windows Server 2003, and the client browser supports the Kerberos v5 authentication protocol, Kerberos v5 authentication is used; otherwise, NTLM authentication is used.

Integrated Windows authentication includes the Negotiate, Kerberos, and NTLM authentication methods. Negotiate, a wrapper for Kerberos v5 and NTLM, allows the client application to select the most appropriate security support provider for the situation. Kerberos v5 and NTLM have the following restrictions:
•NTLM can get past a firewall, but is generally stopped by proxies because NTLM is connection-based, and proxies do not necessarily keep connections established.

•Kerberos v5 requires that the client have a direct connection to Active Directory, which is generally not the case in Internet scenarios.

•Kerberos v5 requires that both the client and the server have a trusted connection to a Key Distribution Center (KDC) and be Active Directory–compatible.

•Kerberos v5 requires SPNs for multiple worker processes. If your Web site uses multiple worker processes, you can use Kerberos authentication, but you must manually register service names. For more information about Kerberos and service registration, see Kerberos and service registration later in this topic.

Integrated Windows authentication has the following limitations:

•Integrated Windows authentication is supported by only Internet Explorer 2 and later.

•Integrated Windows authentication does not work over HTTP proxy connections.

Therefore, Integrated Windows authentication is best suited for an intranet environment, where both user and Web server computers are in the same domain and where administrators can ensure that every user has Internet Explorer 2 or later.

http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/523ae943-5e6a-4200-9103-9808baa00157.mspx?mfr=true

Microsoft NTLM

Windows Challenge/Response (NTLM) is the authentication protocol used on networks that include systems running the Windows operating system and on stand-alone systems.

The Microsoft Kerberos security package adds greater security than NTLM to systems on a network. Although Microsoft Kerberos is the protocol of choice, NTLM is still supported. NTLM must also be used for logon authentication on stand-alone systems. For more information about Kerberos, see Microsoft Kerberos.

NTLM credentials are based on data obtained during the interactive logon process and consist of a domain name, a user name, and a one-way hash of the user's password. NTLM uses an encrypted challenge/response protocol to authenticate a user without sending the user's password over the wire. Instead, the system requesting authentication must perform a calculation that proves it has access to the secured NTLM credentials.

Interactive NTLM authentication over a network typically involves two systems: a client system, where the user is requesting authentication, and a domain controller, where information related to the user's password is kept. Noninteractive authentication, which may be required to permit an already logged-on user to access a resource such as a server application, typically involves three systems: a client, a server, and a domain controller that does the authentication calculations on behalf of the server.

The following steps present an outline of NTLM noninteractive authentication. The first step provides the user's NTLM credentials and occurs only as part of the interactive authentication (logon) process.

1. (Interactive authentication only) A user accesses a client computer and provides a domain name, user name, and password. The client computes a cryptographic hash of the password and discards the actual password.

2. The client sends the user name to the server (in plaintext).

3. The server generates a 16-byte random number, called a challenge or nonce, and sends it to the client.

4. The client encrypts this challenge with the hash of the user's password and returns the result to the server. This is called the response.

5. The server sends the following three items to the domain controller:

· User name
· Challenge sent to the client
· Response received from the client

6. The domain controller uses the user name to retrieve the hash of the user's password from the Security Account Manager database. It uses this password hash to encrypt the challenge.

7. The domain controller compares the encrypted challenge it computed (in step 6) to the response computed by the client (in step 4). If they are identical, authentication is successful.

Your application should not access the NTLM security package directly; instead, it should use the Negotiate security package. Negotiate allows your application to take advantage of more advanced security protocols if they are supported by the systems involved in the authentication. Currently, the Negotiate security package selects between Kerberos and NTLM. Negotiate selects Kerberos unless it cannot be used by one of the systems involved in the authentication.

Ref: http://msdn.microsoft.com/en-us/library/aa378749(VS.85).aspx

Changes to NTLM authentication for HTTPWebRequest in Version 3.5 SP1

Security changes were made in Version 3.5 SP1 that affect how integrated Windows authentication is handled by the HttpWebRequest, HttpListener, NegotiateStream, and related classes in the System.Net namespace. These changes can affect applications that use these classes to make web requests and receive responses where integrated Windows authentication based on NTLM is used. This change can impact web servers and client applications that are configured to use integrated Windows authentication.

Overview

The design of integrated Windows authentication allows for some credential challenge responses to be universal, meaning they can be re-used or forwarded. If this particular design feature is not needed then the challenge responses should be constructed at a minimum with target specific information and preferably also with some channel specific information. Services can then provide extended protection to ensure that credential challenge responses contain service specific information such as a Service Principal Name (SPN). With this information in the credential exchanges, services are able to better protect against malicious use of credential challenge responses that might have been improperly obtained.

Multiple components in the System.Net and System.Net.Security namespaces perform integrated Windows authentication on behalf of a calling application. This section describes changes to System.Net components to add extended protection in their use of integrated Windows authentication.

Ref: http://msdn.microsoft.com/en-us/library/cc982052.aspx

NTLM Authentication Does Not Work If Internet Explorer Is Configured to Use HTTP 1.1 Through Proxy Connections

http://support.microsoft.com/kb/322822

NTLM user authentication in Windows

User records are stored in the security accounts manager (SAM) database or in the Active Directory database. Each user account is associated with two passwords: the LAN Manager-compatible password and the Windows password. Each password is encrypted and stored in the SAM database or in the Active Directory database.

The LAN Manager-compatible password is compatible with the password that is used by LAN Manager. This password is based on the original equipment manufacturer (OEM) character set. This password is not case sensitive and can be up to 14 characters long. The OWF version of this password is also known as the LAN Manager OWF or ESTD version. This password is computed by using DES encryption to encrypt a constant with the clear text password. The LAN Manager OWF password is 16 bytes long. The first 7 bytes of the clear text password are used to compute the first 8 bytes of the LAN Manager OWF password. The second 7 bytes of the clear text password are used to computer the second 8 bytes of the LAN Manager OWF password.

The Windows password is based on the Unicode character set. This password is case sensitive and can be up to 128 characters long. The OWF version of this password is also known as the Windows OWF password. This password is computed by using the RSA MD-4 encryption algorithm. This algorithm computes a 16-byte digest of a variable-length string of clear text password bytes.

Any user account might lack either the LAN Manager password or the Windows password. However, every attempt is made to maintain both versions of the password. For example, if the user account is ported from a LAN Manager UAS database by using PortUas, or if the password is changed from a LAN Manager client or from a Windows for Workgroups client, only the LAN Manager version of the password will exist. If the password is set or changed on a Windows client, and the password has no LAN Manager representation, only the Windows version of the password will exist. (The password might have no LAN Manager representation because the password is longer than 14 characters or because the characters cannot be represented in the OEM character set.) User interface limits in Windows do not let Windows passwords exceed 14 characters. The implications of this limitation are discussed later in this article.

Pass-through authentication

The NetLogon service implements pass-through authentication. It performs the following functions:

· Selects the domain to pass the authentication request to.
· Selects the server within the domain.
· Passes the authentication request through to the selected server.

Selecting the domain is straightforward. The domain name is passed to LsaLogonUser. The domain name is processed as follows:

· If the domain name matches the name of the SAM database, the authentication is processed on that computer. On a Windows workstation that is a member of a domain, the name of the SAM database is considered to be the name of the computer. On an Active Directory domain controller, the name of the account database is the name of the domain. On a computer that is not a member of a domain, all logons process requests locally.

· If the specified domain name is trusted by this domain, the authentication request is passed through to the trusted domain. On Active Directory domain controllers, the list of trusted domains is easily available. On a member of a Windows domain, the request is always passed through to the primary domain of the workstation, letting the primary domain determine whether the specified domain is trusted.

· If the domain name specified is not trusted by the domain, the authentication request is processed on the computer being connected to as if the domain name specified were that domain name. NetLogon does not differentiate between a nonexistent domain, an untrusted domain, and an incorrectly typed domain name.

http://support.microsoft.com/kb/102716