FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

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

> 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.

One interesting advantage of using a new environmental variable is that it
frees up $SYBASE for those helpful applications that use this to find the
libraries during their build sequences -- you can have $SYBASE pointing to the
libs/includes, and $FREETDS pointing to your config file, and theoretically
everything will work just fine.

> 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.

Yes, that makes sense.  Is this DBSETLSECURE flag and LOGINREC structure
something that's part of the Sybase APIs we're using?  Also, are there any
applications (or wrapper libs, e.g. for Perl or PHP) that make use of this?
If not, then the Microsoft Way doesn't really seem to gain us anything.

As to other NT questions, what I'm really interested in is seeing a network
trace of an NT SQL client using trusted logins to connect to an MS SQL server.
If NTLMv2 is used, then it makes sense for us to try to use NTLMv2 as well.
So if you have some spare time :), a network trace (netmon, tcpdump, ethereal,
whatever) would provide a very useful data point to help verify if our
understanding of the mechanics are correct.

> 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 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.

Ok -- I think information explicitly provided to us by the application
should override /any/ defaults that come from freetds.conf.  That includes
security settings.  However, it should be possible to use a freetds.conf
setting to explicitly override any heuristically-determined settings -- such
as looking for a domain part in the username to determine whether we can use
domain authentication.

What's the behavior of DBSETLSECURE when the server is a Sybase server, btw?

> "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?

Ok -- where do you cache the credentials?  Microsoft's extensive use of
credential caching throughout the OS is a large reason why it's taken them ten
years to turn NT into something even remotely resembling a multi-user OS.
(Have you ever seen the error message 'The credentials specified conflict with
an existing set of credentials'? :P) If you're going to cache credentials on
the system so that FreeTDS connections can 'automatically' make use of them,
how are you going to link a specific credentials cache to a specific TDS
session?  By user id?  What if you have a webserver serving multiple
database-driven sites that need different access rights?  By process id?
Fails when using some types of threads, or even when just using asynchronous
connections.

By another environmental variable that points to an on-disk cache?  ...ok, you
could do that.  But what does this really gain anyone?  Nothing else on the
Unix system uses this new facility, and the only way to get credentials into
this cache is if our TDS-using application puts them there.  In the short
term, certainly, it's easier to let applications continue to hand us a
username and password with which to authenticate.  In the long term, perhaps
it would be worthwhile to develop such a Kerberos-like credentials cache...
but in the long term, I'm not sure we won't all be using Kerberos itself with
Win2k servers.

Steve Langasek
postmodern programmer