SPNとは

SPNが表すもの

SPNはService Principal Nameの略で、Kerberosが接続先サービスを一意に識別する名前です。HTTP/web01.example.net、CIFS/files01.example.netのようにサービス種別とホスト名を組み合わせ、Active Directory上のサービス実行アカウントへ登録します。

Clientが要求したSPNをKDCが見つけると、その登録先アカウントの鍵で保護されたService Ticketを発行します。未登録、別名との不一致、重複登録は、TGT取得後に特定サービスだけ失敗する代表的な原因です。

要求名と登録名を突合する

利用者がaliasやLoad Balancer名で接続すると、Clientはその名前を含むSPNを要求します。実サーバー名のSPNしか登録されていない場合、DNSは成功してもKDCのSPN検索で停止します。

調査では、接続に使ったFQDN、要求SPN、setspnなどで見える登録SPN、登録先アカウントを同じ記録へ残します。DNSのCNAME修正だけで解決したように見せず、認証名との整合を確認します。

• Clientが要求したSPNを確認する。
• aliasと実ホスト名の両方を棚卸しする。
• 登録先アカウントの所有者を確認する。

未登録と重複を分ける

未登録ではKDC_ERR_S_PRINCIPAL_UNKNOWNが返ることがあります。重複SPNでは一意な鍵を選べず、認証失敗や予期しないアカウントへのTicket発行につながります。

SPNを追加する前にフォレスト全体で既存登録を検索し、同じ値が別アカウントへ存在しないことを確認します。障害回避のために複数アカウントへ同じSPNを追加する対応は避けます。

• 未登録と重複を別の検索で確認する。
• 追加前後のSPN一覧を保存する。
• 不要な旧アカウント登録を整理する。

サービスアカウントとの関係

SPNの登録先は、サービスが実際に使うアカウントと一致する必要があります。サービス実行アカウントを変更したのにSPNを移していない場合、KDCのTicket発行とサービス側の復号鍵がずれます。

gMSAへ移行する場合も、対象サービス、許可ホスト、SPN、権限を同じ変更として扱います。パスワードや鍵そのものを記録せず、アカウント識別子と検証結果だけを証跡にします。

• サービス実行アカウントを確認する。
• アカウント変更とSPN移行を同時にレビューする。
• 対話ログオンや過剰権限を残さない。

変更後の確認

SPN修正後は、DNS、KDC到達、TGT取得、Service Ticket取得、サービス利用までを順に再確認します。4769のService Name、結果、暗号方式が期待どおりであることも確認します。

台帳にはSPN、対象サービス、FQDN、登録先アカウント、所有者、変更日、廃止条件を残します。一時aliasや旧サーバーのSPNが残ると、将来の重複やKerberoasting対象拡大につながります。

• 正常系と同じ順序で再試験する。
• 4769とサービスログを関連付ける。
• 旧SPNの削除条件を明記する。

関連語

同じ主要カテゴリの用語

セキュリティ・認証の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能