FreeTDS Development Group

["James K. Lowden" <jklowden AT speakeasy.org>]

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