SPN重複で認証が壊れるときは、Kerberos が「このサービスはどのアカウントのものか」を一意に決められなくなっているか、誤ったアカウントに向けてチケットを発行しているのが本質です。復旧の基本は、要求されたSPNを特定し、setspn で所有者と重複を確認し、不要なSPNを削除して正しいアカウントへ -S で登録し直し、その後に Kerberos チケットをクリアして再試験することです。SPN はサービスインスタンスの一意な識別子で、Kerberos はこれを使ってサービスとサインイン アカウントを結び付けます。 (Microsoft Learn)
SPN重複の検索でたどり着く障害でも、実際には「純粋な重複」だけでなく、「誤ったアカウントにSPNがある」「サービスアカウント変更後の再登録漏れ」「クライアントが別名から別のSPNを要求している」が混ざっていることが少なくありません。Microsoft のトラブルシューティングでも、同系統エラーの原因は複数パターンに分けて扱われています。まずは重複探しより、アクセス名と実行アカウントを確定させる方が早道です。 (Microsoft Learn)
SPN重複で認証が壊れる理由
SPN はおおむね serviceclass/host:port/servicename 形式で表されます。クライアントは接続先の名前からSPNを組み立てて KDC にチケットを要求するため、FQDN・短縮名・CNAME・ホストヘッダーが変われば、要求される SPN も変わります。サービスが複数の名前でアクセスされるなら、その名前ごとに適切なSPN整理が必要です。 (Microsoft Learn)
SPNまわりで出やすい代表的なエラーは次の3つです。
KDC_ERR_S_PRINCIPAL_UNKNOWN
SPN が見つからない、間違っている、またはクライアントが誤った名前やDNS情報から別のSPNを組み立てているときに出やすいエラーです。 (Microsoft Learn)KDC_ERR_PRINCIPAL_NOT_UNIQUE
同じ SPN が複数アカウントに付いていて、KDC が所有者を一意に決められない状態です。 (Microsoft Learn)KRB_AP_ERR_MODIFIED
SPN は存在するものの誤ったアカウントに付いているため、サーバー側がチケットを復号できないときの代表例です。 (Microsoft Learn)
厄介なのは、アクセス方法によっては Kerberos が失敗しても NTLM にフォールバックして「つながるときもある」ことです。その場合でも、Kerberos を前提にしたSSOや委任は崩れやすく、症状が断続的に見える原因になります。 (Microsoft Learn)
SPN重複が起きやすい条件
サービス実行アカウントを変更した
IIS、SQL Server、レポートサーバー、独自サービスをコンピューターアカウントからドメインユーザーや gMSA に切り替えたのに、旧アカウントの SPN を残したまま新アカウントにも付けると、典型的な SPN重複または誤登録になります。Microsoft は、サービスのサインイン アカウントが変わったら SPN を新しいアカウントへ再登録する必要があると明記しています。 (Microsoft Learn)
コンピューター名、DNS名、名前空間を変えた
コンピューター名が変わると、そのサービスに紐づく SPN も見直しが必要です。さらに、DNS サフィックスや名前空間の変更では、手動設定した SPN が新しい DNS 名と合わなくなり、認証失敗の原因になります。サーバー更改やドメイン移行の直後に起きやすいのはこのパターンです。 (Microsoft Learn)
DNSエイリアスや別名でアクセスしている
CNAME や別名でアクセスする運用では、その名前に対応する SPN を意識して管理しないと、Kerberos チケット要求が失敗しやすくなります。Microsoft の資料でも、CNAME では別名用の SPN 登録が必要なケースが示されています。また、クライアントやブラウザーは CNAME 解決後の正規名ベースで SPN を作ることがあり、入力した名前と実際に要求される SPN がずれることがあります。 (Microsoft Learn)
コンピューターアカウント運用からカスタムサービスアカウントへ移した
カスタムサービスアカウントは、サービスごとに明示的な SPN が必要です。一方で、コンピューターアカウントで動く一般的なサービスクラスの一部は HOST SPN に自動マップされます。つまり「今までは明示登録なしで動いていた」のに、カスタムアカウントへ変更した途端に壊れるのは自然です。さらに、カスタムアカウントとコンピューターアカウントの両方に同系統の SPN がぶら下がると、切り分けが一気に難しくなります。 (Microsoft Learn)
setspn -A や古い手順で手動追加している
SPN の追加は -A ではなく -S が推奨です。-S は重複確認を行ってから追加します。さらに Microsoft は、少なくとも Windows Server 2012 R2 の DC では重複 SPN 作成をブロックする仕組みを説明していますが、混在環境では下位DCが書き込みを処理して重複が入り込む余地があるとも説明しています。古い運用手順のまま放置していると、ここで事故が起きます。 (Microsoft Learn)
権限不足のまま自動登録や手動修正をしている
Domain Admins / Enterprise Admins でなくても、servicePrincipalName への適切な権限や Validated write to service principal name を委任すれば SPN を更新できます。逆に、この権限が足りないと手動修正に失敗したり、アプリが起動時に自動登録を試みても登録できなかったりします。特にサービスアカウント移行時は、権限不足で「旧SPNは残るのに新SPNは付かない」という半端な状態になりがちです。 (Microsoft Learn)
まず確認する順序
クライアントが何という名前で接続しているかを固定する
最初に固めるべきなのは、ユーザーやアプリが実際に何という名前で接続して失敗しているかです。URL、UNC パス、接続文字列のサーバー名、DB エイリアス、ブラウザーで入力したホスト名をそのまま拾ってください。DNS はクライアントが SPN を作るときの一般的な情報源なので、ここが曖昧だと setspn をいくら見ても噛み合いません。必要なら klist purge の後に klist get <SPN> を使い、今の名前で本当にその SPN が要求されるかを確認します。 (Microsoft Learn)
サービスが実際にどのアカウントで動いているかを確認する
SPN は「実際にそのサービスがサインインに使っているアカウント」に載っていなければ意味がありません。IIS のアプリプール、Windows サービスのログオンアカウント、SQL のサービスアカウントなど、実行主体を先に確定してください。ここを見ずに AD の属性だけ触ると、誤登録を増やしがちです。 (Microsoft Learn)
setspn と klist で所有者・重複・要求SPNを洗う
現場で最初に使うコマンドは次の4つで十分です。
setspn -L <AccountName>
そのアカウントに現在付いている SPN を一覧表示します。マルチドメインならDomain\Name形式で指定した方が安全です。 (Microsoft Learn)setspn -Q <SPN>
その SPN を今どのアカウントが持っているか確認します。まず最初に打つべきコマンドです。 (Microsoft Learn)setspn -X
重複 SPN を検索します。必要に応じて-Fや-Tで検索範囲を広げられますが、範囲を広げるほど時間とメモリを使います。 (Microsoft Learn)klist purge→klist get <SPN>
キャッシュ済みチケットをいったん捨て、今の名前で新しくチケットを取り直します。「修正したのに古い挙動が残る」を減らすのに有効です。 (Microsoft Learn)
たとえば Web サービスなら、HTTP/intranet.contoso.local のような実際のアクセス名を使って setspn -Q し、所有者が意図したアカウントかどうかを見るのが基本です。SQL なら MSSQLSvc/<FQDN>:<port>、SMB なら cifs/<host> のように、サービスクラスとアクセス名の組み合わせをそのまま疑います。 (Microsoft Learn)
イベントログで裏を取る
見るべきログは、クライアント、対象サーバー、ドメインコントローラーの System と Security です。ソースは Kerberos、Key Distribution Center、LSA、Netlogon を優先します。特に Event ID 4 と KRB_AP_ERR_MODIFIED は「SPN はあるが登録先が違う」方向の強いヒントになります。詳細が足りなければ Kerberos の詳細ログを一時的に有効化する方法もありますが、常時有効化は推奨されません。 (Microsoft Learn)
復旧手順
復旧は「怪しいものを全部消す」ではなく、「不要なSPNだけを消して、正しいアカウントにだけ残す」が基本です。順番を崩さない方が安全です。 (Microsoft Learn)
- 失敗時に使われた名前から、本来の SPN を決めます。まずは URL、UNC、接続先ホスト名をそのまま使ってください。 (Microsoft Learn)
setspn -Q <SPN>で現在の所有者を確認し、必要ならsetspn -Xで周辺の重複も確認します。検索範囲が広い場合は-Fや-Tも検討します。 (Microsoft Learn)- 誤ったアカウントから
setspn -D <SPN> <WrongAccount>で削除します。 (Microsoft Learn) - 正しいアカウントへ
setspn -S <SPN> <CorrectAccount>で追加します。追加は-Aではなく-Sを使います。 (Microsoft Learn) - クライアントとサーバーで
ipconfig /flushdns、nbtstat -RR、klist purge、必要ならklist -li 0x3e7 purgeを実行し、名前解決とチケットの古い状態を落としてから再試験します。 (Microsoft Learn) - 最後に
setspn -Q <SPN>またはsetspn -Xを再実行し、同じ SPN が 1 つの正しいアカウントにだけ残っていることを確認します。 (Microsoft Learn)
たとえば旧 WEB01$ に HTTP/intranet.contoso.local が残っていて、新しい実行アカウントが CONTOSO\svc-web なら、setspn -D HTTP/intranet.contoso.local WEB01$ の後に setspn -S HTTP/intranet.contoso.local CONTOSO\svc-web の順で直します。順番を逆にして先に追加すると、重複を自分で作ることになります。 (Microsoft Learn)
なお、コンピューターアカウントで動く一般的なサービスクラスは HOST SPN で足りる場合があります。明示的な SPN を追加する前に、「その SPN は本当に必要か」を一度確認してください。特に http、cifs などはこの見落としが起きやすいポイントです。 (Microsoft Learn)
更新や権限の影響を見落とさない
サービスアカウント変更
サービスアカウントを変えたら、SPN の所有者も変わります。ここを変更手順書に入れていないと、旧アカウントに SPN が残り、新アカウントに追加した瞬間に重複化します。アカウント変更時は「旧SPN削除」と「新SPN登録」をセットで扱うべきです。 (Microsoft Learn)
コンピューター名、DNS名、CNAME、namespace変更
SPN問題は AD の属性だけの問題に見えますが、実際には「接続名の設計」の問題でもあります。名前空間変更で手動SPNがDNS名と合わなくなることがありますし、CNAME では入力名と正規名のどちらが SPN に使われるかがクライアント側の挙動に影響します。更改や統合直後に断続障害が出るなら、このズレを先に疑う方が効率的です。 (Microsoft Learn)
権限不足
SPN 修正をいつも Domain Admin でやる必要はありませんが、適切な権限は必要です。Microsoft は、非管理者に対して Validated write to service principal name や servicePrincipalName の読み書きを委任する手順を案内しています。運用チームに必要最小限の権限だけを与えておくと、障害時の初動がかなり速くなります。 (Microsoft Learn)
フォレストや信頼関係の見落とし
単一ドメインだけ見て「重複なし」と判断するのは危険です。Microsoft の資料では、フォレスト内の一意性が重要であり、複数ターゲットやフォレスト間の重複が認証問題を引き起こす場合があることも説明されています。現在ドメインだけでなく、必要に応じてフォレストや信頼先まで見に行ってください。 (Microsoft Learn)
やってはいけない対処
setspn -Aでとりあえず追加する。重複チェック付きの-Sを使うのが基本です。 (Microsoft Learn)HOST/系やコンピューター既定 SPN を意味もなく削る。多くの組み込みサービスクラスが HOST SPN にマップされるため、闇雲な削除は別の障害を作ります。 (Microsoft Learn)setspn -Rを万能復旧のように使う。-Rはコンピューターのホスト名に対する既定 SPN 登録をリセットするコマンドで、ユーザーやサービスアカウントの誤登録を直す代用にはなりません。 (Microsoft Learn)- IP アドレスや一時的な別名で試して「直った」と判断する。SPN が見つからず NTLM に落ちただけ、というケースを見逃します。 (Microsoft Learn)
- Kerberos の詳細ログを有効にしたまま放置する。Microsoft も、詳細ログはトラブルシューティング時だけ使い、不要になったら無効化するよう案内しています。 (Microsoft Learn)
再発防止と次にやること
SPN重複の再発防止で効くのは、技術よりも運用の揃え方です。変更作業に次の4点を入れておくと、かなり事故が減ります。
- サービス更改票に「利用するアクセス名」「実行アカウント」「登録すべきSPN」「削除すべき旧SPN」を明記する。SPN はアクセス名と実行アカウントが揃って初めて意味を持ちます。 (Microsoft Learn)
- 別名運用をするなら、正式な接続名を決める。CNAME やホストヘッダーを増やすほど、要求SPNの揺れが増えます。 (Microsoft Learn)
- 追加は常に
setspn -Sを使い、定期的にsetspn -Xで重複を棚卸しする。 (Microsoft Learn) - 少なくとも Windows Server 2012 R2 系以降の DC では、重複追加のブロックや Event ID 2974 がヒントになります。混在環境では「DC が防いでくれるはず」と過信せず、ログも見る運用にしておくと安全です。 (Microsoft Learn)
SPN重複の対処は、単に重複を消す作業ではありません。正しい接続名、正しい実行アカウント、正しいSPN所有者を一致させる作業です。今すぐやるなら、まず障害が起きているアクセス名をメモし、その SPN を setspn -Q で引き、誤登録があれば -D と -S で整理し、最後に klist purge で再試験してください。この順番で見れば、多くの「SPN重複で認証が壊れる」障害は最短で切り分けできます。 (Microsoft Learn)
コメント