Tedious: Problème d'authentification Windows à SQL 2014

Autant que je sache, les correctifs que j'ai PR n'ont pas encore été intégrés dans une version. Le message d'erreur que vous voyez correspond à ce que nous avons obtenu en essayant de nous connecter à nos serveurs SQL sur un AD avec certaines restrictions de sécurité en place. Ma première tentative d'ajout de la prise en charge de NTLM n'en tenait pas compte, mais le comportement nouvellement fusionné devrait le faire. Avez-vous essayé NPM d'installer cette bibliothèque à partir de la branche principale ?

J'ai donc récupéré la dernière version de la branche master et l'ai compilée localement puisque npm a en fait laissé de côté le dossier lib - mais toujours pas de joie. Compilé avec coffee 1.9 qui a compilé un peu différemment de coffee 1.7 qui est sur npm.

Je vais continuer cela dans un peu - avez-vous d'autres idées ?

J'ai pu faire fonctionner cela avec SQL Auth sur Azure, mais toujours incapable de faire fonctionner cela avec Windows Auth, - j'ai essayé avec la source actuelle qui n'a pas changé dans le npm, mais cela ne fonctionnait toujours pas mais cela pourrait être parce que de mon manque d'expérience dans la création de scripts de café -

en utilisant la version 1.9 de café - a exécuté ce qui suit contre la source.
coffee --copile --output lib src puis mettez les bibliothèques compilées en place dans le node_modules/tedious mais toujours pas -

Pouvez-vous essayer la version 1.10.0 ?

Je rencontre le même problème avec la dernière version de fastidieux. J'ai fourni le nom du poste de travail, mais j'obtiens toujours le même "La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows."

Y a-t-il quelque chose qui me manque concernant la configuration du domaine qui me permettra d'authentifier un utilisateur de domaine Windows à partir d'un ordinateur ne faisant pas partie du domaine ? J'essaie d'authentifier un utilisateur de domaine à partir d'une instance Ubuntu 14.04 vers SQL Server 2014 sur Windows 2012 R2 Server.

@arobson Dans un autre commentaire, vous avez dit que vous rencontriez ce même problème et qu'après la fusion de votre PR, vous avez pu vous authentifier avec succès en production. Y avait-il quelque chose que vous deviez faire en dehors de fastidieux ?

Rencontrez-vous toujours ce problème avec les dernières versions fastidieuses ?

@arthurschreiber Je viens d'essayer et je rencontre toujours le "La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows." Message d'erreur.

Il semblait que @arobson avait une solution, mais je ne la trouve nulle part.

Toute aide sur les options que je devrais utiliser pour me connecter à notre instance SQL 2014 avec des informations d'identification de domaine serait grandement appréciée.

Ayant également ce problème. Je peux me connecter avec un utilisateur SQL, mais pas avec l'autorisation Windows. Malheureusement, mon équipe de base de données n'autorisera pas un utilisateur SQL permanent, elle doit donc utiliser l'authentification Windows. Voici mes options de configuration :

var config = {
serveur : 'SERVERNAME',
nom d'utilisateur : utilisateur',
mot de passe : 'mot de passe',
domaine : 'FQDN.DOMAIN.COM'
,options : {
déboguer : {
paquet : vrai,
données : vrai,
charge utile : vrai,
jeton : faux,
journal : vrai
},
base de données : 'DB_NAME'
}
} ;

C'est l'erreur que j'obtiens:

{ [ConnectionError : Échec de la connexion. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows.]
nom : 'Erreur de connexion',
message : 'Connexion échouée. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows.',
code : 'ELOGIN' }
{ [RequestError : les requêtes ne peuvent être effectuées qu'à l'état LoggedIn, pas à l'état SentNTLMResponse]
nom : 'DemandeErreur',
message : 'Les requêtes ne peuvent être effectuées qu'à l'état LoggedIn, pas à l'état SentNTLMResponse',
code : 'INVALIDSTATE' }
{ [ConnectionError : Échec de la connexion. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows.]
nom : 'Erreur de connexion',
message : 'Connexion échouée. La connexion provient d'un domaine non approuvé et ne peut pas être utilisée avec l'authentification Windows.',
code : 'ELOGIN' }
{ [RequestError : les requêtes ne peuvent être effectuées qu'à l'état LoggedIn, pas à l'état SentNTLMResponse]
nom : 'DemandeErreur',
message : 'Les requêtes ne peuvent être effectuées qu'à l'état LoggedIn, pas à l'état SentNTLMResponse',
code : 'INVALIDSTATE' }

Y a-t-il un problème avec ma config ?

Non, je ne pense pas que ce soit un problème avec votre configuration. Je dois installer SQL Server 2014 sur ma machine et voir ce qui en est la cause. Peut-être que quelque chose a changé dans le schéma d'authentification et que nous ne le prenons pas encore en charge.

Je vais voir ce que je peux faire.

@jgornick @stefanTHD - voici quelques bizarreries que j'ai remarquées dans nos environnements. NTLM a travaillé pour nous à partir de machines Linux en dehors de l'AD par rapport à 2012 et 2014, même avec des politiques très strictes en place qui empêchent les fonctionnalités NTLM moins sécurisées.

1 - N'utilisez pas le FQDN dans la propriété du domaine. S'il s'agit de "company.com", utilisez "COMPANY"
2 - La capitalisation semble également avoir de l'importance. Nous avons eu du succès avec les noms de domaine en majuscules
3 - _N'utilisez pas_ de nom d'utilisateur qualifié (c'est-à-dire "[email protected]") uniquement "nom.utilisateur"

pour votre information

La documentation NTLM est ancienne et n'est pas fournie par Microsoft. J'ai dû faire beaucoup de recherche pour certains drapeaux binaires parce que la doc que j'ai trouvée n'expliquait pas à quoi servaient certains d'entre eux. Mon premier PR n'a fonctionné que pour NTLM contre SQL Server sur les postes de travail pour nous parce que notre AD avait une politique qui désactivait certaines des fonctionnalités de NTLM.

Prochaines étapes

Si les 3 conseils ci-dessus ne fonctionnent pas, il serait extrêmement utile que vous puissiez trouver les entrées de connexion ayant échoué via Even Viewer / SQL Logs. Le "domaine non approuvé" est en fait une erreur générique fournie par MSFT pour rendre plus difficile pour un attaquant de savoir pourquoi sa demande a été rejetée. Vous pouvez même rechercher cette erreur sur Google et trouver d'autres bibliothèques OSS essayant de prendre en charge NTLM en se plaignant que cette erreur est trompeuse.

J'aimerais vous aider à résoudre ce problème, Tedious est génial et les récentes contributions de @arthurschreiber l'ont rendu encore meilleur.

L'authentification NTLM est décrite dans la documentation MS-NLMP de Microsoft. Je vais voir si je peux trouver un peu de temps pour le lire et le comparer avec ce qui est mis en œuvre jusqu'à présent en fastidieux.

@arthurschreiber @arobson OMG ça marche enfin !!! Merci beaucoup les gars pour votre soutien opportun !!! Voici donc ma configuration finale :

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

J'utilise SQL Server 2008 R2 sur une machine virtuelle. Le script se trouve sur le même serveur qui héberge la base de données.

Ce serait formidable si vous pouviez ajouter ceci à une documentation quelque part

Frais! Le fait que l'authentification NTLM ne fonctionne pas avec le cryptage est un bogue dans le code, et je fournirai bientôt un correctif (si je peux trouver du temps pour cela).

En effet, capitaliser le domaine résout le problème !

https://github.com/pekim/tedious/pull/367 Est un correctif pour l'authentification NTLM qui ne fonctionne pas avec le cryptage.

Cette discussion fait-elle référence à l'utilisation de l'authentification Windows à partir de Linux ? Par exemple Red Hat ?

@pisees Oui, je me connecte de Fedora 22 au serveur SQL en utilisant Windows Auth avec cryptage avec le correctif.

J'ai eu exactement le même problème avec @NamTThai , et cela fonctionne maintenant après avoir lu ceci et changé le domaine comme décrit. (Tout en majuscule et seulement la première partie du domaine, omettre la partie après le point)

Je suis avec Microsoft et je cherche à aider avec quelques contributions à fastidieux.
Quelque chose reste en suspens avec ce problème ou est-ce que tout est résolu ?

@tvrprasad Je pense qu'il existe une solution de contournement, je ne suis pas sûr que nous comprenions tous pourquoi la solution de contournement fonctionne. :)

@benzou La solution de contournement est-elle celle décrite par @arobson dans ce fil le 15/08 ?
Qu'est-ce qui empêche la fermeture de ce problème ? Peut-être que je peux aider à fermer ça... d'une manière ou d'une autre :)

@tvrprasad Je pense que nous avons besoin d'une meilleure documentation à ce sujet.

Nous avons notre documentation stockée dans la branche gh-pages de ce dépôt, mais comme elle est maintenue en dehors de la base de code, elle devient assez facilement obsolète et la maintenance est un frein. 😞

@tvrprasad - les problèmes qui ont été signalés à fastidieux et à notre référentiel depuis que j'ai ajouté le support NTLM, ont toujours été dus au fait que le domaine était spécifié en minuscules et/ou en tant que FQDN. Une solution pour cela pourrait être de suivre un PR qui :

1. convertit le domaine en majuscule (j'aurais dû le faire pour commencer)
2. divise le domaine sur . et n'utilise que le premier segment

Je ne suis certainement pas un expert NTLM, mais nous sommes fans de MSSQL et de Node et nous en avions vraiment besoin. J'ai donc plongé dans la documentation NTLM et d'autres implémentations pour mettre cela en place avec l'aide de notre équipe d'exploitation pour tester un certain nombre de SQL Server. versions afin que nous puissions être relativement confiants quant à la mise en œuvre. Toute analyse et amélioration que vous pouvez fournir par rapport à ce qui existe serait géniale. On ne sait pas ce que j'ai pu manquer puisque la documentation que j'ai suivie date de 2007 😄

Faites-moi savoir s'il y a des questions spécifiques auxquelles je peux répondre sur le bit NTLM.

@arobson - FDQN semble fonctionner pour moi, toujours en majuscules. J'ai créé un problème séparé à convertir en majuscules pour un suivi facile - https://github.com/tediousjs/tedious/issues/414. Je ferai un PR pour ça. Je vais essayer de comprendre pourquoi les minuscules ne fonctionnent pas.

@arthurschreiber - J'essaierai d'aider à mettre à jour la documentation une fois que je pourrai obtenir au moins un PR sur ce sujet afin que j'aie une meilleure compréhension. S'il y a d'autres domaines où la documentation fait défaut, faites-le moi savoir. Je vais essayer d'aider.

J'ai ouvert quelques autres problèmes liés à l'authentification. J'apprécierais des réflexions à ce sujet.
https://github.com/tediousjs/tedious/issues/415
https://github.com/tediousjs/tedious/issues/416

Gens - J'ai un PR pour la mise en œuvre de l'authentification intégrée Windows - https://github.com/tediousjs/tedious/pull/497. Cela ne nécessite pas de nom d'utilisateur ou de mot de passe et utilise les informations de connexion de l'utilisateur.

Si vous êtes en mesure de l'essayer et de donner votre avis, je l'apprécierai beaucoup. J'ai hâte de travailler avec la communauté pour décrocher la fonctionnalité.

bonjour si quelqu'un peut m'aider j'ai essayé de me connecter dans la base de données MS SQL Server 12 utilisé le nœud mssql 4.1, j'ai déjà essayé beaucoup de chose, mais ne se connecte pas

ma connexion l'a conforme ci-dessous:

J'essaye:

const stringConnect = 'Serveur = ADMIN-CCE \ admin : 1433; Base de données = GRD ; ID utilisateur = admin-cce \ admin ; '
DATABASE.connect (stringConnect)
.alors (conn => {
global.conn = conn;
console.log ('connecté au GRD');
})
.catch (err => console.error ( connection error mssql $ {stringConnect} - $ {err} ));

module.exports=BASE DE DONNEES;

* ERREUR DE RETOUR **
erreur de connexion mssql Serveur = ADMIN-CCE \ admin : 1433 ; Base de données = GRD ; ID utilisateur = admin-cce \ admin ; - ConnectionError : Port pour l'administrateur : 1433 introuvable dans ADMIN-CCE

déjà essayé d'autres moyens, également sans succès! Voir:

var config = {
serveur : "ADMIN-CCE\MSSQLSERVER",
base de données : "GRD",
port : 1433,
utilisateur : 'admin-cce\admin',
débogage : vrai,
option : {
chiffrer : faux,
Connexion de confiance : vrai
}
} ;

DATABASE.connect (config, fonction (err) {
si (erreur)
{
console.log (erreur)
}
autre
console.log ('connecté .....')
});

module.exports=BASE DE DONNEES;

* RENVOIE ERREUR *
un message:
'Échec de connexion à ADMIN-CCE : non défini - Impossible de se connecter (séquence)',
code : 'ESOCKET'},
nom : 'Erreur de connexion'}

Hey @allexon , tedious ne prend pas encore en charge l'authentification intégrée Windows, les détails sont dans https://github.com/tediousjs/tedious/issues/660.

est-ce que fastidieux prend encore en charge l'authentification Windows du serveur SQL ?