Как получить ms-доступ для подключения к ms-sql от имени другого пользователя?

Question

Как получить ms-доступ для подключения (через ODBC) к базе данных ms-sql от имени другого пользователя, отличного от его идентификатора Active Directory?

Я не хочу указывать учетную запись в подключении ODBC, я хочу сделать это на стороне ms-access, чтобы скрыть ее от моих пользователей. Выполнение этого в соединении ODBC вернет меня обратно к исходной ситуации, которой я пытаюсь избежать.

Да, это относится к предыдущему вопросу: http://www.stackoverflow.com/questions/50164/

Answer 1

Я думаю, вы можете заставить это работать так, как вы хотите, если вы используете «ODBC DSN-LESS соединение»

Если вам нужно, сохраните ваши DSN ODBC на компьютерах ваших пользователей, используя проверку подлинности Windows. Предоставьте своим пользователям доступ только для чтения к вашей базе данных. (Если они создадут новый файл MDB и свяжут таблицы, они смогут только читать данные.)

Создать учетную запись SQL, которая имеет разрешение на чтение / запись для вашей базы данных.

Напишите подпрограмму VBA, которая перебирает ваши связанные таблицы и сбрасывает соединение, чтобы использовать вашу учетную запись SQL, но обязательно используйте синтаксис «DSN-Less».

"ODBC;Driver={SQL Native Client};" &
       "Server=MyServerName;" & _
       "Database=myDatabaseName;" & _
       "Uid=myUsername;" & _
       "Pwd=myPassword"

Вызовите эту процедуру как часть вашего кода запуска.

Несколько замечаний об этом подходе:

• Похоже, что в Access возникли проблемы с информацией о соединении после того, как вы изменили чтение и запись на чтение и попытались вернуться к чтению / записи без закрытия и повторного открытия файла базы данных (mde / mdb). Если вы можете изменить это один раз при запуске на чтение / запись и не изменять его во время сеанса, это решение должно работать.

• Используя DSN - Less connection, вы можете скрыть учетные данные от пользователя в коде (при условии, что вы даете им файл mde, с вами все должно быть в порядке). Обычно жесткое кодирование строк соединения не является хорошей идеей, но, поскольку вы имеете дело с собственным приложением, вы должны согласиться с этим подходом.

Answer 2

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

Answer 3

То, что я надеялся сделать (с чем я только что экспериментировал), чтобы обновить ссылки на базу данных примерно так для каждой таблицы (Примечание: я переключил соединение ODCB на аутентификацию SQL Server для этого эксперимента и добавил учетные записи для сервера SQL: readonly - не может обновляться и readwrite - имеет полные права на таблицу).

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readonly;" & _
                "PWD=readonly_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

это останавливает их редактирование, но я не могу заставить работать более поздний readwrite

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readwrite;" & _
                "PWD=readwrite_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

Кажется, что любое разрешение, с которым я соединяюсь первым, остается неизменным. Если я запустил readwrite, а затем перешел к readonly, таблица останется с правами readwrite

Answer 4

@ Philippe
Я предполагаю, что вы используете слово admit как примерно эквивалентное понимаю или, возможно, согласен ; в отличие от отрицать .

Я понимаю последствия того, что все пользователи войдут в базу данных, используя один идентификатор и пароль (и сохранят их в приложении). Для меня это меньший риск, чем проблема, с которой я сейчас сталкиваюсь.
@ От

Еще немного предыстории проблемы: У меня настроены соединения ODBC на каждой из рабочих станций пользователей, использующих аутентификацию Windwos NT. В большинстве случаев пользователи подключаются с использованием настройки MDE для использования этого подключения ODBC - в этом случае они ВСЕГДА имеют возможность добавлять / обновлять / удалять данные.

Проблема заключается в том, что некоторые пользователи достаточно осведомлены о MS-Access, чтобы создать новый mdb и связать его с сервером MS-SQL. Затем они могут редактировать данные прямо в таблицах, а не проходить через приложение, которое выполняет определенную проверку и держит их в руках. И они любят делать это, но иногда это портит и вызывает у меня проблемы.

Answer 5

Здесь мы признаем, что вы используете ODBC-соединение с вашей базой данных при включенной интегрированной безопасности, так что вы не хотите / не хотите записывать имя пользователя / пароль в строку подключения (что, по моему мнению, правильно выбор).

В этом случае, к счастью, нет способа «симулировать» другого пользователя при подключении к данным. Признайтесь со мной, что возможность сделать такую ​​вещь была бы огромным прорывом в интегрированной безопасности!

Из вашего предыдущего поста я понял, что вы хотите, чтобы пользователи могли обновлять данные или нет, в зависимости от используемого ими клиентского интерфейса. По моему мнению, идея состоит в том, чтобы создать для каждой таблицы связанный «не обновляемый» вид. Предположим, что для каждой таблицы с именем Table_Blablabla вы создаете представление (= запрос в Access) с именем View_Table_Blablabla ...).

При использовании Access вы можете во время выполнения решить, хотите ли вы открыть обновляемую таблицу или представление только для чтения. Это можно сделать, например, во время выполнения, в событии form_Open, установив источник записей формы либо в таблицу, либо в представление.

Answer 6

Я думаю, вам нужно запустить процесс MS Access под учетной записью, которую вы хотите использовать для подключения. Существуют различные инструменты, которые позволяют вам сделать это, например CPAU . Этот инструмент также позволит вам зашифровать пароль.