FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

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