A tale about solving "Cannot generate SSPI context" and later "[DBNETLIB][ConnectionRead(recv()).] General network error. Check your network documentation" in a shot

  • Article

I had a customer who was receiving the "Cannot generate SSPI context error" when one, and only one, of his users with a specific domain account tried to log into a SQL Server 2005 using TCP network library and Windows Authentication. It ended up being caused by the fact that the default MaxTokenSize of 12,000 set in the workstation from where he was trying to connect to SQL wasn't big enough to hold the kerberos token generated during authentication because he belonged to many Windows security groups, as explained in KB327825. We solved that one out by finding (with the help of tokensz.exe) what was the minimum size we needed to set MaxTokenSize so that the preallocated buffer could hold the complete token of this particular user account.

After we created the MaxTokenSize DWORD under HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters and we set it to 13,500 (our user token was 13,336 bytes long), we rebooted the client machine for the change to take effect, and on the next connection attempt after reboot, it began failing with "[DBNETLIB][ConnectionRead(recv()).] General network error. Check your network documentation".

This time, we went to the server searching for any information that could be related to this error on the client side, and found the following error reported in ERRORLOG, every time the client had tried to connect:

17828 - The prelogin packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library.%.*ls

Re-publishing this blog to correct a mistake I made here. We don't report error 17828 mentioned above, but this one instead:

17832 - The login packet used to open the connection is structurally invalid; the connection has been closed. Please contact the vendor of the client library.%.*ls

After further code analysis on the server side, I discovered the server network library was limiting the maximum token size that would be accepted from a client to the MaxTokenSize set in the server box where SQL Server was running. Since it was a Windows Server 2003 + SP2 and it hadn't been explicitly specified, it was using the default value of 12,000. Since, during the PreLoginHandshake phase, this particular client was presenting us with a token larger than that size, SQL Server considers the packet is invalid and reports that error mentioned above.

So, to solve this second issue, we had to explicitly set the MaxTokenSize setting on the server to 13,500 and reboot the box as well. Why 13,500, because we knew SQL Server could now receive login attempts from clients which could present him a token as big as that.

Hope it helps somebody to solve these two issues.

While troubleshooting this issue, I also found interesting reading Addressing Problems Due To Access Token Limitation.