VPN グループへの追加だけではアクセス権は付与されない
グループ所属は条件のひとつで、許可そのものではありません。ゲートウェイが実際に何を照合したかを見て、許可・拒否の記録を読み、両方の結果を試してください。
アカウントを正しいグループに入れ、ログインも成功したのに接続が拒否される、あるいは接続しても何も届かない。よくある反応は何かが通るまでグループを増やすことだが、それではチケットの要求よりはるかに広い権限を配ってしまう。グループ所属は認可判断への入力の一つであり、判断そのものではない。ゲートウェイはセッションの事実を集め、順序づけられたポリシーと照合し、そのうえで何に触れられるかを決める。別の条件が失敗しているなら、グループを変えても露出が変わるだけだ。
グループ所属は条件であり、許可ではない
RADIUS ではグループは認可属性として届き、属性はセッションを記述するもので許可を与えるものではない。サーバーは Access-Accept か Access-Reject で応答し、受け入れる際に Filter-Id、Class、RFC 2868 のトンネル属性を付けられる。対向機器はベンダーの判断でそれを解釈する。プロトコルにグループを全アクセスへ対応づける仕組みはなく、その対応はゲートウェイやネットワークアクセスサーバーでポリシーを設定した人が書く。
だから同じグループ名でも二つのシステムでは挙動が違う。Microsoft NPS は条件・制約・設定からポリシーを組み立て、定められた順序で評価する。OpenVPN Access Server は独自のグループとアクセス規則のモデルを持ち、コミュニティ版の OpenVPN サーバーは問いのすべてを client-connect スクリプトや client-config-dir ファイルに委ねることが多い。
決めるのは一致した規則であり、期待したグループではない
多くのエンジンは最初に一致したポリシー、または最も具体的なもので止まる。ポリシー 3 が拒否しポリシー 7 が許可する場合、通過させるはずの規則に届かないままセッションが失敗しうる。順序は NPS や多くのネットワークアクセス制御製品で実際の設定であり、年を経てずれていく。
グループに随伴する条件が残りの半分だ。デバイスの状態、認証方式、MFA の完了、送信元ネットワーク、証明書のサブジェクト、時間帯の窓は同じポリシーに置ける。一つでも満たされなければポリシーは一致せず、エンジンは次へ落ち、既定の拒否が適用される。利用者からはグループが無視されたように見え、エンジンからはグループを問い合わせていない。
ディレクトリの細部も同じ錯覚を生む。Windows グループ所属で照合するポリシーはトークン内の SID を読み、そこにはセキュリティグループしか列挙されないため、配布グループは決して現れない。プライマリグループは別のフィールドにあり一覧には載らないので、そこに固定したポリシーは静かに失敗しうる。
グループに触る前に許可・拒否の記録を読む
まず一つ問う。 その要求は認可の段階まで到達したのか。NPS ならイベントログに答えがあり、6272 が許可、6273 が拒否、6274 がポリシー評価前に破棄された要求を記録する。この三つの番号は問題を三つの調査に分け、グループに関わるのは一つだけだ。
| What the record shows | What it means | Where to look next |
|---|---|---|
| 6272, access granted | Authentication and authorization both succeeded | Routes, split tunnel, DNS, per-resource rules |
| 6273, access denied | A policy matched and denied, or nothing matched and the default denied | The conditions of the policy that fired, in order |
| 6274, request discarded | The request never reached authorization | Shared secret, NAS client entry, proxy chain, malformed attributes |
ログに手が届かないときはサーバーに直接問い合わせ、返答を読む。Filter-Id もトンネル属性もない返答は、サーバーがセッションを平凡と見なし、ゲートウェイが独自の規則を適用していることを示す。適用点が実装していない属性を含む返答は別の故障で、認可は通ったが機器が結果を無視している。
radtest alice 'password' 10.0.0.5 0 testing123返ってきた属性は、グループ名が示唆するものではなく、ゲートウェイが文書化している属性と比べる。その比較がポリシーの問題と適用の問題を分ける。
グループ変更は遡及しない
認可属性はセッション認証時に一度だけ返る。ゲートウェイはそれをセッションに保持し、パケットごとにディレクトリを読み直さない。だから誰かをグループから外しても確立済みのセッションは動き続け、新しいセッションは失敗しうる。
変更を効かせるには新しい認可判断が要り、新しい鍵だけでは足りない。RFC 5176 の動的認可に対応するサーバーなら、UDP 3799 への Disconnect-Request や CoA-Request が再評価を強制する。なければクライアントを切断して再接続させる。再ネゴシエーションはトンネル鍵を更新するだけで、認可結果は通常そのまま残る。
直すのは条件であり、グループではない
どのポリシーが発火したか分かれば、修理はたいてい小さい。意図した許可を覆う拒否の順序を入れ替える、狙ったポリシーに不足するデバイスや MFA の条件を足す、あるいは他の十個を抱えるグループへ昇格させる代わりに、その一つの資源に狭い規則を書く。
短いループが変更を誠実に保つ。
- 元のアカウントで拒否を再現し、何かを変える前にイベント ID を書き留める。
- 変えるのは一つの対象だけ、ポリシーの順序、一つの条件、または一つのグループ。どれを変えたか記録する。
- 新しいセッションを開き、許可がログに出ることと、資源が実際に開くことを確認する。
- まだ拒否されるべき利用者を試し、修理がポリシーを誤って広げていないことを確かめる。
許可が正しくても資源が開かないなら、認可が通った時点で 問題は経路制御や名前解決へ移っている。二つの故障を分けておけば、次のチケットは半日ではなく数分で済む。