FreeTDS Development Group

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

Steve Langasek wrote:

> Is this DBSETLSECURE flag and LOGINREC structure
> something that's part of the Sybase APIs we're using?

Yes.  LOGINREC is defined in include/sybdb.h.  DBSETLSECURE is of course not 
there.

> Also, are there any
> applications (or wrapper libs, e.g. for Perl or PHP) that make use of this?
> If not, then the Microsoft Way doesn't really seem to gain us anything.

I tend to use Ole DB myself.  I'm pretty sure Win32 Perl supports trusted
connections.  DBD::Sybase, I dunno.  Will check, though.  It's pretty rare 
these days
to find any Win32 anything that doesn't know about trusted logins.  My friend 
Erwin
is sadly one of them.

> As to other NT questions, what I'm really interested in is seeing a network
> trace of an NT SQL client using trusted logins to connect to an MS SQL 
> server.
> If NTLMv2 is used, then it makes sense for us to try to use NTLMv2 as well.
> So if you have some spare time :), a network trace (netmon, tcpdump, 
> ethereal,
> whatever) would provide a very useful data point to help verify if our
> understanding of the mechanics are correct.

Let me see what I can do.  I think I can get my hands on MS SQL 2000 (not 
sure);
I have W2K on one box (when it's not running Debian) and NT4 on another.  I'd 
have to
install Ethereal on my NetBSD router.  Seems feasible as long as Ethereal 
doesn't
need X.

> I think information explicitly provided to us by the application
> should override /any/ defaults that come from freetds.conf.  That includes
> security settings.  However, it should be possible to use a freetds.conf
> setting to explicitly override any heuristically-determined settings -- such
> as looking for a domain part in the username to determine whether we can use
> domain authentication.

I'm with you.

> What's the behavior of DBSETLSECURE when the server is a Sybase server, btw?

Externally, the login fails.  If you use an MS client library with a Sybase 
server
(or vice versa), all bets are off; I've seen data scrambled.

> where do you cache the credentials?  Microsoft's extensive use of
> credential caching throughout the OS is a large reason why it's taken them 
> ten
> years to turn NT into something even remotely resembling a multi-user OS.
> (Have you ever seen the error message 'The credentials specified conflict 
> with
> an existing set of credentials'? :P) If you're going to cache credentials on
> the system so that FreeTDS connections can 'automatically' make use of them,
> how are you going to link a specific credentials cache to a specific TDS
> session?  By user id?

Yes.  (and MS error messages are my absolute favorite rant, don't even get me
started)

> What if you have a webserver serving multiple
> database-driven sites that need different access rights?

Then you have to use old-fashioned ;-) server logins.

> By process id?
> Fails when using some types of threads, or even when just using asynchronous
> connections.

No.  Uh uh, for your very reasons.

> By another environmental variable that points to an on-disk cache?  ...ok, 
> you
> could do that.  But what does this really gain anyone?  Nothing else on the
> Unix system uses this new facility, and the only way to get credentials into
> this cache is if our TDS-using application puts them there.  In the short
> term, certainly, it's easier to let applications continue to hand us a
> username and password with which to authenticate.  In the long term, perhaps
> it would be worthwhile to develop such a Kerberos-like credentials cache...
> but in the long term, I'm not sure we won't all be using Kerberos itself 
> with
> Win2k servers.

BTW, you're not being fair.  To Unix, that is.  Microsoft doesn't have 
anything
resembling a multi-user OS.  You'd be behind schedule, too, if you were 
trying to
re-invent the wheel (and re-re-invent it when you recognized your errors or 
needed to
boost your revenues)  instead of just climbing aboard the bandwagon.

You're making me think, here, Steve, always a dicey proposition.  Let me see 
if I can
answer you with what I think would work.

All your points about Kerberos and nothing else knowing about it or being 
able to use
it, you're absolutely right, including your long term squinting.  Quite so.  
I didn't
know you were trying to help anyone besides FreeTDS clients.

Obviously (unless we modify the login(1)), we're not going to capture the 
password
when the user first logs in.  So, at some point prior to the first connection 
to the
database server, the client app is going to have to provide a username & 
password to
something somewhere if he wants to participate in this whole domain login 
scheme.
What does he get back?  Credentials, right?  An authentication token?  
Credentials,
let us say.

I guess I was vaguely hoping all that actually wouldn't be necessary, that 
some sort
of inside-out Samba thing would magically get us our credentials.

Now, suppose the caller did this through FreeTDS.  He sets the username with
DBSETLUSER, the password with DBSETLPWD, and indicates with DBSETLSECURE he'd 
like to
use trusted connections for this and all subsequent connections for his user 
id.
FreeTDS sees the DBSETLSECURE call, does its favors for the caller, and hangs 
onto
the credentials for him.  Thereafter, the caller need only call DBSETLSECURE 
because
the credentials are cached for the duration of the task.  Every LOGINREC 
structure so
modified will carry its flag to dbopen(), which is what opens the connection 
and
actually logs into the server.  (I'm sorry to lean so heavily on dblib 
terminology.
It's what I know; I realize this all lives down in the TDS layer somewhere.)  
FreeTDS
knows its user id, looks up the credentials does [insert magic here] and uses 
said
credentials when dbopen() gets called.

You might rightly object that no one's going to use my fancy new API, 
certainly not
without motivation, of which there will be only some.  Other than storing the
username and password on the disk in something like the .netrc that my 
favorite ftp
client uses, I can't think of anything that would affect the caller less.  
Possibly
the whole idea is just nuts.

I think the choices are pretty skinny anyway.  AFAIK, you can't pass a domain
username & password pair to the server.  The alternatives are either (a) 
server login
with username & password, or (b) an authentication token.

On my servers, I often have two usernames (thank you, Erwin).  I use trusted
connections most of the time, but I can't enter my NT username & password 
into a
client app that doesn't know about trusted logins.  Well, I can, but it won't 
work.
I think once upon a time a knowledgeable NT guy could edit some 
system-generated
password, and manually set it to match my NT password, but if that was ever 
true,
I've yet to meet the guy who knows how to do it anymore.

I'm sorry if I'm being obtuse, missing something obvious.  I probably 
shouldn't try
to write something so technical at 2:00 AM.  I hope I'm being helpful and not 
just
annoying.

Regards,

--jkl