Ответ 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. Боюсь, вам придется реализовать его самостоятельно.