NTLM（Windows認証）がSQL Serverに接続するには、どのポートが必要ですか？
ドメインでnotであり、混合モードで動作するnotであるマシンでSQLサーバーを実行しています（ "Windows認証"で実行しています）。
NTLMを使用して認証し、TCP/IPを介してfreetdsを実行しているLinux Webサーバーからそれに接続しようとしています。
SQLサーバーのファイアウォールは非常に制限されています。 1433は私のWebサーバーに対して開いていますが、NTLMが成功するために必要な追加のポート（TCP/UDP）について、Webから矛盾する情報を取得しています。現在は失敗しています。 1433でNTLMを要求することはできますが、実際の認証は常に失敗します。
1つのソースは137、138、139と言っていますが、これらは単なるNetBIOSポートです。本当に必要ですか？別の情報源は135と言っています。さらに別の情報源は1434と言っているようです。私はプログラマーであり、ネットワーク管理者ではありません！
編集：
正確なエラーメッセージ：
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
リモートマシンのユーザー名、つまり「servername\username」で接続しようとしています。一部のソースでは、ローカルマシンとリモートマシンにミラー化されたアカウントを設定することを推奨していますが、ローカルマシンはLinuxではなく、IIS Windowsでは実行されています。
必要な唯一のポートは、TCPとして1433です。これは、デフォルトの名前のないSQL ServerインスタンスがTCP接続用に使用するポートです。FreeTDSはこのポートで接続を開始し、一連のチャレンジとしてこの接続でNTLMv2認証をネゴシエートします。応答パケット交換。Afaikには他のポートは必要ありません。 ドメインログイン を参照してください。
あなたが言及する他のすべてのポートは名前付きパイプ接続用であり、FreeTDSは名前付きパイプ経由のNT認証をサポートしていません。
FreeTDSでのドメインログインのサポートは、TCP/IPネットワークプロトコルスタックに限定されています。 FreeTDSは現在、名前付きパイプベースのSQL接続のサポートを実装していません。つまり、Win32マシンでTCPポート139、445、または135を使用するDCE/RPCインターフェイスを介して転送される接続は、 DCE/RPC自体に使用されるカプセル化のタイプ。
NTドメインユーザーとして認証するには、「ドメイン\ユーザー」の形式でユーザー名を指定する必要があります。 SQL Serverがスタンドアロンコンピュータで実行されている場合、「ドメイン」はコンピュータ名です。
FreeTDS 0.82でのNTLMv2実装は、せいぜいバグが多いと思います。 ここにパッチ があります他のオプションは、ドキュメントで提案されているように、NTLMv1応答を送信するようにSQL Serverのウィンドウのグループポリシーを変更することです。
これは、Windows Server 2003で変更する必要があるものの スクリーンショット です。サーバーに接続している他のクライアントに影響を与え、これを最初にどこかでテストできることを確認します。
編集： ロギングをオンにする を試してみましたか？何か有用なものがあるかどうかを確認しますか？
SQLサーバーが同じ場所に配置されている場合は、コロケーションプロバイダーに連絡して、ローカルファイアウォールがポートをブロックしていないことを確認してください。
このサーバーがドメイン内になく、Windows認証モードでのみ実行されている場合に、このサーバーに接続できるかどうかはわかりません。ログインとしてサーバーに追加したユーザー名と、クライアントマシンからログインしたユーザーを教えてください。
135-139は、SMB（ほとんどの場合、445）とWindows RPCで使用されるポートです。
1434 UDPは、SQLブラウザーを使用してインスタンスに接続している場合（名前付きインスタンス（SERVERNAME\INSTANCE）の場合など）にのみ必要ですが、（SERVERNAMEまたはSERVERNAME、PORT）を使用しており、インスタンスが確実である場合1433で実行している場合、追加のポートは必要ありません。コマンドプロンプトから「telnet SERVERNAME PORT」を発行して、ポートが開いているかどうかをテストできます。