我有SQL服务器运行在不在一个域中的计算机上， 而不是以混合模式运行（它使用“Windows身份validation”运行）。
我试图通过TCP / IP运行freetds的Linuxnetworking服务器连接到它，使用NTLM进行身份validation。
SQL服务器上的防火墙是非常严格的。 1433对我的networking服务器是开放的，但是我从网上得到了有关NTLM成功需要额外的端口（TCP / UDP）的冲突信息。 目前失败; 我可以谈到1433要求NTLM，但实际的身份validation总是失败。
一个来源说137,138,139，但这些只是NetBIOS端口。 我真的需要那些吗？ 另一个消息来源说135.还有一些人似乎说1434 …我不能做它的正面或反面。 该死的吉姆，我是一个程序员，而不是networkingpipe理员！
编辑：
确切的错误信息：
Msg 18452, Level 14, State 1, Server , Line 0 Login failed for user '(null)'. Reason: Not associated with a trusted SQL Server connection. Msg 20002, Level 9, State -1, Server OpenClient, Line -1 Adaptive Server connection failed 我试图连接远程机器的用户名，即“服务器名\用户名”。 有些来源build议我在本地和远程机器上设置镜像帐户，但本地机器运行的是Linux，而不是Windows下的IIS。
您需要的唯一端口是1433作为TCP。 这是默认使用的端口，用于TCP连接的非命名SQL Server实例。 FreeTDS将在这个端口上启动连接，然后在这个连接上协商一个NTLMv2authentication，作为一系列挑战/响应包交换。 Afaik没有任何其他港口的需要。 请参阅域login 。
您提到的所有其他端口都是用于命名pipe道连接，而FreeTDS不支持通过命名pipe道进行NT身份validation：
支持FreeTDS中的域login仅限于TCP / IPnetworking协议栈。 FreeTDS当前不支持基于命名pipe道的SQL连接 – 也就是说，通过DCE / RPC接口传输的连接，它使用Win32计算机上的TCP端口139,445或135，具体取决于DCE / RPC使用的封装types本身。
要以NT域用户身份进行身份validation，您必须以“domain \ user”格式指定用户名。 如果SQL Server在独立的计算机上运行，则“域”是计算机名称。
如果不在域中，并且只能在Windows身份validation模式下运行，我不确定是否可以连接到此服务器。 你作为一个login添加到服务器的用户名是什么以及你从客户机上login哪个用户？
135-139是用于SMB（主要是有时是445）和Windows RPC的端口。
1434只有当你使用SQL浏览器连接到实例时才需要UDP，比如在命名实例（SERVERNAME \ INSTANCE）的情况下，但是如果你正在使用（SERVERNAME或SERVERNAME，PORT）并且实例是肯定的在1433上运行，那么不需要额外的端口。 您可以通过从命令提示符发出“telnet SERVERNAME PORT”来testing端口是否被打开。
我相信在FreeTDS 0.82中的NTLMv2实现是最好的。 这里有一个补丁你的另一个select是更改SQL Server的窗口上的组策略发送NTLMv1响应，如文档中所build议的。
下面是在Windows Server 2003上需要更改的屏幕截图 。您正在影响连接到服务器的其他客户端，以确保您可以先在某个位置进行testing。
编辑：你有没有试图打开日志，看看你有什么用？
如果SQL服务器处于同位置状态，请联系您的托pipe服务提供商以确保其本地防火墙不会阻塞该端口。