У меня есть приложение ASP.NET 4.0 (IIS 7.5), работающее на сервере (Window Server 2008 R2 Standard) с именем WEBSERV, и база данных SQL Server (2008) на другом сервере с именем DATASERV. SQL Server имеет настройку входа в систему в качестве пользователя для моей базы данных с правами чтения. Я являюсь владельцем группы AD, связанной с именем входа в SQL Server, с именем READGROUP и использую для доступа к базе данных с использованием встроенной безопасности, которая, как я понимаю, является проверкой подлинности Windows. Для удостоверения пула приложений приложения ASP.NET задано значение NetworkService. Анонимная аутентификация включена. Олицетворение ASP.NET, обычная проверка подлинности, дайджест-проверка подлинности, проверка подлинности с помощью форм, проверка подлинности Windows отключены. При необходимости я могу включить их. Чтобы предоставить пользователю-человеку доступ на чтение к базе данных, я добавляю их в READGROUP.
Моя цель - добавить в READGROUP одного пользователя, отличного от человека, чтобы приложение ASP.NET могло запрашивать базу данных и отображать данные в таблице HTML. У меня есть код, работающий в моем блоке разработчика, но он работает с моими учетными данными, которые имеют доступ к данным, потому что я являюсь частью READGROUP. Когда приложение работает на WEBSERV, его идентификатор Windows отображается как «NT AUTHORITY \ Network Service».
Я не хочу хранить свой пароль на WEBSERV, например этот. Мне приходится менять его каждые 90 дней, и поддерживать это очень сложно, и ИТ-специалисты категорически не одобряют этого.
Есть ли способ добавить определенного пользователя для WEBSERV + ASP.NET + мое приложение в мою группу AD?
Вам нужно будет добавить учетную запись компьютера для WEBSERV в качестве имени входа SQL.
Вы можете сделать это из T-SQL:
CREATE LOGIN [WEBSERV$] FROM WINDOWS;
или из графического интерфейса, создав логин как обычно, но введя YOURDOMAIN\WEBSERV$ в диалоговом окне поиска при поиске учетной записи AD.
После этого вы можете сопоставить пользователя с базой данных, как обычно.
Вместо этого может быть желательно создать пользователя AD для использования в качестве учетной записи службы для удостоверения пула приложений, присвоить ему очень длинный пароль и установить для учетной записи флаг «Пароль никогда не истекает». Это, вероятно, более безопасно, чем предоставление доступа к учетной записи компьютера, но это зависит от того, насколько гибко ваш ИТ-отдел в отношении политики паролей для учетных записей служб.
В любом случае использование собственной учетной записи AD в качестве учетной записи службы - плохая идея.