Tedious: Проблема с проверкой подлинности Windows для SQL 2014

Насколько я могу судить, исправления, которые я пиарил, еще не вошли в релиз. Сообщение об ошибке, которое вы видите, совпадает с тем, что мы получили, пытаясь подключиться к нашим SQL-серверам в AD с определенными ограничениями безопасности. Мой первый проход по добавлению поддержки NTLM не учитывал этого, но поведение нового слияния должно. Вы пробовали NPM установить эту библиотеку из основной ветки?

Итак, я вытащил последнюю версию из ветки master и скомпилировал ее локально, поскольку npm фактически не включал папку lib, но все равно без радости. Скомпилировал это с coffee 1.9, который скомпилировался немного иначе, чем coffee 1.7, который находится на npm.

Я продолжу это через некоторое время - есть другие идеи?

Я смог заставить это работать с SQL Auth в Azure, но все еще не смог заставить это работать с Windows Auth, - я попытался с текущим источником, который имеет изменения не в npm, но это все еще не работает, но это может быть потому из-за отсутствия у меня опыта создания сценариев для кофе -

используя версию кофе 1.9 - выполнил следующее против источника.
coffee --copile --output lib src , а затем поместите скомпилированные библиотеки на место в node_modules/утомительно, но все равно не идет -

Вы можете попробовать версию 1.10.0?

У меня такая же проблема с последней версией tedious. Я указал имя рабочей станции, но все равно получаю то же самое: «Логин из ненадежного домена и не может использоваться с проверкой подлинности Windows».

Есть ли что-то, что мне не хватает в настройке домена, что позволит мне аутентифицировать пользователя домена Windows с компьютера, не входящего в домен? Я пытаюсь аутентифицировать пользователя домена с экземпляра Ubuntu 14.04 на SQL Server 2014 на сервере Windows 2012 R2.

@arobson В другом комментарии вы сказали, что столкнулись с той же проблемой, и после того, как ваш PR был объединен, вы смогли успешно пройти аутентификацию в рабочей среде. Было ли что-то, что вам нужно было сделать помимо утомительного?

Вы все еще сталкиваетесь с этой проблемой с последними утомительными выпусками?

@arthurschreiber Я только что попробовал, и все еще сталкиваюсь с сообщением «Вход в систему из ненадежного домена и не может использоваться с проверкой подлинности Windows». сообщение об ошибке.

Казалось, что у @arobson есть решение, но я нигде не могу его найти.

Будем очень признательны за любую помощь в том, какие параметры я должен использовать для подключения к нашему экземпляру SQL 2014 с учетными данными домена.

Имея эту проблему, а также. Я могу войти в систему с пользователем SQL, но не с авторизацией Windows, к сожалению, моя команда db не разрешает постоянному пользователю SQL, поэтому необходимо использовать аутентификацию Windows. Это мои параметры конфигурации:

переменная конфига = {
сервер: 'ИМЯ_СЕРВЕРА',
имя_пользователя: пользователь',
пароль: 'пароль',
домен: 'FQDN.DOMAIN.COM'
,опции: {
отладка: {
пакет: правда,
данные: правда,
полезная нагрузка: правда,
токен: ложь,
журнал: правда
},
база данных: 'DB_NAME'
}
};

Это ошибка, которую я получаю:

{ [ConnectionError: Ошибка входа. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows.]
имя: 'ConnectionError',
сообщение: «Войти не удалось. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows.',
код: 'ЭЛОГИН' }
{ [RequestError: запросы можно делать только в состоянии LoggedIn, а не в состоянии SentNTLMResponse]
имя: 'RequestError',
сообщение: «Запросы могут быть сделаны только в состоянии LoggedIn, а не в состоянии SentNTLMResponse»,
код: 'EINVALIDSTATE' }
{ [ConnectionError: Ошибка входа. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows.]
имя: 'ConnectionError',
сообщение: «Войти не удалось. Логин относится к ненадежному домену и не может использоваться с проверкой подлинности Windows.',
код: 'ЭЛОГИН' }
{ [RequestError: запросы можно делать только в состоянии LoggedIn, а не в состоянии SentNTLMResponse]
имя: 'RequestError',
сообщение: «Запросы могут быть сделаны только в состоянии LoggedIn, а не в состоянии SentNTLMResponse»,
код: 'EINVALIDSTATE' }

Есть ли проблема с моей конфигурацией?

Нет, я не думаю, что это проблема с вашей конфигурацией. Мне нужно установить SQL Server 2014 на мою машину и посмотреть, что вызывает это. Возможно, что-то изменилось в схеме аутентификации, и мы пока это не поддерживаем.

Я посмотрю что я могу сделать.

@jgornick @stefanTHD — вот несколько странностей, которые я заметил в нашей среде. NTLM работал на нас из ящиков Linux за пределами AD по сравнению с 2012 и 2014 годами, даже с очень строгими политиками, запрещающими менее безопасные функции NTLM.

1. Не используйте полное доменное имя в свойстве домена. Если это "company.com", используйте "COMPANY"
2 - Капитализация тоже имеет значение. Мы добились успеха с доменными именами с заглавными буквами
3 - _Не_ используйте полное имя пользователя (например, "[email protected]"), просто "user.name"

к вашему сведению

Документация по NTLM устарела и не предоставляется Microsoft. Мне пришлось много искать определенные двоичные флаги, потому что документ, который я нашел, не объяснял, для чего нужны некоторые из них. Мой первый PR работал только для NTLM против SQL Server на рабочих станциях для нас, потому что в нашей AD была политика, которая отключала некоторые функции NTLM.

Следующие шаги

Если 3 вышеприведенных совета не работают, было бы очень полезно найти ошибочные записи в журнале с помощью Even Viewer / SQL Logs. «Ненадежный домен» на самом деле является общей ошибкой, которую MSFT предоставляет, чтобы злоумышленнику было сложнее узнать, почему его запрос был отклонен. Вы даже можете найти эту ошибку в Google и найти другие библиотеки OSS, пытающиеся поддерживать NTLM, жалуясь, что эта ошибка вводит в заблуждение.

Я хотел бы помочь вам решить эту проблему, Tedious великолепен, а недавний вклад @arthurschreiber сделал его еще лучше.

Аутентификация NTLM описана в документации MS-NLMP от Microsoft. Я посмотрю, смогу ли я найти время, чтобы прочитать его и сравнить с тем, что реализовано до сих пор в утомительном режиме.

@arthurschreiber @arobson Господи , наконец-то это работает!!! Большое спасибо, ребята, за вашу своевременную поддержку!!! Итак, вот моя окончательная конфигурация:

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

Я использую SQL Server 2008 R2 на виртуальной машине. Скрипт находится на том же сервере, на котором размещена база данных.

Было бы здорово, если бы вы могли добавить это куда-нибудь в документацию.

Прохладный! Тот факт, что NTLM-аутентификация не работает с шифрованием, является ошибкой в ​​​​коде, и я скоро исправлю ее (если найду для этого время).

Действительно, использование домена с заглавной буквы решает проблему!

https://github.com/pekim/tedious/pull/367 Исправление для аутентификации NTLM, не работающей с шифрованием.

Относится ли это обсуждение к использованию проверки подлинности Windows из Linux? Например РедХат?

@pisees Да, я подключаюсь из Fedora 22 к SQL-серверу, используя Windows Auth с шифрованием и исправлением.

У меня была точно такая же проблема с @NamTThai , и теперь она работает после того, как я прочитал это и изменил домен, как описано. (Вся шапка и только первая часть домена, часть после точки опустить)

Я работаю в Microsoft и хочу помочь с некоторыми вкладами в утомительный.
Что-то еще неясно с этой проблемой или все решено?

@tvrprasad Я думаю, что есть обходной путь, я не уверен, что мы все понимаем, почему обходной путь работает. :)

@benzou Это обходной путь, описанный @arobson в этой ветке 15 августа?
Что мешает закрыть эту тему? Может быть, я могу помочь закрыть это... как-то :)

@tvrprasad Я думаю, нам нужна лучшая документация по этому поводу.

Наша документация хранится в ветке gh-pages этого репозитория, но, поскольку она поддерживается за пределами базы кода, она довольно легко устаревает, а обслуживание утомительно. 😞

@tvrprasad - проблемы, о которых сообщалось утомительно и в наш репозиторий с тех пор, как я добавил поддержку NTLM, постоянно были связаны с тем, что домен был указан в нижнем регистре и / или как полное доменное имя. Одним из решений для этого может быть последующий PR, который:

1. преобразует домен в верхний регистр (я должен был сделать это для начала)
2. разбивает домен на . и использует только первый сегмент

Я, конечно, не эксперт по NTLM, но мы фанаты MSSQL и Node, и нам это действительно нужно, поэтому я углубился в документацию по NTLM и другие реализации, чтобы внедрить это с некоторой помощью нашей операционной группы для тестирования на ряде SQL Server. версий, поэтому мы могли быть относительно уверены в реализации. Любой анализ и улучшения, которые вы можете предоставить, были бы потрясающими. Невозможно сказать, что я мог пропустить, поскольку документация, которой я следовал, была с 2007 года 😄

Дайте мне знать, если есть конкретные вопросы, на которые я могу ответить о бите NTLM.

@arobson - FDQN, кажется, работает для меня, хотя и только в верхнем регистре. Я создал отдельную задачу для преобразования в верхний регистр для удобства отслеживания — https://github.com/tediousjs/tedious/issues/414. Я сделаю PR для этого. Я попытаюсь узнать, почему нижний регистр не работает.

@arthurschreiber - я постараюсь помочь с обновлением документации, как только смогу получить хотя бы один PR по этой теме, чтобы лучше понять. Если есть другие области, где отсутствует документация, дайте мне знать. Я постараюсь помочь.

Я открыл пару других вопросов, связанных с аутентификацией. Буду признателен за мысли по этому поводу.
https://github.com/tediousjs/tedious/issues/415
https://github.com/tediousjs/tedious/issues/416

Ребята, у меня есть PR для реализации встроенной аутентификации Windows - https://github.com/tediousjs/tedious/pull/497. Это не требует имени пользователя или пароля и использует учетные данные пользователя для входа в систему.

Если вы сможете попробовать и оставить отзыв, я буду очень признателен. Я с нетерпением жду совместной работы с сообществом, чтобы получить эту функцию.

привет, если кто-нибудь может мне помочь, я пытался подключиться к базе данных MS SQL Server 12, использовал узел mssql 4.1, я уже много чего пробовал, но не подключается

мое соединение соответствует ниже:

Я попробую:

const stringConnect = 'Сервер = ADMIN-CCE\admin: 1433; База данных = GRD; Идентификатор пользователя = admin-cce\admin; '
DATABASE.connect(stringConnect)
.затем (подключение => {
global.conn = соединение;
console.log('подключен к GRD');
})
.catch (ошибка => console.error ( connection error mssql $ {stringConnect} - $ {err} ));

модуль.экспорт = БАЗА ДАННЫХ;

* ВОЗВРАТ ОШИБКА **
ошибка подключения mssql Server = ADMIN-CCE\admin: 1433; База данных = GRD; Идентификатор пользователя = admin-cce\admin; - ConnectionError: порт для администратора: 1433 не найден в ADMIN-CCE

уже пробовал другие способы, тоже безуспешно! Смотреть:

переменная конфига = {
сервер: "ADMIN-CCE\MSSQLSERVER",
база данных: "GRD",
порт: 1433,
пользователь: 'admin-cce\admin',
отладка: правда,
опции: {
шифровать: ложь,
доверенное соединение: правда
}
};

DATABASE.connect (конфигурация, функция (ошибка) {
если (ошибка)
{
console.log(ошибка)
}
еще
console.log('подключено .....')
});

модуль.экспорт = БАЗА ДАННЫХ;

* ВОЗВРАЩАЕТ ОШИБКУ *
сообщение:
«Не удалось подключиться к ADMIN-CCE: не определено — не удалось подключиться (последовательность)»,
код: 'ESOCKET'},
имя: 'ConnectionError'}

Привет, @allexon , tedious еще не поддерживает встроенную аутентификацию Windows, подробности на https://github.com/tediousjs/tedious/issues/660.

поддерживает ли tedious проверку подлинности Windows на сервере SQL?