古いハッシュを再利用せずに VPN 認証バックエンドを移行する

ユーザー名が新しいディレクトリに現れ、移行は完了と宣言され、それでもログインは失敗し続けます。ゲートウェイは依然としてサポートされた認証経路と正しい認可結果を必要としており、そのどちらもアカウントを含むようになったディレクトリから自動的に出てくるものではありません。バックエンドの移行はライフサイクルを伴う切り替えであり、コピー作業ではありません。以下の症状は、その違いを最もよく露呈するものです。

症状：アカウントはあるがセッションがない

新しいディレクトリにはすべてのユーザー名があり、テストバインドも成功し、それでも VPN クライアントは認証失敗を返します。この組み合わせは、ID は存在するものの、ゲートウェイが使う検証経路がそこに届いていないか、満たせない方式で届いていることを意味します。どちらも設定の問題であり、別々の問題です。

前者は配線です、つまりゲートウェイが応答しないバックエンドを指している、相手が想定していない共有シークレットを使っている、新しいサービスが返さない属性を要求しているということです。後者は暗号論的で、方式が元の秘密を要求するのに新しい保管庫にはそのハッシュしかありません。エラー文はどちらも似て見えるため、二つは一つの問題として扱われます。

アカウントに触れる前にこの二つを分ければ一週間節約できます。一方は経路と信頼の問題、他方は資格情報をリセットするかという判断であり、混ぜると誰も原因を追えない変更が生まれます。

誰かを移す前にチェーンを可視化する

クライアントプロファイルごとに六つを書き出します。外側の認証方式、内側の方式があるならそれ、クライアントが期待するサーバー ID、ゲートウェイとバックエンドの間のインターフェース、ゲートウェイがグループ所属に対応づける属性、そこから生じるリソースポリシー。順に読むと誰も担当していない環が見え、どの項目にも担当者がいて、切り替えは誰も確認しなかった環で壊れます。

通常のディレクトリログインはそのチェーンのほとんどを通りません。アカウントが存在しパスワードが機能することを示すだけで、それは一度も疑われなかった部分です。

ハッシュは方式の間を移動しない

資格情報の互換性は、どの集団を移す前にも一度確認する必要があります。FreeRADIUS はその区分を明確に記しており、サーバー自身が行う CHAP 検証には実際のパスワードが必要で、MS-CHAP はそのパスワードか適切な NT 素材を受け入れます。別の目的で作られたハッシュはどちらにも当てはまりません、どれほど強くても。

違いは誰が証明を計算するかにあります。ディレクトリへの束縛で検証する方式は、ディレクトリに検証できることを任せます。チャレンジ応答を再計算して検証する方式は秘密そのものを必要とします、サーバーが同じ計算を行わなければならないからです。

素材がない場合、誠実な選択肢はサポートされたリセット、再登録、外部の検証サービス、方式の変更です。復元可能なパスワードの一時的なエクスポートはその一覧にありません。プロジェクトで最も混乱する週に平文の資格情報保管庫を作り、たいてい移行より長く生き残ります。

パイロット集団、その後にライフサイクルの変更

承認済み ID の小さな集団を本物のクライアントで移し、四つを試します。新規ログイン、意図的に誤った資格情報、セッションが到達してよいリソース、到達してはならないリソース、そしてクライアントが受け入れたサーバー ID も確認します、証明書名の不一致は誰かがクライアントログを読むまで見えないからです。

次に、配備が実際に依存する変更を練習します。パスワードを変え、証明書を更新または再登録し、パイロットアカウント一つからアクセスを外します。それぞれの後に、どの検証器が試行を処理したかを確認します、切り替え前に作られたセッションは動き続けることがあり、次のログインについては何も証明しないからです。

プロファイル配布と ID 切り替えを分けます。各集団には想定されたプロファイル、資格情報または登録の状態、使うべき認証サービス、サポート連絡先が必要で、これらの記録に秘密を含めてはいけません。

古い経路と新しい経路が併存するなら、終了日で区切ります。自動フォールバックは、新しい所有者がアクセスを外した後でも古い資格情報でアカウントを通してしまうことがあり、それは可用性を装ったセキュリティ後退です。

ロールバックは資格情報を復元できない

切り替えを巻き戻しても、ディレクトリは今のままです。リセットされたパスワードはリセットされたまま、失効した証明書は失効したまま、変更された資格情報の形式は変更されたままです。それらはディレクトリ内の出来事であり、ゲートウェイがその源だったことはありません。復旧は出来事ごとに定義する必要があり、そのどれも互換性のないハッシュから秘密を再構築することに依存できません。

移行中の接続を使わない管理経路を残します。新しい認証が失敗したら集団を止め、期限を守るために全員の認証を弱めるのではなく、文書化された復旧経路を使います。

集団を覆った後、古いバックエンドの資格情報、プロファイル、信頼関係をそれぞれの所有者を通じて退役させます。古い経路がもうユーザーを通さないことを確認し、サポートがまだ必要とする秘密を含まない ID とポリシーの対応を保ちます。移行の完了は、新しいライフサイクルが機能し旧経路から誰も入れなくなったときであり、アカウント一覧が揃って見えるときではありません。