OpenVPN username-as-common-name：CN チェックが空になる理由

client-connect スクリプトを追加して、common_name が username と異なる接続をすべて拒否すると、証明書とアカウントを結び付けているように見えます。username-as-common-name を実行しているサーバーでは、スクリプトが実行される時点でその比較はすでに意味を失っています。両方の値が同じ文字列なので、まったく別人に発行された証明書でもテストは通ってしまいます。

スクリプトの書き方が悪いからチェックが間違っているのではありません。読み取る値が同じ接続のなかで以前に置き換えられているから間違っているのです。

その比較が証明しているように見えるもの

証明書認証とパスワード認証は別々の証明であり、サーバーは両者を要求しても、それが同じ人物のものであることまでは要求しません。その隔たりは現実で、有効なデバイス証明書と任意の有効なアカウントの組み合わせは、そのデバイス証明書と名前を指定した一つのアカウントの組み合わせとは別の主張になります。common_name と username を比較するスクリプトは、両者の間に欠けている環のように読めます。common_name がまだ証明書の言ったとおりの意味を持っていれば、実際にそうなるでしょう。

そうなるかどうかはサーバーの一つのオプション次第で、そのオプションはたいてい無関係な理由、たとえばユーザーごとの設定ファイルに名前を付けやすくするために有効にされます。

username-as-common-name が名前に対して行うこと

username-as-common-name を有効にすると、OpenVPN はユーザー名とパスワードが検証された後に、証明書のコモンネームを認証済みのユーザー名に置き換えます。その検証中に実行される検証フックは、置き換えがまだ行われていないため、依然として証明書のコモンネームを受け取ります。その後のすべて、client-connect を含めて、ユーザー名を見ます。したがって後から呼ばれるコールバックは同じ識別子を二度受け取り、提示された証明書と比較することができません。

bob-device に発行された証明書、alice としてのディレクトリログインの成功、そしてオプションが有効という一つの例の接続をたどってみましょう。検証段階ではまだ二つの異なる文字列が見えます。接続段階では alice と alice が見えます。

この例は比較が空になる理由を示しています。証明書の検証とパスワードの検証は依然として独立して実行されるため、接続がそれ以外の理由で受け入れられるかどうかは示していません。

両方の識別情報がまだ存在する段階に結び付けを置く

ルールは、証明書の識別情報とアカウントを同時に見る段階、実務的にはユーザー名とパスワードの検証フックかそこに読み込まれたプラグインで適用する必要があります。すでにパスワード検証を行っているサポート対象のプラグインが通常は対のルールを追加する正しい場所であり、名前の比較に置き換えるとパスワードのチェックが完全に失われるからです。

等値が実際のポリシーであることはまれなので、コードを書く前にマッピングを定義してください。証明書はしばしばデバイスを識別し、ログインは人物を識別しますが、一つのデバイスが複数の人に正当に使われることもあります。関係は発行を自分で管理できる形式で保存し、改名、再発行、ドメイン修飾名のときにどうなるかを決めておきます。ディレクトリを理解せずに小文字化したりドメイン接頭辞を削除したりすると、別々であるべき二つのアカウントが統合されることがあります。

client-config-dir はコモンネームで引かれるため、このオプションはどのクライアントごとの設定が適用されるかも変えることを忘れないでください。

二つの有効な資格情報で対のルールを試す

ポリシーが許可する組み合わせから始めて、接続できることを確認します。次に同じ有効な証明書を、別のただし有効なアカウントで提示した場合、その試行は失敗しなければならず、失敗の理由はパスワードの打ち間違いではなく対のルールでなければなりません。間違ったパスワードはパスワードチェックが機能することを示すだけで、証明書とアカウントのルールについては何も語りません。

証明書がない経路と無効な証明書の経路も確認し、サーバーがクライアントごとの設定にどの識別情報を使うかを確かめます。比較を機能させる唯一の方法が username-as-common-name を無効にすることなら、すべてのクライアントの設定検索が証明書の名前に戻るため、まずその変更のコストを見積もってください。