FreeTDS Development Group

[Steve Langasek <vorlon AT netexpress.net>]

On Fri, 1 Jun 2001, James K. Lowden wrote:

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

Sorry, one more bit of clarification... just want to make sure we're all on
the same page. :)

The plaintext-equivalent hash isn't acquired from the PDC; it's
deterministically generated (no random salt) from the plaintext password.  The
only thing a Windows client gets from the PDC is /verification/ that the
password entered by the user is correct, because obviously the OS doesn't want
to be caching invalid credentials for the life of the session.  We aren't
going to be caching credentials, and /we/ don't need to authenticate the user
against the NT domain (only the SQL server does); therefore, as a TDS client
we don't need to talk to the PDC /at all/.  For all we care, there can be a
firewall in the way.

The only thing we miss out on is being able to verify that we have the correct
password /before/ we converse with the SQL server, and I don't really see that
being important.  In fact, it's a lot easier if we don't, because we'd need a
lot more infrastructure to be able to reliably locate the PDC.  FreeTDS would
then have to talk RPC-over-SMB (for the actual connection to the PDC on port
139) AND nbns (to find the PDC in the first place).


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

I've argued for having a default domain as a per-server config setting.  The
ISP I work for currently has an NT web server that authenticates all users
against a Unix-controlled NT domain, and because of various NT idiosyncracies
and/or my ignorance in configuring the server, customers who connect via FTP
or FrontPage have to specify the domain name when connecting.  It's taken a
long time for me to come to grips with the fact that this is beyond the
comprehension of not only most of our customers, but also most of our customer
service staff, who continue to instruct customers to use <domain>/<username>
despite my repeated cries of 'BACKslash! BACKslash!'  The worst part is that
IIS's FTP server *accepts* this syntax, which only serves to reinforce the
misunderstanding... argh.

So for me, being able to set the domain name in the config file would be quite
wonderful. :)  But introducing this feature means introducing other options to
deal with the resulting complexity, so I can see the point that it may be
better to leave it out altogether.

OTOH, are there any Sybase servers out there that let you create accounts with
'\' in the name?

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

The Kerberos authentication used by Win2k is unadulterated, actually.  The
embrace-and-extend part comes with the introduction of under-spec'ed
authorization information within the Kerberos ticket; and since the primary
purpose of this authorization info is for controlling access to filesystem
resources, I'm optimistic that SQL 2000 doesn't depend on its presence.

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

Typically, IIS runs as a local system account.  By definition, accounts in the
local SAM database on any machine other than a PDC have no access rights on
remote servers.

Steve Langasek
postmodern programmer