Skip to Content.
Sympa Menu

freetds - Re: [freetds] Windows authentication on Windows

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Windows authentication on Windows
  • Date: Mon, 25 Jan 2010 20:31:01 -0500

Mark Brand wrote:
> I would like to avoid specifying the password when making the
> connection. I am using FreeTDS cross-compiled in mingw-cross-env.
> http://www.nongnu.org/mingw-cross-env/

The feature does not exist in FreeTDS. You're not alone in asking for it,
though. I myself would like that to work, so we'd have a working 64-bit
db-lib implementation.
> I've read a few things on this subject, for example that it might be
> possible to use samba to authenticate from a non-Windows host. But I'm
> thinking there might be an easier way if we are running on Windows.

Samba won't help us here. In fact we had to write our own domain login
code because as an LGPL project we couldn't use samba's GPL code.

The best thing I found was

http://blogs.msdn.com/sql_protocols/archive/2006/12/02/understanding-kerberos-and-ntlm-authentication-in-sql-server-connections.aspx

also

http://blogs.msdn.com/sql_protocols/archive/2005/10/12/479871.aspx
http://support.microsoft.com/kb/811889

According to Mr. Lu, in NTLM:

1. client sends the user name to the server
2. server generates and sends a challenge to the client
3. client encrypts that challenge using the user's password
4. client sends a response to the server.

The hard part has always been #3 because it had to be (and has been)
reverse engineered. As you say, it would be nice to use the Win32 API to
do that when its available because we wouldn't need the password.

I'm interested in NTLM because that's what FreeTDS uses on my servers at
work. (select auth_scheme from sys.dm_exec_connections where
session_id=@@spid yields "NTLM".)

The only such API call in NTWDBLIB.DLL is one of the SSPI functions:
InitSecurityInterface(). It returns a dispatch table to the rest of the
SSPI functions, so that would seem to be what they're doing. From the
docs, it looks like InitializeSecurityContext(),
AcquireCredentialsHandle(), and EncryptMessage() are what we need.

Want to take a stab at this? It would be a great feature for the next
release.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page