Проверка подлинности Kerberos без ограниченного двойного прыжка с помощью Microsoft Edge (Chromium)

Применимо к: службы IIS

Введение

Настройка проверки подлинности Windows на основе протокола проверки подлинности Kerberos может быть сложной задачей, особенно при работе с сценариями, такими как делегирование удостоверений с внешнего сайта на серверную службу в контексте IIS и ASP.NET. Выполните действия, описанные в этой статье, чтобы настроить делегирование билетов на проверку подлинности и использовать службы с современным браузером, например Microsoft Edge версии 87 или более поздней.

В этой статье предполагается, что вы настраиваете архитектуру, похожую на архитектуру, представленную на схеме ниже:

• Компьютер Workstation-Client1 является частью того же active directory, что и основной веб-сервер, называемый Primary-IIS-SRV и сервером серверной части, который называется Backend-Web-SRV.
• Пользователи компьютера Workstation-Client1 будут входить на компьютер с помощью учетной записи Windows Active Directory.
• Затем он запустит браузер (Microsoft Edge), перейдите на веб-сайт, расположенный на веб-сервере, который является псевдонимом, используемым для primary-IIS-SRV, и проходить проверку подлинности через интегрированные проверка подлинности Windows с помощью Kerberos.
• Веб-сайт, расположенный на веб-сервере, будет выполнять HTTP-вызовы с использованием учетных данных пользователя, прошедших проверку подлинности, к API-Серверу (который является псевдонимом для Backend-Web-SRV) для получения данных приложения от имени пользователей с помощью делегирования учетных данных Kerberos.

Приведенные ниже действия помогут устранить неполадки в этом сценарии: программа установки работает с Internet Explorer, но при внедрении Microsoft Edge пользователи больше не смогут использовать функцию делегирования учетных данных. Чтобы использовать делегирование учетных данных Kerberos, сначала обратитесь к устранению неполадок Kerberos в Internet Explorer .

Ограниченное или неограниченное делегирование

В приведенном выше сценарии обе конфигурации позволяют пользователям делегировать учетные данные из сеанса пользователя на компьютере Workstation-Client1 серверу API серверной части при подключении через интерфейсный веб-сервер.

В конфигурации делегирования Kerberos удостоверение пула приложений выполняется на веб-сервере и настраивается в Active Directory для делегирования в любую службу. Учетная запись пула приложений, запущенная на веб-сервере, может делегировать учетные данные прошедших проверку подлинности пользователей веб-сайта, размещенного на этом сервере, любой другой службе в Active Directory. Например, SMTP-сервер, файловый сервер, сервер базы данных, другой веб-сервер и т. д. Это называется неограниченным делегированием, так как учетная запись пула приложений имеет разрешение (оно не ограничено), чтобы делегировать учетные данные любой службе, к ней обращается.

В конфигурации ограниченного делегирования учетная запись Active Directory, используемая в качестве удостоверения пула приложений, может делегировать учетные данные прошедших проверку подлинности пользователей только списку служб, которым было разрешено делегировать. Если веб-приложение, размещенное на сервере с именем Web-Server, также должно связаться с базой данных и пройти проверку подлинности от имени пользователя, то это имя субъекта-службы (SPN) необходимо добавить в список авторизованных служб.

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

Как узнать, используется ли запрос Kerberos, полученный клиентом для отправки на веб-сервер, использует ограниченное или неограниченное делегирование?

Используйте средство командной команды klist в Windows для перечисления кэша билетов Kerberos с клиентского компьютера (Рабочая станция-Client1 на схеме выше). Найдите билет с именем HTTP/<Name of Web-Server>. Примечание.< Имя веб-сервера> — это имя субъекта-службы, к которой вы хотите обратиться и пройти проверку подлинности через Kerberos. Билет также содержит несколько флагов. Два из них представляют интерес: forwardable и ok_as_delegate.

• Первый флаг указывает forwardable, что KDC (центр распространения ключей) может выдавать новый билет с новой маской сети при необходимости. Это позволяет пользователю войти в удаленную систему и для удаленной системы получить новый билет от имени пользователя, чтобы войти в другую серверную систему, как если бы пользователь вошел в удаленную систему локально.

• Второй флаг указывает, ok_as_delegate что учетная запись службы службы, которую пользователь пытается пройти проверку подлинности (в случае с приведенной выше схемой учетная запись пула приложений IIS, на которой размещен веб-приложение), является доверенным для неограниченного делегирования.

Если эти службы используют неограниченное делегирование, билеты на клиентском компьютере содержат ok_as_delegate и forwardable флаги. В большинстве случаев при настройке ограниченного ok_as_delegate делегирования билеты не содержат флаг, но содержат forwardable флаг.

Почему не ограничено делегирование работает в Internet Explorer, а не в Microsoft Edge?

При попытке пройти проверку подлинности на веб-сайте с помощью проверки подлинности на основе Kerberos браузер вызывает API Windows для настройки контекста проверки подлинности. Api, который имеется в вопросе, является InitializeSecurityContext. Этот API может получить ряд флагов, чтобы указать, разрешен ли браузеру delegatable получить билет, полученный пользователем. Билет помечается так, delegatable как служба, которая пытается пройти проверку подлинности, имеет право делегировать учетные данные без ограничений. Однако это не означает, что приложение пытается пройти проверку подлинности (в данном случае браузер) должна использовать эту емкость.

По умолчанию Internet Explorer передает флаг InitializeSecurityContext, указывающий, что если билет можно делегировать, то он должен быть. Microsoft Edge из версии 87 и выше не передает флаг InitializeSecurityContext только потому, что билет помечен флагом ok_as_delegate . Не рекомендуется использовать неограниченное делегирование в приложениях, так как оно предоставляет приложениям больше привилегий, чем требуется. Приложения могут делегировать удостоверение пользователя любой другой службе в домене и проходить проверку подлинности от имени пользователя, что не требуется для большинства приложений, использующих делегирование учетных данных. Приложения должны обращаться только к службам списка, указанным при настройке ограниченного делегирования.

По умолчанию Microsoft Edge работает с ограниченным делегированием, где веб-сайт IIS, работающий на веб-сервере, имеет право обратиться к сайту ВНУТРЕННЕГО API, размещенному на СЕРВЕРе API, как показано в конфигурации учетной записи удостоверения пула приложений из Active Directory ниже:

Включение edge-Chromium для работы с неограниченным делегированием в Active Directory

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

1. Установите административные шаблоны для центрального хранилища групповой политики в Active Directory (если он еще не присутствует).
2. Установите административные шаблоны Microsoft Edge.
3. Создайте объект групповой политики.
4. Измените конфигурацию групповой политики, чтобы разрешить неограниченное делегирование при проверке подлинности на серверах.
5. (Необязательно) Проверьте, использует ли Microsoft Edge правильные флаги делегирования.

Шаг 1. Установка административных шаблонов для Active Directory

1. Скачайте шаблоны из административных шаблонов (ADMX) (для Windows Server 2019).

2. Скачайте установщик и извлеките содержимое в папку вашего выбора. Его можно просто извлечь в указанное по умолчанию расположение пакета, которое является C:\Program Files (x86)\Microsoft Group Policy\обновление Windows 10 за октябрь 2018 г. (1809) версии 2\PolicyDefinitions.

3. После распаковки пакета найдите папку Sysvol на контроллере домена. Путь к папке — C:\Windows\SYSVOL\sysvol\. В папке Sysvol находится папка с тем же именем, что и имя Active Directory (в примере здесь, Oddessy.local). Перейдите в папку "Политики ". Если она не существует, создайте папку с именем "Определения политики", как показано ниже:

   

4. Скопируйте содержимое папки PolicyDefinitions (которая была извлечена из установщика в папку PolicyDefinitions ), созданную внутри домена в папке sysvol на контроллере домена.

   Примечание.

   Файлы, извлеченные установщиком, также содержат локализованное содержимое. Чтобы сэкономить место, передайте локализованные файлы только для нужных языков. Например, папка с именем fr-FR содержит все локализованное содержимое на французском языке.

5. После завершения передачи убедитесь, что шаблоны доступны в Active Directory. Для этого откройте оснастку "Управление групповыми политиками" консоли управления Майкрософт (нажмите клавишу Windows+R и введите gpmc.msc для запуска). В службе управления групповыми политиками найдите объект групповой политики и измените его.

   

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

Шаг 2. Установка административных шаблонов Microsoft Edge

Хотя у вас могут быть административные шаблоны политики на контроллере домена, вам по-прежнему придется установить файлы политики Microsoft Edge, чтобы иметь доступ к политике, предназначенной для включения неограниченного делегирования двойного прыжка через этот браузер. Чтобы установить файлы политики Microsoft Edge, выполните действия.

1. Перейдите на сайт загрузки Microsoft Edge для бизнеса.

2. Выберите версию, которую вы хотите скачать из раскрывающегося списка канала или версии . Рекомендуется последняя стабильная версия.

3. Выберите нужную сборку из раскрывающегося списка сборки и, наконец, целевую операционную систему из раскрывающегося списка платформы . После выбора появится еще две кнопки (кнопка и ссылка).

   

4. Щелкните GET POLICY FILES и примите лицензионное соглашение, чтобы скачать файл с именем MicrosoftEdgePolicyTemplates.cab. Этот файл содержит файлы определения политики для Microsoft Edge.

5. Дважды щелкните файл, чтобы изучить содержимое (ZIP-архив с тем же именем).

6. Извлеките содержимое ZIP-архива в папку на локальном диске. Извлеченное содержимое будет содержать папку с именем Windows , в которой вы найдете вложенную папку С именем Admx. Это будет содержать административные шаблоны, а также локализованные версии (их необходимо использовать на языке, отличном от английского).

   

7. Передайте файлы ADMX внутри той же папки в каталог Sysvol, в котором были переданы административные шаблоны из предыдущего файла (в примере выше: C:\Windows\SYSVOL\sysvol\odessy.local\Policies\PolicyDefinitions).

8. Откройте редактор групповой политики Active Directory и выберите существующий объект групповой политики для редактирования, чтобы проверить наличие недавно перенесенных шаблонов Microsoft Edge. Они будут находиться в папке с именем Microsoft Edge , расположенной под папкой административных шаблонов в представлении дерева:

   

Шаг 3. Создание объекта групповой политики

Вот как создать новый объект групповой политики с помощью оснастки MMC диспетчера групповых политик Active Directory:

1. Нажмите клавишу Windows+R, чтобы открыть меню "Запуск " на контроллере домена.
2. Введите Gpmc.msc , чтобы открыть консоль управления Майкрософт и загрузить оснастку диспетчера групповых политик Active Directory.
3. Найдите узел объектов групповой политики в представлении дерева консоли и щелкните правой кнопкой мыши узел, чтобы открыть контекстное меню.
4. Выберите элемент меню "Создать", введите имя групповой политики, которую вы хотите создать, и нажмите кнопку "ОК".

Шаг 4. Изменение конфигурации групповой политики, чтобы разрешить неограниченное делегирование при проверке подлинности на серверах

Последний шаг — включить политику, которая позволяет браузеру Microsoft Edge передавать ok_as_delegate флаг InitializeSecurityContext вызову API при выполнении проверки подлинности с помощью Kerberos на веб-сайт с поддержкой Windows. Если вы не знаете, используется ли браузер Microsoft Edge для проверки подлинности (и не NTLM), обратитесь к устранению неполадок Kerberos в Internet Explorer.

В редакторе групповой политики Active Directory выберите объект групповой политики, который будет применяться к компьютерам в Active Directory, из которого планируется разрешить конечным пользователям проходить проверку подлинности через проверку подлинности Kerberos и делегировать учетные данные серверным службам через неограниченное делегирование. Политика, которая позволит включить неограниченное делегирование из Microsoft Edge, находится в папке проверки подлинности Http шаблонов Microsoft Edge, как показано ниже:

Используйте этот параметр для настройки списка серверов, для которых разрешено делегирование билетов Kerberos.

Примечание.

Необходимо указать список серверов. В примере, используемом в начале этой статьи, необходимо добавить имя сервера Web-Server в список, чтобы разрешить веб-приложению внешнего веб-сервера делегировать учетные данные серверной части API-Server.

После применения нового объекта групповой политики к клиентским компьютерам в домене перейдите на страницу тестовой проверки подлинности на страницах диагностики для устранения неполадок встроенной проверки подлинности Windows и скачайте страницу whoami.aspx из репозитория примеров ASP.net на сайте GitHub. Он даст параметр ImpersonationLevel делегата вместо олицетворения сигнала о том, что делегирование учетных данных теперь разрешено.

Чтобы проверить правильность применения политики на клиентской рабочей станции, откройте новую вкладку Microsoft Edge и введите edge://policy.

Политика AuthNegotiateDelegateAllowlist должна быть задана, чтобы указать значения имен серверов, для которых Microsoft Edge разрешено выполнять делегирование билетов Kerberos. Если политика не отображается в списке, она не была развернута или развернута на неправильных компьютерах.

Шаг 5 (необязательно). Проверьте, использует ли Microsoft Edge правильные флаги делегирования.

Ниже приведен шаг устранения неполадок или необязательный этап проверки.

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

1. Используйте функцию ведения журнала, доступную в Microsoft Edge, чтобы запросить веб-сайт в браузере. Чтобы включить ведение журнала, сделайте следующее:

   1. Откройте новое окно Microsoft Edge и введите edge://net-export/.

   2. При трассировке используйте параметр "Включить файлы cookie и учетные данные". Без этого параметра данные уровня трассировки проверки подлинности будут опущены.

      

   3. Нажмите кнопку "Начать ведение журнала на диск " и укажите имя файла, в котором требуется сохранить трассировку.

   4. Откройте еще одну вкладку Microsoft Edge, перейдите на веб-сайт, на котором вы хотите выполнить интегрированные проверка подлинности Windows с помощью Microsoft Edge.

   5. После проверки подлинности вернитесь на предыдущую вкладку, в которой была включена трассировка и нажмите кнопку "Остановить ведение журнала ". Интерфейс трассировки указывает, где был записан файл, содержащий трассировку.

2. Используйте JSON-файл, содержащий трассировку, чтобы узнать, какие параметры браузер передал InitializeSecurityContext функции при попытке проверки подлинности. Чтобы проанализировать трассировку, используйте netlog_viewer.

3. Внутри проанализированной трассировки находится журнал событий, похожий на следующее:

   t=3076 [st=12]       +AUTH_LIBRARY_INIT_SEC_CTX  [dt=3]
                         --> flags = {"delegated":false,"mutual":false,"value":"0x00000000"}
                         --> spn = "HTTP/web-server.odessy.local"
   

   В этом журнале показано следующее:

   • AUTH_LIBRARY_INIT_SEC_CTX означает, что браузер вызывает функцию InitializeSecurityContext .
   • "delegated":false означает, что билет не должен быть делегирован даже в том случае, если билет помечен как delegatable.
   • "mutual":false означает, что клиент (браузер) не требует, чтобы сервер также прошел проверку подлинности в клиенте и доказать его удостоверение. Только клиент должен пройти проверку подлинности на сервере, чтобы подтвердить свое удостоверение.
   • HTTP/web-server.odessy.local — это имя субъекта-службы, используемое браузером при вызове проверки подлинности.

Дополнительная информация

Страницы диагностики для устранения неполадок встроенной проверки подлинности Windows