Proposed new FreeTDS configuration format

James K. Lowden jklowden at
Thu May 31 22:00:22 EDT 2001

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?


More information about the FreeTDS mailing list