Веб-приложение ASP.Net пытается использовать олицетворение и делегирование для подключения к SQL Server

Я пытаюсь использовать олицетворение и делегирование в веб-приложении intranet ASP.Net, чтобы передавать учетные данные аутентифицированных пользователей на SQL Server.

Веб-сервер и SQL-сервер - это две отдельные машины, но в том же домене, поэтому требуется делегирование.

Я сделал следующее:

  • установите <authentication mode="Windows"/> и <identity impersonate="true"/> в моем веб-приложении web.config.
  • Включено Ограниченное делегирование с веб-сервера на службу MSSQLSvc на SQL Server в Active Directory.
  • включил только проверку подлинности Windows на веб-сайте через IIS.

По-видимому, все это должно работать, но это не так (SQL Server отказывает в доступе к анонимному пользователю - "Ошибка входа для пользователя" NT AUTHORITY\ANONYMOUS LOGON ").

В IIS7 пул приложений настроен на использование Integrated Pipleline Mode и работает с Identity NetworkService. На веб-сайте включена только проверка подлинности Windows, расширенная защита отключена, включена проверка подлинности в режиме ядра, а NTLM - провайдер.

Все прочитанные веб-страницы, похоже, указывают на то, что моя настройка должна работать. Что мне не хватает?

ОТВЕТЫ

Ответ 1

Я нашел ответ:

Поставщик проверки подлинности Windows в IIS7 должен быть настроен на Negotiate: Kerberos, а не NTLM. Это означает, что параметр проверки подлинности в режиме ядра должен быть отключен. Кажется, все в порядке. Я думаю, что я прав, говоря, что аутентификация в режиме ядра требуется при использовании пользовательского идентификатора, то есть одного конкретного идентификатора. Делегирование может использовать произвольное количество идентификаторов. Так что все хорошо.

Я написал сообщение в блоге об этом тоже, что немного подробнее.

Ответ 2

Нет. Неверно сказать, что вам нужна Kerberos, SPN, чтобы доверять серверу делегированию и что это ТОЛЬКО способ сделать это. Да, это один из способов сделать это (и вам нужно все это, чтобы это произошло через Kerberos), но это не ТОЛЬКО способ или даже технически самый безопасный способ или простой способ. Вы действительно хотите сделать дополнительные настройки и создать логин для каждого пользователя в вашей БД в SQL? Что делать, если какая-либо из этих учетных записей скомпрометирована? Больше учетных записей, больше уязвимостей.

Нет, вместо этого создайте учетную запись службы домена и позвольте этому доступу к SQL. Если ваши охранники блокируют вещи, дайте этому пользователю следующие права: вход в систему как услуга, вход в систему как пакетное задание и разрешение локального входа в систему. Или, если это просто для разработки и тестирования теории, или вам все равно, или вы не можете найти настройки или по-прежнему получать ошибки позже, и это может не получить большое количество, но дать ему локальный администратор (иногда вы должен делать то, что вам нужно - некоторые профессионалы в области безопасности блокируют все более жесткие, чем я хотел бы написать, - всегда могут устранить проблему позже, чтобы заблокировать ее). Затем установите эту учетную запись как пользовательскую учетную запись в пуле приложений и дайте этой учетной записи логин в SQL. Дайте ему dbo только в базе данных THAT ON.

На веб-сайте IIS установите тип проверки подлинности как Windows. Я видел, как они говорят "Основные" в других блогах, поэтому 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, а не непосредственно в теге "impersonate", если вы не хотите, чтобы там были текстовые пароли (которые Я бы рекомендовал против), и поэтому вы можете получить его для создания токена входа в систему, если вам нужно использовать методы олицетворения (как и я).