Можно ли использовать проверку подлинности Windows для контроля доступа к базе данных внешнего сервера SQL?
Мы планируем переместить большую часть нашей базы данных на сервер SQL нашего веб-хостинга. Сервер SQL доступен только через логины SQL. Есть ли способ установить что-то локально, что бы распознавать учетные данные пользователей Windows и автоматически предоставлять им доступ к удаленной базе данных?
Это облегчит работу пользователей, поскольку им не придется придумывать еще один набор учетных данных для входа в систему, и мне будет легче, поскольку мне не придется обслуживать их отдельно.
Самое простое решение, которое я себе представлял, - это хранить учетные данные для входа в какое-либо общедоступное место, доступное только людям, которым должен быть разрешен доступ к базе данных. Однако это кажется мне чрезвычайно наивным решением и, возможно, полным брешей в безопасности.
Другой вариант, который приходил мне в голову, - это использовать веб-интерфейс, размещенный на нашем главном сервере. Тогда только этому сайту понадобятся учетные данные для входа. Однако это не очень хорошо работает, если мы хотим сделать что-то более продвинутое (скажем, приложение Windows Forms или отчеты на основе Access).
В идеале я хотел бы использовать SQL-прокси, но Google не сильно помогает в этом отношении.
Какие-нибудь мысли?
2 ответа
Если у вас все еще есть SQL Server в вашем домене, вы можете использовать связанный сервер в качестве своего рода прокси. Вы можете определить сопоставления удаленного входа в систему в определении связанного сервера, чтобы сопоставить локальные имена входа Windows с их удаленными аналогами, прошедшими проверку подлинности SQL.
Ну, я не знаю, почему вы не включаете аутентификацию в смешанном режиме. Это решило бы вашу проблему, ИМХО, без требования домена.
Как только смешанный режим включен, вы отключаете учетную запись "sa", включаете прослушиватель tcp/ip port 1433, затем добавляете учетные записи пользователей NT в качестве пользователей в SQL, а затем редактируете "общедоступную" роль сервера и затем добавляете пользователей NT в роль "public" на сервере sql с разрешением "connect" (как у пользователя "sa"). Наконец, убедитесь, что пользователь с правами администратора, которому принадлежит сервер SQL, заблокирован, чтобы никто, кроме администратора, не мог войти в систему.