Риски, связанные с настройкой аутентификации Kerberos для служб отчетов WSS

У нас есть созданная интрасеть, основанная на WSS, с двумя интерфейсами и базой данных.

В настоящее время вся аутентификация является NTLM.

Мы установили службы отчетов в режиме интеграции.

RS работает до тех пор, пока веб-интерфейс, на котором установлен RS, обрабатывает транзакции.

Если клиентский интерфейс без RS обрабатывает запрос, мы получаем сообщение UNAUTHORIZED.

Пытаясь решить эту проблему, веб-поиск и т. Д. - ссылались на проблему, вызванную фермой, требующей аутентификации "с двойным переходом", которая не может происходить через NTLM.

Поэтому нам нужно настроить ферму интрасети на прием аутентификации Kerberos.

Я нашел это полезное руководство, но оно принимает позицию, что мы начинаем ферму с нуля.

Итак, нам нужно знать, есть ли какие-либо риски, связанные с обратной настройкой Kerberos? Будет ли NTLM работать так же, как до и после того, как мы выполнили шаги по включению Kerberos?

Источник

3 ответа

Решение

Существует некоторый риск включения делегирования Kerberos для разрешения двойных прыжков. По сути, вы позволяете IIS олицетворять пользователя без повторного ввода учетных данных. В среде Windows 2000 Active Directory существует только то, что известно как неограниченное делегирование. По сути, вы не можете ограничивать то, что делает делегирование и куда оно может делегировать очень хорошо (так, как вы хотели бы). В этих случаях Microsoft настоятельно рекомендует не использовать делегирование Kerberos. Если вы работаете в Windows 2003 или 2008 Active Directory, вы можете и должны использовать ограниченное делегирование. Это позволяет вам довольно специфично относиться к делегированию. В этом случае повышенный риск, но обычно тот факт, что у вас нет пользователей, повторно вводящих учетные данные или использующих учетные записи служб или имена входа SQL Server, стоит повышенного риска.

От того, будет ли NTLM продолжаться, зависит. Если аутентификация Kerberos может быть установлена, она будет использоваться. Это включает в себя случаи, когда он возвращает ошибку (и вы не думаете, что это должно быть), например, если SPN указаны неверно и т. Д. Он вернется к NTLM, только если аутентификация Kerberos не может быть использована. При этом Kerberos является более новым протоколом безопасности и имеет функции безопасности, которые NTLM не включает в себя отметку времени (предотвращение атак ретрансляции), возможность для клиента проверить подлинность сервера (что NTLM не может сделать) и использование билетов что должно уменьшить общий трафик для аутентификации на контроллерах домена.

Источник

Мы обычно вносим изменения в аутентификацию SharePoint NTLM в Kerberos, как вы предлагаете. Когда мы создаем наши сайты SharePoint, для распространения изменений DNS требуется несколько дней, и для того, чтобы наши имена SPN, установленные для учетных записей служб, обычно также занимали некоторое время.

Поэтому после того, как наши SPN установлены, мы сначала создаем небольшой тестовый сайт на сервере, работающем под пулом приложений SP. Мы включаем WIA и помещаем в него одну тестовую страницу:

<%@ Page Language="C#" %>
<script runat="server" language="C#">
  void Page_Load(object Sender,EventArgs E)
  {
    if (User.Identity.IsAuthenticated) {
      lblIdentity.Text = User.Identity.Name;
    } else {
      lblIdentity.Text = "Anonymous";
    }
    lblImpersonation.Text =
      System.Security.Principal.WindowsIdentity.GetCurrent().Name;
  }
</script>
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
  <HEAD>
    <TITLE>Test Application</TITLE>
  </HEAD>
  <BODY>
    <FORM id="frmForm1" method="post" runat="server">
      <HR width="100%" size="1">
      <P>
        <ASP:LABEL id="Label1" runat="server">Current Identity:
          </ASP:LABEL>&nbsp;
        <ASP:LABEL id="lblIdentity" runat="server">Label</ASP:LABEL>
      </P>
      <P>
        <ASP:LABEL id="LABEL3" runat="server">Impersonated Identity:
          </ASP:LABEL>&nbsp;
        <ASP:LABEL id="lblImpersonation" runat="server">Label</ASP:LABEL></P>
      <HR width="100%" size="1">
    </FORM>
  </BODY>
</HTML>

Перейдите на страницу с активным Fiddler и определите, работает ли Kerberos (на вкладке аутентификации Fiddler будет указано, используете ли вы NTLM или Kerberos).

Как только вы узнаете, что Kerberos работает для вашей учетной записи службы / сервера /URL-адреса, сделайте изменения в SharePoint.

Источник

Спасибо обоим ответчикам - оба дали отличный совет.

Я хотел бы указать на некоторые дополнительные инструменты, которые мы обнаружили в процессе настройки нашей фермы для Kerberos:

DelegConfig V2 (бета!):

  • Brian Murphy-Booth Мы не смогли бы сделать это без этой загрузки из его блога. Вы отвечаете на вопросы о конфигурации, которую вы хотите, и она предоставляет информацию о том, где и почему она будет работать или не будет работать - даже имеет средства тестирования, и если запуск под учетными записями администратора может сделать необходимые изменения для вас.

Метабазный проводник

  • Многие статьи скажут вам использовать adsutil.vbs для установки значения NTAuthenticationProviders каждого сайта. Нам было намного проще использовать Metabase Explorer - тем более, что нам приходилось устанавливать значение для виртуальных каталогов ниже сайта по умолчанию. Это также показывает много много страшных значений в метабазе! Используйте с осторожностью! Часть средств IIS 6.0 Resource Kit
Источник
Другие вопросы по тегам