У нас есть установленный Интранет на основе WSS с двумя интерфейсами и базой данных.
В настоящее время вся проверка подлинности - NTLM.
Мы установили службы Reporting Services в режиме интеграции.
RS работает до тех пор, пока веб-интерфейс, на котором установлен RS, обрабатывает транзакции.
Если внешний интерфейс без RS обрабатывает запрос, мы получаем НЕСАНКЦИОНИРОВАННУЮ ошибку.
Пытаясь решить эту проблему, поисковые запросы в Интернете и т. Д. Ссылались на проблему, вызванную тем, что ферме необходимо выполнить «двухэтапную» аутентификацию, что не может происходить через NTLM.
Поэтому нам нужно настроить ферму интрасети для приема проверки подлинности Kerberos.
Я нашел это полезным руководство Но он исходит из того, что мы начинаем ферму с нуля.
Итак, нам нужно знать, есть ли какие-либо риски, связанные с ретроактивной настройкой Kerberos? Будет ли NTLM работать, как прежде, пока и после того, как мы выполнили действия по включению Kerberos?
Обычно мы вносим обратные изменения в аутентификацию Kerberos с SharePoint NTLM, как вы предлагаете. Когда мы устанавливаем наши сайты 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>
<ASP:LABEL id="lblIdentity" runat="server">Label</ASP:LABEL>
</P>
<P>
<ASP:LABEL id="LABEL3" runat="server">Impersonated Identity:
</ASP:LABEL>
<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 для разрешения двойных прыжков. По сути, вы позволяете IIS выдавать себя за пользователя без повторного ввода пользователем каких-либо учетных данных. В среде Windows 2000 Active Directory есть только то, что известно как неограниченное делегирование. По сути, вы не можете ограничить то, что делает делегирование, и то, где оно может делегировать очень хорошо (как вам хотелось бы). В таких случаях Microsoft настоятельно рекомендует не использовать делегирование Kerberos. Если вы используете Windows 2003 или 2008 Active Directory, вы можете и должны использовать ограниченное делегирование. Это позволяет получить более конкретную информацию о делегировании. В этом случае существует повышенный риск, но обычно тот факт, что у вас нет пользователей, повторно вводящих учетные данные, или ваших учетных записей служб или логинов SQL Server, стоит повышенного риска.
Что касается продолжения работы NTLM, это зависит от обстоятельств. Если аутентификация Kerberos может быть установлена, она будет использоваться. Это включает в себя случаи, когда он возвращает ошибку (а вы не думаете, что это должно быть), например, если SPN неправильные и т. Д. Он вернется к NTLM только в том случае, если аутентификация Kerberos не может быть использована. С учетом сказанного, Kerberos является более новым протоколом безопасности и имеет функции безопасности, которые NTLM не включает в себя метку времени (предотвращение ретрансляционных атак), возможность для клиента проверять подлинность сервера (что NTLM не может сделать) и использование билетов. что должно уменьшить общий трафик для аутентификации к контроллерам домена.
Спасибо обоим респондентам - оба дали отличный совет.
Я хотел бы указать на некоторые дополнительные инструменты, которые мы обнаружили в процессе настройки нашей фермы для Kerberos: