Topics from the Microsoft SQL Server Protocols team - Netlibs, TDS, SQL Browser, etc.
Kerberos is a widely accepted network authentication protocol that is used to provide a highly secure method to authenticate users. Reliance is placed upon a trusted third party called the Key Distribution Center (KDC) to facilitate the generation and secure distribution of authentication tokens and symmetric session keys. In a Windows environment, the operation of the KDC is assumed by the Domain Controller (DC) using the Active Directory (AD). Furthermore, all Windows domain users are effectively Kerberos principals and are capable of engaging in Kerberos authentication.
Among the key benefits of Kerberos authentication that make it popular are:
Kerberos with SQL Server
SQL Server 2005 (and 2000) supports Kerberos indirectly through the Windows SSPI interface when using Windows integrated authentication (as opposed to SQL authentication). However, Kerberos will only be used under certain circumstances as SQL Server allows SSPI to negotiate the authentication protocol to use; if Kerberos cannot be used, then Windows will fall back NTLM authentication. Kerberos authentication is far more desirable than NTLM from a security (and, to a lesser degree, performance) point of view and I think it’s important to understand how to ensure Kerberos is used for remote connections when possible. If you're using integrated auth, you need to make sure that the follow are done:
Registering an SPN
The SPN is essentially a mapping between a principal name and the Windows account that started the server instance service. This is needed because the client will use the server’s hostname and the TCP/IP port to which it connects to compose an SPN. If the SPN mapping has not been performed, then the Windows security layer will be unable to determine the account associated with the SPN and Kerberos authentication will not be used. In an attempt to facilitate this, the SQL Server 2005 instance will automatically try to register the SPN with the AD at startup if TCP/IP is enabled. The problem is, however, that only a domain administrator or a Local System account has the authority to register an SPN. Therefore, in the majority of cases where the service is started under a normal account, SQL Server will be unable to register the SPN for the instance. This will not prevent the instance from starting but you will see the following entry in the error log:
The SQL Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.
The alternative is to have a domain admin manually register the SPN for the instance. The format for an SPN is MSSQLSvc/FQDN:tcpport, where FQDN is the fully qualified domain name of the server and tcpport is the TCP/IP port number. To register the SPN, the administrator will need to use the SetSPN.exe tool which is available from the Windows server resource kit (for Windows 2K3, you can find it here, http://support.microsoft.com/default.aspx?scid=kb;en-us;892777). An example of the command is:
setspn -A MSSQLSvc/myhost.redmond.microsoft.com:1433 accountname
If an SPN already exists, then it must be deleted before it can be re-registered. This is accomplished by a domain admin using the setspn -D command.
To verify that Kerberos authentication is being used, you may query the sys.dm_exec_connections DMV and look under the auth_scheme column, e.g.
select auth_scheme from sys.dm_exec_connections where session_id=@@spid
If Kerberos is being used, then it will display “KERBEROS”.
I should also mention that if the instance automatically registered an SPN at startup, then it will unregister it when the instance is stopped.
If instance is configured to listen to a different port, then the SPN will need to be deleted and recreated using the new port number. The problem is worse if the server is configured to use dynamic IP addresses as, potentially, a new SPN must be configured every time the server is started. I recommend that a static IP address be used so that the SPN need only be registered once. In addition, using a static IP address provides the additional benefit that the client can specify the TCP/IP directly in the connection string. Doing this will prevent the need to rely upon SQL Browser to determine the port number (SQL Browser communication uses an unauthenticated UDP channel).
A couple of other considerations that are documented in the BOL are (i) the Dedicated Admin Connection (DAC) only uses NTLM so no SPN is registered for the DAC connection, and (ii) if the instance is configured to listen to multiple IP addresses, then the server will only attempt to automatically register the SPN using the first port that it identifies.
Il-Sung LeeProgram Manager, SQL Server Protocols
Disclaimer: This posting is provided "AS IS" with no warranties, and confers no rights
The Windows Security layer always falls back to NTLM when connections are made locally. This appears to be the design of SSPI when NEGOTIATE is used so what you are seeing is expected.
When you get a NULL user error, then it may mean one of several things including:
1 - Your impersonation failed
2 - You've impersonated the client's credentials but you are making the outbound connection using NTLM
3 - Your application is run under Local System and NTLM is used.
With regard to 2 and 3, make sure that the outbound connection is made using TCP/IP and that the correct SPN is registered. Also make sure that you don't have any DNS problems; specifically, your server's FQDN should resolve correctly. If it doesn't then the client may compose the wrong SPN string and cause the connection to NTLM.
With respect to 3, Windows does not permit applications run under Local System to make outbound connections using NTLM as Local System -- NT ANONYMOUS credentials are used instead.
I hope this helps, but if it doesn't, then I suggest that you post your problem to the SQL Server Data Access Forum: http://forums.microsoft.com/msdn/showforum.aspx?forumid=87&siteid=1
Incorrect DNS can lead to various network connectivity issues. In this post, I explain how it affects
I can connect to my SQL server using KERBEROS from any server on the network (Win 2000, Win 2003)
But when i connect from my Win XP SP2 PC i always connected as NTLM?
Any idea why? Any local policy to check? anything else?
My Setspn return the correct results.
where should SetSPN command executed, Active Directory machine or sql server machin
It does not matter where you execute the SetSPN command, the command updates data in Active Directory which is centrally located in your domain.
I wounder if i can use Kerberos without Active Directory?
We've got samba domain controller.
I need to install WSUS server and i want to use our dedicated SQL 2005 server, but it now runs only with NTLM, because we don't have AD.
Please check out following blog:
i have a error in the installation process like "logon account cannot be validated for the sql service.please verify user name and password".what is this
I can verify that the sql server is using Kerberos authentication by running the select statement: select auth_scheme from sys.dm_exec_connections where session_id=@@spid
However, I can not see the spn name when I run Setspn.exe -L "service-account-name". I am still getting:Login failed for user 'NT AUTHORITY\ANONYMOUS LOGON'
Не первый раз встречаюсь с тем, что настройка делегирования для связанных серверов (так в русском BOL
Is only the SQL service needed as SPN? If not, how is the syntax for SQLAgent service, which seems to need Kerberos in CU3+ updates or is sharing this:
setspn -A MSSQLSvc/FQDN:1433 accountname
Is this error related to this discussion?? Thanks!
SSPI handshake failed with error code 0x8009030c while establishing a connection with integrated security
i have to link postgre sql from sql server 2005 express. (sp_addlinkedserver)
i tried. but its not working
but it is possible in msaccess 97....
pls help me..
We've configured this sometime ago. The problem we have is we get inconsistent results when connecting using the same account.
Client's OS: Windows XP 2002 SP2
SQL Server: SQL 2005 SP2
Result 1 -
If I logon to the client PC with my Windows domain account, and then register SQL Server Management Studio directly with Windows Authentication, the result is 'NTLM'.
Result 2 -
If I logon to the client PC with my Windows account, and then register SQL Server Management Studio with Windows Authentication again but using Run As my Windows domain account, the result is 'KERBEROS'.
As a result of this, we get different results here and there depending on how the user is connecting and how the connection string is set up in the application and how the application is deployed.
It looks like the KERBEROS is configured right for SQL Server. What's wrong here? We need it to be KERBEROS consistently.
Thank you in advance.