Radius сервер для Linux

MULTIFACTOR Radius Adapter — программный компонент, RADIUS сервер для Linux.

Компонент доступен вместе с исходным кодом, распространяется бесплатно. Актуальная версия находится на GitHub: код и сборка (архив release_linux_x64.zip).

Лицензия

Обратите внимание на лицензию. Она не даёт вам право вносить изменения в исходный код Компонента и создавать производные продукты на его основе. Исходный код предоставляется в ознакомительных целях.

Требования для установки компонента

• Компонент устанавливается на Linux сервер, протестирован на CentOS, RHEL, Ubuntu, Debian, Astra Linux, REDOS.
• Минимальные требования для сервера: 1 CPU, 2 GB RAM, 8 GB HDD (обеспечивают работу ОС и адаптера для 100 одновременных подключений — примерно 1500 пользователей);
• На сервере должен быть открыт порт 1812 (UDP) для приема запросов от Radius клиентов;
• Серверу с установленным компонентом необходим доступ к хосту api.multifactor.ru по TCP порту 443 (TLS) напрямую или через HTTP proxy;
• Для взаимодействия с Active Directory, компоненту нужен доступ к серверу домена по TCP порту 389 (схема LDAP) или 636 (схема LDAPS);
• Для взаимодействия с Network Policy Server, компоненту нужен доступ к NPS по UDP порту 1812.

Важно

В linux версиях компонентов, в параметре shared secret, не поддерживаются символы &, #, <, >.

Установка

Установка библиотек

С версии компонента 3.0.4 используется среда выполнения ASP.NET Core runtime версии 8, которая является бесплатной, открытой, разрабатывается компанией Microsoft и Open-Source сообществом. Среда выполнения не накладывает никаких ограничений на использование.

Если ваша ОС не поддерживает ASP.NET Core runtime версии 8, вам нужно будет использовать версию компонента 2.1.22 и использовать ASP.NET Core runtime версии 6. В остальном установка не отличается.

wget https://packages.microsoft.com/config/debian/12/packages-microsoft-prod.deb -O packages-microsoft-prod.deb
sudo dpkg -i packages-microsoft-prod.deb
rm packages-microsoft-prod.deb

sudo apt-get update && 
sudo apt-get install -y aspnetcore-runtime-8.0

sudo apt install libldap-2.5-0 

sudo dnf update -y
sudo dnf upgrade -y
sudo dnf install -y dotnet-runtime-8.0

sudo rpm -Uvh https://packages.microsoft.com/config/centos/8/packages-microsoft-prod.rpm
sudo dnf install -y dotnet-runtime-8.0

sudo dnf install -y dotnet-sdk-8.0

sudo dnf install -y wget
sudo wget https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
sudo rpm -Uvh packages-microsoft-prod.rpm
sudo dnf install -y dotnet-sdk-8.0

sudo rpm -Uvh https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
sudo yum update -y
sudo yum install -y dotnet-runtime-8.0

sudo rpm -Uvh https://packages.microsoft.com/config/rhel/8/packages-microsoft-prod.rpm
sudo dnf update -y
sudo dnf install -y dotnet-runtime-8.0

Если при запуске программ возникает ошибка:

Unable to load shared library 'ldap.so.2' or one of its dependencies

То это означает, что системе не хватает симлинков для корректного поиска библиотек.
Проверка наличия библиотек

Выполните команду:

ls -la /usr/lib/x86_64-linux-gnu | grep libldap
ls -la /usr/lib/x86_64-linux-gnu | grep liblber

Вывод покажет, какие версии библиотек установлены и как они ссылаются друг на друга.

Если в системе не хватает симлинка libldap.so.2, создадим его:

sudo ln -s /usr/lib/x86_64-linux-gnu/libldap-2.5.so.2 /usr/lib/x86_64-linux-gnu/libldap.so.2

Аналогично для liblber:

sudo ln -s /usr/lib/x86_64-linux-gnu/liblber-2.5.so.2 /usr/lib/x86_64-linux-gnu/liblber.so.2

Важно

В РЕД ОС нужны библиотеки libldap-2.4 и liblber-2.4 поэтому для этой ОС симлинки будут выглядеть так:

sudo ln -s /usr/lib64/libldap-2.4.so.2 /usr/lib64/libldap.so.2
sudo ln -s /usr/lib64/liblber-2.4.so.2 /usr/lib64/liblber.so.2

В CentOS или RedHat-подобных дистрибутивах библиотеки обычно находятся в /usr/lib64/, поэтому команды будут такими:

sudo ln -s /usr/lib64/libldap-2.5.so.2 /usr/lib64/libldap.so.2
sudo ln -s /usr/lib64/liblber-2.5.so.2 /usr/lib64/liblber.so.2

Установка компонента

Создайте папку, скачайте и распакуйте актуальную версию компонента из GitHub:

sudo mkdir /opt/multifactor /opt/multifactor/radius /opt/multifactor/radius/logs
sudo wget https://github.com/MultifactorLab/multifactor-radius-adapter/releases/download/3.0.28/release_linux_x64.zip
sudo unzip release_linux_x64.zip -d /opt/multifactor/radius

Создайте системного пользователя mfa и дайте ему права на приложение:

sudo useradd -r mfa
sudo chown -R mfa: /opt/multifactor/radius/
sudo chmod -R 700 /opt/multifactor/radius/

Создайте файл службы systemd:

sudo nano /etc/systemd/system/multifactor-radius.service

Замените содержимое и сохраните файл:

[Unit]
Description=Multifactor Radius Adapter

[Service]
WorkingDirectory=/opt/multifactor/radius/
ExecStart=/usr/bin/dotnet /opt/multifactor/radius/multifactor-radius-adapter.dll
Restart=always
# Restart service after 10 seconds if the service crashes:
RestartSec=10
KillSignal=SIGINT
SyslogIdentifier=multifactor-radius
User=mfa
Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false
 
# How many seconds to wait for the app to shut down after it receives the initial interrupt signal. 
# If the app doesn't shut down in this period, SIGKILL is issued to terminate the app. 
# The default timeout for most distributions is 90 seconds.
TimeoutStopSec=30

[Install]
WantedBy=multi-user.target

Включите автозапуск службы:

 sudo systemctl enable multifactor-radius

Общие параметры

Общие параметры работы компонента хранятся в файле /opt/multifactor/radius/multifactor-radius-adapter.dll.config в формате XML. 

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

1. Основной конфигурационный файл оставить  стандартным (со значениями по умолчанию).
2. Использовать шаблоны из папки clients для настройки новых ресурсов.

Преимущества такого подхода:

• Упрощает добавление новых ресурсов при необходимости расширения 2FA.
• Снижает риск ошибок конфигурации.
• Облегчает поиск и устранение неисправностей.

Этот подход обеспечит более структурированное и поддерживаемое решение.

Минимальная конфигурация:

<!-- Адрес и порт (UDP) по которому адаптер будет принимать запросы на аутентификацию от клиентов -->
<add key="adapter-server-endpoint" value="0.0.0.0:1812"/>

<!-- Адрес API MULTIFACTOR -->
<add key="multifactor-api-url" value="https://api.multifactor.ru"/>

<!-- Доступ к API MULTIFACTOR через HTTP прокси (опционально) -->
<!-- <add key="multifactor-api-proxy" value="http://login:password@proxy:3128"/> -->

<!-- Уровень логирования: 'Verbose', 'Debug', 'Info', 'Warn', 'Error' -->
<add key="logging-level" value="Debug"/>
<!--<add key="logging-format" value="json"/>-->

Переменные среды

Адаптер теперь поддерживает переменные среды: вы можете настроить адаптер, установив переменные среды ОС.
Такой подход имеет ряд преимуществ:

• независимость от файлов конфигурации: решает проблему возможной перезаписи файлов;
• более простая контейнеризация: просто установите набор переменных среды внутри контейнера;
• повышенная безопасность; конфиденциальные данные можно передавать через переменные без использования файловой системы
• Не нужно использовать файлы настроек .config (удалите их или оставьте со значениями по умолчанию.): любые настройки можно описать через переменные окружения.

файлы конфигурации *.config

Вы можете продолжать использовать файлы конфигурации *.config, если хотите.

При старте адаптер считывает конфигурацию из файла MultiFactor.Radius.Adapter.exe.config, а также из файлов *.config, находящихся в папке /clients.
После этого адаптер получает переменные из окружения и «накладывает» их поверх настроек, считанных из файлов: значения из переменных окружения перегружают значения из файлов настроек.

Примеры

Базовый синтаксис:

# Linux
export VAR=VALUE

# Windows (PowerShell)
$Env:VAR = VALUE

VAR — имя переменной окружения, а VALUE — значение.
Директива export нужна, чтобы установить указанную переменную не только для текущей оболочки, но и для всех процессов, запускаемых из этой оболочки.

Чтобы передать в адаптер настройку через переменные окружения, нужно правильно указать имя.
Для передачи настройки в основной конфиг (MultiFactor.Radius.Adapter.exe.config) имя переменной должно выглядеть так:

export RAD_APPSETTINGS__FirstFactorAuthenticationSource=ActiveDirectory

RAD_ — префикс.
APPSETTINGS — секция в файле настроек.
FirstFactorAuthenticationSource — имя настройки.
__ — разделитель уровней вложенности. Регистр не важен.

Важно

Если название файла конфигурации содержит пробелы, при формировании имени для переменной окружения эти пробелы надо игнорировать: my rad -> myrad.

Альтернатива:

<appsettings>
  <add key="first-factor-authentication-source" value="ActiveDirectory" />
</appsettings>

Более сложный пример:

export RAD_RADIUSREPLY__ATTRIBUTES__ADD__0__NAME=Class
export RAD_RADIUSREPLY__ATTRIBUTES__ADD__0__VALUE=users1

0 — это индекс (номер) элемента.

Альтернатива:

<RadiusReply>
  <Attributes>
    <add name="Class" value="users1" />
  </Attributes>
</RadiusReply>

Чтобы передать настройку в клиентскую конфигурацию, нужно добавить имя конфигурации сразу после префикса _RAD. Например, для конфигурации, которая находится в файле my-rad.config имя переменной будет выглядеть так:

export RAD_my-rad_APPSETTINGS__FirstFactorAuthenticationSource=ActiveDirectory

Настройка сетевых подключений

Идентификация клиентов

Для настройки каждого сетевого подключения к адаптеру используется отдельный конфигурационный файл с расширением .config, который должен находиться в папке /clients.

Идентификация клиента производится либо по IP адресу, либо по атрибуту NAS-Identifier. По IP удобно идентифицировать конфигурацию единичных сетевых устройств, например, межсетевых экранов. По NAS-Identifier – несколько однотипных, например, группу хостов с WinLogon или SSH.

<!-- IP адрес сетевого устройства, которое будет подключаться к адаптеру -->
<add key="radius-client-ip" value="10.10.10.10"/>
<!-- Или RADIUS атрибут NAS-Identifier, передаваемый с сетевого устройства при подключении к адаптеру -->
<add key="radius-client-nas-identifier" value="windows"/>
<!-- Shared secret, настроенный на сетевом устройстве -->
<add key="radius-shared-secret" value=""/>

Если идентификация клиентов не требуется, можно сделать универсальные настройки в файле MultiFactor.Radius.Adapter.exe.config, которые будут применимы для всех подключений.

Warning

В параметре radius-shared-secret, не поддерживаются спецсимволы: (‘>’,'<‘,’&’), так как XML-парсер адаптера считает это частью разметки.

Проверка первого фактора в Active Directory

Для проверки первого фактора в домене Active Directory, внесите в конфигурацию клиента следующие параметры:

<!-- Где проверять первый фактор: ActiveDirectory -->
<add key="first-factor-authentication-source" value="ActiveDirectory"/>

<!-- Домен: в текущем примере domain.local на сервере 10.0.0.4 -->
<add key="active-directory-domain" value="ldaps://10.0.0.4/DC=domain,DC=local"/>

<!-- Разрешать доступ только пользователям из указанной группы (не проверяется, если удалить настройку) -->
<add key="active-directory-group" value="VPN Users"/>
<!-- Запрашивать второй фактор только у пользователей из указанной группы (второй фактор требуется всем, если удалить настройку) -->
<add key="active-directory-2fa-group" value="2FA Users"/>
<!-- Не запрашивать второй фактор у пользователей из указанной группы (в том числе, если пользователь одновременно находится в группе, заданной в active-directory-2fa-group) -->
<add key="active-directory-2fa-bypass-group" value="Bypass 2FA Users"/>

<!--Использовать номер телефона из Active Directory для отправки одноразового кода в СМС (не используется, если удалить настройку)-->
<!--add key="use-active-directory-user-phone" value="true"/-->
<!--add key="use-active-directory-mobile-user-phone" value="true"/-->

При включении параметра use-active-directory-user-phone компонент будет использовать телефон, записанный на вкладке General. Формат телефона может быть любым.

При включении параметра use-active-directory-mobile-user-phone компонент будет использовать телефон, записанный на вкладке Telephones в поле Mobile. Формат телефона также может быть любым.

Групповые политики в AD

1. Общий доступ к системе (группа VPN Users)

• Назначение: определяет, кто вообще может получить доступ к системе.
• Сценарии:
  • Если группа указана (<add key="active-directory-group" value="VPN Users"/>):
    • Доступ разрешён только пользователям из группы VPN Users.
    • Пользователи не из этой группы не смогут войти, даже если у них есть 2FA.
  • Если настройка удалена (или значение пустое):
    • Доступ могут получить все пользователи домена (если нет других ограничений).

2. Требование 2FA (группа 2FA Users)

• Назначение: определяет, у кого будет запрашиваться второй фактор аутентификации.
• Сценарии:
  • Если группа указана (<add key="active-directory-2fa-group" value="2FA Users"/>):
    • 2FA требуется только пользователям из группы 2FA Users.
    • Пользователи не из этой группы смогут войти без 2FA (если не попадают в Bypass 2FA Users).
  • Если настройка удалена (или значение пустое):
    • 2FA требуется всем пользователям (кроме тех, кто в Bypass 2FA Users).

3. Исключение из 2FA (группа Bypass 2FA Users)

• Назначение: позволяет отключить 2FA для определённых пользователей, даже если они в группе 2FA Users.
• Сценарии:
  • Если группа указана (<add key="active-directory-2fa-bypass-group" value="Bypass 2FA Users"/>):
    • Пользователи из Bypass 2FA Users никогда не получают запрос 2FA, даже если они в 2FA Users.
    • Это приоритетное правило (переопределяет требование 2FA).
  • Если настройка удалена (или значение пустое):
    • Никаких исключений нет, 2FA применяется согласно настройке 2FA Users.

Возможные комбинации и их эффект

Рассмотрим различные комбинации членства в группах и их влияние на доступ и 2FA:

Выводы

Bypass 2FA Users — отключает 2FA для своих членов вне зависимости от других настроек.

VPN Users — базовая группа доступа. Без неё пользователь не войдёт, даже если у него есть 2FA или исключение.

2FA Users — определяет, кому нужна 2FA. Если не задана — 2FA требуется всем.

При включении параметра phone-attribute компонент будет использовать телефон, записанный в указанном LDAP-атрибуте пользователя. Формат телефона может быть любым.

Проверка первого фактора во внешнем RADIUS сервере

Для проверки первого фактора в RADIUS, например, в Network Policy Server применимы следующие параметры:

<!-- Где проверять первый фактор: Radius -->
<add key="first-factor-authentication-source" value="Radius"/>
<!-- Адрес (UDP), с которого адаптер будет подключаться к серверу -->
<add key="adapter-client-endpoint" value="0.0.0.0"/>
<!-- Адрес и порт (UDP) сервера -->
<add key="nps-server-endpoint" value="192.168.0.10:1812"/>

Проверка первого фактора во FreeIpa

<!-- Где проверять первый фактор: Ldap -->
<add key="first-factor-authentication-source" value="Ldap"/>
<!-- Base DN для подключения к FreeIPA -->
<add key="ldap-bind-dn" value="cn=users,cn=accounts,dc=freeipa,dc=test"/>

Без проверки первого фактора

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

<!--Где проверять первый фактор: None -->
<add key="first-factor-authentication-source" value="None"/>

Проверка второго фактора перед первым

Адаптер может быть настроен на обязательное подтверждение второго фактора до проверки учетных данных в Active Directory.
В этом режиме, если пользователь не подтвердил свой второй фактор, адаптер не отправляет запрос на проверку логина и пароля в AD.

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

Для настройки используется следующая конфигурация клиента:

<!-- [Опционально] Проверка второго фактора перед первым. Варианты METHOD:  "none", "push", "telegram", "otp" -->
<add key="pre-authentication-method" value="METHOD"/>
<!-- Задержка ответа в секундах при отказе в доступе: случайная в интервале между 3 и 6 сек. (включая границы интервала) -->
<add key="invalid-credential-delay" value="3-6" />

Настройка сервисной учётной записи

Сервисная учётная запись необходима для проверки членства пользователей в группах Active Directory и для загрузки LDAP атрибутов.

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

<!-- Домен: в текущем примере domain.local на сервере 10.0.0.4 -->
<add key="active-directory-domain" value="ldaps://10.0.0.4/DC=domain,DC=local"/>
<!-- Логин сервисной учётной записи Active Directory для проверки членства пользователей в группах -->
<add key="service-account-user" value="service-account"/>
<!-- Пароль сервисной учётной записи Active Directory для проверки членства пользователей в группах -->
<add key="service-account-password" value=""/>

Подключение к серверу аутентификации

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

<!-- Параметр NAS-Identifier для подключения к API MULTIFACTOR - из личного кабинета -->
<add key="multifactor-nas-identifier" value=""/>
<!-- Параметр Shared Secret для подключения к API MULTIFACTOR - из личного кабинета -->
<add key="multifactor-shared-secret" value=""/>

Значения параметров необходимо взять из личного кабинета, в разделе «Ресурсы».

Разграничение IP-адресов

Данный параметр задаёт список допустимых IP адресов для обработки адаптером. Если AccessRequest пакет пришел не с адреса из настройки, то такой пакет игнорируется. Пакеты StatusServer будут обрабатываться в обычном режиме. Можно задавать конкретные IP, подсети, диапазоны адресов. Несколько значений задаются через точку с запятой.
Пример:

<appSettings>
. . .
<add key="ip-white-list" value="192.168.0.1; 127.0.0.1/16 ; 199.168.0.1-199.168.0.10"/>
<add key="ip-white-list" value="192.168.0.1; 192.168.0.2"/>
<add key="ip-white-list" value="199.168.0.1-199.168.0.10; 136.168.0.1-136.168.0.10"/>
. . .

</appSettings>

Дополнительные RADIUS атрибуты

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

Атрибуты могут быть четырёх видов:

1. Безусловные
2. Условные: с проверкой вхождения пользователя в группу на сервере LDAP
3. Условные: с проверкой имени пользователя
4. С трансляцией значения атрибута LDAP в RADIUS.

Пример XML-синтаксиса файла конфигурации для передачи атрибута Class (RADIUS Attribute ID 25).

<configuration>
  <!-- Объявление секции RadiusReply -->
  <configSections>
      <section name="RadiusReply" type="MultiFactor.Radius.Adapter.RadiusReplyAttributesSection, multifactor-radius-adapter" />
  </configSections>
  
  <!-- Параметры работы компонента -->
  <appSettings>
    ...
  </appSettings>
  
  <!-- Настройка передачи дополнительных RADIUS атрибутов -->
  <RadiusReply>
      <Attributes>
        <!-- Всегда передавать атрибут Class со значением Test1 -->
        <add name="Class" value="Test1" />
        <!-- Всегда передавать атрибут Class со значением из Ldap атрибута SampleLdapAttr -->
        <add name="Class" from="SampleLdapAttr"/>
        <!-- Передавать атрибут Class со всеми группами пользователя в Active Directory -->
        <add name="Class" from="memberOf"/>
        <!-- Передавать атрибут Class со значением Users, если пользователь входит в LDAP-группу VPN Users или Staff -->
        <add name="Class" value="Users" when="UserGroup=VPN Users;Staff"/>
        <!-- Передавать атрибут Class со значением Admin, если имя пользователя SamlpeAdminName или SampleUserName -->
        <add name="Class" value="Admin" when="UserName=SamlpeAdminName;SampleUserName"/>
      </Attributes>
  </RadiusReply>
</configuration>

Названия и значения атрибутов могут быть любыми, которые поддерживаются на вашем сетевом устройстве. Например, для передачи групп FortiGate можно использовать атрибут Fortinet-Group-Name. Словарь со всеми доступными атрибутами расположен в файле /opt/multifactor/radius/content/radius.dictionary.

Для передачи LDAP атрибутов должно быть выполнено одно из условий:

• Указан источник первого фактора ActiveDirectory и задано название домена;
• Заданы параметры сервисной учётной записи Active Directory, если источником первого фактора является RADIUS, или первый фактор не проверяется.

Кэширование аутентификации

Адаптер можно настроить на кэширование аутентификаций пользователей вторым фактором.

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

Запрос является повторным, если параметры текущего запроса совпадают с параметрами предыдущего запроса. Параметры:

1. название клиентской конфигурации адаптера;
2. calling-station-id (IP или Remote Host пользователя) — не может быть пустым;
3. логин пользователя.

Для настройки используется следующий параметр:

<!-- Пропускать повторные аутентификации без запроса второго фактора в течение 1 часа 20 минут 10 секунд (максимальное значение 23:59:59, кэширование отключено, если удалить настройку) -->
<add key="authentication-cache-lifetime" value="01:20:10" />

Максимальное значение для данного параметра 23:59:59.

Кэширования второго фактора на основе групп пользователей

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

Важно

Настройка работает только вместе с настройкой authentication-cache-lifetime.

<add key="authentication-cache-groups" value="Auth1;admins"/>

Защита от сбоев

В случае недоступности (по любой причине) API MULTIFACTOR, адаптер может работать в одном из двух вариантов:

1. Пропускать без второго фактора (по умолчанию)
2. Отказывать в доступе

Для настройки используется следующий параметр:

<!-- true: пропускать, false: запрещать -->
<add key="bypass-second-factor-when-api-unreachable" value="true"/>

Прочие параметры

Дополнительные параметры работы с Active Directory:

<!-- Отключить проверку вложенных групп в Active Directory (ускорение запроса) -->
<add key="load-active-directory-nested-groups" value="false"/>
<!-- dn контейнеров где искать группы пользователя. Задается через точку с запятой. Пример CN=Users,DC=domain,DC=local -->
<add  key="nested-groups-base-dn" value="CN=Users,DC=domain,DC=your;OU=Admins,DC=domain,DC=your"/>
<!-- Передавать атрибут userPrincipalName из Active Directory в качестве логина пользователя -->
<add key="use-upn-as-identity" value="true"/>
<!-- Передавать указанный атрибут из Active Directory в качестве логина пользователя -->
<add key="use-attribute-as-identity" value="mail"/>

Параметр use-upn-as-identity устарел, с версии 2.0.59 вместо него следует использовать use-attribute-as-identity.

Пользователям, регистрирующимся в системе через Radius адаптер, можно автоматически присваивать членство в группах MULTIFACTOR следующей настройкой:

<add key="sign-up-groups" value="group1;Название группы 2"/>

Дополнительные настройки безопасности и конфиденциальности:

<!-- Отключить передачу адаптером ФИО, email, IP пользователей на сервер MULTIFACTOR -->
<add key="privacy-mode" value="Full"/>
<!-- можно указать перечень передаваемых атрибутов -->
<add key="privacy-mode" value="Partial:Name,Email,Phone,RemoteHost"/>

Настройка времени ожидания ответа API MULTIFACTOR:

<!--Время ожидания ответа от api мультифактора, по умолчанию 65 секунд. Время в формате hh:mm:ss-->
<add key="multifactor-api-timeout" value="00:01:05"/>
<!--Если указываете время менее 65 секунд, используйте следующий синтаксис. Время в формате hh:mm:ss-->
<add key="multifactor-api-timeout" value="00:00:45!"/>

Настройка времени ожидания от LDAP каталога:

<!-- Время ожидания ответа от LDAP каталога, по умолчанию 30 секунд. Формат hh:mm:ss -->
    <add key="ldap-bind-timeout" value="00:00:30"/>

Запуск

После настройки конфигурации запустите компонент:

sudo systemctl start multifactor-radius

Статус можно проверить командой:

sudo systemctl status multifactor-radius

Дебаг

Логи старта приложения находятся в отдельном файле startup.logs в папке logs.

Для вывода причин неуспешного запуска адаптера используйте следующую команду:

/usr/bin/dotnet /opt/multifactor/radius/multifactor-radius-adapter.dll 

Последующие изменения в файле конфигурации службы потребуют перезапуска подсистемы служб и службы:

sudo systemctl daemon-reload
sudo systemctl restart multifactor-radius

Журналы

Журналы работы компонента записываются в syslog и сохраняются в текстовые файлы в директорию /opt/multifactor/radius/logs. Если директория пуста или ее нет, нужно убедиться, что у пользователя, под которым запускается служба, есть права на запись в эту директорию.

Уровень и формат логирования

Уровень и формат логирования необходимо настраивать в корневом файле конфигурации MultiFactor.Radius.Adapter.exe.config :

Существуют следующие уровни логирования:

• Verbose
• Debug
• Info
• Warn
• Error

Пример:

<add key="logging-level" value="Debug"/>

Существуют следующие форматы логирования:

• ElasticCommonSchema
• Json
• JsonUtc
• JsonTz

Пример:

<add key="logging-format" value="json"/>

Логирование ошибок запуска

При запуске системы активируется механизм логирования. Ошибки, возникающие на этапе запуска, дублируются в два потока вывода: в консоль и в файл startup.log, расположенный в папке logs.

Лог-файлы адаптеров подвергаются ротации с интервалом в 30 дней.
В процессе ротации старые логи удаляются и замещаются новыми.

Для просмотра содержимого syslog можно воспользоваться командой:

sudo less /var/log/syslog

Для просмотра журналов службы multifactor-radius используйте команду:

sudo journalctl -fu multifactor-radius

Обновление адаптера

• наличие компонента .Net версии 8
• остановить службу
• перезаписать файлы на новые (не заменяя конфигурационные файлы)
• включить службу обратно.

Необходимо будет вновь дать права на каталог с адаптером

sudo chown -R mfa: /opt/multifactor/radius/
sudo chmod -R 700 /opt/multifactor/radius/

Шаблоны журналов

Для настройки шаблона записи журналов используются следующие настройки в корневом файле конфигурации multifactor-radius-adapter.dll.config:

<!-- 
  Примеры шаблонов:
  1) [{Timestamp:HH:mm:ss} {Level:u3}] ext_ip={CallingStationId} {Message:lj}{NewLine}{Exception}
  2) [{Timestamp:HH:mm:ss} {Level:u3}] {CorrelationId} {Message:lj}{NewLine}{Exception}
  3) {Timestamp:yyyy-MM-dd HH:mm:ss.fff zzz} [{Level:u3}] {CorrelationId}{Message:lj}{NewLine}{Exception}
-->

<!-- Шаблон записи журналов в текстовый файл -->
<!-- <add key="file-log-output-template" value=""/> -->
<!-- Шаблон записи журналов в консоли -->
<!-- <add key="console-log-output-template" value=""/> -->

Подробнее о шаблонах: https://github.com/serilog/serilog/wiki/Formatting-Output.

Идентификатор корреляции

Для отслеживания событий на протяжении всей цепочки аутентификации пользователя используется идентификатор корреляции {CorrelationId}.

Значение идентификатора передается в формате «ConfigName-N», где

• «ConfigName» — имя конфигурации клиента, который подключился
• «N» — счетчик, который сбрасывается каждые сутки в 00:00.

Адрес удалённого клиента

Для записи названия хоста или IP удалённого пользователя используется шаблон {CallingStationId}.

Значение параметра последовательно проверяется в следующих RADIUS-атрибутах до первого непустого:

• Calling-Station-Id;
• MS-Client-Machine-Account-Name;
• MS-RAS-Client-Name.
  

Работа с несколькими адаптерами

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

Создайте директорию:

mkdir /opt/multifactor/radius1

Создайте системного пользователя mfa, если не был создан ранее:

sudo useradd -r mfa

Задайте ему права на новые директорию:

sudo chown -R mfa: /opt/multifactor/radius1/
sudo chmod -R 700 /opt/multifactor/radius1

Создайте файл службы systemd:

sudo nano /etc/systemd/system/multifactor-radius-1812.service

Далее его необходимо отредактировать следующим образом:

# /etc/systemd/system/multifactor-radius-1812.service
[Unit]
Description=Multifactor Radius Adapter (listening on UDP 1812)
After=network.target

[Service]
Type=simple
WorkingDirectory=/opt/multifactor/radius1/
ExecStart=/usr/bin/dotnet /opt/multifactor/radius1/multifactor-radius-adapter.dll
Restart=always
RestartSec=10
KillSignal=SIGINT
TimeoutStopSec=30

User=mfa
SyslogIdentifier=multifactor-radius-1812

Environment=ASPNETCORE_ENVIRONMENT=Production
Environment=DOTNET_PRINT_TELEMETRY_MESSAGE=false

[Install]
WantedBy=multi-user.target

После внесения всех изменений необходимо сохранить файл и перезапустить подсистемы служб:

sudo systemctl daemon-reload

Далее добавьте службу в автозагрузку:

sudo systemctl enable multifactor-radius-1812

После чего запустите службу:

sudo systemctl start multifactor-radius-1812

Кластерная конфигурация

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

Для наилучшей работы с nginx или HAProxy также укажите в настройках прокси-сервера заголовок proxy_protocol.

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

• Для работы с Active Directory используется простая проверка подлинности пароля пользователя. Настоятельно рекомендуем использовать схему LDAPS для шифрования трафика между адаптером и доменом (на сервере AD должен быть установлен сертификат, в т.ч. самоподписанный).

Удаление компонента

Удаление .NET Core

Для просмотра списка установленных на вашей машине версий SDK и сред выполнения .NET Core используйте команду:

dotnet --info

Далее, выполните команды:

sudo apt-get remove aspnetcore-runtime-8.0

sudo rm /usr/bin/dotnet
sudo rm -r /usr/local/lib/dotnet/
sudo dpkg --purge 1.0.2n-1ubuntu5.10

sudo rm /usr/bin/dotnet
sudo rm -r /usr/local/lib/dotnet/
sudo dpkg --purge 1.0.2n-1ubuntu5.10

sudo apt-get remove aspnetcore-runtime-8

sudo apt-get remove dotnet-sdk-8.0

sudo apt purge dotnet-* aspnetcore-*

sudo dnf remove aspnetcore-runtime-8.0

sudo dnf remove dotnet* aspnetcore* netstandard*

sudo dnf remove aspnetcore-runtime-8.0

Удаление адаптера

Остановите службу multifactor-radius, удалите её из автозапуска и удалите конфигурационный файл юнита:

sudo systemctl stop multifactor-radius
sudo systemctl disable multifactor-radius
sudo rm /etc/systemd/system/multifactor-radius.service

Перезагрузите настройки systemd, просканировав систему на наличие изменённых юнитов:

sudo systemctl daemon-reload

Удалите файлы адаптера и системного пользователя mfa:

sudo rm -rf /opt/multifactor/radius/
sudo userdel -r mfa

Вопросы и ответы

В: Где прописывается сервисная учетная запись для подключения к Active Directory?

О: Если проверка первого фактора осуществляется в Active Directory, сервисная учётная запись не используется. Адаптер подключается к AD от имени пользователя, который запрашивает аутентификацию.

В иных случаях, см. Настройка сервисной учётной записи.

В: Можно указать несколько групп AD для контроля доступа и условного включения второго фактора?

О: Да, перечислите их через точку с запятой.

В: Как ускорить проверку групп в Active Directory?

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

<add key="load-active-directory-nested-groups" value="false"/>

В: Как указать несколько доменов или хостов DC?

О: Перечислите их через точку с запятой.

В: Адаптер может работать в режиме Radius proxy?

О: Да, при подключении к внешнему Radius серверу, адаптер работает в качестве прокси: транслирует трафик между сетевым устройством и внешним сервером без изменений.

В: Как указать несколько IP для идентификации клиента?

О: Можно перечислить адреса через точку с запятой, можно указать диапазон, можно комбинировать, например:

<add key="radius-client-ip" value="192.168.0.1-192.168.0.5; 192.168.0.10"/>

или так

<add key="radius-client-ip" value="10.0.0.0/24"/>