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: "James K. Lowden" <jklowden AT speakeasy.org>
  • To: TDS Development Group <freetds AT franklin.oit.unc.edu>
  • Subject: Re: Proposed new FreeTDS configuration format
  • Date: Fri, 01 Jun 2001 02:00:22 +0000


Brian, Steve,

I get it now. Thank you for spelling it out in small words.

> 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.

Brian has set out to enable FreeTDS to connect to SQL Servers using a "domain
login",
which amounts to acquiring the plaintext-equivalent hash from the PDC and
using it to log
into the database.

Caching the plaintext-equivalent password hash is not all that helpful in the
end, my
misguided suggestions notwithstanding. The cache would be FreeTDS specific,
and not that
helpful to FreeTDS clients, who after all have to provide the
username-password pair once
at least, and would have to adapt to any API change.

Brian's transparent approach is to parse the username. If it includes a
domain component,
he goes after a domain login, else revert to status quo.

As far as I can tell, there's no need for any freetds.conf entry. The
behavior of the
login can be controlled by the form of the username.

> 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.
>

If they've decided to use unadulterated unbroken embraced-but-not-extended
Kerberos
authentication, then FWIW I agree with Steve, Kerberos
participation/awareness/exploitation in FreeTDS would be a good feature. Of
course. BTW,
doesn't Sybase speak Kerberos too, somehow?

> 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.

I think in theory the IIS *could* use trusted connections. It runs under an
account,
after all (likely the system account), but I can't think of why that would
prevent setting
up a trusted connection for that account. In practice, though, it's neither
safe nor
flexible. Not flexible, because it's one more cross-discipline thing: the
IIS setup guys
are not the database sa's. Not safe because it's all-or-nothing: once in
place, all
scripts would automatically acquire the privileges of the IIS's trusted
account, the
consequences of which are too horrible to contemplate in a family newspaper.

Right? Any loose ends?

--jkl





Archive powered by MHonArc 2.6.24.

Top of Page