Подключение к SQL Server из .NET с использованием учетной записи службы Active Directory

Question

У меня есть приложение Winforms, написанное на C #, которое подключается к базе данных SQL Server.Когда я подключаюсь к SQL Server, я создаю строку подключения, которая может содержать либо данные для входа в SQL Server, либо использовать проверку подлинности Windows, и в этом случае я опускаю имя пользователя и пароль и использую параметр

"Integrated Security=SSPI" 

встрока подключения.

Теперь пользователь запросил, чтобы у него была возможность подключиться к MS SQL Server с использованием учетной записи службы Active Directory, а не учетной записи сетевого пользователя (что, как я полагаю, соединение с использованием проверки подлинности Windows будет

Я не знаком с учетными записями служб или Active Directory, и мне было интересно, может ли кто-нибудь указать мне правильное направление. Существует ли какой-либо способ построения строки подключения, которая позволит моему приложению подключаться кбазы данных с использованием определенной учетной записи службы Active Directory?

Answer 1

Строки подключения не имеют к этому никакого отношения.

пользователь запросил, чтобы у него была возможность подключиться к MS SQL Server с использованием учетной записи службы Active Directory, а не учетной записи сетевого пользователя

Это означает, что пользователь запросил ваше приложение для запуска в качестве учетной записи службы, а не в качестве текущего пользователя.Один из простых способов сделать это - просто запустить приложение под runas /netonly:

runas /netonly /user:domain\serviceaccount MyWinFormsApp.exe

Таким образом, ваше приложение работает как учетная запись службы домена в сети и будет подключаться кSQL Server, используя учетные данные domain\serviceaccount.Это удовлетворит требование вашего клиента, по крайней мере, на поверхностном поверхностном взгляде.

Если решение использования runas не является удовлетворительным (клиент может на законных основаниях жаловаться, что он требует, чтобы пользователи, запускающие приложение, знали домен \ serviceaccount.пароль), тогда все становится немного сложнее.Правильный способ сделать это - разделить ваше приложение на две части: приложение .exe уровня представления пользовательского интерфейса, которое запускается под учетными данными пользователя, вошедшего в систему, и компонент уровня бизнес-логики, который работает как служба, под учетными данными домена \ serviceaccount.Эти два компонента взаимодействуют, используя ваш IPC по вашему выбору (обычно WCF).Как вы, вероятно, понимаете, это требует s major переписывания вашего приложения.

Некоторые могут предложить использовать, чтобы ваше приложение имитировало домен \ serviceaccount перед открытием соединений с базой данных.Я настоятельно рекомендую это из-за беспорядка хранения / восстановления пароля учетной записи.Поскольку приложению потребуется знать пароль учетной записи службы, чтобы олицетворять его, пользователь, вошедший в систему при запуске приложения, либо узнает этот пароль, либо легко сможет его найти ( невозможно предотвратить его)Форма найти его, если приложение может найти его).Так как пароль службы домена доступен для вошедшего в систему пользователя в любом случае , он может просто использовать решение runas /netonly.И это, наконец, объясняет, почему решение runas является просто решением для мелкого дыма и зеркал: единственная причина, по которой ваш клиент, возможно, запросил то, что он запрашивал, состоит в том, что он хочет отделить привилегии пользователей, вошедших в систему, от привилегий приложения (т. е. не давать SQL-серверу доступ каждому сотруднику).Поскольку решение runas (а также олицетворение в приложении) требует, чтобы вошедший в систему пользователь знал пароль учетной записи службы, разделение привилегий на самом деле не происходит, поскольку вошедший в систему пользователь может использовать любое время, когда он желает ввести пароль учетной записи службы.и повысить его привилегии для доступа к базе данных SQL Server по желанию.Поэтому единственное решение, о котором стоит поговорить, - это разделение приложения на две части.

Answer 2

Строка подключения «Integrated Security = SSPI» будет передавать учетные данные текущего пользователя на SQL Server. Однако, если пользователь хочет использовать другого пользователя Active Directory без изменения строки подключения, используйте функциональность Запуск от имени , предлагаемую операционной системой. Если вы используете Windows 7, нажмите Shift и щелкните правой кнопкой мыши на exe и выберите Запуск от имени другого пользователя.

Это просто взлом, а не правильное решение.

Answer 3

Вообще говоря, активная учетная запись каталога совпадает с сетевой учетной записью пользователя. Существуют исключения, такие как рабочие группы и сети, отличные от AD, но в большинстве случаев они будут одинаковыми.

Если ваши пользователи не в сети AD, то ваши пользователи просят чего-то довольно сложного (междоменное доверие между сетями разных типов).

Однако, если ваши пользователи работают в сети AD, но хотят войти в систему как пользователь, отличный от своего интерактивного пользователя (например, они вошли на свою машину как MJames, но хотят войти в базу данных как FJones), тогда у вас есть два варианта:

1) Скажите им, что им нужно войти в систему на своем компьютере как запрошенный пользователь.

2) Запрашивает у пользователя учетные данные для входа в систему, которые выполняют учетную запись AD для проверки их учетных данных, а затем олицетворяет пользователя, вошедшего в систему с помощью .Net framework. Эта ссылка MSDN , хотя и для ASP.Net, содержит основную информацию, которая вам нужна, в частности, раздел Impersonating by Using LogonUser.

В любом из вышеперечисленных случаев ваш аргумент командной строки Integrated Security=SSPI будет подключаться к SQL Server как пользователь AD, в котором ваш пользователь в настоящий момент вошел в систему, либо напрямую на компьютер, либо через олицетворение.

Answer 4

вы можете соединиться с конкретным пользователем в базе данных, установив идентификатор вашего пула приложений для этого конкретного пользователя. Конечно, этот же пользователь должен иметь все необходимые права доступа для выполнения этого пула.

Answer 5

Это строка подключения, которую я пробовал, и она работала для меня.Да - Integrated Security=SSPI необходимо.

"Data Source=myServerName\myInstanceName;Initial Catalog=myInitialDB;App=myApplication;Integrated Security=SSPI;"

Answer 6

«Integrated Security = SSPI» передаст учетные данные текущего пользователя, вошедшего в систему.Служебная учетная запись - это просто другой пользователь, хотя вам нужно указать его в строке подключения.Я предполагаю, что по умолчанию вы захотите просто передать вошедшего в систему пользователя с помощью «Integrated Security = SSPI», но предложите возможность указать учетные данные для входа в систему, и в этом случае вы будете использовать строку подключения, которая задает имя пользователяи пароль.