FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

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.