Как соединиться с SQL-сервером с аутентификацией Windows от сервиса окон?
Я запрограммировал службу Windows в C#, который должен соединиться с Базой данных Экспресса SQL Server 2005 года с Системой. Данные. SqlClient.
Поскольку Microsoft предпочитает использовать аутентификацию Windows по аутентификации SQL, которую я пытался подключить к DB с Доверяемым Conenction / Интегрированная защита.
Однако это не работает, поскольку я получаю Систему. Данные. SqlClient. SqlException: Вход в систему привел к сбою для пользователя 'УСЛУГИ NT AUTHORITY\LOCAL'.
Действительно ли возможно войти в систему с другим Windows Account?
5 ответов
В настоящее время служба работает под учетной записью LocalService, и эта учетная запись службы в настоящее время не авторизована в SQL.
Ситуацию можно исправить одним из двух способов: запустить учетную запись под учетной записью, которая авторизована в SQL, или добавить учетную запись LocalService в качестве логина в SQL. А именно:
- Измените учетную запись, под которой запущена служба, в консоли управления службами. (например: Computer Management | Services and Applications | Services, затем правой кнопкой мыши выберите "Properties" для данной службы)
- Альтернативно, в "Microsoft SQL Management Studio", добавьте учетную запись LSA в качестве логина и установите этого нового принципала (логина) таким образом, чтобы он мог получить доступ к нужным объектам базы данных.
Редактировать: Первый подход, вероятно, предпочтительнее, поскольку учетная запись LocalService настолько широко распространена в системе, что предоставление ей доступа к SQL приведет к раскрытию SQL и баз данных, если конкретная служба или драйвер, использующие ее, будут скомпрометированы.
Вместо этого, введя специальную учетную запись, можно получить больше контроля над тем, кто и как получает доступ к объектам SQL. При этом, конечно, возникает вопрос конфигурирования такой учетной записи, в отношении привилегий, которые ей должны быть предоставлены, на уровне системы (не SQL), и в зависимости от того, что делает базовая служба, может потребоваться сделать эту учетную запись довольно мощной, следовательно, потенциальной ответственностью в других отношениях.....
Как сказал mjv, вам необходимо либо предоставить локальной учетной записи службы доступ к базе данных, либо использовать другую учетную запись для запуска службы. Вы спросили, как можно изменить учетную запись программно, что достигается путем создания установщика для службы и изменения свойства учетной записи на «Пользователь», а затем указания имени пользователя и пароля для запуска службы.
Следующая ссылка содержит информацию о создании установщика при прокрутке вниз:
http://msdn.microsoft.com/en-us/library/aa984464 (VS.71) .aspx
Хотя ниже приводится немного более подробная информация о свойстве Account:
Надеюсь, что это помогает.
Когда служба Windows запускается диспетчером управления службами, процесс выполняется от имени конкретного пользователя, как и любой другой процесс, запущенный в ОС.
Существует ряд «встроенных» учетных записей пользователей, которые используются для запуска служб Windows. Вы можете увидеть полный набор служб Windows и учетную запись, под которой они работают (в Windows 7 она называется «Вход в систему как»), если вы посмотрите на узел «Службы» в «Управлении компьютером».
По моему опыту, когда мы захотим Служба Windows для взаимодействия с БД с использованием интегрированной безопасности, мы используем второй подход, описанный ниже:
1) Назначьте одну из встроенных учетных записей в качестве учетной записи «Вход в систему как» и добавьте эту учетную запись в качестве входа на SQL Server. экземпляр с соответствующими разрешениями БД
2) Используйте / создайте локальную или доменную учетную запись для службы Windows, а затем добавьте эту учетную запись в качестве логина с соответствующими разрешениями БД. учетные данные во время установки службы.
Я не могу претендовать на то, чтобы быть достаточно экспертом, чтобы указать все плюсы и минусы каждого подхода, однако стоит учесть следующее:
с подходом 1 все службы и процессы, которые запустить, поскольку выбранная встроенная учетная запись будет иметь разрешение на доступ к вам d atabase. Это не относится к подходу 2.
с подходом 1 конфигурация пароля управляется самой машиной, но с подходом 2 пароль может управляться администраторами, а также соответствовать любым требуемым политикам безопасности.
Надеюсь, это поможет
Вам необходимо предоставить доступ к учетной записи LOCAL SERVICE в SQL Express. Согласно моему комментарию, я бы посоветовал создать новую учетную запись, под которой ваша служба может работать, а затем добавить соответствующие разрешения внутри SQL Express, другими словами, не запускайте свою службу в ЛОКАЛЬНОЙ СЛУЖБЕ.
Если вы хотите использовать доверенную аутентификацию windows, проще всего запустить службу с доменной учетной записью (с минимально необходимыми привилегиями), имеющей права на базу данных sql-сервера.