Перейти к содержимому
AD Academy
Сетевая безопасность: Fortinet
Средний16 мин.Обновлено: Тема 9 из 14

FSSO — как файрвол узнаёт, кто есть кто в AD

Карта «пользователь ↔ IP» из событий входа на DC и политики файрвола по группам AD.

Не прочитано

Что вы узнаете

  • Связанные темы курса
  • Как это работает
  • Два режима работы

Перед этой темой стоит прочитать:Логи и диагностика неполадок

Файрвол традиционно мыслит IP-адресами, но политики формулируются в терминах пользователей и групп : «бухгалтерия может, остальные — нет». (Fortinet Single Sign-On) — механизм, с помощью которого FortiGate узнаёт, какой пользователь сидит за каким IP, и применяет политики по группам AD.

Пользователь входит в домен, DC пишет событие 4624, Collector Agent читает журнал и отдаёт FortiGate карту «пользователь ↔ IP». Группы подтягиваются по LDAP, политика пишется по группам AD. Слепые зоны: общий компьютер, смена IP, устройства вне домена.

Коротко и понятно

  • FSSO никого не аутентифицирует — он лишь узнаёт, кто уже вошёл в домен и с какого IP.
  • Источник — событие 4624 в журнале безопасности DC; группы подтягиваются отдельно по LDAP.
  • Политика пишется именем группы («G-Finance»), а не адресами — поэтому переживает смену IP.
  • Общий компьютер, BYOD или некорректное выключение = неточное сопоставление до таймаута.

Пример из практикиПользователь жалуется, что нет доступа к ERP, хотя он в нужной группе. diagnose debug authd fsso list показывает, что его IP всё ещё закреплён за предыдущим человеком, сидевшим за этой машиной.

Связанные темы курса

  • Event ID 4624 — то самое событие входа, из которого строит сопоставление (справочник Event IDs).
  • — HasSession: там тот же вопрос «кто сидит за какой машиной» (/course/tools/bloodhound-walkthrough).
  • Tiering — политика по группам позволяет закрепить разделение уровней и на сетевом уровне.

Как это работает

  • Пользователь входит в домен — обычный вход по , на клиенте ничего нового.
  • На контроллере домена (или на отдельном сервере) работает — читает журнал безопасности и видит событие входа 4624.
  • Агент сопоставляет пользователя с IP рабочей станции и передаёт карту на FortiGate (TCP, по умолчанию порт 8000).
  • FortiGate применяет политику по группе: CN=Teachers → правило «разрешить», CN=Students → «запретить».

Два режима работы

  • Event Log / Polling mode — на выделенном сервере опрашивает DC и собирает события входа.
  • Kerberos-based — лёгкий агент на каждом DC смотрит Kerberos-аутентификацию; лучше масштабируется.
  • Есть и по Accounting (для Wi-Fi) — та же концепция, другой источник карты.

Практика в лаборатории

  • Установите на сервере Windows в лабораторном домене corp.local. Создайте сервисную учётку svc-fsso с паролем без срока действия и правами Event Log Readers — не админом.
  • В укажите DC, пароль для подключения FortiGate и порт (по умолчанию 8000).
config user fsso-agent
    edit "FSSO-CA"
        set server "10.0.0.10"
        set password <password-from-collector-agent>
    next
end
bash

Теперь привязываем группу FortiGate к группе :

config user group
    edit "FSSO-Teachers"
        set member "FSSO-CA"
        config match
            edit 0
                set server-name "FSSO-CA"
                set group-name "CN=Teachers,OU=Groups,DC=corp,DC=local"
            next
        end
    next
end
bash

Затем используйте группу в политике (Policy & Objects → Firewall Policy → Source: FSSO-Teachers). Проверка: с рабочей станции под пользователем из Teachers откройте сайт — сессия должна появиться в Security Fabric → User & Device → .

Риски и детектирование

  • Учётка : компрометация = чтение журналов и влияние на карту. Минимум прав, мониторинг 4624 от её имени.
  • Трафик агента к FortiGate — не VPN; используйте изолированный сегмент управления. Это Tier 0-коммуникация.
  • «Мёртвые» сопоставления: некорректно выключенная станция оставляет пару «пользователь ↔ IP» до таймаута. Учитывайте в чувствительных правилах.

Митигация

  • Отдельный VLAN для управления FortiGate ↔ .
  • Учётка агента: Event Log Readers + запрет интерактивного входа.
  • Регулярный аудит: сравнение активных FSSO-сессий с реальными входами (quser / whoami на подозрительных станциях).
  • Чувствительные правила (доступ к серверам Tier 1) — не только по FSSO-группе, но и по IP-диапазону сегмента.

Проверь себя

Что является источником карты «пользователь ↔ IP» в FSSO?

Какие права достаточны сервисной учётке Collector Agent?

Почему компрометация AD делает ненадёжными и политики FSSO?

В каком случае карта «пользователь ↔ IP» может указывать на неправильного пользователя?

Эта страница вам помогла?