SIMATIC MANAGER THE SQL SERVER CANNOT ACCESS DATA WINDOWS
Be aware that only TCP/IP provider can provides the benefits of Kerberos authentication as discussed inīack to the questions we left before, the reason that disconnected from network (no network media) works is because, in such case, local is resolved to “127.0.0.1” by windows network layer and NTLM is used directly. Not going too deep, the simple answer is that only TCP/IP provider, with an exception of loop-back connection, uses SPNEGO while other providers use NTLM. Reader might ponder why avoiding using TCP/IP provider can solve the problem while explaining it is because certain behavior of SPNEGO in Windows. This issue is not a security issue though. For this specific case, SPNEGO chooses not to fallback, hence connection fail. KDC, normally, is part of your domain controller. Whether to fallback to NTLM if KDC is not available when the target SPN points to local machine. The reason that we didn’t fix this subtle issue is because the limitation is rooted in a behavior of an integrated authentication module (SPNEGO) in XP and windows 2000, i.e. If these workarounds described above do not fit your needs, we would like to hear more from you. If the connection string is prefixed with “tcp”, then you do need to modify your connection string to specify “127.0.0.1” as. Remember that the “Cannot Generate SSPI context” problem described in this post only happens when connecting to a local server thus, the “127.0.0.1” is applicable.
For example, if your connection string has form of “” and is not prefixed with “tcp”, without modifying the connection string, you can configure an alias with alias name as, protocol as TCP/IP, server as “127.0.0.1” or “127.0.0.1,”. In very rare case, however, if you really in need of TCP/IP connection, the option is to use TCP/IP loop-back address, i.e. Note that certain SKUs of SQL Server have named pipe connection turned off by default. To do that, first, on the server side, make sure your server is listening on Shared Memory or/and Named Pipe connection requests then, on the client side, change the protocol order list such that Shared Memory and/or Named Pipe are in front of TCP/IP, or prefixing your connection strings with “lpc” or “np” to force Shared Memory or Named Pipe, or using alias that prefix Named Pipe in connection strings, whichever you feel most comfortable with. As described above, only TCP/IP provider has the issue hence, configuring network library not to choose TCP/IP is a solution. A simple answer is that it can happen if the TCP/IP provider is in front of other providers in the client protocol order list, or/and the local server is not listening on Share Memory and Name Pipe.
Users might wonder why network library chooses TCP/IP provider instead of Shared Memory provider, if the connection string is not prefixed with “tcp” and the server is local. For example connection strings in form of “.”, “(local)”, “” are among them. In most cases, users do not explicitly require TCP/IP as the connection provider. From user’s perspective, however, in many cases, either connecting over VPN or disconnecting from network might prevent you from accessing some valuable resources, so I want to discuss solutions that do not depend on (1) first. The reason why they work is subtle and I’ll discuss it later.
One solution, of course, is to avoid condition (1) by connecting to your corporate domain through VPN or disconnecting from network completely. But the reality is that it is quit often if the hosting machine is a laptop computer. (4) Connection configuration causes network library to choose TCP/IP provider.Ī scenario that meets all of (1) (2) and (3) looks like an extreme corner case. (3) The connection is to a local SQL Server.
(2) The OS of the hosting machine is Windows XP or 2000. (1) The hosting machine of SQL Server is connected to a network, including home network or dialup connection, but it is disconnected from its domain. It can happen when all of followings are true: SQL Native Client]Cannot generate SSPI context” The Local Security Authority cannot be contacted.[ The error message for the failed connection that we discussed here is But actually, it can happen with any SKU of SQL Server, including SQL Server 2000 and SQL Server 2005, that support NT integrated authentication. In most related cases, customers report this issue as "I can connect to my local SQL Server, but once I connect to my network, I can't connection to my local SQL Server". Such issue is reported against MSDE and SQLExpress. In this post I will discuss one daunting case of “Cannot generate SSPI context” error message when failing to connect to SQL server. The “Cannot generate SSPI context” issue is described by
0 kommentar(er)
