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: Brian Bruns <camber AT ais.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Proposed new FreeTDS configuration format
  • Date: Thu, 31 May 2001 18:22:08 -0400 (EDT)


On Thu, 31 May 2001, Steve Langasek wrote:

> 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.
>
I was explaining this to someone at work today and drew out the 7 layer
model...TDS over TCP fits really neatly into it, whereas TDS over named
pipes via SMB had all these extra layers. It's a bandwidth pig, and
probably slow as well. I'd reccomend TCP as well.

> > 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.
>
That was my understanding of it. I just thought maybe I was missing
something with all the discussion. Cached passwords would be a little
like creating a shared mem region and having all freetds processes check
it (I am in *no way* advocating this...just using an example).

B.





Archive powered by MHonArc 2.6.24.

Top of Page