FreeTDS Development Group

[Thomas Stover <thomas AT wsinnovations.com>]

Wow thanks for the insight. I now see where I got lost. I look at 
problems from the Unix perspective, and on *nix Unix domain sockets can 
be used to authenticate a user by asking the kernel what user is on the 
other end of the connection. The same thing can be done with windows 
named pipes, and I assumed that was how it worked. Apparently, that's 
just not the mentality on windows, and storing and routing passwords all 
over the place is considered "a good idea". What you are saying 
logically makes sense, because even though windows services can connect 
to sql server with out being logging on, the PASSWORD is stored by the 
service control manager - that must be one reason why. This would also 
explain why in my experiments with spawning sql server client programs 
from key pair authenticated ssh sessions, they would also never work. I 
think this paragraph from the cygwin docs is a good tie-in: 
http://www.cygwin.com/cygwin-ug-net/ntsec.html#ntsec-switch

So now that I get that part, it sounds like the end result I want is 
still attainable. I would like to log into a linux workstation that is 
already set up for kerberos authentication with a windows domain, then 
run a freetds program that can connect to a ms sql server on that same 
domain without resupplying the password. So as you were saying, it comes 
down to finding some mechanism that can securely hold a password during 
a session, and be queried for passwords as needed. Then just add support 
for this into freetds.

I take it that NTLM is this facility on windows, and that when running 
freetds natively on windows, this is supported, and therefore 
password-less works on windows? I didn't realize that until now. I'll 
have to read more about samba/winbind to see what your getting at there. 
I do know that in the worst case, I could make something new to do this. 
A pam module could wrap around existing pam modules to "hook in" and 
grab the login password to be feed to a background process. Freetds and 
others could then ask it for passwords.

> Date: Sat, 24 May 2008 11:08:51 +0200
> From: Frediano Ziglio <freddy77 AT gmail.com>
> Subject: Re: [freetds] windows named pipe authentication
> To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
> Message-ID: <1211620131.7360.18.camel@freddy>
> Content-Type: text/plain
>
> Il giorno ven, 23/05/2008 alle 23.05 -0500, Thomas Stover ha scritto:
>   
> > OK here's one from left field. I was reading the notes about domain 
> > authentication, and how password-less authentication / win32 named pipes 
> > connections, would require a lgpl compatible Unix implementation of the 
> > smb ipc stuff (at least). Since this is something that really would help 
> >     
>
> Looking deeper to the problem I can really say that I never see a
> password-less authentication on Windows... usually password are "cached"
> during login and windows have some stuff to login using this cached
> login. There are some services that don't require authentication (ftp,
> http, many unix daemons with particular configurations) but Windows
> authentication require a password somewhere.
> Named pipes use windows authentication to do the job (lm/ntlm/kerberos
> usually). At this point however your *nix system should have some stuff
> to store login password... I don't know if samba can do something
> similar providing also ntlm support. Currently FreeTDS support either
> kerberos and ntlm so "password-less" authentication can be done with
> kerberos (ntlm require your password cause *nix don't have stuff to
> store login password in a safe way... well... perhaps we could use
> winbind in some way using ntlm_auth or the newer libwbclient, see
> http://us3.samba.org/samba/ftp/pre/WHATSNEW-3-2-0pre3.txt, yes it's a
> prerelease!)
>
>   
> > me out, I started looking into the issue some more. I have come up with 
> > three possible avenues of approach: 1) conceivably using socat & 
> > smbclient to forward a tcp port on the loopback adapter to the sql 
> > server named pipe. 2) similar except use socat on *nix forward to child 
> > ssh that logs into a 'doz box with cygwin sshd, then run socat inside 
> > cygwin to forward stdio to the named pipe as a "regular" windows file. 
> > 3) write special purpose windows and *nix utilities to forward a tcp (or 
> > better yet unix domain socket) connection to the windows sql server 
> > named pipe.  
> >     My main question is this: For the sake of discussion lets say that 
> > freetds could interface with a ms sql server over a windows named pipe. 
> > How difficult would it be from there? Would this just turn into 
> > man-years of examining wireshark dumps (which I noticed will do win 
> > named pipes), or is it suppose to be the same wire level protocol?
> >
> >     
>
> Well... you don't need either to use wireshark... you could port jcifs
> (which is lgpl but java) to C... there are some projects that support
> smb/cifs that are quite open (samba is gpl :( that is building FreeTDS
> with samba code produce a gpl object that is to use this library your
> application have to be gpl while using standard FreeTDS you have no
> limit for your license) however the better IMHO is jCIFS.
> However there has been very few requires for named pipes, the reason is
> that mssql came (from 2000 version) with tcp protocol enabled so you can
> do all with tcp (which is also faster)!
> Time ago (some years) I spoke with Simo Sorce about moving some stuff to
> lgpl but it tolds me that Andrew own most of copyrights (honestly I
> never wrote to Andrew but if you want to try feels free). 
>
> freddy77
>
>