Skip to Content.
Sympa Menu

freetds - Re: Proposed new FreeTDS configuration format

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Proposed new FreeTDS configuration format
  • Date: Thu, 31 May 2001 17:40:26 -0500 (CDT)


On Wed, 30 May 2001, Brian Bruns wrote:

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

> What the client app knows is the existing SMB connection (which generally
> would not exist under *nix), or the cached password from the same.

Frequently, there's no existing SMB connection in the Windows case either;
unless your SQL server doubles as a fileserver or PDC, the first connection
you make to the SQL server using trusted logon logic is going to have to
establish the SMB connection. Or the TDS connection: nothing in the meaning
of 'trusted connections' precludes doing this with the TCP/IP client library
instead of with the Named Pipes client library, though I haven't a clue if
Microsoft has implemented trusted connections for TDS.

> Perhaps, PAM SMB is our saviour here?

I wouldn't bank on it. pam_smb (and the rest of the SMB-speaking PAM modules)
are largely designed for use on servers, not on client machines.

> The whole thing reeks of insecurity.

Hear, hear. As I said, the only way I can foresee that this could ever work
securely is if we implemented a scheme that behaves exactly like Kerberos, but
deals in NTLMSSP credentials instead of Kerberos tickets. I for one would
rather focus on getting true Kerberos support into FreeTDS, since I'm sure
that would already be useful for SQL 2000.

Steve Langasek
postmodern programmer





Archive powered by MHonArc 2.6.24.

Top of Page