Серверы аутентификации

ID статьи: 96
Последнее обновление: 02 авг, 2023
Documentation:
Version: 6.1.9, 5.x
Внимание! На версиях UserGate старше 6.1.8 этот раздел носит название Сервера авторизации.

"Серверы аутентификации" - это внешние источники учетных записей пользователей(сервера аутентификации), например, LDAP-сервер, или серверы, производящие аутентификацию для UserGate, например, Radius, TACACS+, Kerberos, SAML. Система поддерживает следующие типы серверов аутентификации:

  • LDAP-коннектор.

  • Сервер аутентификации пользователей Radius.

  • Сервер аутентификации пользователей TACACS+.

  • Сервер аутентификации Kerberos.

  • Сервер аутентификации NTLM.

  • Сервер аутентификации SAML (SSO).

Серверы аутентификации Radius, TACACS+, NTLM, SAML могут осуществлять только аутентификацию пользователей, в то время как LDAP-коннектор позволяет также получать информацию о пользователях и их свойствах.

LDAP-коннектор

LDAP-коннектор позволяет:

  • Получать информацию о пользователях и группах Active Directory или других LDAP-серверов. Поддерживается работа с LDAP-сервером FreeIPA. Пользователи и группы могут быть использованы при настройке правил фильтрации.

  • Осуществлять аутентификацию пользователей через домены Active Directory/FreeIPA с использованием методов аутентификации Captive-портал, Kerberos, NTLM.

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

Наименование

Описание

Включено

Включает или отключает использование данного сервера аутентификации.

Название

Название сервера аутентификации.

SSL

Определяет, требуется ли SSL-соединение для подключения к LDAP-серверу.

Доменное имя LDAP или IP-адрес

IP-адрес контроллера домена или название домена LDAP. Если указано доменное имя, то UserGate получит адрес сервера LDAP с помощью DNS-запроса.

Bind DN («login»)

Имя пользователя, которое необходимо использовать для подключения к серверу LDAP. Имя необходимо использовать в формате DOMAIN\username или username@domain. Данный пользователь уже должен быть заведен в домене.

Пароль

Пароль пользователя для подключения к домену.

Домены LDAP

Список доменов, которые обслуживаются указанным контроллером домена, например, в случае дерева доменов или леса доменов Active Directory. Здесь же можно указать короткое netbios имя домена. Список доменов, указанный здесь будет использован для выбора на странице авторизации Captive-портала при включении соответствующей опции. Более подробно о настройке Captive-портала смотрите раздел Настройка Captive-портала.

Пути поиска

Список путей в сервере LDAP, начиная с которых система будет осуществлять поиск пользователей и групп. Необходимо указывать полное имя, например, ou=Office,dc=example,dc=com.

Kerberos keytab

Здесь можно загрузить keytab-файл для аутентификации Kerberos. Подробно об аутентификации Kerberos и создании keytab-файла смотрите в разделе Метод аутентификации Kerberos.

Примечание Рекомендуется загрузить keytab-файл даже в случае, если вы не планируете использовать авторизацию Kerberos. При загруженном keytab-файле UserGate использует механизм kerberos для получения списка пользователей и их групп с серверов LDAP, что очень сильно снижает нагрузку на серверы LDAP. Если у вас в организации серверы LDAP содержат большое количество объектов (более 1000 групп и пользователей) использование keytab-файла обязательно.

После создания сервера необходимо проверить корректность параметров, нажав на кнопку Проверить соединение. Если параметры указаны верно, система сообщит об этом либо укажет на причину невозможности соединения.

Примечание

Для аутентификации пользователей с помощью LDAP-коннектора необходимо, чтобы пользователи входили в доменную группу Domain users.

Настройка LDAP-коннектора завершена. Для авторизации LDAP пользователей по имени и паролю необходимо создать правила Captive-портала. Более подробно о Captive-портале рассказывается в следующих главах руководства.

Для добавления пользователя или группы пользователей LDAP в правила фильтрации необходимо нажать на Добавить пользователя LDAP/Добавить группу LDAP, в поле поиска указать как минимум один символ, входящий в имена искомых объектов, после чего нажать на Поиск и выбрать желаемые группы/пользователей.

Сервер аутентификации пользователей Radius

Сервер аутентификации Radius позволяет аутентификацировать пользователей на серверах Radius, то есть UserGate выступает в роли Radius-клиента. При аутентификации через Radius-сервер UserGate посылает на серверы Radius информацию с именем и паролем пользователя, а Radius-сервер отвечает, успешно прошла аутентификация или нет.

Сервер Radius не может предоставить список пользователей в UserGate и, если пользователи не были заведены в UserGate предварительно (например, как локальные пользователи или получены из домена AD с помощью LDAP-коннектора), поэтому в политиках фильтрации можно использовать только пользователей типа Known (успешно прошедших авторизацию на сервере Radius) или Unknown (не прошедших аутентификацию).

Для создания сервера аутентификации Radius необходимо нажать на кнопку Добавить, выбрать Добавить Radius-сервер и указать следующие параметры:

Наименование

Описание

Включен

Включает или отключает использование данного сервера аутентификации.

Название сервера

Название сервера аутентификации.

Секрет

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

Хост

IP-адрес сервера Radius.

Порт

UDP-порт, на котором сервер Radius слушает запросы на аутентификацию. По умолчанию это порт UDP 1812.

После создания сервера аутентификации необходимо настроить Captive-портал для использования метода аутентификации Radius. Более подробно о Captive-портале рассказывается в следующих главах руководства.

Сервер аутентификации пользователей TACACS+

Сервер аутентификации TACACS+ позволяет аутентифицировать пользователей на серверах TACACS+. При аутентификации через TACACS+ сервер UserGate посылает на серверы TACACS+ информацию с именем и паролем пользователя, а сервер TACACS+ отвечает, успешно прошла аутентификация или нет.

Сервер TACACS+ не может предоставить список пользователей в UserGate и, если пользователи не были заведены в UserGate предварительно (например, как локальные пользователи или получены из домена AD с помощью LDAP-коннектора), поэтому в политиках фильтрации можно использовать только пользователей типа Known (успешно прошедших аутентификацию на сервере TACACS+) или Unknown (не прошедших аутентификацию).

Для создания сервера аутентификации TACACS+ необходимо нажать на кнопку Добавить, выбрать Добавить TACACS+ сервер и указать следующие параметры:

Наименование

Описание

Включен

Включает или отключает использование данного сервера аутентификации.

Название сервера

Название сервера аутентификации.

Секретный ключ

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

Адрес

IP-адрес сервера TACACS+.

Порт

UDP-порт, на котором сервер TACACS+ слушает запросы на аутентификации. По умолчанию это порт UDP 1812.

Использовать одно TCP-соединение

Использовать одно TCP-соединение для работы с сервером TACACS+.

Таймаут (сек)

Время ожидания сервера TACACS+ для получения аутентификации. По умолчанию 4 секунды.

Сервер аутентификации пользователей SAML IDP

Сервер аутентификации SAML IDP (Security Assertion Markup Language Identity Provider) позволяет аутентифицировать пользователей c помощью развернутой на предприятии системе Single Sign-On (SSO), например, Microsoft Active Directory Federation Service. Это позволяет пользователю единожды авторизовавшись в системе SSO прозрачно проходить авторизацию на всех ресурсах, поддерживающих аутентификацию SAML. UserGate может быть настроен в качестве SAML сервис-провайдера, использующего сервера SAML IDP для аутентификации клиента.

Внимание! Сервер SAML IDP не может предоставить свойства пользователей в UserGate поэтому, если не настроено подключение к домену AD с помощью LDAP-коннектора, в политиках фильтрации можно использовать только пользователей типа Known (успешно прошедших аутентификацию на сервере SAML) или Unknown (не прошедших аутентификацию).

Настройка ADFS

Для использования аутентификации с помощью сервера SAML IDP необходимо выполнить следующие шаги:

Наименование

Описание

Шаг 1. Создать DNS-записи для сервера UserGate.

На контроллере домена создать DNS-записи соответствующие серверу UserGate для использования в качестве домена для auth.captive, например, utm.domain.loc. В качестве IP-адреса укажите адрес интерфейса UserGate, подключенного в сеть Trusted.

Шаг 2. Настроить DNS-серверы на UserGate.

В настройках UserGate в качестве системных DNS-серверов указать IP-адреса контроллеров домена.

Шаг 3. Изменить адрес Домен auth captive-портала.

Изменить адрес Домен auth captive-портала в разделе Настройки на созданную на предыдущем шаге запись DNS. Подробно об изменении адреса домена Auth Captive-портала смотрите в разделе Общие настройки.

Шаг 4. Настроить сервер SAML IDP.

Статью по настройке Microsoft ADFS можно найти на сайте Microsoft.

Необходимо добавить на сервере SAML IDP запись о сервис-провайдере USERGATE, указывая созданное на шаге 1 FQDN имя.

В процессе установки ADFS будет сгенерирована ссылка на xml-файл вида https://<adfs-server>/federationmetadata/2007-06/federationmetadata.xml  с конфигурацией и сертификатом ADFS. Эта ссылка понадобится для настройки сервера SAML-авторизации на UserGate NGFW.

Шаг 5. Создать сервер авторизации пользователей SAML IDP.

Создать в USERGATE сервер аутентификации пользователей SAML IDP.

Настройка UserGate NGFW

Для создания сервера аутентификации пользователей SAML IDP необходимо в разделе Пользователи и устройства ➜ Серверы авторизации нажать на кнопку Добавить, выбрать Добавить SAML IDP-сервер выполнив следующие шаги

 

Наименование

Описание

Шаг 1. Заполнить поле SAML metadata URL

SAML metadata URL - это путь где можно скачать xml-файл (полученный ранее при настройке ADFS) с корректной конфигурацией для сервис-провайдера (клиента) SAML. Также заполнить все необоходимые поля кроме кроме  URL для метаданных SAML IDP (оно появится после сохранения).

Шаг 2. Нажать на кнопку Загрузить

При этом происходит заполнение необходимых полей настройки сервера аутентификации данными, полученными из xml-файла.

Шаг 3. Нажать кнопку Сохранить

При этом произойдет автоматическое заполнение поля URL для метаданных SAML IDP.

Шаг 4. Открыть для редактирования только что созданный SAML IDP сервер.

Теперь можно скопировать автоматически сгенерированную ссылку на файл метаданных UserGate NGFW из поля URL для метаданных SAML IDP.

Шаг 5. Передать метаданные UserGate NGFW на сервер ADFS

С помощью данной ссылки нужно передать данные на ADFS сервер (в настройках ADFS сервера загрузить этот файл аналогично как это сделано на UserGate NGFW.).

Это предпочтительный метод настройки сервера аутентификации SAML IDP.

Описание полей Сервера авторизации доступных для заполнения:

Наименование

Описание

Включен

Включает или отключает использование данного сервера аутентификации.

Название сервера

Название сервера аутентификации.

Описание

Описание сервера аутентификации.

SAML metadata URL

URL до файла метаданных сервера ADFS, который необходимо получить. Создается при настройке ADFS.

Сертификат SAML IDP

Сертификат, который будет использован в SAML-клиенте. Возможны варианты:

  • Создать новый сертификат из скачанного - если при настройке был использован метод загрузки xml- файла, то сертификат автоматически создается и ему назначается роль SAML IDP (смотрите раздел Управление сертификатами).

  • Использовать существующий сертификат. Сертификат уже должен быть создан или импортирован в разделе Сертификаты, и ему не должна быть назначена роль. После создания и сохранения сервера аутентификации этому сертификату будет назначена роль SAML IDP.

  • Не использовать сертификат.

Примечание Сертификат нужен для установки SSL\TLS соединения между ADFS и UserGate NGFW.

Single sign-on URL

URL, используемая в сервере SAML IDP в качестве единой точки входа. Смотрите документацию на используемый у вас сервер SAML IDP для более детальной информации.

Single sign-on binding

Метод, используемый для работы с единой точкой входа SSO. Возможны варианты POST и Redirect. Смотрите документацию на используемый у вас сервер SAML IDP для более детальной информации.

Single logout URL

URL, используемый в сервере SAML IDP в качестве единой точки выхода. Смотрите документацию на используемый у вас сервер SAML IDP для более детальной информации.

Single logout binding

Метод, используемый для работы с единой точкой выхода SSO. Возможны варианты POST и Redirect. Смотрите документацию на используемый у вас сервер SAML IDP для более детальной информации.

Сервер аутентификации NTLM

Аутентификация NTLM позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При аутентификации с помощью NTLM сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

Сервер NTLM не может предоставить список пользователей в UserGate и, если пользователи не были заведены в UserGate предварительно (например, как локальные пользователи или получены из домена AD с помощью LDAP-коннектора), поэтому в политиках фильтрации можно использовать только пользователей типа Known (успешно прошедших аутентификацию на сервере NTLM) или Unknown (не прошедших аутентификацию).

Аутентификация NTLM может работать как при явном указании прокси-сервера в браузере пользователя (это стандартный режим), так и в прозрачном режиме, когда прокси-сервер в браузере не указан. Настройка UserGate не отличается от режима работы аутентификации.

Для настройки аутентификации с помощью NTLM необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Настроить синхронизацию времени с контроллером домена.

В настройках UserGate включить синхронизацию времени с серверами NTP, в качестве основного и - опционально - запасного NTP-сервера указать IP-адреса контроллеров домена.

Шаг 2. Создать DNS-записи для сервера UserGate.

На контроллере домена создать DNS-записи, соответствующие серверу UserGate для использования в качестве домена для auth.captive и logout.captive, например, auth.domain.loc и logout.domain.loc.

В качестве IP-адреса укажите адрес интерфейса UserGate, подключенного в сеть Trusted.

Шаг 3. Изменить адрес Домен Auth Captive-портала.

Изменить адрес домена Auth Captive-портала и опционально адрес домена Logout Captive-портала в разделе Настройки.

Для домена Auth Captive-портала необходимо указать созданную на предыдущем шаге запись DNS.

Для домена Logout Captive-портала необходимо указать созданную на предыдущем шаге запись DNS.

Подробно об изменении адресов доменов Auth Captive-портала и Logout Captive-портала смотрите в разделе Настройка Captive-портала.

Шаг 4. Добавить NTLM-сервер авторизации.

В разделе Серверы авторизации нажать на кнопку Добавить, выбрать Добавить NTLM-сервер и указать название и имя домена Windows. Для корректной работы авторизации NTLM, необходимо, чтобы указанное здесь имя домена разрешалось(resolve) в IP-адреса контроллеров домена.

Шаг 5. Создать правило Captive-портала с авторизацией NTLM.

Настроить Captive-портал для использования метода авторизации NTLM. Более подробно о Captive-портале рассказывается в следующих главах руководства.

Шаг 6. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью NTLM

Шаг 7. Для авторизации в стандартном режиме настроить прокси-сервер на компьютерах пользователей.

На компьютерах пользователей указать обязательное использование прокси-сервера, указать IP-адрес Trusted интерфейса UserGate в качестве адреса прокси сервера.

Примечание Вместо IP-адреса можно использовать доменное имя, но для NTLM важно, чтобы это имя было не из домена Active Directory, иначе Windows-компьютер будет пытаться использовать аутентификацию Kerberos.
Важно! В настройках UserGate имена, используемые в качестве домена для auth.captive и logout.captive, не должны быть из домена Active Directory, иначе Windows-компьютер будет пытаться использовать аутентификацию Kerberos.

Шаг 8. Для авторизации в прозрачном режиме настроить автоматическую проверку подлинности пользователя браузером для всех зон.

На компьютерах пользователей зайдите в Панель управления ➜ Свойства браузера ➜ Безопасность, выберите зону Интернет ➜ Уровень безопасности ➜ Другой ➜ Проверка подлинности пользователя и установите Автоматический вход в сеть с текущем именем пользователя и паролем

(Control panel ➜ Internet options ➜ Security, выберите зону Internet ➜ Custom level ➜ User Authentication ➜ Logon и установите Automatic logon with current name and password)

Повторите данную настройку для всех других зон, настроенных на данном компьютере (Local intranet, Trusted sites).

Метод аутентификации Kerberos

Аутентификация Kerberos позволяет прозрачно (без запроса имени пользователя и его пароля) авторизовать пользователей домена Active Directory. При аутентификации через Kerberos сервер UserGate работает с контроллерами домена, которые выполняют проверку пользователя, который получает доступ в интернет.

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

Для аутентификации Kerberos необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать DNS-записи для сервера UserGate.

На контроллере домена создать DNS-записи, соответствующие серверу UserGate для использования в качестве домена для auth.captive и logout.captive, например, auth.domain.loc и logout.domain.loc

В качестве IP-адреса укажите адрес интерфейса UserGate, подключенного в сеть Trusted.

Примечание Для корректной работы создайте записи типа A, не используйте CNAME-записи.

Шаг 2. Создать пользователя для сервера UserGate.

Создать пользователя в домене AD, например, kerb@domain.loc с опцией password never expires. Установите пароль пользователю kerb.

Важно! Не используйте символы национальных алфавитов, например, кириллицу, в именах пользователя kerb или в организационных единицах Active Directory, где вы планируете создать учетную запись пользователя kerb.
Важно! Не используйте в качестве пользователя для Kerberos пользователя, созданного для работы LDAP-коннектора. Необходимо использовать отдельную учетную запись.

Шаг 3. Создать keytab-файл.

На контроллере домена, создать keytab файл, выполнив следующую команду из-под администратора (команда в одну строку!):

ktpass.exe /princ HTTP/auth.domain.loc@DOMAIN.LOC /mapuser kerb@DOMAIN.LOC /crypto ALL /ptype KRB5_NT_PRINCIPAL /pass * /out C:\utm.keytab

Введите пароль пользователя kerb.

Важно! Команда чувствительна к регистру букв. В данном примере:
auth.domain.loc - DNS-запись, созданная для сервера UserGate на шаге 1
DOMAIN.LOC - Kerberos realm domain, обязательно большими буквами!
kerb@DOMAIN.LOC - имя пользователя в домене, созданное на шаге 2, имя realm-домена обязательно большими буквами!

Шаг 4. Настроить DNS-серверы на UserGate.

В настройках UserGate в качестве системных DNS-серверов указать IP-адреса контроллеров домена.

Шаг 5. Настроить синхронизацию времени с контроллером домена.

В настройках UserGate включить синхронизацию времени с серверами NTP, в качестве основного и - опционально - запасного NTP-сервера указать IP-адреса контроллеров домена.

Шаг 6. Изменить адрес Домен auth captive-портала.

Изменить адрес Домен auth captive-портала и опционально адрес Домен logout captive-портала в разделе Настройки на созданные на предыдущем шаге записи DNS. Подробно об изменении адресов доменов смотрите в разделе Общие настройки.

Шаг 7. Создать LDAP-коннектор и загрузить в него keytab-файл.

Создать сервер аутентификации типа LDAP коннектор и загрузить полученный на предыдущем шаге keytab-файл.

Важно! Не используйте в качестве пользователя для LDAP-коннектора, пользователя, созданного ранее для работы Kerberos. Необходимо использовать отдельную учетную запись.

Подробно о настройке LDAP-коннектора смотрите раздел LDAP-коннектор.

Шаг 8. Создать правило Captive-портала с авторизацией Kerberos.

Настроить Captive-портал для использования метода аутентификации Kerberos. Более подробно о Captive-портале рассказывается в разделе Настройка Captive-портала.

Шаг 9. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью Kerberos.

Шаг 10. Для авторизации в стандартном режиме настроить прокси-сервер на компьютерах пользователей.

На компьютерах пользователей указать обязательное использование прокси-сервера в виде FQDN-имени USERGATE, созданного на шаге 3.

Шаг 11. Для авторизации в прозрачном режиме настроить автоматическую проверку подлинности пользователя браузером для всех зон.

На компьютерах пользователей зайдите в Панель управления ➜ Свойства браузера ➜ Безопасность, выберите зону Интернет ➜ Уровень безопасности ➜ Другой ➜ Проверка подлинности пользователя и установите Автоматический вход в сеть с текущем именем пользователя и паролем

(Control panel ➜ Internet options ➜ Security, выберите зону Internet ➜ Custom level ➜ User Authentication ➜ Logon и установите Automatic logon with current name and password)

Повторите данную настройку для всех других зон, настроенных на данном компьютере (Local intranet, Trusted sites).

Критически важно! Если браузер осуществляет запрос по https, но на NGFW дешифрование не настроено, то NGFW не в состоянии вмешаться в трафик и вставить туда требование авторизоваться по Kerberos. Для того, чтобы была возможность это сделать, в NGFW по умолчанию идёт правило Decrypt all for unknown users, которое включает дешифрование трафика для не авторизованных подключений.

Метод аутентификации HTTP Basic

Аутентификация Basic позволяет авторизовать пользователей с явно указанным прокси сервером по базе локальных и LDAP-пользователей. Не рекомендуется использовать данный тип аутентификации поскольку имя пользователя и пароль передаются в открытом виде по сети. Аутентификацию HTTP Basic можно использовать для автоматической авторизации утилит командной строки, которым необходим доступ в интернет, например:

curl -x 192.168.179.10:8090 -U user: password http://www.msn.com

Для аутентификации HTTP Basic необходимо выполнить следующие действия:

Наименование

Описание

Шаг 1. Создать DNS-записи для сервера UserGate.

На контроллере домена создать DNS-записи, соответствующие серверу UserGate для использования в качестве домена для auth.captive и logout.captive, например, auth.domain.loc и logout.domain.loc.

В качестве IP-адреса укажите адрес интерфейса UserGate, подключенного в сеть Trusted.

Шаг 2. Изменить адрес Домен Auth Captive-портала.

Изменить адрес домена Auth Captive-портала и опционально адрес домена Logout Captive-портала в разделе Настройки.

Для домена Auth Captive-портала необходимо указать созданную на предыдущем шаге запись DNS.

Для домена Logout Captive-портала необходимо указать созданную на предыдущем шаге запись DNS.

Подробно об изменении адресов доменов Auth Captive-портала и Logout Captive-портала смотрите в разделе Настройка Captive-портала.

Шаг 3. Создать правило Captive-портала с аутентификации HTTP Basic.

Настроить Captive-портал для использования метода аутентификации HTTP Basic.

При настройке, помимо метода HTTP Basic, необходимо добавить базу пользователей, по которой будет проверяться аутентификация (например, добавить методы аутентификации Локальный пользователь или Сервер LDAP).

Более подробно о Captive-портале рассказывается в следующих главах руководства.

Шаг 4. Разрешить доступ к сервису HTTP(S) для зоны.

В разделе Зоны разрешить доступ к сервису HTTP(S)-прокси для зоны, к которой подключены пользователи, авторизующиеся с помощью NTLM.

Шаг 5. Настроить прокси-сервер на компьютерах пользователей

На компьютерах пользователей указать обязательное использование прокси-сервера, указать IP-адрес Trusted интерфейса UserGate в качестве адреса прокси сервера.

Эта статья была:   Полезна | Не полезна
Сообщить об ошибке
ID статьи: 96
Последнее обновление: 02 авг, 2023
Ревизия: 29
Просмотры: 13144
Комментарии: 0
Теги

Также опубликовано в