Проверка подлинности дайджест: Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint Server — SharePoint Server

Настройка дайджест-проверки подлинности на основе утверждений для веб-приложения в SharePoint Server — SharePoint Server





Twitter




LinkedIn




Facebook




Адрес электронной почты










  • Статья




ОБЛАСТЬ ПРИМЕНЕНИЯ:2013 2016 2019 Subscription Edition SharePoint в Microsoft 365

Вы можете настроить дайджест-проверку подлинности для одной или нескольких зон в веб-приложении на основе утверждений SharePoint Server. Веб-приложение — это веб-сайт служб IIS, который создает и использует SharePoint Server. Зоны представляют собой разные логические пути для получения доступа к одному веб-приложению. В каждом веб-приложении можно создать до пяти зон. Каждую зону представляет отдельный веб-сайт в IIS. Зоны позволяют применять разные условия доступа и политики для больших групп пользователей. Чтобы настроить дайджест-проверку подлинности для одной или нескольких зон в веб-приложении SharePoint Server, используйте консоль диспетчера IIS вместо центра администрирования SharePoint Server.

В отличие от обычной проверки подлинности дайджест-проверка подлинности шифрует учетные данные пользователя для повышения безопасности. Учетные данные пользователя отправляются в виде дайджеста сообщения MD5, в котором исходное имя пользователя и пароль не могут быть определены. При дайджест-проверке подлинности используется протокол с запросом и подтверждением, который требует от запросившей стороны представить действительные учетные данные в ответ на запрос с сервера. Для проверки подлинности относительно сервера клиент должен предоставить в ответ дайджест сообщения MD5, который содержит строку пароля общего секрета. Алгоритм хэша MD5 описан в стандарте RFC 1321. Сведения о доступе к RFC 1321 см. в разделе Internet Engineering Task Force (https://go.microsoft.com/fwlink/p/?LinkId=159913).

Подготовка к работе

Перед выполнением указанной процедуры проверьте соответствие следующим условиям:

  • Ваша система работает под управлением SharePoint Server.

  • Пользователь и сервер IIS должны быть членами или доверенными одного и того же домена.

  • Пользователи должны иметь действительную учетную запись Windows, хранимую в доменных службах Active Directory (AD DS) на контроллере домена.

  • Домен должен использовать контроллер домена Windows Server 2008 или Windows Server 2008 R2.

    Примечание.

    Для SharePoint Server 2016 домен должен использовать контроллер домена Windows Server 2012 R2 или Windows Server 2016

  • Вы понимаете дайджест-проверку подлинности для веб-трафика.

    Дополнительные сведения см. в статье Что такое дайджест-проверка подлинности? (/previous-versions/windows/it-pro/windows-server-2003/cc778868(v=ws.10))).

Настройка IIS для включения дайджест-проверки подлинности

Используйте консоль диспетчера Диспетчер IIS, чтобы настроить IIS для включения дайджест-проверки подлинности для одной или нескольких из следующих зон для веб-приложения с проверкой подлинности на основе утверждений:

  • По умолчанию

  • Интрасеть

  • Экстрасеть

Зона по умолчанию — это зона, которая создается первой при создании веб-приложения. Остальные зоны создаются путем расширения веб-приложения. Дополнительные сведения см. в статье Расширение веб-приложений на основе утверждений в SharePoint.

Настройка IIS для включения дайджест-проверки подлинности

  1. Убедитесь, что вы входите в группу «Администраторы» сервера, на котором настраиваются службы IIS.

  2. В меню Пуск выберите Администрирование и Диспетчер служб IIS, чтобы запустить консоль диспетчера Диспетчер IIS.

  3. Разверните узел Сайты в дереве консоли, щелкните веб-сайт IIS, соответствующий зоне веб-приложения, для которой необходимо настроить дайджест-проверку подлинности.

  4. В режиме просмотра возможностей в IIS дважды щелкните Проверка подлинности.

  5. В режиме просмотра возможностей в разделе Проверка подлинности щелкните правой кнопкой мыши Дайджест-проверка подлинности и нажмите кнопку Включить.

  6. Щелкните правой кнопкой мыши Дайджест-проверка подлинности и выберите пункт Изменить.

  7. В диалоговом окне Изменение параметров дайджест-проверки подлинности в текстовом поле Область введите соответствующую область и нажмите кнопку ОК.

    Область — это доменное имя DNS или IP-адрес, которые будут использовать учетные данные, проверенные в вашем внутреннем домене Windows. Необходимо настроить имя области для дайджест-проверки подлинности.

Теперь веб-сайт будет настроен на использование дайджест-проверки подлинности.

См. также

Концепции

Настройка обычной проверки подлинности для веб-приложений на основе утверждений

Другие ресурсы

Планирование методов проверки подлинности для пользователей в SharePoint Server

Расширение веб-приложений, основанных на утверждениях, в SharePoint






Методы проверки подлинности

В этом разделе представлен обзор методов проверки подлинности,
используемых Forefront TMG. включая следующие:

  • Проверка
    подлинности HTTP
  • Проверка подлинности на основе
    форм
  • Проверка подлинности
    сертификата клиента

Сведения о сценариях, в которых используются эти методы, см. в
разделе Общие
сведения о проверке подлинности в Forefront TMG.

Проверка подлинности HTTP

Forefront TMG поддерживает следующие типы проверки
подлинности HTTP:

  • Обычная
    проверка подлинности
  • Проверка подлинности Digest
    и WDigest
  • встроенная проверка
    подлинности Windows

Обычная проверка подлинности

Обычная проверка подлинности – широко применяемый
метод, который состоит в сборе таких сведений, как имя пользователя
и пароль. При обычной проверке подлинности сведения о пользователе
отправляют и получают в виде текстовых символов, которые можно
прочитать. Хотя пароли и имена пользователей подлежат шифрованию,
при обычной проверке подлинности шифрование не используется.

Ниже описывается, как происходит проверка подлинности
клиента при обычной проверке подлинности.

  1. Пользователю предлагается ввести имя и пароль для входа в
    учетную запись Windows.
  2. Forefront TMG получает HTTP-запрос с учетными данными
    пользователя и подтверждает их с помощью определенного сервера
    проверки подлинности (RADIUS или доменные службы Active Directory,
    LDAP-сервер используется только для входящих запросов).
  3. Для исходящих запросов веб-прокси Forefront TMG подтверждает
    учетные данные пользователя и затем определяет правила доступа. Для
    входящих запросов Forefront TMG использует учетные данные для
    проверки подлинности на опубликованном веб-сервере в соответствии с
    настроенным методом делегирования. Веб-сервер должен быть настроен
    на использование схемы проверки подлинности, которая соответствует
    методу делегирования, используемому Forefront TMG. Текстовый пароль
    кодируется с помощью Base64 до отправки по сети, однако это не
    шифрование, и если пароль будет перехвачен в сети анализатором
    сетевых пакетов, неавторизованные пользователи могут раскодировать
    и повторно использовать пароль.

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

Проверка подлинности Digest и
WDigest

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

Проверка подлинности дайджест использует протокол HTTP
1.1 согласно определению RFC 2617
(http://go.microsoft.com/fwlink/?LinkId=160622). Этот протокол
поддерживается не всеми обозревателями. Если обозреватель, не
поддерживающий протокол HTTP 1.1, запрашивает файл при
включенной проверке подлинности Digest, запрос отклоняется.
Проверка подлинности Digest может использоваться только в доменах
Windows.

Дайджест-проверка подлинности успешно применима, если
на контроллере домена в доменной службе Active Directory хранится
обратимая зашифрованная (текстовая) копия запроса пароля
пользователя. Чтобы разрешить хранение паролей в незашифрованном
текстовом виде, необходимо в доменной службе Active Directory
активировать настройку Хранить пароль с использованием
обратимого шифрования на вкладке Учетная запись. Также
пользователь может включить данную функцию, установив
соответствующую групповую политику. После настройки этого параметра
необходимо установить новый пароль для активации этой функции, так
как старый пароль не может быть определен.

W-дайджест, обновленная форма проверки подлинности
дайджест, используется, если Forefront TMG установлен в домене
Windows Server 2008. Проверка подлинности W-дайджест не требует,
чтобы в доменной службе Active Directory хранилась обратимая
зашифрованная копия пароля пользователя.

Проверка подлинности Digest и WDigest осуществляется
следующим образом:

  1. Клиент делает запрос.
  2. Forefront TMG отказывает в доступе и предлагает клиенту ввести
    имя пользователя и пароль для входа в учетную запись Windows.
    Примечание. При использовании W-дайджест имя пользователя и имя
    домена чувствительны к регистру и должны указываться точно так же,
    как они отображены в доменной службе Active Directory. Кроме этого
    для WDigest требуется ввести значение для пути доступа к URL.
    Например, запрос пользователя http://host.domain.tld не
    обрабатывается, поскольку отсутствует путь доступа к URL.
  3. Учетные данные пользователя проходят одностороннюю процедуру,
    наименование которой известно как хэширование. На выходе
    получается зашифрованный хэш или профиль сообщения. В него
    добавляются значения для идентификации пользователя, компьютера
    пользователя и домена. Чтобы исключить применение пользователем
    аннулированного пароля, добавляется отметка времени. Это явное
    преимущество перед обычной проверкой подлинности, поскольку
    снижается вероятность перехвата и использования пароля
    неавторизованным пользователем.

встроенная проверка подлинности
Windows

Встроенная проверка подлинности Windows использует
методы проверки подлинности NTLM, Kerberos и Negotiate. Это более
безопасные формы проверки подлинности, поскольку имя пользователя и
пароль хэшируются до отправления их по сети. Если включена проверка
подлинности NTLM, Kerberos или Negotiate, обозреватель пользователя
подтверждает пароль при помощи обмена криптографическими данными с
сервером Forefront TMG и хэширования.

Ниже описывается, как происходит проверка подлинности
клиента при встроенной проверке подлинности Windows.

  1. В зависимости от настроек обозревателя проверка подлинности
    может не запрашивать изначально имя пользователя и пароль. Если
    изначально не удается идентифицировать пользователя, обозреватель
    запрашивает имя пользователя и пароль для входа в учетную запись
    Windows, которые он обрабатывает с помощью встроенной проверки
    подлинности Windows. Веб-браузер продолжает запрашивать имя
    пользователя и пароль до тех пор, пока пользователь не введет
    достоверные сведения или не закроет диалоговое окно с запросом. Имя
    пользователя необходимо вводить в формате:
    домен\имя_пользователя
  2. Если изначально не удается идентифицировать пользователя,
    обозреватель запрашивает имя пользователя и пароль для входа в
    учетную запись Windows, которые он обрабатывает с помощью
    встроенной проверки подлинности Windows.
  3. Forefront TMG продолжает запрашивать имя пользователя и пароль
    до тех пор, пока пользователь не введет достоверные сведения или не
    закроет диалоговое окно с запросом.
Примечание.
  • Forefront TMG обращается к серверу доменной
    службы Active Directory каждый раз, когда требуется проверка
    подлинности NTLM. По этой причине рекомендуется создать защищенную
    сеть для доменной службы Active Directory и Forefront TMG для
    предотвращения доступа пользователей (как внешних, так и
    внутренних) к этому обмену информацией.
  • Поскольку проверка подлинности для внешних
    пользователей применяет метод NTLM, рекомендуется использовать
    SSL-шифрование трафика между Forefront TMG и клиентом. Проверка
    подлинности NTLM осуществляется для каждого соединения, а
    шифрование предупреждает повторное использование соединений
    унаследованными устройствами прокси в Интернете.

Проверка подлинности на основе форм

Проверка подлинности на основе форм в Forefront TMG
может использоваться для входящих запросов на опубликованные
веб-серверы.

Существует три типа проверки подлинности на основе
форм:

  • Форма для ввода пароля. В эту форму
    вводятся имя пользователя и пароль. Эти типы учетных данных
    необходим для проверки подлинности с помощью доменной службы Active
    Directory, LDAP и RADIUS.
  • Форма для ввода секретного кода. В эту
    форму вводятся имя пользователя и секретный код. Эти типы учетных
    данных необходим для проверки одноразовых паролей методами SecurID
    и RADIUS.
  • Форма для ввода секретного кода и
    пароля    . В эту форму вводятся имя пользователя и секретный код,
    а также имя пользователя и пароль. Имя пользователя и код доступа
    используются при проверке подлинности для доступа к Forefront TMG с
    помощью методов проверки подлинности одноразовых паролей SecurID
    или RADIUS, а имя пользователя и пароль — при методе
    делегирования.

Проверка подлинности сертификата клиента

Проверка подлинности сертификата клиента не
поддерживается для исходящих веб-запросов.

Для входящих запросов на опубликованные ресурсы
требование сертификата клиента может повысить безопасность
опубликованного сервера пользователя. Пользователи могут получить
сертификаты клиента в коммерческом (CA) или внутреннем центре
сертификации организации пользователя. Сертификаты могут быть в
виде смарт-карт или использоваться мобильными устройствами так,
чтобы они могли подключаться к Microsoft ActiveSync.

Сертификат должен согласовываться с учетной записью
пользователя. Когда пользователи делают запросы на опубликованные
ресурсы, сертификат клиента, отправленный в Forefront TMG,
передается на контроллер домена, который определяет соответствие
между сертификатами и учетными записями. Forefront TMG должен
являться членом домена. Сведения передаются обратно на Forefront
TMG для применения соответствующих правил политики межсетевого
экрана. Примечание. Forefront TMG не может передавать сертификаты
клиента на внутренний веб-сервер.

См. также

Основные понятия

Общие сведения о
проверке подлинности в Forefront TMG

Что такое дайджест-аутентификация? — Переполнение стека

спросил

Изменено
5 лет, 9 месяцев назад

Просмотрено
124 тыс. раз

Чем дайджест-аутентификация отличается от обычной аутентификации, кроме отправки учетных данных в виде обычного текста?

  • дайджест-аутентификация

4

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

Сервер предоставляет клиенту одноразовый номер (одноразовый номер), который он объединяет с именем пользователя, областью, паролем и запросом URI. Клиент запускает все эти поля с помощью метода хэширования MD5 для создания хеш-ключа.

Он отправляет этот хеш-ключ на сервер вместе с именем пользователя и областью для попытки аутентификации.

На стороне сервера тот же метод используется для генерации хеш-ключа, только вместо использования пароля, введенного в браузере, сервер ищет ожидаемый пароль для пользователя из своей базы данных пользователей. Он ищет сохраненный пароль для этого имени пользователя, выполняет тот же алгоритм и сравнивает его с тем, что отправил клиент. Если они совпадают, доступ предоставляется, в противном случае он может отправить обратно 401 Unauthorized (нет входа или неудачный вход) или 403 Forbidden (доступ запрещен).

Дайджест-аутентификация стандартизирована в RFC2617. В Википедии есть хороший обзор этого:

Вы можете думать об этом так:

  1. Клиент делает запрос
  2. Клиент возвращает одноразовый номер с сервера и запрос аутентификации 401
  3. Клиент отправляет обратно следующий массив ответов (имя пользователя, область, generate_md5_key (одноразовый номер, имя пользователя, область, URI, пароль_данный_пользователем_в_браузер)) (да, это очень упрощено)
  4. Сервер берет имя пользователя и область (плюс он знает URI, запрашиваемый клиентом) и ищет пароль для этого имени пользователя. Затем он выполняет свою собственную версию generate_md5_key(nonce, username, realm, URI, password_I_have_for_this_user_in_my_db)
  5. Он сравнивает вывод generate_md5(), который он получил, с тем, что отправил клиент, если они совпадают с тем, что клиент отправил правильный пароль. Если они не совпадают, отправленный пароль был неправильным.

7

Хэш учетных данных отправляется по сети.

 HA1 = MD5 (имя пользователя: область: пароль)

В Википедии есть отличная статья на эту тему

0

Единственный способ получить хэш HA1 учетных данных — это узнать пароль. Сервер знает HA1, но не знает пароль, который его сгенерировал. Если HA1 был известен злоумышленнику, он мог проникнуть в систему. Таким образом, это не передается по проводам. Перед этим выполняется дополнительный хеш, основанный на одноразовом номере и т. д., и это должно согласовываться с аналогичным вычислением, выполненным на сервере. Таким образом, пока сервер держит HA1 закрытым, система безопасна.

1

Зарегистрируйтесь или войдите в систему

Зарегистрируйтесь с помощью Google

Зарегистрироваться через Facebook

Зарегистрируйтесь, используя электронную почту и пароль

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Опубликовать как гость

Электронная почта

Требуется, но не отображается

Дайджест-аутентификация HTTP по сравнению с SSL

спросил

Изменено
8 лет, 5 месяцев назад

Просмотрено
26 тысяч раз

В чем разница между дайджест-аутентификацией HTTP и SSL с точки зрения производительности, безопасности и гибкости?

  • ssl
  • HTTP-аутентификация
  • дайджест

3

Плюсы и минусы дайджест-аутентификации HTTP довольно четко объясняются в статье на эту тему в Википедии — вы должны ее прочитать!

Проще говоря: HTTP Digest Auth защитит вас только от потери вашего открытого пароля злоумышленником (и, учитывая состояние безопасности MD5, возможно, даже не это).

Однако он широко открыт для атак типа «человек посередине», а также — в зависимости от реализации, поскольку большинство расширенных функций являются необязательными — воспроизведения, словаря и других форм атак.

Однако самая большая разница между HTTPS-соединением и HTTP-соединением, защищенным дайджест-аутентификацией, заключается в том, что первое все шифруется с помощью шифрования с открытым ключом, в то время как с последним содержимое отправляется в открытом виде.

Что касается производительности: из вышеперечисленных пунктов должно быть совершенно ясно, что вы получаете то, за что платите (с учетом циклов процессора).

Для «гибкости» я выберу: да?

1

Дайджест-аутентификация шифрует только учетные данные аутентификации (то есть имя пользователя и пароль, которые вы вводите в диалоговом окне аутентификации браузера)… SSL шифрует все на странице. Таким образом, SSL будет менее эффективным, и его настройка обычно требует больше усилий.