FreeTDS Development Group

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

Jeremy Kister wrote:
> Is it true that this could be a named pipes problem, even though I can
> make a socket to the server on port 1433/tcp, and can /not/ make sockets
> to 135/139/445 ?

Yes.  

How are you attempting to connect to 135/139/445?  telnet(1) uses TCP; you
shouldn't expect it to connect to a named-pipe service.  

Your SQL server may be listening for connections on 1433, but be unwilling
to accept domain logins there.  As Frediano suggests, your best tool to
answer, "Does my server accept domain logins via tcp/ip?" is tsql.  

> is there reasoning against setting the "Send LM & NTLM responses", as
> the FreeTDS site suggests?

No valid technical or security reason that I'm aware of.  Whatever
"disadvantages" tcp/ip might be said to have versus NetBEUI, it's hard to
see how requiring plaintext passwords would be an improvement.  I suspect
it has more to do with backwards compatibility and various degrees of
breakage in old client stacks.  

A long time ago, Microsoft did everything by named pipes.  After adding
tcp/ip, for a long time all authentication continued to be handled on
named pipes.  It's easy to imagine a scenario in which some broken old
client "prefers" tcp/ip, but is unable to use domain logins that way (or
implemented a putative "version 1.0" which the server doesn't support),
causing it to prompt the user for a password.  It may be that turning off
domain logins on the tcp/ip stack makes some old client behave in a more
acceptable way.  

You can take that for what it's worth, somewhere between sheer conjecture
and educated guess.  

--jkl