Tedious: Problem mit der Windows-Authentifizierung für SQL 2014

Soweit ich das beurteilen kann, haben es die Korrekturen, die ich PR gemacht habe, noch nicht in eine Veröffentlichung geschafft. Die Fehlermeldung, die Sie sehen, stimmt mit dem überein, was wir beim Versuch erhalten haben, eine Verbindung zu unseren SQL-Servern auf einem AD mit bestimmten Sicherheitseinschränkungen herzustellen. Mein erster Durchgang beim Hinzufügen der NTLM-Unterstützung hat dies nicht berücksichtigt, aber das neu zusammengeführte Verhalten sollte es tun. Haben Sie versucht, NPM diese Bibliothek aus dem Master-Zweig zu installieren?

Also habe ich das Neueste aus dem Master-Zweig eingezogen und lokal kompiliert, da npm den lib-Ordner tatsächlich weggelassen hat - aber immer noch keine Freude. Kompiliert dies mit Kaffee 1.9, der etwas anders kompiliert wurde als Kaffee 1.7, was auf npm ist.

Ich werde dies in Kürze fortsetzen - irgendwelche anderen Ideen?

Ich konnte dies mit SQL Auth auf Azure zum Laufen bringen, aber immer noch nicht mit Windows Auth zum Laufen bringen, - ich habe es mit der aktuellen Quelle versucht, die Änderungen nicht im npm enthält, aber das hat immer noch nicht funktioniert, aber es könnte daran liegen meiner mangelnden Erfahrung mit dem Erstellen von Kaffeeskripten -

unter Verwendung von Kaffee Version 1.9 - lief Folgendes gegen die Quelle.
coffee --copile --output lib src und dann die kompilierten Bibliotheken in node_modules/mühsam ablegen, aber immer noch nicht möglich -

Können Sie die Version 1.10.0 ausprobieren?

Ich habe das gleiche Problem mit der neuesten Version von Tedious. Ich habe den Namen der Arbeitsstation angegeben, erhalte aber immer noch das gleiche "Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden."

Fehlt mir etwas in Bezug auf die Domäneneinrichtung, das es mir ermöglicht, einen Windows-Domänenbenutzer von einem Computer aus zu authentifizieren, der nicht Teil der Domäne ist? Ich versuche, einen Domänenbenutzer von einer Ubuntu 14.04-Instanz bei SQL Server 2014 auf Windows 2012 R2 Server zu authentifizieren.

@arobson In einem anderen Kommentar sagten Sie, dass Sie dasselbe Problem hatten und dass Sie sich nach der Zusammenführung Ihres PR erfolgreich in der Produktion authentifizieren konnten. Gab es etwas, das Sie außerhalb von langweilig tun mussten?

Tritt dieses Problem immer noch bei den neuesten langweiligen Versionen auf?

@arthurschreiber Ich habe es gerade versucht und erlebe immer noch die Meldung "Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden." Fehlermeldung.

Es schien, dass @arobson eine Lösung hatte, aber ich kann sie nirgendwo finden.

Jede Hilfe zu den Optionen, die ich verwenden sollte, um eine Verbindung zu unserer SQL 2014-Instanz mit Domänenanmeldeinformationen herzustellen, wäre sehr willkommen.

Habe dieses Problem auch. Ich kann mich mit einem SQL-Benutzer anmelden, aber nicht mit Windows-Autorisierung. Leider lässt mein DB-Team keinen dauerhaften SQL-Benutzer zu, daher muss es die Windows-Authentifizierung verwenden. Dies sind meine Konfigurationsoptionen:

var config = {
server: 'SERVERNAME',
Benutzername: Benutzer',
Passwort: 'Passwort',
Domäne: 'FQDN.DOMÄNE.COM'
,Optionen: {
debuggen: {
Paket: wahr,
Daten: wahr,
Nutzlast: wahr,
Zeichen: falsch,
log: stimmt
},
Datenbank: 'DB_NAME'
}
};

Dies ist der Fehler, den ich bekomme:

{ [Verbindungsfehler: Anmeldung fehlgeschlagen. Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden.]
name: 'Verbindungsfehler',
Meldung: „Anmeldung fehlgeschlagen. Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden.',
Code: 'ELOGIN' }
{ [RequestError: Requests can only be made in the LoggedIn state, not the SentNTLMResponse state]
name: 'Anforderungsfehler',
Nachricht: 'Anfragen können nur im LoggedIn-Zustand gestellt werden, nicht im SentNTLMResponse-Zustand',
Code: 'INVALIDSTATE' }
{ [Verbindungsfehler: Anmeldung fehlgeschlagen. Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden.]
name: 'Verbindungsfehler',
Meldung: „Anmeldung fehlgeschlagen. Die Anmeldung stammt von einer nicht vertrauenswürdigen Domäne und kann nicht mit der Windows-Authentifizierung verwendet werden.',
Code: 'ELOGIN' }
{ [RequestError: Requests can only be made in the LoggedIn state, not the SentNTLMResponse state]
name: 'Anforderungsfehler',
Nachricht: 'Anfragen können nur im LoggedIn-Zustand gestellt werden, nicht im SentNTLMResponse-Zustand',
Code: 'INVALIDSTATE' }

Gibt es ein Problem mit meiner Konfiguration?

Nein, ich glaube nicht, dass es an deiner Konfiguration liegt. Ich muss SQL Server 2014 auf meinem Computer installieren und sehen, was dies verursacht. Vielleicht hat sich etwas im Authentifizierungsschema geändert und wir unterstützen das noch nicht.

Ich sehe was ich tun kann.

@jgornick @stefanTHD - hier sind ein paar Macken, die mir in unserer Umgebung aufgefallen sind. NTLM hat für uns von Linux-Boxen außerhalb des AD gegen 2012 und 2014 gearbeitet, selbst mit sehr strengen Richtlinien, die weniger sichere NTLM-Funktionen verhindern.

1 – Verwenden Sie den FQDN nicht in der Domäneneigenschaft. Wenn es "company.com" ist, verwenden Sie "COMPANY".
2 - Die Großschreibung scheint auch eine Rolle zu spielen. Wir hatten Erfolg mit All-Cap-Domainnamen
3 - _Verwenden Sie keinen qualifizierten Benutzernamen (z. B. "[email protected]"), sondern nur "user.name".

FYI

Die NTLM-Dokumentation ist alt und wird nicht von Microsoft bereitgestellt. Ich musste viel nach bestimmten binären Flags suchen, weil das Dokument, das ich fand, nicht erklärte, wofür einige von ihnen waren. Mein erster PR funktionierte nur für NTLM gegen SQL Server auf Arbeitsstationen für uns, weil unser AD eine Richtlinie hatte, die einige der NTLM-Funktionen deaktivierte.

Nächste Schritte

Wenn die 3 obigen Tipps nicht funktionieren, wäre es enorm hilfreich, wenn Sie die fehlgeschlagenen Anmeldeeinträge über Even Viewer / SQL Logs finden könnten. Die „nicht vertrauenswürdige Domäne“ ist eigentlich ein generischer Fehler, den MSFT bereitstellt, um es einem Angreifer zu erschweren, herauszufinden, warum seine Anfrage abgelehnt wurde. Sie können sogar nach diesem Fehler googeln und andere OSS-Bibliotheken finden, die versuchen, NTLM zu unterstützen, und sich darüber beschweren, dass dieser Fehler irreführend ist.

Ich möchte Ihnen helfen, dies zu lösen, Tedious ist großartig und die jüngsten Beiträge von @arthurschreiber haben es noch besser gemacht.

Die NTLM-Authentifizierung ist in der MS-NLMP -Dokumentation von Microsoft beschrieben. Ich werde sehen, ob ich etwas Zeit finde, es durchzulesen und es mit dem zu vergleichen, was bisher in mühsam implementiert wurde.

@arthurschreiber @arobson OMG es funktioniert endlich!!! Vielen Dank für Ihre rechtzeitige Unterstützung!!! Hier also meine endgültige Konfiguration:

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

Ich verwende SQL Server 2008 R2 auf einer virtuellen Maschine. Das Skript befindet sich auf demselben Server, der die Datenbank hostet.

Es wäre toll, wenn Sie dies irgendwo in eine Dokumentation einfügen könnten

Cool! Die Tatsache, dass die NTLM-Authentifizierung nicht mit Verschlüsselung funktioniert, ist ein Fehler im Code, und ich werde bald einen Fix bereitstellen (wenn ich etwas Zeit dafür finde).

In der Tat löst die Großschreibung der Domain das Problem!

https://github.com/pekim/tedious/pull/367 Ist ein Fix für die NTLM-Authentifizierung, die nicht mit Verschlüsselung funktioniert.

Bezieht sich diese Diskussion auf die Verwendung der Windows-Authentifizierung unter Linux? Zum Beispiel RedHat?

@pisees Ja, ich verbinde mich von Fedora 22 mit dem SQL-Server über Windows Auth mit Verschlüsselung mit dem Fix.

Ich hatte genau das gleiche Problem mit @NamTThai und es funktioniert jetzt, nachdem ich dies gelesen und die Domain wie beschrieben geändert habe. (Alle Großbuchstaben und nur der erste Teil der Domäne, lassen Sie den Teil nach dem Punkt weg)

Ich bin bei Microsoft und suche nach Hilfe mit einigen Beiträgen zu mühsam.
Ist bei diesem Problem noch etwas offen oder ist alles gelöst?

@tvrprasad Ich denke, es gibt eine Problemumgehung, ich bin mir nicht sicher, ob wir alle verstehen, warum die Problemumgehung funktioniert. :)

@benzou Ist die Problemumgehung die von @arobson in diesem Thread am 15. August beschriebene?
Was verhindert, dass dieses Problem geschlossen wird? Vielleicht kann ich helfen, das zu schließen ... irgendwie :)

@tvrprasad Ich denke, wir brauchen diesbezüglich eine bessere Dokumentation.

Wir haben unsere Dokumentation im gh-pages -Zweig dieses Repositorys gespeichert, aber da sie außerhalb der Codebasis gepflegt wird, veraltet sie ziemlich leicht und die Wartung ist mühsam. 😞

@tvrprasad - Die Probleme, die zu langwierig und zu unserem Repository gemeldet wurden, seit ich NTLM-Unterstützung hinzugefügt habe, waren durchweg darauf zurückzuführen, dass die Domäne in Kleinbuchstaben und/oder als FQDN angegeben wurde. Eine Lösung dafür könnte eine PR sein, die:

1. wandelt die Domain in Großbuchstaben um (das hätte ich gleich am Anfang machen sollen)
2. teilt die Domain auf . und verwendet nur das erste Segment

Ich bin sicherlich kein NTLM-Experte, aber wir sind Fans von MSSQL und Node und brauchten das wirklich, also habe ich mich mit der NTLM-Dokumentation und anderen Implementierungen beschäftigt, um dies mit etwas Hilfe von unserem Betriebsteam zum Testen gegen eine Reihe von SQL Servern einzurichten Versionen, sodass wir bezüglich der Implementierung relativ zuversichtlich sein konnten. Alle Analysen und Verbesserungen, die Sie gegenüber dem, was vorhanden ist, bereitstellen könnten, wären großartig. Es ist nicht abzusehen, was ich vielleicht übersehen habe, da die Dokumentation, der ich gefolgt bin, aus dem Jahr 2007 stammt 😄

Lassen Sie mich wissen, wenn es spezifische Fragen gibt, die ich zum NTLM-Bit beantworten kann.

@arobson - FDQN scheint für mich zu funktionieren, allerdings immer noch nur in Großbuchstaben. Ich habe ein separates Problem erstellt, um es zur einfachen Nachverfolgung in Großbuchstaben umzuwandeln - https://github.com/tediousjs/tedious/issues/414. Ich werde dafür eine PR erstellen. Ich werde versuchen herauszufinden, warum Kleinbuchstaben nicht funktionieren.

@arthurschreiber - Ich werde versuchen, dabei zu helfen, die Dokumentation auf den neuesten Stand zu bringen, sobald ich in der Lage bin, mindestens eine PR zu diesem Thema durchzubringen, damit ich ein besseres Verständnis habe. Wenn es andere Bereiche gibt, in denen die Dokumentation fehlt, lassen Sie es mich wissen. Ich werde versuchen zu helfen.

Ich habe ein paar andere Probleme im Zusammenhang mit der Authentifizierung geöffnet. Ich würde mich über Gedanken dazu freuen.
https://github.com/tediousjs/tedious/issues/415
https://github.com/tediousjs/tedious/issues/416

Leute – ich habe eine PR für die Implementierung der integrierten Windows-Authentifizierung veröffentlicht – https://github.com/tediousjs/tedious/pull/497. Dies erfordert keinen Benutzernamen oder Passwort und verwendet die Anmeldeinformationen des Benutzers.

Wenn Sie in der Lage sind, es auszuprobieren und Feedback zu geben, würde ich es sehr schätzen. Ich freue mich darauf, mit der Community zusammenzuarbeiten, um das Feature an Land zu ziehen.

Hallo, wenn mir jemand helfen kann, ich habe versucht, eine Verbindung in MS SQL Server-Datenbank 12 zu verwenden, mssql-Knoten 4.1, ich habe schon viel ausprobiert, aber keine Verbindung

Meine Verbindung hat es unten angepasst:

Ich versuche:

const stringConnect = 'Server = ADMIN-CCE \ admin: 1433; Datenbank = GRD; Benutzer-ID = admin-cce \ admin; '
DATABASE.connect (stringConnect)
.then (conn => {
global.conn = conn;
console.log ('verbunden mit dem GRD');
})
.catch (err => Konsole.Fehler ( connection error mssql $ {stringConnect} - $ {err} ));

module.exports = DATENBANK;

* RÜCKGABEFEHLER **
mssql-Verbindungsfehler Server = ADMIN-CCE \ admin: 1433; Datenbank = GRD; Benutzer-ID = admin-cce \ admin; - ConnectionError: Port für Admin: 1433 nicht in ADMIN-CCE gefunden

habe auch schon andere möglichkeiten probiert, ebenfalls ohne erfolg! Aussehen:

var config = {
server: "ADMIN-CCE\MSSQLSERVER",
Datenbank: "GRD",
Hafen: 1433,
Benutzer: 'admin-cce \ admin',
Debuggen: wahr,
Optionen: {
verschlüsseln: falsch,
TrustedConnection: wahr
}
};

DATABASE.connect (config, function (err) {
wenn (irr)
{
console.log (err)
}
anders
console.log ('verbunden .....')
});

module.exports = DATENBANK;

* FEHLER ZURÜCKGEBEN *
Botschaft:
'Verbindung zu ADMIN-CCE fehlgeschlagen: undefiniert - Verbindung konnte nicht hergestellt werden (Sequenz)',
code: 'ESOCKET'},
name: 'Verbindungsfehler'}

Hey @allexon , tedious unterstützt die integrierte Windows-Authentifizierung noch nicht, Details finden Sie unter https://github.com/tediousjs/tedious/issues/660.

unterstützt langweilig die SQL-Server-Windows-Authentifizierung noch?