Assume that you migrate from SQLNCLI11.dll to MSODBCSQL11.dll, or from earlier versions of Microsoft SQL Server to SQL Server 2014 or later. In this situation, you may notice changes in the way that client providers resolve server names. In turn, this changes how authentication occurs.

Depending on your system configuration, this change may affect connectivity for applications that are using new client drivers. This includes some SQL Server 2014 or later utilities, such as SQLCMD.EXE, BCP.EXE, and OSQL.EXE, depending on their connection parameters.


The earlier versions of the client providers perform a reverse lookup for integrated authentication. Because this behavior has potential security implications, the newer client drivers fall back to NTLM authentication when the Fully Qualified Domain Name (FQDN) is not used.


There are two workarounds for connectivity issues that occur in the scenario that's described in the "Symptoms" section.

Method 1

Use the FQDN to connect to the server. This forces the name that's being used in the connection. Therefore, it also forces the authentication method that's being used.

Method 2

Set the Server Principal Name (SPN) for your server name. For information about how to register an SPN, see Register a Service Principal Name for Kerberos connections.

Examples of SPNs:


Note The SERVER_NAME placeholder represents the NETBIOS name of the server.

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

What affected your experience?

Thank you for your feedback!