Re: Dazed & Confused
- From: BigSam <BigSam@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 28 Feb 2008 06:10:02 -0800
I think the problem may have been related to the certificate used on the
remote server for SQL encryption. The certificate had a different name than
the name of the server. I replaced the certificate & re-enable encryption &
can now connect from both IIS servers.
"BigSam" wrote:
Thanks for your reply. However, I'm afraid your solution doesn't fit all of.
my issues. One new issue I've uncovered has to do with the connection string.
We created a VB script (see below) that just connects to the remote server.
When connecting with provider=SQLOLEDB, the connection fails, but when
connecting with provider=SQLNCLI the connection completes. It leads me to
believe the SQLOLEDB provider module on the client server is corrupt.
Any ideas regarding this theory or how to proceed?
Thanks
VB Script
Set Conn = CreateObject("ADODB.Connection")
Conn.Open "Provider=sqloledb;Network Library=DBMSSOCN;Data
Source=ip_addr;Initial Catalog=dbname;User ID=SQLUserID;Password=999999;"
'Conn.Open "Provider=SQLNCLI;Server=ip_addr;Initial
Catalog=dbname;UID=SQLUserID;Pwd=999999;"
msgbox("opened")
Conn.Close
msgbox("closed")
"Rick Byham, (MSFT)" wrote:
Weird. I was just writing an explanation of that error:
Explanation
The SQL Server computer was unable to process the client login packet. This
may be because the packet was created improperly or because the packet was
damaged during transmission. It can also be caused by the configuration of
the SQL Server computer. The IP address listed is the address of the client
computer.
More Information
When using Windows Authentication in a Kerberos environment, a client
receives a Kerberos ticket that contains a Privilege Attribute Certificate
(PAC). The PAC contains various types of authorization data including groups
that the user is a member of, rights the user has, and what policies apply
to the user. When the client receives the Kerberos ticket, the information
contained in the PAC is used to generate the user's access token. The client
presents the token to the SQL Server computer as part of the login packet.
If the token was improperly created or damaged during transmission, SQL
Server cannot offer additional information about the problem.
When the user is a member of many groups or has many policies, the token may
grow larger than normal to list them all. If the token grows larger than the
MaxTokenSize value of the server computer, the client fails to connect with
a General Network Error (GNE) and error 17832 can occur. This problem may
affect only some users: users with many groups or policies. When the problem
is the MaxTokenSize value of the server computer, error 17832 in the SQL
Server error log will be accompanied by an error with state 9. For
additional details about the Kerberos and MaxTokenSize, see KB327825
(http://support.microsoft.com/kb/327825).
User Action
To resolve this problem, increase the MaxTokenSize value of the server
computer, to a size large enough to contain the largest token of any user in
your organization. To research the correct token size for your organization,
consider using the Tokensz
(http://www.microsoft.com/downloads/details.aspx?familyid=4A303FA5-CF20-43FB-9483-0F0B0DAE265C&displaylang=en)
application.
Caution Incorrectly editing the registry can severely damage your system.
Before making changes to the registry, we recommend that you back up any
valued data on the computer.
To change the MaxTokenSize on the server computer
1. On the Start menu, click Run.
2. Type regedit, and then click OK. (If the User Account Control dialog box
appears, click Continue.)
3. Navigate to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa\Kerberos\Parameters.
4. If the MaxTokenSize parameter is not present, right-click Parameters,
point to New, and then click DWORD (32-bit) Value. Name the registry entry
MaxTokenSize.
5. Right-click MaxTokenSize, and then click Modify.
6. In the Value data box type the desired MaxTokenSize value.
Note Hexadecimal value ffff (decimal value 65535) is the maximum
recommended token size. Providing this value would probably solve the
problem, but could have negative computer-wide effects with regard to
performance. We recommend that you establish the minimum MaxTokenSize value
that allows for the largest token of any user in your organization and enter
that value.
7. Click OK.
8. Close Registry Editor.
9. Restart the computer.
--
Rick Byham (MSFT)
This posting is provided "AS IS" with no warranties, and confers no rights.
"BigSam" <BigSam@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:FED761E5-40EC-427F-AC20-EEAD5A0D6D39@xxxxxxxxxxxxxxxx
I have an application running on 2 w2k3 servers, each running IIS. (These
servers sit behind a load balancer.) Each server needs to connect to a
database on a remote server. The connection string to the remote server is
stored on another SQL server in the same LAN as the IIS servers; the
applications on the IIS servers retrieve the connection string before
attempting to connect. One IIS server connects without incident, but the
other consistently does not connect. The error message on the Remote SQL
server in the Application Event log is “Error: 17832, Severity: 20, State:
9
Connection opened but invalid login packet(s) sent. Connection closed.”
To really confound the problem, I can connect to the remote server from
the
troubled IIS server using SQL Managment Studio.
I’ve checked the dlls on both IIS servers – all are identical versions. I
compared the executable for Size & Last Modified Date – they are the same,
too. The dlls & executables were written in VB 6.
Rebooting has resolved nothing.
I didn’t capture anything helpful with SQL Profiler on the SQL server – it
showed no errors. I tried to see what’s happening with NetMon, but SQL
connections are ‘forced encryption’ on the SQL server, so I wasn’t able
to
see what was in the login packets.
I’m at a loss for the next steps to investigate. Any suggestions?
- References:
- Dazed & Confused
- From: BigSam
- Re: Dazed & Confused
- From: Rick Byham, \(MSFT\)
- Re: Dazed & Confused
- From: BigSam
- Dazed & Confused
- Prev by Date: Re: problem with getdate()
- Next by Date: Re: SQL Server 2000 SP4 client connection problem
- Previous by thread: Re: Dazed & Confused
- Next by thread: Commandtext using an @parametername but not with a stored procedure
- Index(es):
Relevant Pages
|
Loading
