Endpoint Authentication Types
This feature will be removed in a future version of Microsoft SQL Server. Avoid using this feature in new development work, and plan to modify applications that currently use this feature.
The process for endpoint authentication involves granting permissions to allow users to connect to endpoints that are created on the server and specifying how authentication is performed.
How authentication is performed is specified by using the AUTHENTICATION clause of the CREATE ENDPOINT statement or the ALTER ENDPOINT statement. The AUTHENTICATION clause provides the following options for specifying the authentication type:
Anonymous authentication on an endpoint is not supported. For user access to an endpoint, the user must be a valid authenticated Windows user, either a trusted Windows user or a member account on the local computer.
Basic authentication is one of the two required authentication mechanisms in the HTTP 1.1 specification. Basic authentication is made up of an Authentication header that contains the base64-encoded user name and password separated by a colon. For more information, visit http://www.ietf.org/rfc/rfc2617.txt.
Consider the following when you specify BASIC:
The PORTS value cannot be set to CLEAR.
Credentials sent as basic HTTP authentication must be mapped to a valid Windows login.
Basic authentication should only be used as a last resort. Because it uses easily decoded base64-encoding, if basic authentication is specified, the instance of SQL Server requires that a Secure Sockets Layer (SSL) port be used for HTTP connection. Basic authentication can be used in situations in which the user that is granted permissions to the endpoint is a local user on the server computer itself.
Digest is the second authentication mechanism required by HTTP 1.1. This authentication is made up of the user name and password. This is then hashed with MD5, a one-way hashing algorithm, and sent to the server. The server has access to either the raw password, or a stored MD5 hash that was created when the password was set. The server can then compare the stored calculated value to the one provided by the client. This way, the client can prove that it knows the password without actually giving it to the server. For more information, visit http://www.ietf.org/rfc/rfc2617.txt.
The credentials sent as part of a digest authentication over HTTP must be mapped to a valid Windows domain account. Local user accounts are not supported for Windows-based digest authentication.
For security reasons, Windows-based digest authentication only supports MD5-sess encryption over domain controllers that are running under Windows Server 2003.
NTLM is the authentication mechanism supported by Windows 95, Windows 98, and Windows NT 4.0 (client and server). This authentication mechanism is a challenge-response protocol that offers stronger authentication than either basic or digest. NTLM is implemented in Windows 2000 and later versions by a Security Support Provider Interface (SSPI). For more information, see Microsoft NTLM.
Kerberos authentication is an Internet standard authentication mechanism. Kerberos authentication is supported in Windows 2000 and later versions by an SSPI.
When Kerberos authentication is used, the instance of SQL Server must associate a Service Principal Name (SPN) with the account it will be running on. For more information, see Registering Kerberos Service Principal Names by Using Http.sys.
For more information about Kerberos authentication, see Microsoft Kerberos.
Endpoints configured to support integrated authentication can respond with either of the following authentication types as part of the authentication challenge: Kerberos or NTLM.
Under this configuration, the server will try to authenticate the client with whichever type the client uses in requesting authentication.
If that process fails for one integrated authentication type, the server will terminate the connection for the client. The server does not fall back to trying the other authentication type.