FortiGate VPN が誤ったグループに入る：RADIUS の照合

ログインは成功し、トンネルは上がり、ユーザーは誤ったポリシー、あるいはどのポリシーにも入りません。FortiGate のログにはグループが欠けていたことが一切出ません。FortiGate 側では認証が通り、グループ照合が単に発火しなかったからです。調べるべき連鎖には三つの別々の名前があり、ふつうそれらは同じ文字列ではありません。

三つの役割を持つ三つの名前

設定に触る前に三つとも書き出してください。二つは別のシステムに存在するからです。

ディレクトリのグループは RADIUS ポリシーが評価する対象です。返される属性は Access-Accept 応答の中の値です。FortiGate のローカルグループは、ポリシーが名前で参照する入れ物です。このうち二つを混同すると、ログインは通るのに認可が通らない状態になります。

照合は実際どこで行われるか

Fortinet のRADIUS グループ照合の解説は、Fortinet-Group-Nameを既定のグループ属性として挙げています。FortiGate は設定されたリモートサーバーとグループ名の値を、応答が持つ内容と比較します。つまり比較対象は返された文字列であり、ローカルグループの表示ラベルではありません。

そのためVPN-Engineeringというローカルグループが、vpn-engineeringとして返された値の隣にあっても一切一致しないことがあります。この比較では大文字小文字と綴りは飾りではありません。一つの文字列を選び、それを応答で使い、ゲートウェイの照合ルールでも同じ文字列を参照してください。

FortiAuthenticator では、グループを属性に関連付け、該当する RADIUS サービス ポリシーに含める必要があり、必要に応じてグループ属性の返却制御を有効にします。

属性がなくても応答は成功しうる

NPS などの RADIUS サーバーでは、ポリシーでディレクトリグループの条件を強制し、そのうえでサポートされる応答属性を設定します。パスワード検査が成功すればそれだけで Access-Accept が生成され、グループ文字列のない Access-Accept も完全に有効な応答であり、FortiGate 側では何も認可しません。これがこの問題の最も一般的な形です。

グループを定義することと送信することは同じではありません。別々の画面での二つの設定手順であり、ふつうは片方しか行われません。

Any との照合が罠である理由

Any のリモートグループ照合は、RADIUS サーバーがすでに望む母集団だけを許可しているなら正当な設計です。その委譲を意図的に選んでください。欠けた属性を消すために照合を広げると、RADIUS サーバーがたまたま受け入れるアカウントをすべて通してしまい、VPN アクセスを想定していなかったものまで含まれます。症状は消え、アクセス制御は静かに存在しなくなります。

RADIUS サーバーが誰を許可すべきか名指しできないなら、Any 照合の準備はできていません。

サポート用に四つの記録を残す

それでも動かないときは、四つを集めてください。選択された RADIUS ポリシー、実際に返されたグループ属性、照合に使われた FortiGate サーバーとその値、そして結果としてのローカルグループです。この四つがあれば、パスワードを露出させたりグループ所属を変えたりせずに、破綻箇所を特定できます。

実際のルールの下で、許可されたアカウントと範囲外のアカウントを一つずつ試し、認証結果だけでなく結果のポリシーとリソースへのアクセスも確認してください。この組だけが、照合が意図どおりに動いているかを教えてくれます。