Skip to Content.
Sympa Menu

freetds - Re: [freetds] ubuntu client and microsoft sql server

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: jklowden AT schemamania.org
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] ubuntu client and microsoft sql server
  • Date: Wed, 4 Jan 2012 11:37:14 -0500

On Tue, Jan 03, 2012 at 03:20:12PM -0800, mark mitchell wrote:
> I am trying to connect an Ubuntu client to Microsoft SQL Server. The server
> has only Windows NT Authentication, with no possibility of SQL Server
> authentication getting added (corporate policy - it's not going to happen).

Kudos to your security guys.

>
> I use 'tsql -S MYSERVER -U ...' with a well-defined
> /etc/freetds/freetds.conf file entry:
> [MYSERVER]
> dump file = /tmp/freetds.log
> debug flags = 0xffff
> host = ...
> port = 1433
> tds version = 7.0
> use ntlmv2 = yes
^^^^^^
Are you sure you need this?

> I always get '*Login failed for user. The user is not associated with a
> trusted SQL Server connection*'.
...
> However, my first impression from the freetds documentation at
> http://www.freetds.org/userguide/domains.htm was that freetds could handle
> Windows NT authentication without any extra steps.

Two ways to connect using domain authentication: with or without the help of
the
primary domain controller (or KDC).

If you use

tsql -S MYSERVER -U 'domain\username' -P password

FreeTDS will answer the challenge all by itself. No trust relationship need
exist. AIUI the server verifies the encrypted password with its constroller.

That must work. If you cannot log in as above, you either don't have a valid
username/password or the server doesn't accept them over tcp/ip.

To connect without presenting a username+password (neither -U nor -P)
you need to be linked to the appropriate library. You're on Ubuntu, so you
want
Kerberos. I use these on RHEL:

LDFLAGS=-Wl,--rpath -Wl,/usr/.../kerberos/lib64

--enable-krb5=/usr/.../kerberos/lib64/libgssapi_krb5.so

yielding

$ ldd $(which tsql) | sed (to shorten)
libgssapi_krb5.so.2 => /usr/.../libgssapi_krb5.so.2
libtermcap.so.2 => /lib64/libtermcap.so.2
libreadline.so.5 => /usr/lib64/libreadline.so.5
librt.so.1 => /lib64/librt.so.1
libpthread.so.0 => /lib64/libpthread.so.0
libc.so.6 => /lib64/libc.so.6
libcom_err.so.3 => /usr/.../libcom_err.so.3
libkrb5.so.3 => /usr/.../libkrb5.so.3
libk5crypto.so.3 => /usr/.../libk5crypto.so.3
libkrb5support.so.0 => /usr/.../libkrb5support.so.0
libresolv.so.2 => /lib64/libresolv.so.2
/lib64/ld-linux-x86-64.so.2
libdl.so.2 => /lib64/libdl.so.2


I still need to run kinit(1) once per session before tsql will work. You
might
or might not need to do that, depending on how you logged in and how your
Ubuntu
box is set up.

If, built with --enable-krb5, you can't connect, TDSDUMP should record the
error returned by Kerberos. That's rocky territory, though. If you don't
get what you need post what you do see. Maybe someone will be able to clarify
or suggest a patch.

HTH.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page