Skip to Content.
Sympa Menu

freetds - Re: [freetds] Domain Login Support, connecting to MSSQL issue

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Steve Langasek <vorlon AT netexpress.net>
  • To: 'FreeTDS Development Group' <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Domain Login Support, connecting to MSSQL issue
  • Date: Tue, 5 Aug 2003 19:35:19 -0500

On Wed, Aug 06, 2003 at 07:00:26AM +0800, Varley, David (CBorn at Alcoa)
wrote:
> That's interesting. When some of our client databases were updated from
> MSSQL7 to MSSQL2K recently, our access via Enterprise Manager failed with
> the message about "user null". Our complaints took a while to filter up to
> an expert in Microsoft Support, and the answer came back to use only Named
> Pipes instead of tcp/ip.

> We are connecting cross-domain, and the solution seems to be to map a
> network drive to the NETLOGON share on the SQL server box using a valid NT
> username/pw, and then connect using Named Pipes, which is much slower, but
> authenticates.

> From what's been said in this thread, sounds like this may be a configurable
> policy setting on their servers.

That's correct; use of Named Pipes vs. direct TCP connections is
configurable on both client and server in Windows.

> [I haven't tested against those servers with FreeTDS. Since the start of the
> iconv changes a long time back I haven't been able to get a working build on
> Tru64 :( ]

FreeTDS does not currently implement support for Named Pipe-based SQL
connections -- that is, connections transported over the DCE/RPC
interface, which uses tcp port 139, 445, or 135 on Windows machines
depending on the type of encapsulation used for DCE/RPC itself.
Supporting this would require a fairly extensive DCE/RPC library for
Unix (such as the one built into Samba, which is licensed under the GPL
and therefore not generally considered usable by most other projects
aiming to produce libraries).

Microsoft generally favors RPC interfaces, in part because it provide
an integrated security context without the need to handle usernames and
passwords at the application level. As you can see from your own
experience, this doesn't always translate well into practice. ;)

--
Steve Langasek
postmodern programmer



Archive powered by MHonArc 2.6.24.

Top of Page