FortiGate FSSO の設定手順とエージェントレス AD 連携のポイント

はじめに

FortiGate のログを確認していて、こうした課題に直面したことはないでしょうか。

怪しい通信があるが、送信元が 192.168.1.50 としか記録されていない。この端末の利用者を特定したい。

DHCP 環境では IP アドレスが変動するため、ログの IP と DHCP サーバーのリース履歴を突き合わせて利用者を特定するのは手間のかかる作業です。

Active Directory（以下 AD）と FortiGate を連携させれば、この課題を解消できます。ログの送信元にユーザー名が表示されるようになるため、「誰が」何をしたのかを即座に識別できます。

本記事では、AD 連携の仕組み（FSSO）の解説から、追加コストのかからない「エージェントレス」での具体的な設定手順までを紹介します。

ユーザーを識別する仕組み（LDAP と FSSO）

FortiGate が Active Directory（AD）の情報を利用する際には、以下の 2 つの技術が使われます。役割が異なるため、両者を押さえておくことが重要です。

LDAP（Lightweight Directory Access Protocol）

役割: AD に登録された静的情報の参照

FortiGate が AD サーバー内のデータベースを参照するためのプロトコルです。「ユーザー一覧」「どのセキュリティグループに所属しているか」といった、登録済みの属性情報 を取得するために使います。主に、権限の確認や VPN 接続時の認証などで利用されます。

通信には TCP 389（平文）または TCP 636（LDAPS: SSL/TLS 暗号化）が使われます。本番運用ではパスワードの平文送信を避けるため、LDAPS の採用を推奨します。

Fortinet Single Sign-On（FSSO）

役割: ユーザーのログイン情報の動的な連携

ユーザーが PC にログインした情報を FortiGate に連携する技術です。「IP アドレス 192.168.1.50 でログインしたユーザーは user01 である」という情報を AD 経由で取得することで、FortiGate はパケットの IP アドレスとユーザー名を紐付けられます。

これにより、ユーザーは FortiGate 側で再度 ID/パスワードを入力することなく（シングルサインオン）、自動的にユーザー単位のポリシーが適用されます。

参考: FortiGate 7.6 Administration Guide – FSSO polling connector agent installation
“The agent actively polls Windows Security Event log entries on Windows Domain Controller (DC) for user login information. The FSSO user groups can then be used in a firewall policy.”
（FortiGate のエージェントは Windows ドメインコントローラーの Windows セキュリティイベントログを能動的にポーリングしてユーザーログイン情報を取得します。FSSO ユーザーグループはファイアウォールポリシーで利用可能です。）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/503764/fsso-polling-connector-agent-installation

FSSO の実装方式を比較する

FSSO を実装する方式は大きく 3 種類に分けられます。DC Agent モード / Collector Agent モード（ポーリング）/ FortiGate 直接ポーリング（エージェントレス） の 3 方式が存在します。

参考: Fortinet Community – FortiGate FSSO Polling mode benefits and limitations
“In agentless polling mode, FortiGate reads the event viewer logs directly from the domain controllers (DCs) using the SMB protocol.”
（エージェントレスポーリングモードでは、FortiGate は SMB プロトコルを使用してドメインコントローラーのイベントビューアログを直接読み取ります。）
https://community.fortinet.com/t5/FortiGate/Technical-Tip-FortiGate-FSSO-Polling-mode-Agentless-benefits-and/ta-p/391640

本記事で採用する方式: FortiGate 直接ポーリング（エージェントレス）

本記事では、③ FortiGate 直接ポーリング方式（エージェントレス） を採用します。理由は、AD サーバー側への追加ソフトウェアインストールが不要で、FortiGate の設定のみで完結するためです。

稼働中のドメインコントローラーへ外部ツールを追加導入する場合、動作検証や再起動調整など運用上の制約が大きくなります。エージェントレス方式であれば、FortiGate から AD に対して定期的にログイン情報を問い合わせる（ポーリング）だけのため、AD サーバーへの影響を抑えつつ導入できます。

ただし、後述する通りエージェントレスには固有の制約（NTLM 非対応、ネストグループの扱い等）があります。採用前に「導入前に知っておきたい制約・ハマりポイント」セクションで確認することを推奨します。

なお、認証方式ごとの使い分けとして、Explicit Proxy を使った ID/PW 入力型の認証については関連記事『FortiGate プロキシ設定の手順と Explicit Proxy 認証のポイント』、ゲスト Wi-Fi 向けのキャプティブポータル認証については『FortiGate キャプティブポータルの設定手順とゲスト Wi-Fi 構築のポイント』で解説しています。

設定手順

手順

LDAP サーバーの登録

まず、FortiGate が AD のユーザー情報を参照できるように、LDAP サーバーとして登録します。

GUI での設定

1. FortiGate の管理画面で ユーザー&認証 ＞ LDAP サーバー を開きます。
2. 新規作成 をクリックし、AD サーバーの情報を入力します。

• IP アドレス/ドメイン名: AD サーバーの IP アドレスまたは FQDN
• 識別名（Distinguished Name）: AD ツリーのルート DN（例: dc=example,dc=com）
• バインドタイプ: レギュラー を選択し、AD の参照権限を持つユーザーとパスワードを入力

3. 接続のテスト をクリックして 成功 と表示されることを確認し、OK をクリックします。

識別名（DN）の書き方のポイント

DN には以下のような指定が可能です。範囲を絞ることで検索負荷を下げられます。

パターン	記述例	効果
ドメイン全体	dc=example,dc=com	AD 全体を検索対象にする
特定 OU 配下	ou=Sales,dc=example,dc=com	営業部 OU 配下のみ検索
Users コンテナのみ	cn=Users,dc=example,dc=com	デフォルトの Users コンテナのみ

CLI での設定

CLI で同じ設定を行う場合は以下の通りです。LDAPS（SSL/TLS 暗号化）を使う場合は set secure ldaps を有効化します。

config user ldap
    edit "AD-Server"
        set server "192.168.1.10"
        set cnid "sAMAccountName"
        set dn "dc=example,dc=com"
        set type regular
        set username "CN=fgt-reader,CN=Users,DC=example,DC=com"
        set password <管理者パスワード>
        # LDAPS を使用する場合
        # set secure ldaps
        # set port 636
    next
end

参考: FortiGate 7.6 Administration Guide – FSSO polling connector agent installation
“Refer to Configuring an LDAP server. The connection must be successful before configuring the FSSO polling connector.”
（LDAP サーバーの設定は FSSO ポーリングコネクタの設定前に完了させ、接続が成功していることを確認します。）
https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/503764/fsso-polling-connector-agent-installation

手順

FSSO（エージェントレス）の設定

次に、AD のログイン情報を取得するための FSSO ポーリングコネクタを設定します。FortiGate では 「ファブリックコネクタ（外部コネクタ）」 機能を使用します。

コネクタの作成

1. セキュリティファブリック ＞ 外部コネクタ を開きます。
2. 新規作成 をクリックし、Active Directory サーバーのポーリング（または Poll Active Directory Server）を選択します。
3. 設定画面で、以下を入力します。

• サーバー IP: ドメインコントローラーの IP アドレス
• ユーザー名: DC のセキュリティイベントログ読み取り権限を持つユーザー
• LDAP サーバー: 手順 1 で作成した LDAP サーバーを選択

4. OK をクリックして保存します。

これにより、FortiGate が DC に対して定期的にログイン情報を問い合わせる構成になります。

CLI での設定例は以下の通りです。

config user fsso-polling
    edit 1
        set status enable
        set server "192.168.1.10"
        set user "fgt-reader"
        set password <パスワード>
        set ldap-server "AD-Server"
        set polling-frequency 10     # ポーリング間隔（秒）、1〜30 で指定
    next
end

参考: FortiGate 7.6 CLI Reference – config user fsso-polling
“Configure FSSO active directory servers for polling mode.”
（ポーリングモードで動作する FSSO Active Directory サーバーを設定します。）
https://docs.fortinet.com/document/fortigate/7.6.4/cli-reference/825346697/config-user-fsso-polling

ユーザー / グループの取り込み

コネクタを作成しただけでは、ファイアウォールポリシーでは利用できません。制御対象としたいグループを FortiGate にインポートします。

1. 作成したコネクタの設定画面にある ユーザー / グループ タブ（またはボタン）をクリックします。
2. + 追加 をクリックすると、AD 上のツリーが表示されます。
3. FortiGate で制御したいグループ（例: FG_Users）やユーザーを検索・選択し、OK をクリックします。

これで、AD 上のユーザーグループが FortiGate の FSSO ユーザーグループとして利用可能になります。以降はファイアウォールポリシーの 送信元ユーザー 欄で、取り込んだグループを指定できます。

動作確認: ログにユーザー名が表示されるか

設定が完了したら、クライアント PC から通信を行いログを確認します。これが本記事のゴールです。

転送トラフィックログの確認

AD ユーザー（例: user01）で PC にログインし、インターネット（Google など）へアクセスします。

1. FortiGate 管理画面の ログ&レポート ＞ 転送トラフィック を開きます。
2. 該当の通信ログを検索し、詳細を確認します。

これまで IP アドレスのみが表示されていた送信元欄に、ユーザー名（user01）が表示される構成になります。

Web フィルタログの確認（ブロック時）

次に、Web フィルタで禁止されているサイトへアクセスします（例: user02 で確認）。セキュリティインシデントの調査において、このログの可視化は特に重要です。

1. ログ&レポート ＞ セキュリティイベント ＞ Web フィルタ を開きます。
2. ブロックされた通信のログを確認します。

誰が禁止サイトへアクセスしようとしたかを即座に特定できるため、管理者の調査工数やインシデント対応のスピードの向上につながります。

CLI での認証状態確認

GUI に加え、CLI でも FSSO の状態を確認できます。トラブルシュートの第一手として有用です。

認証済みの FSSO ユーザー一覧

diagnose debug authd fsso list

IP アドレス・ユーザー名・所属グループがまとめて表示されます。

FSSO サーバー（ポーリング）の状態確認

diagnose debug authd fsso server-status

ポーリング対象 DC への接続状態や、直近のポーリング結果を確認できます。

取り込み済みグループ情報の再取得

diagnose debug authd fsso refresh-groups

AD 側でグループ構成を変更した場合、再取得を行うことで反映されます。

導入前に知っておきたい制約・ハマりポイント

エージェントレス方式は手軽に導入できる反面、Collector Agent 方式と比較して機能制限があります。採用前に押さえておきたい 7 つの制約事項 を整理します。

Kerberos ログインイベント（4768 / 4769）のみサポート

FortiGate 直接ポーリングは、AD のセキュリティイベントログのうち Kerberos 認証イベントの 2 種類のみ を監視します。通常の AD 環境ではほぼ全てのログインが Kerberos で処理されるため問題にはなりにくいものの、NTLM 認証ベースのログインは検知されません。

参考: Fortinet Community – Troubleshoot FSSO agentless polling mode issues
“WinSec (Windows Security Events) polling only. NTLM-based authentication is not supported. Only Kerberos login events 4768 and 4769 are supported.”
（WinSec（Windows セキュリティイベント）ポーリングのみ対応。NTLM 認証はサポートされず、Kerberos ログインイベント 4768 と 4769 のみサポートされます。）
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-troubleshoot-FSSO-agentless-polling/ta-p/214349

対処

• 対象の DC で 監査ポリシーにより Kerberos 認証イベント（4768: TGT 発行 / 4769: サービスチケット発行）の記録が有効化されていることを確認する。
• NTLM 主体の環境では Collector Agent 方式の採用を検討する。

ワークステーションチェック・デッドエントリーチェックがない

Collector Agent 方式では、PC が起動中かどうかをポーリングで確認してログオフを検知する「ワークステーションチェック」や、無効化された認証エントリを定期的に破棄する「デッドエントリーチェック」が動作します。エージェントレス方式ではこれらが提供されません。

そのため、ユーザーが PC をシャットダウンせずにネットワークから離脱した場合、AD 側のログオフイベントが記録されないケースで認証エントリが残り続けることがあります。

ネストしたグループで正しく動作しないことがある

AD でグループがネストされている構成（親グループの配下に子グループを所属させる運用）では、エージェントレス方式がメンバーシップを正しく解決できないケースがあります。FortiGate 側のポリシーで利用するグループは、ユーザーを直接メンバーに持つグループを選ぶ構成を推奨します。

FortiGate の CPU 消費が増える

エージェントレス方式では、FortiGate 自体が Collector の役割を担います。Collector Agent 方式と比較して FortiGate 側の CPU 消費が増加する 傾向があります。ユーザー数が多い環境では、CPU 使用率の推移を事前に検証することを推奨します。

SMB（TCP 445）の通信許可が必須

FortiGate は DC に対して SMB プロトコル（TCP 445） でイベントログを読み取りに行きます。FortiGate と DC の間に別の FW や ACL がある構成では、この通信を許可する必要があります。

参考: Fortinet Community – Troubleshoot FSSO agentless polling mode issues
“FortiGate polls the DC on TCP port 445 to collect user login events.”
（FortiGate はユーザーログインイベント収集のため、TCP 445 で DC をポーリングします。）
https://community.fortinet.com/t5/FortiGate/Troubleshooting-Tip-How-to-troubleshoot-FSSO-agentless-polling/ta-p/214349

SMBv1 は FortiOS 6.2 以降で既定無効

過去のバージョンでは SMBv1 が利用されていましたが、FortiOS 6.2 以降では SMBv1 の使用は既定で無効化されています。そのため DC 側も SMBv2 / SMBv3 への対応が前提となります。特段の事情がなければ、SMBv1 を有効にしないまま運用することを推奨します。

CLI での確認は以下の通りです。

config user fsso-polling
    edit <id>
        set smbv1 disable        # 既定値は disable
    next
end

時刻同期が必須（Kerberos 要件）

Kerberos 認証はチケットの有効期限チェックを時刻に依存します。FortiGate・DC・クライアント PC 間で時刻がずれていると、ポーリング自体は成功していても認証エントリが正しく取得できない場合があります。 FortiGate・DC のいずれも NTP サーバーと同期させた構成を推奨します。

# FortiGate の NTP 設定確認
config system ntp
    show
end

トラブルシューティング

FSSO が想定通りに動作しない場合、以下の順序で切り分けを行います。エージェントレス方式は CLI でのトラブルシュート情報が充実しているため、GUI だけで原因が特定できない場合は CLI を活用することを推奨します。

diagnose debug authd fsso server-status

diagnose debug authd fsso list

----FSSO logons----
IP: 10.15.69.101  User: JDOE
  Groups: CN=DOMAIN USERS,CN=USERS,DC=EXAMPLE,DC=LOCAL
  Workstation: WIN11-01
  MemberOf: CN=DOMAIN USERS,CN=USERS,DC=EXAMPLE,DC=LOCAL
Total number of logons listed: 1, filtered: 0
----end of FSSO logons----

diagnose debug fsso-polling detail

diagnose sniffer packet any "host <DC の IP> and tcp port 445" 4 0 l

# FSSO ユーザー / グループ情報の再取得
diagnose debug authd fsso refresh-groups

# 全 FSSO ログオンエントリのフラッシュ
diagnose debug fsso-polling refresh-user

diagnose debug reset
diagnose debug console timestamp enable
diagnose debug application authd 8256    # 8256 で FSSO 関連のみに絞る
diagnose debug enable

diagnose debug disable
diagnose debug reset

よくあるエラーと対処一覧

まとめ

本記事では、FortiGate と Active Directory を連携させてログの可視性を高める FSSO（エージェントレス） の設定手順を解説しました。

• FSSO 連携によりログの送信元表示が IP アドレス から ユーザー名 になり、調査工数が削減できる
• 静的情報は LDAP、ユーザーのログイン状態は FSSO で連携する
• FSSO の実装方式は DC Agent / Collector Agent / FortiGate 直接ポーリングの 3 種類
• エージェントレス方式は AD サーバーへのインストール不要で、小〜中規模向きの選択肢
• FortiGate から DC への TCP 445（SMB）の通信許可が前提条件
• エージェントレスは Kerberos イベント（4768 / 4769）のみ対応という制約に注意

「AD 連携」と聞くと難易度が高く感じられる場面もありますが、エージェントレス方式であれば FortiGate 側の設定のみで完結するため、既存環境への影響を最小限に抑えて導入できます。

以上、最後までお読みいただきありがとうございました。