Моно к SQL Server с Windows Auth

Быстрый...

Как использовать проверку подлинности Windows на SQL Server с Mono SQL Client, работающим в Windows без имени пользователя + пароля в строке подключения?

Подробнее...

  • Мы должны использовать Mono для поддержки нескольких платформ для некоторых компонентов нашего приложения
    Это внешнее ограничение, которое мы не можем изменить

  • Мы запустим компоненты, которые обращаются к базе данных только в Windows

    Функции переносимости/OS-агностики Mono SQL Client не добавляют значения

То есть любой компонент, работающий на не-Windows, не будет обращаться к базе данных SQL Server

  • Процесс выполняется под некоторым пользователем Windows (реальный пользователь, учетная запись службы и т.д.)

  • Вложение имени пользователя и паролей - это плохая вещь
    Независимо от того, какой угол вы пришли из

Итак, как мы можем заставить Mono SQL Client читать токен входа в систему NT для пользователя, выполняющего этот процесс, и передать его SQL Server? Точно так же, как MS.net?

  • Есть ли флаг или параметр, который не является хорошо документированным

  • Нужно ли нам внедрять собственное расширение?
    Если это так, мы действительно первые люди, желающие это сделать?

Есть еще 5 вопросов (в настоящее время) с метками Mono и SQL-Server: они не отвечают на это...

ОТВЕТЫ

Ответ 1

Это не так легко выполнить, как кажется. Как я уверен, вы знаете, Mono SqlClient поддерживает аутентификацию NT:

Имеет формат строки подключения для NT Authentication: Server = имя хоста; Database = Databasename; Пользователь ID = windowsDomain\windowsUserid; Password = windowsPassword Интегрированное Безопасность = ССПИ

Но, конечно, вам нужна более простая форма Integrated Security=SSPI, и пусть аутентификация аутентификации NT использует текущие учетные данные процесса. И здесь проблема. Хотя тривиально получить текущее имя пользователя (идентификатор) процесса, невозможно, чтобы процесс обнаружил его собственный пароль учетных данных. При выполнении NT-аутентификации процесс Windows фактически не выполняет аутентификацию, а вместо этого запрашивает Locas Security Authority (также известный как LSASS.EXE, пустяки: не прикрепляйте к нему отладчик;)) для аутентификации этого процесса. Это означает, что любая библиотека, которая хочет достичь того же, должна использовать один и тот же протокол, т.е. попросите LSA проверить подлинность. Фактические данные для любознательных находятся в последовательности AcquireCredentialHandle, InitializeSecurityContext, AcceptSecurityContext, как описано в Использование ССПИ. Я не изучал монофонический источник для SqlClient, но я уверен, что они используют библиотеку GSS-API для аутентификации, а не SSPI. поэтому, по определению, они требуют знать пароль, так как они собираются сделать обмен Kerberos самостоятельно, а не просить LSA делать это от их имени.

Это, как вы можете судить, спекуляции и больше предположений на моей стороне, но я был бы удивлен, услышав другую историю. В то время как, безусловно, возможно разветкить или установить Mono.Data.Tds и изменить реализацию аутентификации, чтобы использовать SSPI вместо GSS, это по определению будет не переносной реализацией Windows. Я бы предположил, что для него мало стимулов, учитывая, что точка притяжения №1 в Mono - это не Windows. Боюсь, вам придется реализовать его самостоятельно.