Изменения в аутентификации NTLM для HttpWebRequest в версии 3.5 с пакетом обновления 1 (SP1)Changes to NTLM authentication for HttpWebRequest in Version 3.5 SP1

В .NET Framework версии 3.5 с пакетом обновления 1 (SP1) и более поздних внесены касающиеся безопасности изменения, влияющие на обработку встроенной проверки подлинности Windows классами HttpWebRequest, HttpListener, NegotiateStream и связанными классами в пространстве имен System.Net.Security changes were made in .NET Framework version 3.5 SP1 and later that affect how integrated Windows authentication is handled by the HttpWebRequest, HttpListener, NegotiateStream, and related classes in the System.Net namespace. Эти изменения могут влиять на приложения, которые используют данные классы для выполнения веб-запросов и получения ответов с применением встроенной проверки подлинности Windows на основе NTLM.These changes can affect applications that use these classes to make web requests and receive responses where integrated Windows authentication based on NTLM is used. Они также могут повлиять на веб-серверы и клиентские приложения, в которых используется встроенная проверка подлинности Windows.This change can impact web servers and client applications that are configured to use integrated Windows authentication.

ОбзорOverview

Структура встроенной проверки подлинности Windows позволяет формировать универсальные ответы на некоторые запросы учетных данных. Это означает, что эти ответы можно использовать повторно или перенаправлять.The design of integrated Windows authentication allows for some credential responses to be universal, meaning they can be re-used or forwarded. Если эта функция не нужна, то протоколы проверки подлинности должны передавать сведения, относящиеся к целевому объекту и каналу.If this particular design feature is not needed, then the authentication protocols should carry target specific information as well as channel specific information. Кроме того, службы могут предоставлять расширенную защиту, чтобы в ответах на запросы учетных данных также содержались сведения о службе, например имя субъекта-службы.Services can then provide extended protection to ensure that credential responses contain service specific information such as a Service Principal Name (SPN). С включением этих сведений в ответы на запросы учетных данных службы могут обеспечить лучшую защиту при изменении ответов злоумышленниками.With this information in the credential exchanges, services are able to better protect against malicious use of credential responses that might have been improperly obtained.

Несколько компонентов в пространствах имен System.Net и System.Net.Security выполняют встроенную проверку подлинности Windows от имени вызывающего приложения.Multiple components in the System.Net and System.Net.Security namespaces perform integrated Windows authentication on behalf of a calling application. В этом разделе описаны изменения в компонентах System.Net для добавления расширенной защиты при использовании встроенной проверки подлинности Windows в этих компонентах.This section describes changes to System.Net components to add extended protection in their use of integrated Windows authentication.

ИзмененияChanges

Процесс проверки подлинности NTLM, используемый со встроенной проверкой подлинности Windows, включает в себя запрос, который выдается конечным компьютером и отправляется обратно на клиентский компьютер.The NTLM authentication process used with integrated Windows authentication includes a challenge issued by the destination computer and sent back to the client computer. Когда компьютер получает созданный им самим запрос, проверку подлинности пройти не удается, если только подключение не замыкается на себя (например, как в случае с IPv4-адресом 127.0.0.1).When a computer receives a challenge it generated itself, the authentication will fail unless the connection is a loop back connection (IPv4 address 127.0.0.1, for example).

Доступ к службе, работающей на внутреннем веб-сервере, часто осуществляется по URL-адресу, похожему на http://contoso/service или https://contoso/service.When accessing a service running on an internal Web server, it is common to access the service using a URL similar to http://contoso/service or https://contoso/service. Здесь contoso часто не является именем компьютера, на котором развернута служба.The name "contoso" is often not the computer name of the computer on which the service is deployed. System.Net и связанные пространства имен поддерживают использование Active Directory, DNS, NetBIOS, файла hosts локального компьютера (например, WINDOWS\system32\drivers\etc\hosts) или файла lmhosts локального компьютера (например, WINDOWS\system32\drivers\etc\lmhosts) для разрешения имен в адреса.The System.Net and related namespaces support using Active Directory, DNS, NetBIOS, the local computer's hosts file (typically WINDOWS\system32\drivers\etc\hosts, for example), or the local computer's lmhosts file (typically WINDOWS\system32\drivers\etc\lmhosts, for example) to resolve names to addresses. Имя contoso разрешается так, что адресуемые на него запросы отправляются на соответствующий сервер.The name "contoso" is resolved so that requests sent to "contoso" are sent to the appropriate server computer.

При настройке больших развертываний также часто бывает так, что одно имя виртуального сервера присваивается всему развертыванию, а имена входящих в него компьютеров никогда не используются клиентскими приложениями и пользователями.When configured for large deployments, it is also common for a single virtual server name to be given to the deployment with the underlying machine names never used by client applications and end users. Например, можно вызвать сервер www.contoso.com, но во внутренней сети достаточно указать просто contoso.For example, you might call the server www.contoso.com, but on an internal network simply use "contoso". Это имя называется заголовком узла в веб-запросе клиента.This name is called the Host header in the client web request. Согласно спецификации протокола HTTP в поле заголовка узла в запросе указываются узел в Интернете и номер порта запрашиваемого ресурса.As specified by the HTTP protocol, the Host request-header field specifies the Internet host and port number of the resource being requested. Эти сведения берутся из исходного универсального кода ресурса (URI), предоставленного пользователем или ссылающимся ресурсом (как правило, это URL-адрес HTTP).This information is obtained from the original URI given by the user or referring resource (generally an HTTP URL). В .NET Framework версии 4 эти сведения также могут быть заданы клиентом с помощью нового свойства Host.On .NET Framework version 4, this information can also be set by the client using the new Host property.

Класс AuthenticationManager контролирует управляемые компоненты (модули) проверки подлинности, которые используются производными классами WebRequest и классом WebClient.The AuthenticationManager class controls the managed authentication components ("modules") that are used by WebRequest derivative classes and the WebClient class. Класс AuthenticationManager предоставляет свойство, обеспечивающее доступ к объекту AuthenticationManager.CustomTargetNameDictionary, который индексируется по строке URI. С его помощью приложения указывают пользовательскую строку с именем субъекта-службы, которая должна использоваться во время проверки подлинности.The AuthenticationManager class provides a property that exposes a AuthenticationManager.CustomTargetNameDictionary object, indexed by URI string, for applications to supply a custom SPN string to be used during authentication.

Если свойство CustomTargetNameDictionary не задано, то при обмене данными для проверки подлинности NTLM в версии 3.5 с пакетом обновления  1 (SP1) в качестве имени субъекта-службы по умолчанию указывается имя узла, используемое в URL-адресе запроса.Version 3.5 SP1 now defaults to specifying the host name used in the request URL in the SPN in the NTLM (NT LAN Manager) authentication exchange when the CustomTargetNameDictionary property is not set. Имя узла, используемое в URL-адресе запроса, может отличаться от заголовка узла, указанного в System.Net.HttpRequestHeader в запросе клиента.The host name used in the request URL may be different from the Host header specified in the System.Net.HttpRequestHeader in the client request. Кроме того, оно может отличаться от фактического имени узла сервера, имени компьютера сервера, IP-адреса компьютера или петлевого адреса.The host name used in the request URL may be different from the actual host name of the server, the machine name of the server, the computer's IP address, or the loopback address. В таких случаях Windows отклонит запрос проверки подлинности.In these cases, Windows will fail the authentication request. Для решения этой проблемы необходимо уведомить Windows о том, что имя узла, используемое в URL-адресе запроса клиента (например, contoso), на самом деле является альтернативным именем локального компьютера.To address the issue, we need to notify Windows that the host name used in the request URL in the client request ("contoso", for example) is actually an alternate name for the local computer.

Адаптировать серверное приложение к этому изменению можно несколькими способами.There are several possible methods for a server application to work around this change. Рекомендуемый подход заключается в сопоставлении имени узла, используемого в URL-адресе запроса, с разделом реестра BackConnectionHostNames на сервере.The recommended approach is to map the host name used in the request URL to the BackConnectionHostNames key in the registry on the server. Раздел реестра BackConnectionHostNames, как правило, служит для сопоставления имени узла с петлевым адресом.The BackConnectionHostNames registry key is normally used to map a host name to a loopback address. Необходимые действия описаны ниже.The steps are listed below.

Чтобы указать имена узлов, которые сопоставлены с петлевым адресом и с которых возможно подключение к веб-сайтам на локальном компьютере, выполните указанные ниже действия.To specify the host names that are mapped to the loopback address and can connect to Web sites on a local computer, follow these steps:

  1. Нажмите кнопку "Пуск", щелкните "Выполнить", введите команду "regedit" и нажмите кнопку "ОК".Click Start, click Run, type regedit, and then click OK.

  2. В редакторе реестра найдите следующий раздел реестра и выберите его:In Registry Editor, locate and then click the following registry key:

    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0

  3. Щелкните раздел MSV1_0 правой кнопкой мыши, наведите указатель на пункт "Создать" и выберите пункт "Мультистроковый параметр".Right-click MSV1_0, point to New, and then click Multi-String Value.

  4. Введите BackConnectionHostNames и нажмите клавишу ВВОД.Type BackConnectionHostNames, and then press ENTER.

  5. Щелкните параметр BackConnectionHostNames правой кнопкой мыши и выберите пункт "Изменить".Right-click BackConnectionHostNames, and then click Modify.

  6. В поле "Значение" введите одно или несколько имен узлов для сайтов, размещенных на локальном компьютере (то есть имена узлов, используемых в URL-адресе запроса), и нажмите кнопку "ОК".In the Value data box, type the host name or the host names for the sites (the host name used in the request URL) that are on the local computer, and then click OK.

  7. Закройте редактор реестра, перезапустите службу IISAdmin и выполните команду IISReset.Quit Registry Editor, and then restart the IISAdmin service and run IISReset.

Менее безопасный способ — отключить проверку замыкания на себя, как описано на странице https://support.microsoft.com/kb/896861.A less secure work around is to disable the loop back check, as described in https://support.microsoft.com/kb/896861. При этом отключается защита от атак отражением.This disables the protection against reflection attacks. Поэтому лучше ограничить набор альтернативных имен только теми, которые действительно будут использоваться компьютером.So it is better to constrain the set of alternate names to only those you expect the machine to actually use.

См. также разделSee also