Настройка Kerberos аутентификации в различных браузерах

В этой статья, мы рассмотрим, как настроить Kerberos аутентификацию для различных браузеров в домене Windows для прозрачной и безопасной аутентификации на веб-серверах без необходимости повторного ввода пароля в корпоративной сети. В большинстве современных браузерах (IE, Chrome, Firefox) имеется поддержка Kerberos, однако, чтобы она работала, нужно выполнить несколько дополнительных действий.

Чтобы браузер мог авторизоваться на веб-сервере, нужно, чтобы были выполнены следующие условия:

• Поддержка Kerberos должны быть включена на стороне веб-сервера (пример настройки Kerberos авторизации на сайте IIS)
• Наличие у пользователя прав доступа к серверу
• Пользователь должен быть аутентифицирован на своем компьютере в Active Directory с помощью Kerberos (должен иметь TGT — Kerberos Ticket Granting Ticket).

К примеру, мы хотим разрешить клиентам Kerberos авторизацию через браузер на всех веб серверах домена winitpro.ru (нужно использовать именно DNS или FQDN, а не IP адрес веб сервера)

Настройка Kerberos аутентификации в Internet Explorer

Рассмотрим, как включить Kerberos аутентификацию в Internet Explorer 11.

Откройте Свойства браузера -> Безопасность -> Местная интрасеть (Local intranet), нажмите на кнопку Сайты -> Дополнительно. Добавьте в зону следующие записи:

Далее перейдите на вкладку Дополнительно (Advanced) и в разделе Безопасность (Security) убедитесь, что включена опция Разрешить встроенную проверку подлинности Windows (Enable Integrated Windows Authentication).

Включаем Kerberos аутентификацию в Google Chrome

Чтобы SSO работала в Google Chrome, нужно настроить Internet Explorer вышеописанным способом (Chrome использует данные настройки IE). Кроме того, нужно отметить, что все новые версии Chrome автоматически определяют наличие поддержки Kerberos. В том случае, если используется одна из старых версий Chrome (Chromium), для корректной авторизации на веб-серверах с помощью Kerberos, его нужно запустить с параметрами:

«C:\Program Files (x86)\Google\Chrome\Application\chrome.exe” —auth-server-whitelist=»*.winitpro.ru» —auth-negotiate-delegate-whitelist=»*.winitpro.ru»

Либо эти параметры могут быть распространены через групповые политики для Chrome (политика AuthServerWhitelist) или строковый параметр реестра AuthNegotiateDelegateWhitelist (находится в ветке HKLM\SOFTWARE\Policies\Google\Chrome).

Для вступления изменений в силу нужно перезагрузить браузер и сбросить тикеты Kerberos командой klist purge (см. статью).

Настройка Kerberos аутентификации в Mozilla Firefox

По умолчанию поддержка Kerberos в Firefox отключена, чтобы включить ее, откройте окно конфигурации браузера (в адресной строке перейдите на адрес about:config). Затем в следующих параметрах укажите адреса веб-серверов, для которых должна использоваться Kerberos аутентификация.

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

Клиенты Kerberos разрешают адреса узлов IPv4 и IPv6 в именах субъектов-служб (SPN). Kerberos clients allow IPv4 and IPv6 address hostnames in Service Principal Names (SPNs)

Область применения. Windows Server (Semi-Annual Channel), Windows Server 2016 Applies To: Windows Server (Semi-Annual Channel), Windows Server 2016

Начиная с Windows 10 версии 1507 и Windows Server 2016, клиенты Kerberos можно настроить для поддержки имен узлов IPv4 и IPv6 в именах участников-служб. Beginning with Windows 10 version 1507 and Windows Server 2016, Kerberos clients can be configured to support IPv4 and IPv6 hostnames in SPNs.

По умолчанию Windows не будет пытаться выполнить проверку подлинности Kerberos для узла, если имя узла является IP-адресом. By default Windows will not attempt Kerberos authentication for a host if the hostname is an IP address. Она будет возвращаться к другим включенным протоколам проверки подлинности, таким как NTLM. It will fall back to other enabled authentication protocols like NTLM. Однако иногда приложения жестко используют IP-адреса, что означает, что приложение будет возвращаться к NTLM, а не использовать Kerberos. However, applications are sometimes hardcoded to use IP addresses which means the application will fall back to NTLM and not use Kerberos. Это может вызвать проблемы совместимости, так как среда переходит в отключенную среду NTLM. This can cause compatibility issues as environments move to disable NTLM.

Чтобы снизить влияние отключения NTLM, была введена новая возможность, которая позволяет администраторам использовать IP-адреса в качестве имен узлов в именах участников-служб. To reduce the impact of disabling NTLM a new capability was introduced that lets administrators use IP addresses as hostnames in Service Principal Names. Эта возможность включена на клиенте с помощью значения раздела реестра. This capability is enabled on the client through a registry key value.

Чтобы настроить поддержку имен узлов в именах участников-служб, создайте запись Трипспн. To configure support for IP address hostnames in SPNs, create a TryIPSPN entry. Эта запись не существует в реестре по умолчанию. This entry does not exist in the registry by default. После создания записи измените значение DWORD на 1. After you have created the entry, change the DWORD value to 1. Это значение реестра необходимо установить на каждом клиентском компьютере, которому требуется доступ к ресурсам, защищенным с помощью Kerberos, по IP-адресу. This registry value will need to be set on each client machine that needs to access Kerberos-protected resources by IP address.

Настройка имени субъекта-службы в качестве адреса IP Configuring a Service Principal Name as IP Address

Имя субъекта-службы — это уникальный идентификатор, используемый при проверке подлинности Kerberos для идентификации службы в сети. A Service Principal Name is a unique identifier used during Kerberos authentication to identify a service on the network. SPN состоит из службы, имени узла и, при необходимости, порта в виде, service/hostname[:port] например host/fs.contoso.com . An SPN is composed of a service, hostname, and optionally a port in form of service/hostname[:port] such as host/fs.contoso.com . Windows будет регистрировать несколько имен участников-служб в объекте компьютера при присоединении компьютера к Active Directory. Windows will register multiple SPNs to a computer object when a machine is joined to Active Directory.

IP-адреса обычно не используются вместо имен узлов, так как IP-адреса часто являются временными. IP addresses are not normally used in place of hostnames because IP addresses are often temporary. Это может привести к конфликтам и ошибкам проверки подлинности в случае истечения срока действия аренды адресов и продления сроков. This can lead to conflicts and authentication failures as address leases expire and renew. Поэтому регистрация SPN на основе IP-адреса выполняется вручную и должна использоваться, только если невозможно переключиться на имя узла на основе DNS. Therefore registering an IP address-based SPN is a manual process and should only be used when it’s impossible to switch to a DNS-based hostname.

Как включить ведение журнала событий Kerberos

В этой статье описывается, как включить ведение журнала событий Kerberos.

Исходная версия продукта: Windows Server 2019, Windows Server 2016, Windows Server 2012 R2, Windows 10 версии 1809 и более поздних версий, Windows 7 Пакет обновления 1
Исходный номер КБ: 262177

Аннотация

Windows 7 Пакет обновления 1, Windows Server 2012 R2 и более поздних версий предоставляют возможность трассить подробные события Kerberos через журнал событий. Эти сведения можно использовать при устранении неполадок Kerberos.

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

Примеры ошибок ложного срабатываирования:

KDC_ERR_PREAUTH_REQUIRED возвращается по первоначальному запросу Kerberos AS. По умолчанию клиент Windows Kerberos не включит данные предварительной проверки подлинности в этот первый запрос. Ответ содержит сведения о поддерживаемых типах шифрования в KDC, а в случае AES — о солях, которые будут использоваться для шифрования хеш-кодов паролей.

Рекомендация: всегда игнорируйте этот код ошибки.

KDC_ERR_S_BADOPTION используется клиентом Kerberos для получения билетов с определенным набором параметров, например с определенными флагами делегирования. Если запрашиваемая возможность делегирования не является возможной, возвращается ошибка. Затем клиент Kerberos попытается получить запрашиваемую заявку с помощью других флагов, которые могут быть успешными.

Рекомендация: если не возникла проблема делегирования, игнорируйте эту ошибку.

KDC_ERR_S_PRINCIPAL_UNKNOWN регистрируются в журнале для различных проблем, связанных с взаимодействием клиента приложения и сервера. Причиной может быть:

• Отсутствуют или дублируются SPNs, зарегистрированные в AD.
• Неправильные имена серверов или DNS-суффиксы, используемые клиентом, например, клиент использует записи DNS CNAME и использует итоговую запись A в SPN.
• Использование имен серверов без FQDN, которые необходимо разрешить за пределами леса AD.

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

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

Рекомендация. Как и KDC_ERR_S_PRINCIPAL_UNKNOWN, проверьте правильность задаваемой spN.

Другие сценарии или ошибки требуют внимания системных администраторов или администраторов домена.

В этот раздел, описание метода или задачи включены действия, содержащие указания по изменению параметров реестра. Однако неправильное изменение параметров реестра может привести к возникновению серьезных проблем. Поэтому следует в точности выполнять приведенные инструкции. Для дополнительной защиты создайте резервную копию реестра, прежде чем редактировать его. Так вы сможете восстановить реестр, если возникнет проблема. Дополнительные сведения см. в сведениях о том, как создать и восстановить реестр в Windows.

Включить ведение журнала событий Kerberos на определенном компьютере

Откройте редактор реестра.

Добавьте следующее значение реестра:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Значение реестра: LogLevel
Тип значения: REG_DWORD
Значение: 0x1

Если подмайка Parameters не существует, создайте его.

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

Закройте редактор реестра. Этот параметр начнет действовать сразу в Windows Server 2012 R2, Windows 7 и более поздних версиях.

В системном журнале можно найти любые события, связанные с Kerberos.

Дополнительные сведения

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

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

Например, журнал событий 3 об ошибке Kerberos с кодом ошибки 0x7 KDC_ERR_S_PRINCIPAL_UNKNOWN for Server Name cifs/ будет регистрироваться при доступе к совместному доступу с IP-адресом сервера без имени сервера. Если эта ошибка зарегистрирована, клиент Windows автоматически пытается вернуться к проверке подлинности NTLM для учетной записи пользователя. Если эта операция работает, ошибка не будет.

Kerberos с именем субъекта-службы (SPN) Kerberos with Service Principal Name (SPN)

Область применения: Windows Server 2019 Applies to: Windows Server 2019

Сетевой контроллер поддерживает несколько методов проверки подлинности для взаимодействия с клиентами управления. Network Controller supports multiple authentication methods for communication with management clients. Вы можете использовать проверку подлинности на основе Kerberos, аутентификацию X509 на основе сертификата. You can use Kerberos based authentication, X509 certificate-based authentication. Вы также можете использовать проверку подлинности без аутентификации для тестовых развертываний. You also have the option to use no authentication for test deployments.

System Center Virtual Machine Manager использует проверку подлинности на основе Kerberos. System Center Virtual Machine Manager uses Kerberos-based authentication. При использовании проверки подлинности на основе Kerberos необходимо настроить имя участника-службы (SPN) для сетевого контроллера в Active Directory. If you are using Kerberos-based authentication, you must configure a Service Principal Name (SPN) for Network Controller in Active Directory. Имя участника-службы — это уникальный идентификатор экземпляра службы сетевого контроллера, который используется проверкой подлинности Kerberos для связывания экземпляра службы с учетной записью входа службы. The SPN is a unique identifier for the Network Controller service instance, which is used by Kerberos authentication to associate a service instance with a service login account. Дополнительные сведения см. в разделе имена субъектов-служб. For more details, see Service Principal Names.

Настройка имен субъектов-служб (SPN) Configure Service Principal Names (SPN)

Сетевой контроллер автоматически настраивает имя субъекта-службы. The Network Controller automatically configures the SPN. Все, что нужно сделать, — предоставить разрешения на компьютеры сетевого контроллера для регистрации и изменения имени участника-службы. All you need to do is to provide permissions for the Network Controller machines to register and modify the SPN.

На компьютере контроллера домена запустите Active Directory пользователи и компьютеры. On the Domain Controller machine, start Active Directory Users and Computers.

Выберите вид > Дополнительно. Select View > Advanced.

В разделе Компьютерынайдите одну из учетных записей компьютера сетевого контроллера, а затем щелкните ее правой кнопкой мыши и выберите пункт свойства. Under Computers, locate one of the Network Controller machine accounts, and then right-click and select Properties.

Перейдите на вкладку Безопасность и нажмите кнопку Дополнительно. Select the Security tab and click Advanced.

Если в списке не указаны все учетные записи компьютера сетевого контроллера или группы безопасности с учетными записями всех компьютеров сетевого контроллера, нажмите кнопку Добавить , чтобы добавить их. In the list, if all the Network Controller machine accounts or a security group having all the Network Controller machine accounts is not listed, click Add to add it.

Для каждой учетной записи компьютера сетевого контроллера или одной группы безопасности, содержащей учетные записи компьютера сетевого контроллера: For each Network Controller machine account or a single security group containing the Network Controller machine accounts:

а. a. Выберите учетную запись или группу и нажмите кнопку изменить. Select the account or group and click Edit.

b. b. В разделе Разрешения выберите проверить запись перезаписи. Under Permissions select Validate Write servicePrincipalName.

d. d. Прокрутите вниз и в разделе Свойства выберите: Scroll down and under Properties select:

Чтение и считывание Read servicePrincipalName

Написание перезаписи Write servicePrincipalName

д) e. Щелкните дважды ОК. Click OK twice.

Повторите шаг 3-6 для каждого компьютера сетевого контроллера. Repeat step 3 — 6 for each Network Controller machines.

Закройте окно Пользователи и компьютеры Active Directory. Close Active Directory Users and Computers.

Не удалось предоставить разрешения для регистрации или изменения имени участника-службы Failure to provide permissions for SPN registration/modification

В новом развертывании Windows Server 2019, если выбран параметр Kerberos для проверки подлинности клиента RESTful и не предоставлено разрешение узлам сетевого контроллера регистрировать или изменять имя участника-службы, операции RESTful на сетевом контроллере не позволяют управлять Sdn. On a NEW Windows Server 2019 deployment, if you chose Kerberos for REST client authentication and don’t grant permission for Network Controller nodes to register or modify the SPN, REST operations on Network Controller fails preventing you from managing the SDN.

Для обновления с Windows Server 2016 до Windows Server 2019 и выбора протокола Kerberos для проверки подлинности клиента RESTFUL операции RESTFUL не блокируются, что обеспечивает прозрачность для существующих рабочих развертываний. For an upgrade from Windows Server 2016 to Windows Server 2019, and you chose Kerberos for REST client authentication, REST operations do not get blocked, ensuring transparency for existing production deployments.

Если имя участника-службы не зарегистрировано, то для проверки подлинности клиента используется менее безопасный протокол NTLM. If SPN is not registered, REST client authentication uses NTLM, which is less secure. Вы также получаете критическое событие в канале администрирования канала событий нетворкконтроллер-Framework , предлагающего предоставить разрешения на узлы сетевого контроллера для регистрации SPN. You also get a critical event in the Admin channel of NetworkController-Framework event channel asking you to provide permissions to the Network Controller nodes to register SPN. После предоставления разрешения сетевой контроллер регистрирует имя участника-службы автоматически, а все операции клиента используют протокол Kerberos. Once you provide permission, Network Controller registers the SPN automatically, and all client operations use Kerberos.

Как правило, в сетевом контроллере можно настроить использование IP-адреса или DNS-имени для операций на основе службы «сеть — сеть». Typically, you can configure Network Controller to use an IP address or DNS name for REST-based operations. Однако при настройке Kerberos нельзя использовать IP-адрес для запросов RESTFUL к сетевому контроллеру. However, when you configure Kerberos, you cannot use an IP address for REST queries to Network Controller. Например, можно использовать , но нельзя использовать . For example, you can use , but you cannot use . Имена субъектов-служб не могут работать, если используются адреса IP. Service Principal Names cannot function if IP addresses are used.

Если вы использовали IP-адрес для операций RESTFUL вместе с проверкой подлинности Kerberos в Windows Server 2016, фактическое взаимодействие потребовалось бы через проверку подлинности NTLM. If you were using IP address for REST operations along with Kerberos authentication in Windows Server 2016, the actual communication would have been over NTLM authentication. В таком развертывании после обновления до Windows Server 2019 продолжает использоваться проверка подлинности на основе NTLM. In such a deployment, once you upgrade to Windows Server 2019, you continue to use NTLM-based authentication. Чтобы перейти на проверку подлинности на основе Kerberos, необходимо использовать DNS-имя сетевого контроллера для операций RESTFUL и предоставить разрешение узлам сетевого контроллера зарегистрировать SPN. To move to Kerberos-based authentication, you must use Network Controller DNS name for REST operations and provide permission for Network Controller nodes to register SPN.