Какие порты необходимы для NTLM (аутентификации Windows) для подключения к SQL Server?
У меня есть SQL-сервер, работающий на компьютере, который не находится в домене, и который не работает в смешанном режиме (он работает с "Аутентификацией Windows").
Я пытаюсь подключиться к нему с веб-сервера Linux, работающего на freetds через TCP/IP, используя NTLM для аутентификации.
Брандмауэр на сервере SQL очень ограничен. 1433 открыт для моего веб-сервера, но из Интернета я получаю противоречивую информацию о том, какие дополнительные порты (TCP/UDP) необходимы для успеха NTLM. Это в настоящее время не удается; Я могу говорить на 1433, чтобы запросить NTLM, но фактическая аутентификация всегда терпит неудачу.
В одном источнике говорится о 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
Я пытаюсь подключиться с помощью имени пользователя удаленного компьютера, то есть "имя_сервера \ имя пользователя". В некоторых источниках рекомендуется настроить зеркальные учетные записи на локальных и удаленных компьютерах, но на локальном компьютере работает Linux, а не IIS под Windows.
4 ответа
Единственный порт, который вам нужен, это 1433 как TCP. Этот порт используется дефолтными безымянными экземплярами SQL Server для TCP-соединений. FreeTDS инициирует соединение через этот порт и затем согласовывает проверку подлинности NTLMv2 для этого соединения как серию обменов пакетами запрос / ответ. Afaik нет необходимости в любом другом порту. Смотрите доменные логины.
Все остальные упомянутые порты предназначены для соединений по именованным каналам, и FreeTDS не поддерживает аутентификацию NT по именованным каналам:
Поддержка входа в домен во FreeTDS ограничена стеком сетевых протоколов TCP/IP. FreeTDS в настоящее время не реализует поддержку SQL-соединений на основе именованных каналов, то есть соединений, транспортируемых через интерфейс DCE/RPC, который использует TCP-порт 139, 445 или 135 на машинах Win32, в зависимости от типа инкапсуляции, используемой для DCE/RPC. сам.
Для аутентификации в качестве пользователя домена NT вы должны указать имя пользователя в форме "домен \ пользователь". Если SQL Server работает на автономном компьютере, то "домен" - это имя компьютера.
Если сервер SQL находится в одном месте, обратитесь к поставщику, чтобы убедиться, что его локальный брандмауэр не блокирует порт.
Я не уверен, что вы сможете подключиться к этому серверу, если он не находится в домене и работает только в режиме аутентификации Windows. Какое имя пользователя вы добавили на сервер в качестве логина, и каким пользователем вы вошли как с клиентского компьютера?
135-139 - это порты, используемые для SMB (в основном, иногда 445) и Windows RPC.
1434 UDP будет необходим, только если вы используете браузер SQL для подключения к экземпляру, скажем, в случае именованного экземпляра (SERVERNAME\INSTANCE), но если вы используете (SERVERNAME или SERVERNAME,PORT), и экземпляр наверняка при работе на 1433 дополнительные порты не требуются. Вы можете проверить, открыт ли порт, введя "Telnet SERVERNAME PORT" из командной строки.
Я считаю, что реализация NTLMv2 в FreeTDS 0.82 в лучшем случае глючит. Здесь есть патч. Другой вариант - изменить групповую политику в окнах SQL Server для отправки ответов NTLMv1, как это предлагается в документации.
Вот скриншот того, что вам нужно изменить на Windows Server 2003. Вы влияете на других клиентов, подключающихся к серверу, чтобы убедиться, что вы можете сначала где-нибудь проверить это.
РЕДАКТИРОВАТЬ: Вы пытались включить вход в систему и посмотреть, если вы получаете что-нибудь полезное?