VPN グループポリシーにおける ASA LDAP グループマッピングと DAP の比較

AnyConnect セッションが受け取るグループポリシーを決めるレコードは二つあり、それぞれ設定の別の場所にあり、失敗の仕方も異なります。LDAP 属性マップは認証時にディレクトリの値を ASA の認可属性へ変換します。DAP レコードはその後で条件を評価し、属性を追加または上書きできます。どちらも同じポリシー名に行き着くため、ログインが成功しただけではどちらの仕組みが働いたのか分かりません。両者を比べる意味は、二つ目が一つ目を黙って上書きするのに任せず、意図して一方を選ぶことにあります。

二つの仕組み、二つの判断点

選択は三つの問いに集約されます。ディレクトリの単一の属性値だけで決まるのか、その値以上の情報が必要なのか、両方が一致したときにどちらが優先されるのか、という問いです。

入力がグループ所属だけなら、属性マップはより小さな道具で、監査もしやすいものです。マップは一つ、AAA サーバー一つに紐づき、グループごとに一行で済みます。選択にデバイスの状態、エンドポイントの識別、二つ目の属性、時間帯などを考慮する必要があるなら、マップの入力は足りなくなり、その規則を表現できるのは DAP です。両方を使っている場合は、どちらかを書く前に自分のリリースでの優先順位を確認してください。DAP レコードに一致したセッションが、マップが返したポリシーを保持しないことがあるからです。それ以外は事務作業です。

属性マップの経路、設定順に

マップの経路は AAA サーバーの定義から始まります。属性マップは、接続プロファイルが実際に使う LDAP サーバーエントリに紐づいていなければなりません。稼働中の設定に存在しても、そのサーバーから参照されていないマップは何も変えません。この紐づけの一行が、残りの設定を生かします。ASA LDAP マッピングガイド は 9.x リリースのマップ構文の参照先です。

マップの内部では、一つの文がディレクトリ属性とそれが供給する ASA 属性を指定し、続く文が具体的な値を変換します。map-name memberOf Group-Policy に続く map-value memberOf CN=VPN-Support,OU=Groups,DC=corp,DC=example Support-ReadOnly が形です。左辺はディレクトリが返した値、右辺はすでに存在していなければならないグループポリシー名です。識別名とポリシーの表示名は交換できず、どちらの文字列でもわずかな違いがあるとログイン時にエラーは出ません。

ここで二つの点が効いてきます。memberOf はアカウントが属するすべてのグループを返すため、二つのマップ済みグループに属するユーザーはマップに二つの候補値を与えます。ガイドにあるアルファベット順の規則が、自分の優先順位ではなく頼れる唯一の同点処理です。マップされていない値は何も返さず、プロファイルの既定ポリシーへ黙って戻ります。

DAP の経路と、それが加えるもの

DAP は条件を評価し、AAA の結果の上に属性を適用します。レコードは優先度、アクション、条件の集合を持ちます。レコードは優先度順に評価され、アクションが評価を続けるか止めるかを決めます。これは値の検索とは異なる実行モデルであり、まさにそのためマップには表せない規則を表せます。

DAP が加えるのは入力です。条件はディレクトリ属性、エンドポイント属性、デバイスの状態を参照でき、一致したレコードはそのセッション用の ACL、URL リスト、フィルターを持てます。したがって、管理対象のノート PC を使うサポート担当者には読み取り専用ポリシーを、管理されていない端末の同じ担当者には制限付きポリシーを与える、といった規則は DAP では表現できますが、属性マップでは表現できません。マップの入力はただ一つ、指定した属性に対してディレクトリが返した値だけです。

DAP はまた、セッションが誤ったポリシーに落ちたときに見る場所を二つ目として加えます。継続のアクションで一致するレコードは評価を終わらせず、後続のレコードが結果を変えることもあるため、観測されるのは単一の検索ではなく一連の流れの結果です。優先度の番号を順に読み、フォールバックのレコードが実際に仕事をしている可能性を忘れないでください。一方マップには流れがありません。一つの属性、一つの値、一つの答えです。

両者が食い違うところ

設計を壊すのは優先順位の部分です。セッションがマップの項目と DAP レコードの両方に一致する場合、結果はリリースとレコードのアクションに依存します。どちらかの仕組みが結果を所有すると決めつけず、自分の ASA で確認してください。

混乱の大半は三つの失敗パターンで説明できます。定義されていても、プロファイルが使うサーバータグに一度も紐づけられていないマップは、どこにもエラーを出さずに既定ポリシーを返します。ディレクトリの値と大文字小文字や空白が異なる DAP 条件文字列は決して一致せず、フォールバックのレコードが黙って適用されます。そしてまだ存在しないグループポリシーはマップに受け入れられます。マップは名前を返すだけだからです。その結果セッションは意図した権限を一つも得られず、ログには欠けているオブジェクトを指すものが何も残りません。グループ所属に触れる前に三つとも確認してください。

稼働中のセッションから証拠を読む

設定ではなく新しいセッションから答えを読みます。show vpn-sessiondb detail anyconnect filter name jdoe はセッションが実際に受け取ったグループポリシーを表示し、show running-config ldap attribute-map はマップが返し得た値を確認します。ディレクトリ側では、test aaa-server authentication LDAP-AD username jdoe password <password> が ASA が受け取った属性を示し、debug ldap 255 がテストの結果が期待と違うときのやり取りを示します。

そのうえで四つのレコードを書面で突き合わせます。ディレクトリの値、設定したマップまたは DAP 条件、ローカルのグループポリシー、そしてユーザーが実際に到達できたリソースです。最初の三つが一致して四つ目が合わないなら、問題は選択ではなくポリシーの本体にあります。セッションが正しいポリシー名を示すのに ACL が違うなら、LDAP を見るのはやめてください。一度に一つのレコードを変えて新しいセッションで再確認します。再接続したセッションだけが、いま書いた設定を反映した証拠になるからです。