PAM ポリシーで OpenVPN のログインを一つのグループに限定する

すべてのアカウントが通常どおりログインできる状態を保ちつつ、VPN を使えるのは一つのグループだけにします。PAM は二つ目のパスワードストアなしでその違いを表現でき、OpenVPN プラグインは意図したチェックだけを含むサービスに向けられます。コツは、システム全体のスタックを誤って継承せずにそのサービスを構築することです。

ここからの手順は、プラグインのサービス名から始めてポリシーを組み立て、メンバー、有効なパスワードを持つ部外者、不正な資格情報という重要な三つの結果を検証します。

なぜ専用の PAM サービスなのか

auth-pam プラグインは引数としてサービス名を受け取ります。その名前が /etc/pam.d 配下のファイルを選び、そのファイルのスタックが VPN ログイン時に実行されます。システム全体のログインが使うのと同じ名前を渡すと、そのスタックのすべての判断を継承し、後から無関係な理由で追加されたものも含まれます。

代わりに専用のサービスを作ります。想定したバックエンドに対してすでに認証している動作中のスタックから始め、たとえばローカルのパスワードファイル、SSSD、ディレクトリサービスなどを使い、そこに資格のルールを追加します。空のファイルに二行をコピーするのがよくある誤りで、パスワードの有効期限、アカウントのロック、その他のチェックがコピーしなかったスタックに残っているかもしれません。

サービスを分けることは被害の範囲も限定します。共有スタックに VPN 専用のルールを置くと、全員の SSH やコンソールのアクセスを拒否してしまい、アクセスの変更が障害になります。

グループのルールを書く

資格のチェックは、資格情報が検証された後のアカウント段階に属します。account required pam_succeed_if.so user ingroup vpnusers のようなルールは、認証されたユーザーがそのグループのメンバーである場合にだけ処理を継続させます。

その行は断片であり、完全なサービスではありません。受け入れられるすべての経路がそこに到達する場所に組み込み、周囲の制御フラグを確認します。スタックの前方にある sufficient やジャンプの制御は、あなたのルールが動く前に処理を終了させることがあり、制限が提案になってしまいます。

習慣で use_uid を追加しないでください。これがない場合、モジュールは認証されるユーザーを評価し、これがある場合、モジュールは OpenVPN プロセスが実行されているアカウントを評価しますが、それは通常 root かサービスアカウントであり、ログインしている本人ではありません。

グループのメンバーシップはシステムの ID 解決から来るもので、あなたが知っている名前からではありません。ディレクトリのユーザーについては、よく知られた名前のローカルグループが同じ名前のディレクトリグループとは別のオブジェクトなので、同じバックエンドがそのユーザーのグループ照会に応答することを確認してください。

順序と ID の落とし穴

グループのルールは、認証スタックの後、なお適用すべきチェックの後に置き、保持するアカウントチェックの前か横に並べます。PAM はファイルの順序でモジュールを評価し、各行の制御値が失敗を最終的なものにするかを決めます。

スタックの重複に注意します。よくあるパターンは、すでにアカウントのルールを含む include に、自分のグループのルールを続けるもので、一つを期待していた場所に二つの判断が生まれます。編集したファイルだけでなく、インクルードされたファイルも読みます。実際の順序をすばやく見るには、ファイルを上から下へ読み、各制御値を書き留めます。

他の受け入れ要件はそのままにします。パスワードの成功は証明書のチェック、第二要素、接続後の認可の代わりにはならず、このポリシーもそれらの代わりにはなりません。これはアカウントが VPN アクセスの検討対象として適格かどうかだけを決めます。

メンバー、部外者、誤ったパスワードを試す

ポリシーを完了とみなす前に三つのケースを試します。メンバーは正常に接続します。グループ外の有効なアカウントはパスワードを認証しますが、VPN アクセスは拒否されます。どちらのアカウントでも誤ったパスワードは認証段階で拒否され、グループのルールによるものではありません。

クライアントに見えるエラーとサーバーのログを一緒に見ます。接続する人にはどちらの失敗も同じに見えることがあるため、この区別はサポートで重要で、正しいパスワードの部外者にはグループの変更が必要であり、誤ったパスワードには資格情報の再設定が必要です。

PAM を編集している間は二つ目のセッションを開いたままにし、変更後に通常の SSH ログインも確認します。専用サービスの要点は、システムのログインが影響を受けないことであり、それを知る唯一の方法は試すことです。

何かが壊れたら、コピーから以前のサービスファイルを復元します。望むルールは簡単で、メンバーシップがアカウントを VPN アクセスの対象として適格にし、他の必要なチェックはすべて引き続き適用されます。