まずEAP方式を読む — VPNが使えるパスワードハッシュはどれか
VPNが検証するのは秘密そのもので、Webのハッシュではない。同じパスワードが使い続けられる約束をする前に、方式と保存内容を確認する。
Webログインは動くのに、同じテーブルのパスワードをVPNがすべて拒否する、というチームは少なくありません。Webアプリは自分で計算したハッシュを比較しますが、トンネルはサーバーが検証できる形で秘密の所持をクライアントに証明させます。保存されている材料に対する要求が違うのです。こうした案件のほとんどは、この差のところで止まります。
方式を先に読み、スキーマは後
どのスキーマを見る前に、選んだ方式がどんな証明を求めるのかを書き出します。チャレンジ応答方式は、サーバーが期待する応答を計算できる材料を必要とし、実際にはパスワードそのものか互換の派生形になります。保護されたトンネルの中でパスワードを運ぶ方式は、検証側にパスワードそのものが要ります。クライアント設定ではなく検証側の要件について方式のドキュメントを読んでください。クライアント側の要件はたいてい簡単な部分です。
現代のWebフレームワークが作るソルト付きハッシュは、どちらも提供しません。ある一つの比較を検証するだけで、元の秘密に戻すことはできません。
チャレンジ応答はソルト付きハッシュを使えない
MSCHAPv2はチャレンジ応答の交換であり、サーバーはパスワードを受け取らないため保存文字列と比較できません。すでに持っている材料から期待応答を導出する必要があり、互換の保存形式が非常に狭いのはそのためです。利用者ごとのソルト付きbcryptやArgon2の値は一方向性が強く、この交換を完全に排除します。下の表は方式名ではなく保存形式から始めます。答えを決めるのは保存形式だからです。
| What the store holds | What that material can verify | What has to change |
|---|---|---|
| A bcrypt or Argon2 value with a per-user salt | nothing challenge-response can use, and not the password either | re-enrol the users, or place a verifying service in front |
| An unsalted NT-hash | MSCHAPv2, and inner PAP through a TLS tunnel | nothing, as long as that store is the verifier |
| A client certificate with a revocation list | EAP-TLS only | move enrolment and revocation to the PKI owner |
strongSwan向けの SQLプラグインのドキュメント は、構成と資格情報のための独自スキーマを定義していますが、プロジェクトは今もこのプラグインを実験的と位置づけています。アプリケーションの利用者テーブルに適応することも、どのハッシュ方式が保存値を作ったかを推測することもありません。したがって現実的な選択は、ゲートウェイが使える保存先への移行か、既存の保存先の手前に置く認証サービスでこの交換を担わせるかです。それ以外は、内側に隠れた前提を抱えたコネクターにすぎません。
RADIUSは作業を移すだけで、要件は移さない
EAPをRADIUSサーバーに委ねると検証の場所が変わり、通常は監査証跡が改善します。一方通行のハッシュからパスワードを取り戻すわけではないので、認証サービスには終端する方式と互換の材料が依然として必要です。チームがこれを知るのは、RADIUS経路を作り、反対側で同じ壁に突き当たった後です。
RADIUSサーバーが互換の資格情報を持つディレクトリを読める場合、設計は成立し、VPNゲートウェイは単純なままです。読めない場合、正直な答えは別のコネクターではなく登録の変更です。プロビジョニングと失効は身元を持つ者の仕事なので、対応する同期処理のないコピーしたテーブルは、シングルサインオンではなく二つ目の資格情報のライフサイクルです。誰かが一か所だけでパスワードを再設定した最初の瞬間に食い違い、その食い違いは、両方のシステムに存在するアカウントがそれぞれで違う振る舞いをするまで静かに続きます。
ディレクトリを読むアカウントはその読み取りだけに限定し、ゲートウェイが自身の設定に使うアカウントとは分けてください。管理アカウントを共有すると、読み取り専用の設計がはるかに広い影響範囲に変わります。
アカウントをどこに置くか
材料の問題が片づくと、二つの構成が残ります。ゲートウェイが自分だけが読む小さな資格情報ストアを持つか、企業ディレクトリの手前に立つ認証サービスに委ねるかです。
前者は筋道立てて考えやすい一方で利用者には不利で、二つ目のパスワードを維持することになります。後者は一つのアイデンティティを保ちますが、接続前に必ず起動していなければならないサービスへの依存を追加します。どちらも誤りではありませんが、選択はゲートウェイの設定の隣に記録すべきです。そうしないと次のエンジニアはもう一方が選ばれたと前提します。どちらを選ぶにせよ、下の二つのコマンドが、変更前の現状を示すものです。
mysql -N -e "SELECT id, username FROM vpn_users WHERE active = 1 LIMIT 5" vpn
swanctl --list-connsアカウント認証は認可も解決しません。グループ所属、端末の状態、ネットワーク権限は、利用者が要求された身元を証明した後も明示的な対応づけが必要です。完璧に認証して何も認可しない接続はポリシーの結果であり、方式の不具合ではありません。