Нет - неверно говорить, что вам нужно Kerberos, SPN, чтобы доверять серверу для делегирования, и что это ЕДИНСТВЕННЫЙ способ сделать это. Да, это один из способов сделать это (и вам нужно все это, чтобы это произошло через Kerberos), но это не ЕДИНСТВЕННЫЙ, или даже технически самый безопасный или самый простой способ. Вы действительно хотите сделать дополнительные настройки и создать логин для каждого веб-пользователя для вашей базы данных в SQL? Что если какая-либо из этих учетных записей будет взломана? Больше аккаунтов, больше уязвимостей.
Нет, вместо этого создайте учетную запись службы домена и разрешите этому доступ к SQL. Если ваши сотрудники службы безопасности заблокировали вещи, предоставьте этому пользователю следующие права: вход в систему как служба, вход в систему как пакетное задание и разрешение локального входа в систему. Или, если это просто для того, чтобы развить и проверить теорию, или вам все равно, или вы не можете найти настройки, или по-прежнему получаете ошибки позже, и это может не получить большого числа подписчиков, но вы должны предоставить это локальному администратору (иногда вы должен делать то, что должен делать - некоторые профессионалы в области безопасности фиксируют вещи более жесткие, чем я хотел бы написать - всегда могут позже устранить неполадки безопасности, чтобы заблокировать их). Затем установите эту учетную запись в качестве настраиваемой учетной записи в пуле приложений и введите для этой учетной записи имя в SQL. Дайте ему dbo только на ЭТО ОДНУ базу данных.
На веб-сайте в IIS установите тип аутентификации Windows. Я видел, как они говорят «Basic» в других блогах, поэтому Kerberos будет работать, но NTLM использует проверку подлинности Windows. В IIS 7 вы также можете включить олицетворение ASP .NET. Лично я пробовал это только на IIS 6, но основной принцип тот же.
В файле web.config добавьте его в <configuration>, который является «равноправным» для <system.web>:
<connectionStrings>
<add
name="NorthwindConnectionString"
connectionString="Data Source=serverName;Initial
Catalog=Northwind;Integrated Security=SSPI;User
ID=userName;Password=password"
providerName="System.Data.SqlClient"
/>
</connectionStrings>
А в <system.web>:
<authentication mode="Windows"/>
<identity impersonate="true"
userName="domain\user"
password="password" />
Затем прочитайте строку в ваше приложение следующим образом:
using System.Configuration;
string connString = String.Empty;
if (ConfigurationManager.ConnectionStrings.ConnectionStrings.Count > 0)
{
connString = ConfigurationManager.ConnectionStrings["NorthwindConnectionString"].ConnectionString;
if (connString != null) // do DB connection stuff here
Console.WriteLine("Northwind connection string = \"{0}\"",
connString.ConnectionString);
else
Console.WriteLine("No Northwind connection string");
}
См. http://msdn.microsoft.com/en-us/library/ms178411.aspx.
Если он не подключится к учетной записи службы после заполнения этой учетной записи в web.config для тега олицетворения и подключения SQL, вы можете затем использовать методы олицетворения с помощью WindowsImpersonationContext (http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx). В частности, вы хотите wic.Impersonate () и wic.Undo () после получения их токена. Вы можете прочитать в домене учетной записи службы, имя и пароль из web.config в форме AppKeys.
Короче говоря, есть способы обойти проблемы. Вы даже можете зашифровать пароль в файле web.config - как в ConnectionString, так и, если вы хотите сохранить его в AppKey, а не непосредственно в теге «олицетворять», если вы не хотите, чтобы пароли в виде простого текста были там (что Я бы рекомендовал против), и поэтому вы можете использовать его для создания токена Logon, если вам нужно использовать методы олицетворения (как я).