NetExtender はログインできるのにアクセスできない：SonicWall ローカル + LDAP
NetExtender は接続するのに何も応答しない：SonicWall の認証、SSL VPN サービスへの所属、VPN アクセスの許可を分けて確認します。ローカルアカウントと LDAP アカウントの両方で同じです。
ログインは成功し、トンネルも確立するのに、ファイアウォールの内側からは何も応答しない。SonicWall SSL VPN でこの症状が出るときは、アカウントが認証を通過したうえで、その後の二つの許可のどちらかで止まっていることが多い。SSL VPN サービスへの受け入れか、リソースへの到達許可である。ローカルと LDAP のアカウントが混在すると事態は悪化する。二つのストアがこれらの許可に至る経路が違うからだ。クライアント側から見た症状は同じなので、層を意識して切り分ける必要がある。
症状と、その背後にある三つの許可
ユーザー名から到達可能なサーバーまでの間には、独立した三つの判断がある。認証方式は、資格情報が受け入れられるか、どのストアが受け入れるかを決める。SSL VPN サービスへの所属は、その身元がそもそも SSL VPN を使えるかを決める。VPN アクセスリストは、セッションがどのプライベート宛先に届くかを決める。一つを通っても、次の二つについては何も分からない。
認証は通ったが SSL VPN サービスのグループに入っていないユーザーには、確立しても何も運ばない接続が見える。ファイアウォールのログには失敗ではなく、ログインの受け入れが記録される。早く見抜く価値のあるケースだ。修正はグループへの所属であり、パスワードの再設定ではない。
受け入れられてもリソースがないユーザーには、接続はするが有用な場所へルーティングされないセッションが見える。どちらもヘルプデスクからは壊れたトンネルに見えるが、どちらも設定の問題であって接続性の問題ではない。
ドメイン欄はディレクトリではない
NetExtender はドメインを尋ねるが、その欄は Active Directory の検索ベースではない。既定の構成では、この欄はファイアウォールに設定された SSL VPN ユーザードメインと一致していなければならず、その文書化された既定値は LocalDomain。 比較は大文字と小文字を区別するため、大文字小文字が異なる値はアカウントが正しくても失敗する。
認証パーティションを設定している場合は、パーティション名が外部認証コンテキストを選び、設定済みの既定値は独自の役割を保つ。どちらの構成でも、クライアント側のドメインラベルはユーザー名の一部として LDAP や RADIUS に転送されないため、ディレクトリ検索の制御には使えない。
三つの文字列はメモで分けておく。会社の DNS サフィックス、LDAP 検索ベース、NetExtender のドメインラベルである。似て見えるが、どれも他の代わりにはならない。別のファームウェア版についてのフォーラム投稿の値ではなく、この設置環境の運用者が示した値を使う。
受け入れとリソースアクセスは別の許可
ローカルアカウントは、サービスが受け入れる前に SSL VPN サービスのグループへの所属が必要だ。ディレクトリアカウントは、サポートされているグループマッピングのワークフローで同じグループに到達する。つまり LDAP のグループ関係を設定し、そのうえで ディレクトリ側の想定ではなく、実際に有効な所属として検証する必要がある。
次にリソースアクセスがある。ユーザーまたはグループの VPN アクセスで設定する。役割に必要な具体的なサブネットとサービスだけを与え、一つのアプリケーションが必要だからといって LAN 全体を渡す近道はしない。セッションのルート、アクセス規則、宛先サービスの権限は、すべてその範囲と一致していなければならない。
| Layer | What it decides | Where it is set |
|---|---|---|
| Authentication | Whether the credential is accepted, and by which store | Authentication method and directory configuration |
| Admission | Whether the identity may use the SSL VPN | SSL VPN service group membership |
| Resource | Which destinations the session may reach | VPN Access on the user or group |
クライアント上のルートは宛先を選択可能にするだけで、許可を与えるものではない。SSL VPN グループへの所属も、アカウントをファイアウォール管理者にするものではなく、一般的な権限付与として扱うべきではない。
二つの身元、それぞれ四つの確認
ローカルアカウント一つとディレクトリアカウント一つでテストする。どちらも権限を狭くし、どちらもテスト用アカウントとして文書化する。それぞれについて、ログインを受け入れた認証元、有効なグループ、割り当てられたリソースアクセス、許可されたアプリケーション操作を一つ記録する。四つの確認、二つのストア、組み合わせごとの文書化された結果である。
次に否定ケースを試す。アカウントが到達すべきでないリソースと、そもそも拒否されるべきアカウントである。肯定経路だけを示す設計は、特に同じ短いユーザー名が両方のストアにある場合に、第二の入口を開けたままにしがちだ。ディレクトリアカウントを無効にし、ローカルのアカウントが黙って使え続けないことを確認する。
重複名の確認は、インシデントの後ではなく展開の一環として行う。同じ人物が二つのストアにいることは、サポート上の便利さであると同時に監査上の問題であり、ファイアウォールは設定したほうを喜んで認証する。
復旧経路は狭く保つ
ローカルアカウントを除外するのではなく、アカウント区分ごとに MFA ポリシーを維持する。ディレクトリ障害時の承認済み復旧経路としてローカルアカウントを使うなら、その経路を名前を特定した管理者に限定し、意図的に運用する。従業員全員にローカルの緊急アカウントを与えるのは、監視の弱い二つ目の認証システムだからだ。
クライアントのドメイン、認証元、有効なアクセスを同じ記録に書く。そうすれば次の管理者は、ログインが通るまでドメイン文字列を試すのではなく、機能する混在アカウントの設計を再現できる。