EAPかクライアント証明書か — IKEv2認証の判断

ゲートウェイは自身の身元を証明書で示しつつ、あなたの身元をEAPで示すことができ、この組み合わせは矛盾ではなく一般的です。二つの仕組みは別の問いに答えます。このエンドポイントは想定どおりか、このユーザーまたは端末は許可されているか。プロファイルにEAPがあってもサーバー検証は無効になりません。プロファイルを単一の設定として読むことが、誤った資格情報をリセットさせる原因です。

どちらのオブジェクトにも触れる前に、どの主張が失敗したかを判断します。失敗した段階を順に読めば、それが分かります。

二つの資格情報、二つの主張

サーバー証明書は名前を鍵に結び付け、クライアントはその結び付きを信頼ストアと照合します。クライアント証明書は身元を鍵に結び付け、ゲートウェイは提示された証明書が信頼するものへ連鎖するかを確認します。EAPは認証のやり取りを運び、その内容は選択した方式によって変わります。これらは寿命、所有者、失敗の仕方が異なる三つの構造です。

秘密鍵を解錠するパスフレーズはアカウントのパスワードではありません。両方のプロンプトが数秒差で現れる場合でも同じです。一方は端末の鍵ストアにローカルで、もう一方はゲートウェイの背後の認証サーバーが検証します。

EAPは入れ物であり、方式ではない

EAPは枠組みです。ゲートウェイとクライアントが方式を交渉し、その方式がパスワード、トークン、トンネル内の内部交換、証明書のどれに関わるかを決めます。strongSwanのIKEv2ドキュメントが説明しているとおりです。だからこそEAP-TLSはクライアント側から見てEAP-MSCHAPv2とまったく似ていません。メニューではどちらもEAPと表示されますが。EAPとだけ書かれたプロファイルは、ユーザーに何を尋ねるのかを教えてくれません。

方式とバックエンドを一緒に読みます。バックエンドがアカウントの形式、ロックアウトの挙動、パスワードリセットで実際に変わるものを決めており、それらのどれもクライアントのプロファイルには見えません。

混在した配備は普通のこと

ユーザー向けにサーバー証明書とEAPを併用する形は、多くのリモートアクセスゲートウェイが採用しています。クライアントには検証可能なエンドポイントを、運用者には中央のアカウントストアにおけるユーザーごとの身元を与えるからです。クライアント証明書による配備もあり、通常はパスワードより端末の身元が重要な場合に選ばれます。どちらも正当であり、先週見たものが目の前のものだと決めつけるのが誤りです。

クライアントのフィールド名から推測するのではなく、文書化された方式とアカウント形式を運用者に確認します。

失敗した段階から判断する

観察を順に並べます。ユーザーへのプロンプトより前の信頼エラーはサーバー証明書の問題で、パスワードでは直りません。プロンプトの後に拒否が続く場合はユーザー認証の問題です。EAP方式とバックエンドが疑わしい対象です。認証に成功した後にchild-SAが失敗する場合は、どちらでもありません。

さらに二つの区別が重要です。サーバー証明書を拒否するクライアントは通常、名前の不一致や不明な認証局を報告し、これは信頼ストアの問題です。ユーザーを拒否するゲートウェイは多くの場合、EAP方式と理由の分類を記録し、これはアカウントやポリシーの問題です。

二つのモデルの運用

証明書では、発行、更新、失効、紛失端末の削除が仕事であり、自分で管理するスケジュールで行います。EAPでは、アカウントのライフサイクル、各クライアントプラットフォームでの方式対応、バックエンドが要求する第二要素が仕事です。どちらのモデルも抽象的に安いわけではなく、負荷のかかるチームが異なります。実際にどちらを使っているかを書き留めてください。サポート用スクリプトは設定以上に異なります。

ノートでは分けて書きます。証明書の失効はある日付で失敗を生み、アカウントのロックはパスワード変更後に失敗を生み、方式の不一致は一つのプラットフォームだけで失敗を生みます。

身元が受け入れられた後に

認証は一つの関門です。childセキュリティアソシエーション、トラフィックセレクター、DNS、アプリケーション自身の権限はその後の関門であり、それぞれ独自の条件で失敗します。何にも到達しない受け入れ済みの身元は、認証の問題ではありません。

方式、使用したアカウントまたは証明書、失敗した段階を記録します。そのメモが次のインシデントを実験ではなく照会に変えます。