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 16:37:50 -0500 (CDT)


On Thu, 31 May 2001, Brian Bruns wrote:

> 2) trusted connections

> This is purely in the desktop realm. A user logs into the network and his
> credentials are then used in a single sign-on scheme to access all the
> resources, including SQL Server. It's a convenience to the desktop
> user. How many of those do we have? Don't really know, but I'm guessing
> not many. Question is, can SQL Server restrict access to only trusted
> connections?

When Windows caches credentials, all it does is take the plaintext password
from the user, verify it against the SAM database (PDC), and then store the
plaintext-equivalent password hash away in memory. If you have that
plaintext-equivalent hash, you have everything you need to authenticate as
that user to any service that uses NT4 authentication. That includes SQL
using the Named Pipes client library (the clearest example of 'trusted'
connections I can think of, since all the authentication is handled by a lower
layer on both client and server sides), and TDS with NTLMSSP authentication.

Unless someone's configuring their SQL server to only accept connections over
DCE/RPC, then we don't have anything to worry about -- we've already
deciphered the authentication pieces necessary to do trusted connections over
TDS, we just don't have an external credentials cache like we would on a
Windows desktop. For the Named Pipes case, there's also not much to worry
about; I believe TCP/IP is still the default client library on Windows, and we
actually had Microsoft recommend to us that we not use Named Pipes as the
client library, even for NT-NT connections.

> And if so what happens under a situation such as IIS/ASP/ADO whatever where
> the application is running with no user logged into the box? I'm not sure I
> understand this peice of it at all. Someone educate me, please.

I would presume that IIS itself would never run in a security context that
would allow for trusted connections. All the ASP scripts I've ever seen that
do database connections have always needed the password explicitly specified
somewhere, either in the script, in an include file, or in a DSN.

Steve Langasek
postmodern programmer






Archive powered by MHonArc 2.6.24.

Top of Page