![[Note]](../images/note.gif) | Note |
|---|---|
Domain logins can be used only with TDS protocol versions 7.0 or above. |
As mentioned in the installation chapter, Microsoft SQL Server includes the ability to use domain [20] logins instead of standard server logins. Passwords are encrypted on the wire using a challenge-response protocol. FreeTDS plays nice with such logins.
FreeTDS supports single sign-on (connecting without prompting for a username & password) or not, depending on how it was configured. For Windows hosts (both 32- and 64-bit), if SSPI is enabled, FreeTDS will log in using so-called “trusted authentication”. For non-Windows hosts, enabling Kerberos provides similar functionality.
When neither option is enabled, FreeTDS can still log in using the domain account, but the user must supply the username & password.
To use domain logins without SSPI or Kerberos, use the 'DOMAIN\username' syntax for the username and use the domain password.
Example 5.3. Logging in with a domain login
$tsql -S camelot -U 'NOTTINGHAM\lancelot' -P roundtablelocale is "C" locale charset is "646" Msg 5703, Level 0, State 1, Server CPRO200, Line 0 Changed language setting to middle_english. 1>
When FreeTDS sees the “\” character, it automatically chooses a domain login.
To log in with a user principal name (UPN), like lancelot@nottingham.example.com, leave the domain empty: '\lancelot@nottingham.example.com'. Without the leading “\” the name is used for a normal SQL Server login, for instance the user@server form used by Azure SQL.
Support for domain logins in FreeTDS is limited to the TCP/IP network protocol stack. 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 Win32 machines depending on the type of encapsulation used for DCE/RPC itself. Supporting this would require a fairly extensive DCE/RPC library for Unix. Samba has one that is licensed under the GPL and therefore not usable by LGPL-licensed projects such as FreeTDS .
FreeTDS uses NTLMv2 (unless disabled with use ntlmv2), including the message integrity code (MIC) and the target name, like recent Windows clients.
Non-ASCII user names and passwords are supported.
For a technical description of the protocol used for domain logins, see [MS-NLMP].
Microsoft SQL Server can be configured to require Extended Protection for Authentication (EPA).
In this case the client must bind the authentication (NTLM, Kerberos or SSPI) to the encrypted channel used,
providing a channel binding token and the service principal name of the server.
FreeTDS supports EPA with all these methods, using tls-unique channel binding up to TLS 1.2 and
tls-server-end-point with TLS 1.3 (used with strict encryption).
No configuration is required, but the connection must be encrypted.
With TDS 7.x the server checks the channel binding token, with strict encryption it checks the
service principal name, so the host name used to connect must match the one registered for the server
(see SPN on freetds.conf).
[20] The term domain in this context is a Microsoft term. It refers to what's sometimes called an NT domain. It's unrelated to the DNS domain. DNS domains are used for name resolution. NT domains are used for authentication. Authentication is done by the domain controller, often the Primary Domain Controller (PDC).
The Microsoft SQL Server machine may belong to an NT domain. FreeTDS provides an encrypted password — a domain password, known to the domain controller — that the server will ask the domain controller to verify.