В браузере Chrome (и его вариациях) не отображается портал авторизации. Пользователь видит пустое окно со следующим содержимым:
Заголовок:
HTTP/1.1 407 Authorization Required
Содержимое страницы
<html> <!-- please auth via kerberos/NTLM ➜ </html>
Для подробной информации по работе с политиками в браузере, обратитесь к документации по адресу: https://www.chromium.org/administrators/linux-quick-start
В соответствии с инструкцией, нужно создать json-файл в директории managed:
touch /etc/opt/chrome/policies/managed/test_policy.json
Содержимое файла должно быть следующего вида:
{
"AuthServerWhitelist": "*.usergate.demo",
"AuthSchemes": "ntlm,negotiate"
}
“usergate.demo” необходимо заменить на доменное имя вашего домена.
В браузере Chrome открыть страницу политик about:policy.
Вы должны увидеть настройки прописанные в файле на открытой странице:
Если этих строк нет, значит браузеру не удалось загрузить политики из созданного файла. Проверьте права доступа, и другие возможные причины. Обратите внимание, различные браузеры имеют особенности в загрузке политик. Например браузер Chromium на Kali Linux автоматически не загружает описанные политики.
После проведенных манипуляций, браузер не способный произвести прозрачную Kerberos аутентификацию, будет перенаправлять пользователя на портал авторизации.
После авторизации на captive-портале с помощью NTLM для части запросов определяется только тип пользователей Known/Unknown.
При авторизации с использованием NTLM некоторые GET-запросы приходят от системы, а не от пользователя. В этом случае идентификация пользователя невозможна, поэтому такому пользователю присваивается тип Known. Для исправления данной ситуации необходимо в списке правил captive-портала включить и поставить первым правило Skip auth for Microsoft Internet checker, созданное по умолчанию для исключения подобных запросов из captive-портала.
Настроены несколько методов аутентификации (Kerberos, NTLM, локальный пользователь); используются несколько правил captive-портала без дополнительных условий (источник, назначение и т.п.), т.е. всегда срабатывает первое правило, для которого совпали все условия.
Добавьте в используемый профиль аутентификации сразу три метода аутентификации: Kerberos, NTLM и локальный пользователь. В соответствии с данным профилем:
О применении политик UserGate к пользователя читайте в соответствующей статье: Применение к пользователям политик UserGate.
Администратору даны права доступа Чтение и запись на раздел Политики сети ➜ Межсетевой экран. При попытке редактирования правил данного раздела отображается ошибка: У вас нет прав доступа.
Необходимы дополнительные разрешения на объекты: сценарии, серверы ICAP, профили защиты DoS и т.п.
Для возможности внесения изменений в политику межсетевого экранирования, помимо прав Чтение и запись на раздел Межсетевой экран, администратору необходимы разрешения на просмотр раздела Политики безопасности ➜ Сценарии.
Данное разрешение необходимо для работы с разделами Межсетевой экран, NAT и маршрутизация, Пропускная способность, Фильтрация контента, Правила защиты DoS (для раздела Правила защиты DoS также необходимы права на раздел Политики безопасности ➜ Профили DoS).
При изменении членства пользователя в доменных группах, UserGate NGFW не учитывает эти изменения.
Для того, чтобы UserGate NGFW обновил информацию о членстве в группах для пользователя, нужно:
После этого работа с обновленным пользователем нормализуется.
При работе с потоковыми сервисами (например, видеоконференция) периодически происходит обрыв связи.
Это штатное поведение, описанное в Руководстве Администратора. Параметр Время жизни авторизованного пользователя - это таймер, устанавливаемый при аутентификации пользователя. По его истечении сбрасываются все установленные с IP-адреса пользователя соединения.
Вы можете:
Как автоматизировать загрузку сертификатов на клиентское устройство с ОС Windows 11.
При тестировании технических решений бывает необходимо автоматизировать процесс загрузки пользовательских сертификатов на клиентское устройство с ОС Windows. Часто для этих целей в скриптах используется системная утилита certutil. Однако в Windows 11 утилита certutil загружает пользовательский сертификат некорректно. В качестве альтернативного метода загрузки сертификата на клиентском устройстве с ОС Windows 11 можно использовать следующую последовательность команд в PowerShell:
$pfx = new-object System.Security.Cryptography.X509Certificates.X509Certificate2
$pfx.import("C:\cert.pfx","1234","MachineKeySet, PersistKeySet")
$store = new-object System.Security.Cryptography.X509Certificates.X509Store("My","LocalMachine")
$store.open("MaxAllowed")
$store.add($pfx)
$store.close()
Подробнее об использованных атрибутах смотрите в статье: https://learn.microsoft.com/en-us/dotnet/api/system.security.cryptography.x509certificates.x509keystorageflags?view=net-8.0