# Не работает аутентификация Kerberos
# Симптомы
*Доменные пользователи не могут пройти прозрачную авторизацию \ аутентификацию Kerberos, соответственно не могут выйти в интернет через Usergate. Любые принимаемые настройки приводят к тому, что у пользователя открывается окно captive-портала, где требуется ввести логин пароль доменного пользователя для дальнейшего доступа к интернет*
*В некоторых случаях адреса их компьютеров оказываются в устройствах BYOD.*
# Решение
1. Проверить настройки в соответствии с данной статьей:
[https://docs.usergate.com/avtorizaciya-s-pomosh6yu-kerberos\_15.html](https://docs.usergate.com/avtorizaciya-s-pomosh6yu-kerberos_15.html)
2. Включить SSL-инспектирование для Unknown пользователей, чтобы иметь возможность произвести аутентификацию при использовании HTTPS-протокола, иначе аутентификация будет возможна только через HTTP-протокол (если используется direct прокси, то не требуется).
3. Отключить галку "Разрешить браузерам запоминать аутентификацию" в свойствах captive-профиля.
4. Проверьте, что время на UserGate синхронизировано с контроллером домена.
5. Убедитесь, что пользователь осуществляет аутентификацию в домене по протоколу kerberos, информацию можно получить на AD в журналы Windows - Безопасность - код события 4624, либо записать трафик на контроллере домена с помощью Wireshark.
# Диагностика
1\) На тестовой машине укажите FQDN домена Auth в качестве явного прокси
2\) Выполните logout пользователя через CLI на UG (execute terminate usersession IP\_ADDRESS) или с помощью страницы logout.domain.local (logout нажимать, пока не появится красная надпись "no such user")
3\) На клиенте запишите трафик через Wireshark при обращении к сайту [http://cbr.ru](http://cbr.ru/) (тут важно HTTP)
4\) Найдите в трафике GET запрос к cbr.ru по коду события "407 Authentication required". Если в этом событии будет присутствовать NTLMSSP\_NEGOTIATE, делаем вывод, что запрос от клиента проходит не по Kerberos, а по NTLM.
Пример дампа с запросом NTLM:
Пример дампа с запросом Kerberos:
Если видите NTLM, вместо Kerberos, необходимо:
* Разобраться, по какой причине на клиенте вместо Kerberos уходит запрос NTLM. Например это может быть при недоступной сетевой связанности между клиентом и сервером по портам Kerberos. Также бывают случаи, когда на клиенте указан не тот домен Auth captive-портала, который был указан в общих параметрах UG, или с которым генерировался файл keytab, из-за чего в дампе трафика можно увидеть ошибки Kerberos.
* Проверить, что в качестве адреса прокси-сервера на клиенте используется FQDN, а не IP-адрес.
* Проверить, что в системных настройках прокси снята галка "Автоматическое определение настроек"
* Проверить, чтобы в настройках NTP сервера на NGFW был указан контроллер домена
Если выяснить причину не удаётся, добавьте метод NTLM вторым по очереди в профиле аутентификации, настроенный по следующей инструкции [https://docs.usergate.com/avtorizaciya-s-pomosh6yu-ntlm\_16.html](https://docs.usergate.com/avtorizaciya-s-pomosh6yu-ntlm_16.html)
### Не работает аутентификация Kerberos на Windows 7
В Windows 7 имеются некоторые алгоритмы шифрования для Kerberos, но по умолчанию они отключены.
Для их включения необходимо выполнить следующие шаги, согласно официальной документации Microsoft:
```txt
Измените локальные параметры безопасности. Введите команду secpol.msc через «Выполнить» и перейдите в следующий раздел:
"Локальная политика безопасности - Локальные политики - Параметры безопасности - Безопасность сети: Настройка разрешенных типов шифрования для Kerberos"
Включите все параметры в этой категории, и аутентификация Kerberos должна заработать на Windows 7.
```
Оригинальный источник:
[https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos](https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos)
### Не работает аутентификация Kerberos на Windows 10/Windows 11
Включите поддержку AES в доменных довериях. Для этого нужно открыть «Домены и доверия» Active Directory и перейти в нужный домен.
Затем нажать на домен правой кнопкой мыши и выбрать «Свойства». Перейти на вкладку «Доверительные отношения» и проверить в поле «Домены, которые доверяют этому домену (входящие доверительные отношения)» соответствующий домен-партнёр. Затем снова нажать на «Свойства» и активировать поле «Другой домен поддерживает шифрование Kerberos AES». После этого нужно нажать «ОК».
О методе настройка доверия и настройки клиента для поддержки шифрования AES128 и AES 256 в дополнение к шифрованию RC4 можно ознакомиться здесь:
[https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/windows-security/unsupported-etype-error-accessing-trusted-domain](https://learn.microsoft.com/ru-ru/troubleshoot/windows-server/windows-security/unsupported-etype-error-accessing-trusted-domain)