Есть ли возможность создать DSN (ODBC для SQL Server) с использованием другой учетной записи Windows, чем текущая учетная запись для входа на копьютер? Я пытаюсь создать системный DSN для SQL Server, и я хотел бы создать это соединение с использованием проверки подлинности Windows с использованием моей учетной записи администратора. Я создаю это DSN, используя свою обычную учетную запись Windows.
Вы также можете использовать команду «runas» для запуска администратора источника данных ODBC под своей учетной записью администратора при входе в систему под своей обычной учетной записью. Это позволит вам настроить и проверить соединение без получения сообщения об ошибке «пользователь не связан с доверенным SQL-соединением».
Вот пример команды командной строки:
runas /netonly /user:domain\adminusername "C:\Windows\System32\odbcad32.exe"
Как сказал Джимми, определение DSN не будет привязано к учетной записи администратора, но будет использовать любую учетную запись Windows Authentication, в которую вы вошли, как при использовании подключения позже. (Таким образом, вам нужно будет снова использовать runas для запуска любых программ, использующих соединение, если вы не вошли в систему под своей учетной записью администратора.)
Я собираюсь добавить к ответу Mac, что да, это определенно работает для установки соединения ODBC, и это действительно работает некоторое время. Вероятно, пока активна аутентификация Kerberos. К сожалению, это не постоянная аутентификация, которую я предпочел бы для системного DSN. Вот командный файл, который я использую для запуска odbcad32.exe:
net use \\dbserver-host /user:DOMAIN\username
runas /netonly /user:DOMAIN\username C:\Windows\syswow64\odbcad32.exe
Обратите внимание, что это может привести к тому, что вам будет предложено дважды войти в систему, но, похоже, это работает более стабильно, чем запускается отдельно.
Системный DSN по определению применяется ко всему компьютеру, независимо от того, какая учетная запись используется, поэтому (если я правильно читаю ваш вопрос) это означает, что (1) ответ - «да» и (2) вам понадобится Admin права на создание DSN.
Вы, кстати, смотрели как DSN-соединения? Я считаю, что они будут намного более подходящими для ваших требований, а также устранят необходимость в настройке клиента перед использованием вашего приложения.
Я не верю, что есть возможность сделать это. Использование доверенного NT-соединения с SQL Server подразумевает, что при аутентификации на сервер не отправляется пароль и что для аутентификации используется существующий токен NT. Другими словами, SQL Server «доверяет» аутентификации NT. Он будет использовать любого пользователя, вошедшего в систему во время подключения.
Я обнаружил, что использование диспетчера учетных данных Windows работает довольно хорошо. Вы можете напрямую добавить учетные данные Windows. Хитрость в том, что вам нужно иметь полное доменное имя, включая порт, а также ваше полное имя пользователя Active Directory с квалификатором домена, например, mydb.myinternaldomain.com:1433 и myinternaldomain\myusername с вашим паролем. Затем вы можете добавить mydb.myinternaldomain.com в качестве источника ODBC, и окна волшебным образом меняют правильные учетные данные. Это также работает для Sql Server Management Studio.
Похоже, что это не работает для нативных приложений, отличных от Windows, вам все равно нужны runas.