Поделиться через

Встроенная проверка подлинности Windows с расширенной защитой

Были произведены улучшения, которые влияют на обработку интегрированной проверки подлинности Windows классами HttpWebRequest, HttpListener, SmtpClient, SslStream, NegotiateStream и связанными с ними классами в пространстве имен System.Net и связанных пространствах имен. Добавлена поддержка расширенной защиты для повышения безопасности.

Эти изменения могут повлиять на приложения, использующие эти классы для выполнения веб-запросов и получения ответов, в которых используется встроенная проверка подлинности Windows. Это изменение также может повлиять на веб-серверы и клиентские приложения, настроенные для использования встроенной проверки подлинности Windows.

Эти изменения также могут повлиять на приложения, использующие эти классы для выполнения других типов запросов и получения ответов, где используется встроенная проверка подлинности Windows.

Изменения в поддержке расширенной защиты доступны только для приложений в Windows 7 и Windows Server 2008 R2. Функции расширенной защиты недоступны в более ранних версиях Windows.

Обзор

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

Расширенная защита — это усовершенствование протоколов аутентификации, предназначенное для устранения атак ретрансляции аутентификации. Она вращается вокруг концепции сведений о каналах и привязке служб.

Общие цели приведены ниже.

  1. Если клиент обновляется для поддержки расширенной защиты, приложения должны предоставлять сведения о привязке канала и привязке служб ко всем поддерживаемым протоколам проверки подлинности. Сведения о привязке канала можно предоставить только в том случае, если есть канал (TLS) для привязки. Сведения о привязке сервиса всегда должны быть предоставлены.

  2. Обновленные серверы, которые правильно настроены, могут проверить сведения о канале и привязке службы, если они присутствуют в маркере проверки подлинности клиента, и отклонить попытку проверки подлинности, если привязки канала не совпадают. В зависимости от сценария развертывания серверы могут проверять привязку каналов, привязку службы или оба варианта.

  3. Обновленные серверы могут принимать или отклонять запросы клиента нижнего уровня, которые не содержат сведения о привязке канала на основе политики.

Информация, используемая расширенной защитой, состоит из одной или двух следующих частей:

  1. Маркер привязки канала или маркер CBT (Channel Binding Token).

  2. Сведения о привязке службы в виде имени субъекта-службы или SPN.

Сведения о привязке службы — это указание намерения клиента пройти проверку подлинности в определенной конечной точке службы. Он передается от клиента к серверу со следующими свойствами:

  • Значение SPN должно быть доступно серверу, выполняющему проверку подлинности клиента, в текстовом формате.

  • Значение SPN является общедоступным.

  • Имя субъекта-службы (SPN) должно быть защищено криптографически при передаче таким образом, чтобы атака типа "человек посередине" не могла вставлять, удалять или изменять его значение.

CBT — это свойство внешнего безопасного канала (например, TLS), используемого для связывания его с беседой через внутренний канал, прошедший аутентификацию клиента. CBT должен иметь следующие свойства (также определены IETF RFC 5056):

  • Если внешний канал существует, значение CBT должно определяться как свойство, которое идентифицирует либо внешний канал, либо конечную точку сервера, независимо достигнутое обеими сторонами — клиентом и сервером.

  • Значение CBT, отправленного клиентом, не должно быть чем-то, что злоумышленник может изменить.

  • Гарантии секретности значения CBT не предоставляются. Однако это не означает, что значение привязки службы, а также сведения о привязке канала всегда могут быть проверены любым другим, но сервером, выполняющим проверку подлинности, так как протокол, содержащий CBT, может шифровать его.

  • CBT должен быть криптографически защищен при передаче таким образом, чтобы злоумышленник не может вставлять, удалять или изменять его значение.

Привязка канала осуществляется клиентом, который передает имя субъекта службы и CBT серверу в защищенном виде. Сервер проверяет сведения о привязке канала в соответствии с политикой и отклоняет попытки проверки подлинности, для которых он не считает себя целевым объектом. Таким образом, два канала становятся криптографически привязанными друг к другу.

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

Несколько компонентов в System.NetSystem.Net.Security пространствах имен выполняют встроенную проверку подлинности Windows от имени вызывающего приложения. В этом разделе описываются изменения System.Net компонентов для добавления расширенной защиты при использовании встроенной проверки подлинности Windows.

Расширенная защита в настоящее время поддерживается в Windows 7. Предоставляется механизм, позволяющий приложению определить, поддерживает ли операционная система расширенную защиту.

Изменения в поддержке расширенной защиты

Процесс проверки подлинности, используемый с интегрированной проверкой подлинности Windows в зависимости от используемого протокола проверки подлинности, часто включает вызов, выданный конечным компьютером и отправленный обратно на клиентский компьютер. Расширенная защита добавляет новые функции в этот процесс проверки подлинности

Пространство System.Security.Authentication.ExtendedProtection имен обеспечивает поддержку проверки подлинности с помощью расширенной защиты для приложений. Класс ChannelBinding в этом пространстве имен представляет привязку канала. Класс ExtendedProtectionPolicy в этом пространстве имен представляет политику расширенной защиты, используемую сервером для проверки входящих клиентских подключений. Другие члены класса используются с расширенной защитой.

Для серверных приложений эти классы включают следующие:

Объект ExtendedProtectionPolicy с следующими элементами:

  • Свойство, указывающее, поддерживает ли операционная OSSupportsExtendedProtection система встроенную проверку подлинности Windows с расширенной защитой.

  • PolicyEnforcement Значение, указывающее, когда следует применить расширенную политику защиты.

  • ProtectionScenario Значение, указывающее сценарий развертывания. Это влияет на проверку расширенной защиты.

  • Необязательный ServiceNameCollection, содержащий настраиваемый список SPN, используемый для сопоставления с SPN клиента, предоставленным в качестве целевой цели проверки подлинности.

  • Необязательный объект ChannelBinding , содержащий настраиваемую привязку канала для проверки. Этот сценарий не является типичным случаем

Пространство имен System.Security.Authentication.ExtendedProtection.Configuration предоставляет возможность настройки аутентификации с использованием расширенной защиты для приложений.

Были внесены ряд изменений функций для поддержки расширенной защиты в существующем System.Net пространстве имен. К этим изменениям относятся следующие изменения:

  • Новый TransportContext класс, добавленный в System.Net пространство имен, представляющее контекст транспорта.

  • Новые EndGetRequestStream и GetRequestStream перегруженные методы в классе HttpWebRequest, которые позволяют извлечь TransportContext, поддерживающее расширенную защиту для клиентских приложений.

  • Дополнения к HttpListener и HttpListenerRequest классам для поддержки серверных приложений.

Было внесено изменение функции для поддержки расширенной защиты клиентских приложений SMTP в существующем System.Net.Mail пространстве имен:

  • TargetName Свойство в классе SmtpClient, представляющее имя главного субъекта службы (SPN) для проверки подлинности при использовании расширенной защиты для клиентских приложений SMTP.

Были внесены ряд изменений функций для поддержки расширенной защиты в существующем System.Net.Security пространстве имен. К этим изменениям относятся следующие изменения:

Свойство SmtpNetworkElement было добавлено для поддержки конфигурации расширенной защиты для клиентов SMTP в System.Net.Security пространстве имен.

Расширенная защита клиентских приложений

Расширенная поддержка защиты для большинства клиентских приложений происходит автоматически. Классы HttpWebRequest и SmtpClient поддерживают расширенную защиту всякий раз, когда базовая версия Windows поддерживает расширенную защиту. Экземпляр HttpWebRequest отправляет SPN, созданный из Uri. По умолчанию экземпляр SmtpClient отправляет имя субъекта службы (SPN), сформированное из имени узла почтового сервера SMTP.

Для пользовательской проверки подлинности клиентские приложения могут использовать HttpWebRequest.EndGetRequestStream(IAsyncResult, TransportContext) или методы в HttpWebRequest.GetRequestStream(TransportContext) классе, которые позволяют получить HttpWebRequest и CBT с помощью TransportContext метода.

SPN, используемый для интегрированной аутентификации Windows, отправляемое экземпляром HttpWebRequest данной службе, можно переопределить, установив свойство CustomTargetNameDictionary.

Это TargetName свойство можно использовать для установки пользовательского имени субъекта-службы (SPN), применяемого для интегрированной аутентификации Windows в SMTP-подключении.

Расширенная защита для серверных приложений

HttpListener автоматически предоставляет механизмы проверки привязок служб при выполнении проверки подлинности HTTP.

Самый безопасный сценарий — включить расширенную защиту префиксов HTTPS:// . В этом случае установите значение HttpListener.ExtendedProtectionPolicy на ExtendedProtectionPolicy при значениях PolicyEnforcement установленных на WhenSupported или Always, а ProtectionScenario - на TransportSelected. Значение WhenSupported, которое помещает HttpListener в частично защищенный режим, в то время как Always соответствует полностью защищенному режиму.

В этой конфигурации, когда запрос выполняется на сервер через внешний безопасный канал, внешний канал запрашивается для привязки канала. Эта привязка канала передается вызовам SSPI для проверки подлинности, которые удостоверяют, что привязка канала совпадает с той, что содержится в объекте данных проверки подлинности. Существует три возможных результата:

  1. Базовая операционная система сервера не поддерживает расширенную защиту. Запрос не будет предоставлен приложению, и несанкционированный ответ (401) будет возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

  2. Вызов SSPI завершается сбоем, указывающий, что клиент указал привязку канала, которая не соответствовала ожидаемому значению, полученному из внешнего канала, или клиент не смог предоставить привязку канала при настройке Alwaysрасширенной политики защиты на сервере. В обоих случаях запрос не будет предоставлен приложению, а несанкционированный ответ (401) будет возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

  3. Клиент указывает правильную привязку канала или может подключаться без указания привязки канала, так как расширенная политика защиты на сервере настроена с WhenSupported. Запрос возвращается приложению для обработки. Проверка имени службы не выполняется автоматически. Приложение может выполнить собственную проверку имени службы с помощью ServiceName свойства, но в этих случаях она является избыточной.

Если приложение выполняет собственные вызовы SSPI для выполнения проверки подлинности на основе передаваемых данных внутри тела HTTP-запроса и хочет поддерживать привязку канала, необходимо получить ожидаемую привязку от внешнего защищенного канала, используя HttpListener, чтобы передать её в собственную функцию Win32 AcceptSecurityContext. Для этого используйте свойство TransportContext и вызовите метод GetChannelBinding, чтобы получить CBT. Поддерживаются только привязки конечных точек. Если указано что-то другое Endpoint, будет выброшено NotSupportedException. Если базовая операционная система поддерживает привязку каналов, GetChannelBinding метод вернет ChannelBindingSafeHandle, оборачивающий указатель на привязку канала, подходящую для передачи в функцию AcceptSecurityContext в качестве члена pvBuffer структуры SecBuffer, передаваемого pInput параметру. Свойство Size содержит длину в байтах привязки канала. Если базовая операционная система не поддерживает привязки каналов, функция возвращается null.

Другой возможный сценарий — включить расширенную защиту префиксов HTTP:// , если прокси-серверы не используются. В этом случае установите значение HttpListener.ExtendedProtectionPolicy на ExtendedProtectionPolicy при значениях PolicyEnforcement установленных на WhenSupported или Always, а ProtectionScenario - на TransportSelected. Значение WhenSupported, которое помещает HttpListener в частично защищенный режим, в то время как Always соответствует полностью защищенному режиму.

Список имен разрешенных служб создается автоматически на основе префиксов, зарегистрированных в HttpListener. Этот список по умолчанию можно просмотреть с помощью DefaultServiceNames свойства. Если этот список не является исчерпывающим, приложение может указать коллекцию пользовательских имен службы в конструкторе для ExtendedProtectionPolicy класса, который будет использоваться вместо списка имен службы по умолчанию.

В этой конфигурации, когда запрос к серверу выполняется без внешнего защищенного канала, проверка подлинности происходит обычно, без проверки привязки канала. Если проверка подлинности выполнена успешно, контекст запрашивается для имени службы, предоставленного клиентом и проверяемого в списке допустимых имен служб. Существует четыре возможных результата:

  1. Базовая операционная система сервера не поддерживает расширенную защиту. Запрос не будет предоставлен приложению, и несанкционированный ответ (401) будет возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

  2. Базовая операционная система клиента не поддерживает расширенную защиту. WhenSupported В конфигурации попытка проверки подлинности будет выполнена успешно, и запрос будет возвращен приложению. Always В конфигурации попытка проверки подлинности завершится ошибкой. Запрос не будет предоставлен приложению, и несанкционированный ответ (401) будет возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

  3. Базовая операционная система клиента поддерживает расширенную защиту, но приложение не указало привязку службы. Запрос не будет предоставлен приложению, и несанкционированный ответ (401) будет возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

  4. Клиент указал служебную привязку. Привязка сервиса сравнивается со списком разрешённых привязок сервиса. Если оно совпадает, запрос возвращается приложению. В противном случае запрос не будет предоставлен приложению, а несанкционированный ответ (401) будет автоматически возвращен клиенту. Сообщение будет зарегистрировано в источнике трассировки HttpListener, указывая причину сбоя.

Если такой простой подход с использованием разрешенного списка приемлемых имен служб недостаточен, приложение может предоставить собственную валидацию имени службы путем запроса свойства ServiceName. В случаях 1 и 2 выше свойство возвращается null. В случае 3 возвращается пустая строка. В случае 4 возвращается имя службы, указанное клиентом.

Эти функции расширенной защиты также могут использоваться серверными приложениями для проверки подлинности с другими типами запросов и при использовании доверенных прокси-серверов.

См. также

  • Last updated on