Re: Windows authentication on Windows
"James K. Lowden" <[email protected]>
| Newsgroups | gmane.comp.db.tds.freetds |
|---|---|
| Message-ID | <[email protected]> |
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