Proposed new FreeTDS configuration format
vorlon at netexpress.net
Thu May 31 18:40:26 EDT 2001
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.
More information about the FreeTDS