FreeTDS Development Group

["Lowden, James K" <LowdenJK AT bernstein.com>]

Facinating.  One of the things I like best about talking with smart people
is learning stuff.  Long response follows, sigh, testing your patience, I'm
sure.  

Steve demolished my "workgroup" suggestion; please ignore it.  

Backwards compatibility: FWIW, I'm against it in this case, for the record.
Too crufty.  I don't think it buys much, especially if "make; make install"
migrates the interfaces file for you, and writes the environment settings to
freetds.conf.  Not for nothing is perl "the duct tape of the Internet", eh?


Brian: I liked your rant and I'm not surprised by it.  Remember the
Solaris(?) user who needed $TDSVER even though the build was configured
identically to the linux box?  Once we've moved every conceivable setting
into freetds.conf, I'll help rip out every reference to $SYBASE/interfaces,
with pleasure.  

> Why not just use the --prefix from configure

Because it's nice to be able to relocate a configuration file without having
to rebuild from source, and AFAIK there's no way to know what --prefix was
used after "make clean".  That's not to say I'm sold on the idea, but that's
the pro side.  

I'm suggesting, with reservations, a single environment variable pointing to
the location of freetds.conf.  I agree, it shouldn't guide locating the
libraries anymore.  And I agree life should be easy for the package makers,
for they are the wind will carry FreeTDS to the four corners of the earth.  

On specifying the TDS protocol version

Brian, I understand your point about control and the value of being
explicit.  How can we sidle our way toward more of a "what I've got" notion,
instead of a "do this" one?  Most of the time, the FreeTDS program(mer)
knows better than the user does what the optimal protocol version is, and
when we're All Done, obviously no one is going to want to specify TDSVER
anymore.  

I'd like the user to see documentation like this:

<documentation doodle>
Specify your database server's vendor {SYBASE|MICROSOFT} and version as
follows:
        db vendor = SYBASE      ; or MICROSOFT
        db version = 10 ; of 4.x, 10.x, 11.x, 12.x, 6.0, 6.5, 7.0, 2000

If you indicate a log file in freetds.conf, the TDS protocol chosen will be
logged.  Normally, FreeTDS uses the highest protocol appropriate for your
server, but for debugging purposes you can downgrade the protocol with the
line:
        
        tds version = 4.2       ; of 4.2, 5.0, 7.0

Don't put that in your [globals] section unless you really mean it!
</doodle>

On domain login negotiation

Good points all around about clarity in reporting failed logins.  Here's a
bit of self-important MS documentation:

"By setting the secure connection flag in a LOGINREC structure with
DBSETLSECURE, the application requests a secure, or trusted, connection to
Microsoft® SQL Server(tm). This means that SQL Server will use Windows NT
Authentication security to establish connections made (using dbopen) with
this LOGINREC, regardless of the current login security mode at the server.
Any login ID or password supplied by DBSETLUSER or DBSETLPWD is ignored."  

Steve, does that answer your question about NT clients?  From db-lib's point
of view, your DSN is an application.  If you have other NT questions, ask
away; it's what I do.  

Each db-lib connection (at bottom, every TDS connection) decides
per-connection what authentication system to use.  Microsoft applications,
including ISQL, rely on domain logins unless the user takes some action
(normally, providing a username) to override that.  In principle, conforming
to MS's own behavior should make FreeTDS invisible.  You heard it here
first: Good design is invisible.  

Steve said:
"There are at least two distinct failure cases that it may be important for
FreeTDS to distinguish between: a failure to negotiate NTLMSSP (be it a
network failure, a protocol incompatibility, or something else) has
different
implications than if we negotiate NTLMSSP and the server rejects our
credentials.  I think I would like to distinguish between the two cases, but
I'm not sure the best way to represent this in the config file."

Precisely so.  Databases generally and ODBC especially especially! have
lousy vague stupid useless rant rant "failed to connect" error messages.
(Why is it Microsoft has fewer error messages than API calls?  Lack of
imagination?  Where do you want to not connect to today?)  The use/nonuse of
domain logins is incidental to that problem.  

Steve also said:
"you may have a server that you know can't/shouldn't negotiate NTLMSSP.
Turning off domain auth for this server entry in the conf file will speed up
authentications a little bit, but more importantly it'll make the SQL
server's logs much less spammy with failed authentications, making it a more
useful audit tool.  On the other hand, you may have a server that you know
supports NTLMSSP...."

Well said, again.  Respectfully, I disagree because:

Preventing some negotiation with a library setting will break the
DBSETLSECURE behavior as documented.  

Whatever the settings are in freetds.conf, they have to conform to what the
server's settings are.  They can't be anything else, or they're broken.
There's no  (OK, almost no) point in redescribing the server's settings in
the library's configuration file.  The opportunity to get out of synch
outweighs IMHO the value of faster negotiation and less spammy logs.  

All to say, it's the server's job in the end, anyway.  Consider how Samba or
ftpd works.  If your log files fill up with refused connection messages, you
yell at the fool, er, talk to the user/developer about login policy.  

+++

"unless Brian's getting very ambitious here :), the client app will still
always have to supply the username & password, even in domain auth mode"

If this is true, I know I'm missing something.  I can tell, because it feels
different from missing something and not knowing it.  

What does the client app know that FreeTDS can't know (about
authentication)?  Why wouldn't FreeTDS get the credentials and, yes, cache
them, and honor DBSETLSECURE, etc.?  Why is that "ambitious"?  What easier
way is there, to manage domain authentication?  

As I said, it's fun learning (even if it's not short).  

--jkl