Skip to Content.
Sympa Menu

freetds - Re: [freetds] windows named pipe authentication / kerberos auth

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Thomas Stover <thomas AT wsinnovations.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] windows named pipe authentication / kerberos auth
  • Date: Sun, 25 May 2008 16:42:51 -0500

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






  • Re: [freetds] windows named pipe authentication / kerberos auth, Thomas Stover, 05/25/2008

Archive powered by MHonArc 2.6.24.

Top of Page