Sql Windows Authentication

Question

Good Morning,

Here is the scenario, on my Domain network I have a Sql server 2008 installed on a Windows 2008 server R2. I have an application who is using DBLIBRARY APIS (NTWDBLIB.DLL), I know it's OLD ! :). If I launch the software from a Windows XP pro or Windows Vista I can connect to the SQL SERVER 2008 remotly with the Windows authentication mode, If I lunch the software from a Windows 7 computer DBOPEN() always return error 2 (server not found). If I set a SQL user and try to commect in SQL authentication mode it's working on ALL computer.

So my question is do I have to do something special in my Windows 7 computer to get Windows authentication work ? or wich version of NTWDBLIB.DLL work with Windows 7, I think the problem come from inpersonnation but I'm not sure !

Thanks for any clue !

Sylvain

 

Answer 1

Hi,

From “If I set a SQL user and try to connect in SQL authentication mode it's working on ALL computers. “, I think the problem may be not related with NTWDBLIB.DLL, please ensure that the domain account which you log in to Windows has been added to SQL Server logins. If the error persists, check please pick out more detail information in Windows Event Viewer.

Another thread also talked about this problem, please take a look, and see: http://social.msdn.microsoft.com/Forums/en/sqlgetstarted/thread/28a2a5df-c33b-45f3-99d3-16e4567f5a03.

Thanks,
Chunsong

 

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 2

Chunsong,

 Just to clarify something the only station that give error in Windows Authentication mode are the one in Windows 7 all other Workstation work correctly !

 Here is the Message in the log of SQL server when the Windows 7 workstation try to logon on the SQL server 2008 !

Date  2010-03-31 09:33:11
Log  SQL Server (Current - 2010-03-31 00:00:00)

Source  Logon

Message
Length specified in network packet payload did not match number of bytes read; the connection has been closed. Please contact the vendor of the client library. [CLIENT: 192.168.0.162]

Can it be related to SMB 2.0 ??. I don't think NTWDBLIB.DLL is involved in the transport layer ! :)

Sylvain

 

 

Answer 3

Hi Sylvain,

Thanks for you update. Please help me do a test – Connecting to the server using other provider such as SQL Native Client. If the server can be connected in this way, the problem may be related with DB-Library.

Besides, from the error message:
>> Length specified in network packet payload did not match number of bytes read; the connection has
been closed. Please contact the vendor of the client library. [CLIENT: 192.168.0.162]

If this application came from other software vendor, I would suggest you talking with them.

Thanks,
Chunsong

---

Please remember to mark the replies as answers if they help and unmark them if they provide no help.

Answer 4

 Hi Chunsong,

 On  the Windows 7 computer I have no problem working with Sql Server Management studio, We are the producer and the vendor of the software !. I'll try the OLEDB syntax on that computer to see if it's working correctly !

Thank you for your precious time,

Sylvain

 

 

 

Answer 5

Hi,

 

I have the same issue using DBLIBRARY with a trusted connection from Win 7 to SQL 2008 running on Windows Server 2008.

Using an SQL login account the connection works fine.

Has anyone got a solution to this.

 

Thanks

Answer 6

We are just now encountering this issue when trying to connect a Win 7 PC to SQL Server 2008 R2. Everything is fine on XP but, it fails on Win 7. 

Answer 7

Good Morning,

 This will fix the issue :

Type "secpol.msc"
in Run;
Expand local policies;
Click on "Security Options", and find
"Network Security: LAN Manager authenctication level";
In the comming dropdownlist, choose "Send LM&NTLM - use NTLMv2 session security if negotiated";

Best Regards,

Sylvain

Answer 8

Hi Sylvain,

Do you have any explanation about why this change in Security Policy works?

I have a similar problem.  We have an old PowerBuilder app that uses NTWDBLIB.DLL to connect to SQL Server 2008 R2.  This works fine from WinXP (which most of the users at my company still have).

But it doesn't work with Windows 7.

I wanted to try your fix, but this functionality is locked down at my company.

So I need to find another solution.

Thanks,

Jim

Answer 9

Exactly what happens on Windows 7? I have not tested whether DB-Library works on Win7, but I would not be surprised if it does not.

---

Erland Sommarskog, SQL Server MVP, [e-mail]

Answer 10

Hi Sylvain,

Do you have any explanation about why this change in Security Policy works?

I have a similar problem.  We have an old PowerBuilder app that uses NTWDBLIB.DLL to connect to SQL Server 2008 R2.  This works fine from WinXP (which most of the users at my company still have).

But it doesn't work with Windows 7.

I wanted to try your fix, but this functionality is locked down at my company.

So I need to find another solution.

Newer Windows operating systems require NTLMV2 by default.  You have only 3 options:

• Change the OS LAN Manager Authention Level to allow older NTLM authentication if NTLMV2 is not possible (see Sylvain's post)
• Change your appliction to use SQL Authentication
• Change your application to use another API (which may require you upgrade to a newer version of Power Builder)

DB-LIB has been deprecated for over a decade.  It's only a matter of time before it breaks completely with no workaround.

---

Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/

Answer 11

Thanks Dan, Here is my current situation: Windows 7 includes the options to run programs under a different compatibility mode. Right-click on an exe and it offers Troubleshoot Compatibility. This starts a wizard that lets you select an old OS version. I was able to run my app under 'WIN NT 4.0 SP 5' compatibility. Unfortunately, this didn't work for another user, who got a message "The server principal ... is not able to access the database ... under the current security context" So perhaps this can still be resolved by the first bullet. The second bullet might be a fallback for us, but it'd be a difficult change right now. And, the third bullet will be tough. My company is not going to upgrade PowerBuilder Jim

Answer 12

Oh, one other thing.

You were completing a thought?

"The change works because newer operating systems require"......?

---

Answer 13

Is that other user able to log into the application from XP? The error message indicates that he makes it to the server, but is not authenticated with the database.

One alternative is to put the application in a VM that runs an old OS.

But in the long run, you will need to look for a replacement, one way or another.

---

Erland Sommarskog, SQL Server MVP, [e-mail]

Answer 14

You were completing a thought?

"The change works because newer operating systems require"......?

That was left over from a previous draft of my response that I forgot to delete.  I edited my reply and removed it.

---

Dan Guzman, SQL Server MVP, http://weblogs.sqlteam.com/dang/

Answer 15

I tracked down the issue with the other user, and it was due to permissions in the database. 

So the plan is to go ahead and run the app under the Win NT compatibility.

All the other options aren't practical for us.

-- I can't imagine that we will be allowed to change any security settings on corporate desktops

-- Changing to Sql Authentication would be a major rewrite

-- We're running PowerBuilder 7(!), and they're not going to upgrade, and I can't get it running with ODBC.

The company has been looking to replace the app since I got here, 10 years ago.  So it goes...