Tedious: Problema de autenticação do Windows para SQL 2014

Tanto quanto eu posso dizer, as correções que eu fiz ainda não foram lançadas. A mensagem de erro que você está vendo se alinha com o que tentamos conectar aos nossos servidores SQL em um AD com certas restrições de segurança em vigor. Minha primeira tentativa de adicionar suporte a NTLM não levou em conta isso, mas o comportamento recém-mesclado deveria. Você tentou o NPM instalando esta lib do branch master?

Então eu puxei o mais recente do branch master e o compilei localmente, já que o npm realmente deixou de fora a pasta lib - mas ainda sem alegria. Compilei isso com o coffee 1.9, que compilou um pouco diferente do coffee 1.7, que é o que está no npm.

Vou continuar isso daqui a pouco - alguma outra ideia?

Consegui fazer isso funcionar com o SQL Auth no Azure, mas ainda não consegui fazer isso funcionar com o Windows Auth, - tentei com a fonte atual que tem alterações não no npm, mas ainda não estava funcionando, mas pode ser porque da minha falta de experiência com a construção de roteiros de café -

usando o coffee versão 1.9 - executou o seguinte na fonte.
coffee --copile --output lib src e, em seguida, coloque as bibliotecas compiladas no node_modules/tedious, mas ainda não vá -

Você pode tentar a versão 1.10.0?

Estou enfrentando o mesmo problema com a versão mais recente do tedious. Forneci o nome da estação de trabalho, mas ainda recebo o mesmo "O logon é de um domínio não confiável e não pode ser usado com autenticação do Windows".

Há algo que esteja faltando em relação à configuração do domínio que me permita autenticar um usuário de domínio do Windows de um computador que não faz parte do domínio? Estou tentando autenticar um usuário de domínio de uma instância do Ubuntu 14.04 para o SQL Server 2014 no Windows 2012 R2 Server.

@arobson Em outro comentário, você disse que estava enfrentando esse mesmo problema e depois que seu PR foi mesclado, você conseguiu se autenticar com sucesso na produção. Havia algo que você tinha que fazer fora do tedioso?

Você ainda está encontrando esse problema com os últimos lançamentos tediosos?

@arthurschreiber Acabei de tentar e ainda estou com a mensagem "O login é de um domínio não confiável e não pode ser usado com a autenticação do Windows". mensagem de erro.

Parecia que @arobson tinha uma solução, mas não consigo encontrar em lugar nenhum.

Qualquer ajuda sobre quais opções devo usar para conectar à nossa instância do SQL 2014 com credenciais de domínio seria muito apreciada.

Tendo esse problema também. Consigo fazer login com um usuário SQL, mas não com autorização do Windows, infelizmente minha equipe de banco de dados não permitirá um usuário SQL permanente, portanto, ele precisa usar a autenticação do Windows. Estas são minhas opções de configuração:

var configuração = {
servidor: 'SERVERNAME',
nome_do_usuário: usuário',
senha: 'senha',
domínio: 'FQDN.DOMAIN.COM'
,opções: {
depurar: {
pacote: verdade,
dados: verdadeiro,
carga útil: verdadeiro,
token: falso,
registro: verdadeiro
},
banco de dados: 'DB_NAME'
}
};

Este é o erro que estou recebendo:

{ [ConnectionError: Falha no login. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows.]
nome: 'ConnectionError',
mensagem: 'Falha no login. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows.',
código: 'ELOGIN' }
{ [RequestError: Solicitações só podem ser feitas no estado LoggedIn, não no estado SentNTLMResponse]
nome: 'RequestError',
mensagem: 'Solicitações só podem ser feitas no estado LoggedIn, não no estado SentNTLMResponse',
código: 'EINVALIDSTATE' }
{ [ConnectionError: Falha no login. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows.]
nome: 'ConnectionError',
mensagem: 'Falha no login. O login é de um domínio não confiável e não pode ser usado com autenticação do Windows.',
código: 'ELOGIN' }
{ [RequestError: Solicitações só podem ser feitas no estado LoggedIn, não no estado SentNTLMResponse]
nome: 'RequestError',
mensagem: 'Solicitações só podem ser feitas no estado LoggedIn, não no estado SentNTLMResponse',
código: 'EINVALIDSTATE' }

Há algum problema com minha configuração?

Não, eu não acho que seja um problema com sua configuração. Precisarei instalar o SQL Server 2014 na minha máquina e ver o que está causando isso. Talvez algo tenha mudado no esquema de autenticação e ainda não suportamos isso.

Verei o que posso fazer.

@jgornick @stefanTHD - aqui estão algumas peculiaridades que notei em nossos ambientes. O NTLM tem trabalhado para nós a partir de caixas Linux fora do AD em 2012 e 2014, mesmo com políticas muito rígidas em vigor que impedem recursos NTLM menos seguros.

1 - Não use o FQDN na propriedade do domínio. Se for "empresa.com", use "EMPRESA"
2 - A capitalização parece importar também. Tivemos sucesso com nomes de domínio all-cap
3 - _Não_ use um nome de usuário qualificado (ou seja, "[email protected]") apenas "user.name"

Para sua informação

A documentação NTLM é antiga e não é fornecida pela Microsoft. Eu tive que pesquisar muito por certos sinalizadores binários porque o documento que encontrei não explicava para que serviam alguns deles. Meu primeiro PR só funcionou para NTLM contra SQL Server em estações de trabalho para nós porque nosso AD tinha uma política que desabilitava alguns dos recursos do NTLM.

Próximos passos

Se as 3 dicas acima não funcionarem, seria extremamente útil se você pudesse encontrar as entradas de login com falha por meio do Even Viewer / SQL Logs. O "domínio não confiável" é na verdade um erro genérico que o MSFT fornece para dificultar que um invasor saiba por que sua solicitação foi rejeitada. Você pode até pesquisar esse erro no Google e encontrar outras bibliotecas de OSS tentando oferecer suporte ao NTLM reclamando que esse erro é enganoso.

Eu gostaria de ajudá-lo a resolver isso, Tedious é ótimo e as contribuições recentes de @arthurschreiber o tornaram ainda melhor.

A autenticação NTLM é descrita na documentação MS-NLMP da Microsoft. Vou ver se consigo algum tempo para lê-lo e compará-lo com o que foi implementado até agora em tedioso.

@arthurschreiber @arobson OMG finalmente funciona!!! Muito obrigado por seus apoios oportunos!!! Então aqui está minha configuração final:

var config = {
    "userName": "user.name",
    "password": "password",
    "server": "servername",
    "domain": "DOMAIN_NAME_CAPITALIZED_AND_NOT_FQDM",
    "options": {
        "encrypt": false
    }
};

Estou usando o SQL Server 2008 R2 em uma máquina virtual. O script está no mesmo servidor que hospeda o banco de dados.

Seria ótimo se você pudesse adicionar isso a uma documentação em algum lugar

Frio! O fato de a autenticação NTLM não funcionar com criptografia é um bug no código, e fornecerei uma correção em breve (se eu encontrar algum tempo para isso).

De fato, capitalizar o domínio resolve o problema!

https://github.com/pekim/tedious/pull/367 É uma correção para a autenticação NTLM não funcionar com criptografia.

Esta discussão está se referindo ao uso da autenticação do Windows no Linux? Por exemplo Red Hat?

@pisees Sim, estou me conectando do Fedora 22 ao servidor SQL usando o Windows Auth com criptografia com a correção.

Eu tive exatamente o mesmo problema com @NamTThai , e está funcionando agora depois de ler isso e alterar o domínio conforme descrito. (Todos Cap e apenas a primeira parte do domínio, omita a parte após o ponto)

Estou com a Microsoft e procurando ajudar com algumas contribuições tediosas.
Alguma coisa ainda pendente com este problema ou está tudo resolvido?

@tvrprasad Acho que há uma solução alternativa, não tenho certeza se todos entendemos por que a solução alternativa funciona. :)

@benzou A solução alternativa é a descrita por @arobson neste tópico em 15/08?
O que está impedindo que este problema seja encerrado? Talvez eu possa ajudar a fechar isso... de alguma forma :)

@tvrprasad Acho que precisamos de uma documentação melhor sobre isso.

Temos nossa documentação armazenada na ramificação gh-pages deste repositório, mas como ela é mantida fora da base de código, fica desatualizada com bastante facilidade e a manutenção é uma chatice. 😞

@tvrprasad - os problemas que foram relatados como tediosos e para nosso repositório desde que adicionei o suporte NTLM foram consistentemente devido ao domínio ser especificado em minúsculas e/ou como FQDN. Uma solução para isso pode ser acompanhar um PR que:

1. converte o domínio em maiúsculas (eu deveria ter feito isso para começar)
2. divide o domínio em . e usa apenas o primeiro segmento

Certamente não sou um especialista em NTLM, mas somos fãs de MSSQL e Node e realmente precisávamos disso, então mergulhei na documentação NTLM e outras implementações para colocar isso em prática com alguma ajuda de nossa equipe de operações para testar em vários SQL Server versões para que pudéssemos estar relativamente confiantes sobre a implementação. Qualquer análise e melhorias que você possa fornecer sobre o que existe seria incrível. Não há como dizer o que posso ter perdido já que a documentação que segui era de 2007 😄

Deixe-me saber se há perguntas específicas que eu possa responder sobre o bit NTLM.

@arobson - FDQN parece funcionar para mim, mas ainda em maiúsculas. Criei um problema separado para converter em maiúsculas para facilitar o rastreamento - https://github.com/tediousjs/tedious/issues/414. Vou montar um PR para isso. Vou tentar aprender porque minúsculas não funcionam.

@arthurschreiber - Vou tentar ajudar a atualizar a documentação assim que conseguir pelo menos um PR sobre este tópico para que eu tenha uma melhor compreensão. Se houver outras áreas onde a documentação está faltando, me avise. Vou tentar ajudar.

Abri alguns outros problemas relacionados à autenticação. Eu apreciaria pensamentos sobre aqueles.
https://github.com/tediousjs/tedious/issues/415
https://github.com/tediousjs/tedious/issues/416

Pessoal - Eu tenho um PR para implementação da Autenticação Integrada do Windows - https://github.com/tediousjs/tedious/pull/497. Isso não requer nome de usuário ou senha e usa as credenciais de login do usuário.

Se você puder experimentar e dar um feedback, ficarei muito agradecido. Estou ansioso para trabalhar com a comunidade para conseguir o recurso.

ola se alguem puder me ajudar ja tentei conectar no banco de dados MS SQL Server 12 usei mssql node 4.1, ja tentei muita coisa, mas nao conecta

minha conexão está conforme abaixo:

Eu tento:

const stringConnect = 'Servidor = ADMIN-CCE \ admin: 1433; Banco de dados = GRD; ID do usuário = admin-cce \ admin; '
DATABASE.connect (stringConnect)
.then (conn => {
global.conn = conn;
console.log ('conectado ao GRD');
})
.catch (err => console.error ( connection error mssql $ {stringConnect} - $ {err} ));

modulo.exports = BANCO DE DADOS;

* ERRO DE RETORNO**
erro de conexão mssql Servidor = ADMIN-CCE \ admin: 1433; Banco de dados = GRD; ID do usuário = admin-cce \ admin; - ConnectionError: Porta para administrador: 1433 não encontrado em ADMIN-CCE

já tentei outras formas, também sem sucesso! Veja:

var configuração = {
servidor: "ADMIN-CCE\MSSQLSERVER",
banco de dados: "GRD",
porta: 1433,
usuário: 'admin-cce \ admin',
depurar: verdadeiro,
opções: {
criptografar: falso,
trustedConnection: true
}
};

DATABASE.connect (config, function (err) {
se (errar)
{
console.log (erro)
}
outro
console.log('conectado.....')
});

modulo.exports = BANCO DE DADOS;

* ERRO DE RETORNO *
mensagem:
'Falha ao conectar ao ADMIN-CCE: indefinido - Não foi possível conectar (sequência)',
código: 'ESOCKET'},
nome: 'ConnectionError'}

Ei @allexon , tedious ainda não oferece suporte à autenticação integrada do Windows, os detalhes estão em https://github.com/tediousjs/tedious/issues/660.

o tedioso suporta a autenticação do Windows do SQL Server ainda?