Quais portas são necessárias para o NTLM (Autenticação do Windows) para se conectar ao SQL Server?

Question

Tenho o SQL Server em execução em uma máquina que não é em um domínio e que não está operando no modo misto (ele está sendo executado com "Windows Authentication" ).

Estou tentando conectar-me a ele a partir de um servidor da web Linux executando o freetds via TCP / IP, usando o NTLM para autenticar.

O firewall no servidor SQL é muito restritivo. O 1433 está aberto para o meu servidor web, mas estou recebendo informações conflitantes da Web sobre quais portas adicionais (TCP / UDP) são necessárias para que o NTLM seja bem-sucedido. Atualmente está falhando; Eu posso falar em 1433 para solicitar o NTLM, mas a autenticação real sempre falha.

Uma fonte diz 137, 138, 139, mas essas são apenas as portas NetBIOS. Eu realmente preciso disso? Outra fonte diz 135. Outros ainda parecem dizer 1434 ... Eu não posso fazer cara ou coroa disso. Maldito Jim, eu sou um programador, não um administrador de rede!

EDITAR:

A mensagem de erro exata:

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

Estou tentando conectar-me a um nome de usuário da máquina remota, por exemplo, 'servername \ username'. Algumas fontes recomendam que eu configure contas espelhadas nas máquinas locais e remotas, mas a máquina local está executando o Linux, não o IIS no Windows.

    

Answer 1

A única porta que você precisa é 1433 como TCP. Esta é a porta usada por instâncias defasadas e não nomeadas do SQL Server para conexões TCP. O FreeTDS iniciará uma conexão nessa porta e, em seguida, negociará uma autenticação NTLMv2 nessa conexão, como uma série de trocas de pacotes de desafio / resposta. Afaik não há necessidade de qualquer outro porto. Consulte Login de domínio .

Todas as outras portas mencionadas são para conexões de Pipes Nomeados e o FreeTDS não suporta a autenticação NT sobre pipes nomeados:

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.

Para autenticar como um usuário de domínio do NT, você deve especificar um nome de usuário no formulário 'domínio \ usuário'. Se o SQL Server for executado em um computador autônomo, 'domain' é o nome do computador.

    

Answer 2

Não tenho certeza se você conseguirá se conectar a esse servidor se não estiver em um domínio e estiver sendo executado apenas no modo de autenticação do Windows. Qual nome de usuário você adicionou ao servidor como um login e em qual usuário você efetuou login a partir da máquina cliente?

135-139 são as portas usadas para SMB (principalmente, às vezes 445) e Windows RPC.

1434 O UDP só será necessário se você estiver usando o Navegador SQL para se conectar à instância, por exemplo, no caso de uma instância nomeada (SERVERNAME \ INSTANCE), mas se estiver usando (SERVERNAME ou SERVERNAME, PORT) e a instância é com certeza rodando em 1433, então nenhuma porta adicional seria necessária. Você pode testar para ver se a porta está aberta emitindo "telnet SERVERNAME PORT" em um prompt de comando.

    

Answer 3

Acredito que a implementação do NTLMv2 no FreeTDS 0.82 seja um buggy na melhor das hipóteses. Existe um patch aqui Sua outra opção é alterar a política de grupo nas janelas do SQL Server para enviar respostas NTLMv1, conforme sugerido na documentação.

Aqui está uma captura de tela do que você precisa alterar no Windows Server 2003. Você faz afetando outros clientes se conectando ao servidor para ter certeza de que você pode testar isso em algum lugar primeiro.

EDIT: Você tentou ativar o login & ver se você consegue alguma coisa útil?

    

Answer 4

Se o servidor SQL estiver localizado, entre em contato com o provedor de colocation para verificar se o firewall local também não está bloqueando a porta.