FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Wed, 30 May 2001, James K. Lowden wrote:

> I was all out of breath from leaping to the conclusion that the 150-odd
> lines of code you're using did more-or-less the same thing viz., requested a
> security token from the PDC, which you'd cache and then have ready when the
> time comes.  I see now that even if that were so (which now looks less
> likely), there would still be the significant challenge of figuring out
> where to squirt that token into the TDS stream.  Ugh.

What you see in those 150 lines of code is all there is.  The hashing is a
little different for NT v. Win9x clients, but that's it.  No tokens from the
KDC, just the password hash we already have.

When a client connects to a member server, the first thing that's negotiated
(normally-- TDS seems a little strange here) is the authentication domain.
The client says what domain it has credentials for, which could be the local
server, the domain the server is a member of, or a remote domain there's a
trust relationship for.  Depending what auth domain the client is from, the
server either generates a random bit of data for the challenge, or it asks its
PDC for one.  The server sends this challenge to the client, which hashes it
with the pre-hashed password and sends it back.  If the server has the
password database, it performs the same operation on its end and compares the
results; if not, it forwards the hash to its PDC and waits for a yay or nay.

So if Brian's code can do that reliably, you'll find that FreeTDS will work
with anything the MS SQL server can throw at it.  It just requires the
application to continue to provide the username and password.

Steve Langasek
postmodern programmer