Mac の Kerberos SSO と VPN：二つのサインイン経路を比較する

二つの仕組みは Mac 上で同じ親しみやすい結果を生みますが、内部の動作はまったく異なります。一方は SSO 拡張機能を通じて Kerberos チケットを取得し、参加するアプリケーションに渡します。もう一方は ID プロバイダーとのブラウザーセッションを維持し、Web アプリケーションにそれを尊重させます。必要なネットワーク、資格情報の有効期間、トンネルが切れた瞬間に何が起きるかが異なります。

二つの仕組み、一つのサインイン画面

チケットベースの経路は、Kerberos ドメイン、鍵配布センター、それと一致する時計に依存します。ブラウザーの経路は、到達可能な ID プロバイダー、Cookie またはトークン、その発行者を信頼するアプリケーションに依存します。どちらもサインイン時に開始するよう構成できるため、同じ機能と誤解されます。どちらを受け入れるかはアプリケーションが決め、Mac は両方を同時に正当に実行できます。

ユーザーがアプリケーションを開いたときに何を確認するかを問うことで比較してください。Kerberos ドメインに参加したファイルサービスはサービスチケットを要求し、どれだけブラウザーセッションがあっても満たされません。最新の ID プロバイダーの背後にある Web アプリケーションはそのプロバイダーのトークンを要求し、Kerberos チケットは完全に無視します。どちらの確認が行われるか分かれば、展開の問いは一般的ではなく具体的になります。

Kerberos 拡張機能がネットワーク上で必要とするもの

Apple のKerberos SSO 拡張機能ガイドは、事前のチケット取得を伴うネイティブな Active Directory 認証を説明し、ドメイン結合ではなくローカルアカウントと組み合わせています。できないのは、ドメインコントローラーへの経路を発明することです。Mac には Kerberos サービスレコードに応答するリゾルバーと、承認されたトンネルを通じてそれらに到達するルートが必要です。きれいにインストールされるプロファイルは、クライアントからドメインを実際に検出できるまで何も証明しません。

資格情報を確認する前に検出を確認してください。Kerberos ドメインの SRV レコードが解決し、返されるアドレスが VPN 起動後に到達可能でなければなりません。時刻は到達性と同じくらい重要です。Kerberos は許容範囲を超えてずれた時計からの要求を拒否し、生成されるエラーは認証失敗のように見えるからです。トンネルが切れている間に時刻源に到達できない Mac は、復帰した瞬間に再び失敗します。時刻源はインシデント対応ではなく、展開の一部として修正してください。

klist
sudo sntp -sS time.apple.com

アプリごとの VPN が拡張機能の動作を決める

フルトンネルはすべてをルーティングするため、この問題を隠します。アプリごとの構成は VPN プロファイルに記載されたアプリケーションだけをルーティングし、SSO 拡張機能自体もチケットを取得するためにネットワークを必要とするプロセスです。マッピングになければ、ローカルサインインは成功し、ブラウザー用にトンネルは上がり、チケット取得は依然として失敗します。

VPN 構成を読み、対象とすべきすべてのアプリケーションを列挙してから、バンドル ID を推測するのではなく文書化されたマッピング機構を通じて SSO コンポーネントを追加してください。見えるクライアントだけをマッピングし、その背後のコンポーネントをマッピングしないのが、この誤りの典型的な形です。マッピングは拡張機能と同じ管理プロファイルに置き、一方の変更が他方を黙って無効にしないようにします。その Mac に一度もサインインしたことのないユーザーでテストしてください。キャッシュされたチケットが壊れた経路を健全に見せるからです。その後、パスワード変更後に再度テストします。

ブラウザーの ID セッションは別の契約

ブラウザーセッションには Kerberos ドメインもサービスチケットもなく、Kerberos の意味での時計の許容範囲もありません。発行者、トークンの有効期間、更新経路があり、失敗の形は完了しないリダイレクトと、プライベートウィンドウが破棄する Cookie です。チケット経路の代替として扱うのが安全なのは、アプリケーション自体がその発行者を受け入れる場合だけです。VPN ポータルからの認証応答を無関係なサービスにコピーすることは、どれほど近道に見えても統合ではありません。

両方の仕組みを展開する場合は、どのアプリケーションがどちらを使うかを文書化してください。サポートの会話はそれに依存します。サインインしているのにファイル共有を開けないというユーザーは 二つのシステムを説明しており、答えはチケット経路が一度も実行されなかったということです。共有は開けるがイントラネットポータルは開けないユーザーはその逆を説明しており、チケットに仕組みを書いておけば質問の往復を 一度省けます。

部分ではなく順序をたどる

通常の登録済みアカウントでチェーン全体をたどります。ローカルサインイン、トンネル、チケット取得、そしてサービスに対する実際の操作を 一つ行います。トンネルの再接続後と意図的なパスワード変更後に繰り返してください。それぞれのケースが有効期間ロジックの異なる部分を試すからです。各段階が単独で通ることは、チェーンが機能することと同じではありません。チェーンこそがユーザーの体験であり、受け入れケースがカバーすべきものです。

プロファイルの所有者、VPN 認証方式、ドメイン検出経路、拡張機能のアプリケーションマッピングを 一か所に記録してください。その記録が、構築していない人にもフローを再現可能にします。次に、最も遭遇しやすい障害、トンネルが切れている間のチケット期限切れを確認し、クライアントが再起動なしで回復することを確かめてください。コールドスタートからしか動かない展開は未完成です。

各段階の所有者も記録してください。誰も保守しない Kerberos ドメインは古くなります。誰も説明できないチェーンは、誰もデバッグできないチェーンです。