SPNとActive Directoryおよびセキュリティにおける役割
Sep 4, 2026
Service Principal Names (SPN) は、Kerberos 認証のためにサービスインスタンスをサービスアカウントにマッピングする Active Directory の一意の識別子です。管理されたサービスアカウントではなくユーザーアカウントに登録された SPN は、攻撃者がアカウントのパスワードをオフラインで解読する Kerberoasting への直接的な経路を作成します。Event ID 4769 で検出し、Group Managed Service Accounts、強力なパスワード、および AES のみの Kerberos 暗号化で対処してください。
サービス プリンシパル ネーム（Service Principal Names、SPNs）は Active Directory 上の一意の識別子であり、Kerberos 認証のためにサービス インスタンスをサービス アカウントへ対応付ける用途に使われます。この記事では、SPN の構造、登録方法、一意性の要件、ツール（例：setspn）、およびセキュリティ上の影響を説明します。Kerberoasting のような攻撃、ベスト プラクティス、検出方法、ハイブリッド環境・クラウド環境・コンテナ環境における高度なユースケースも扱います。
サービス プリンシパル ネーム（Service Principal Names、SPNs）の紹介
SPN（Service Principal Name）とは何でしょうか？Active Directory をある程度経験している Windows 管理者であっても、Service Principal Names がドメイン環境で果たす役割を知らないことがあります。セキュリティ プリンシパル名（security principal name、SPN）とは、特定のサービス インスタンスを、そのサービスを実行しているアカウントに関連付ける一意の識別子です。これにより、クライアントは Active Directory（AD）内の正しいサービスに対して認証し、接続できるようになります。これは、同一サービスの複数のインスタンスが異なるサーバー上で動作する可能性がある大規模なエンタープライズ環境で、特に重要です。この記事では、Active Directory の SPN とは何か、そのセキュリティへの貢献、そして今日のモダンなネットワークにおいてその利用がどのように拡大し続けているのかを説明します。
Kerberos 認証における SPN の役割
飛行機に乗る、映画館に入るにはチケットが必要であるのと同様に、Active Directory（AD）内のリソースにアクセスするためにもチケットが必要です。クライアントが AD 上でホストされているサービスへのアクセスを要求すると、プロセスは次のように進みます：
- クライアントがそのサービスを利用しようとすると、そのサービスの SPN を作成します
- クライアントは、その SPN を使ってチケットをドメイン コントローラーに要求します
- ドメイン コントローラーが、その SPN を Active Directory で検索します
- 見つかると、ドメイン コントローラーがサービス チケットを発行します
- クライアントはこのチケットを使って、パスワードなしでサービスに認証します
基本を分解して理解する
SPN の構成要素
SPN は複数のコンポーネントで構成されており、それらを組み合わせることで特定のサービスに対する完全な識別情報を提供します:
- サービス クラス：これはサービス インスタンスの名前です。たとえば、Microsoft SQL Server では “MSSQLSvc”、Web サービスでは “www” などです。
- ホスト名：サービスが実行されているサーバーまたはホストを指定します。Windows マシンの NetBIOS 名（例: “FilerServer”）である場合もあれば、“fileserver.company.com” のような完全修飾ドメイン名である場合もあります。
- アカウント：サービスに関連付けられた Active Directory アカウント。これは SPN 文字列自体の一部ではなく、サービス プリンシパル名が登録されるアカウントです。
- ポート （任意）：サービスが標準以外のポートで動作している場合は、SPN にそのポートを指定できます。
Active Directory でよく使われる一般的な SPN の例
- Web サービス – HTTP/webserver.netwrix.com
- SQL Server – MSSQLSvc/myhost.redmond.microsoft.com:1433
- ファイル共有 – CIFS/fileserver.contoso.com
- リモート デスクトップ サービス – TERMSRV/rdserver.abcdomain.com
- LDAP 認証 – LDAP/domaincontroller.fabricam.com
SPN と Active Directory：そのつながり
SPN が Active Directory オブジェクトと連携する仕組み
SPN は、ユーザー アカウント、サービス アカウント、コンピューター オブジェクトなどの AD オブジェクトに関連付けられた属性です。SPN は、どのアカウントの下でどのサービスが実行されるかを示すラベルとして機能します。この仕組みにより、コンピューターはネットワーク上にパスワードを送信せずに、Kerberos を使って安全に認証を行えます。サービスをインストールまたは構成すると、そのサービスは Kerberos が認証要求を正しいアカウントに対応付けられるよう、SPN を登録します。SPN が適切に構成されていない場合、Kerberos の認証は失敗し、認証エラーやサービスの中断につながる可能性があります。
servicePrincipalName 属性における SPN の格納
SPNは、オブジェクトの servicePrincipalName 属性の一部として Active Directory に保存されます。この属性は、コンピューター アカウントとサービス アカウントの両方に存在します。以下のスクリーンショットに示すように、Active Directory Users and Computers を使用してオブジェクトの詳細プロパティからこの属性を確認できます。
この属性には、そのオブジェクトに割り当てられた SPN の一覧が格納されています。各 SPN エントリは、サービス種別、ホスト、および（任意の）ポート番号を含む構造化された形式に従います。
次のコマンドを使用すると、AD オブジェクトの SPN を確認できます：setspn –L hostname。以下の例では、このコマンドを使って ABCDomain.com というドメインに対し、ドメイン コントローラーが生成した SPN の一覧を表示しています。
AD フォレストにおける SPN の一意性の重要性
各サービス プリンシパル名（service principal name）は、Active Directory フォレスト全体にわたって一意である必要があります。この一意性により、Kerberos がサービス要求を適切なアカウントに正しくルーティングできるようになります。異なるアカウントに同じ SPN が重複していると認証の競合が発生し、予測できない動作や、場合によっては認証の完全な失敗につながります。
SPN の設定：ステップバイステップガイド
SPN 設定に必要なツール
SPN の設定における主なツールは、Windows Server オペレーティング システムに組み込まれている setspn.exe です。このコマンドライン ツールにより、管理者は Active Directory のサービス アカウントに対するサービス プリンシパル名を読み取り、変更し、削除できます。
以前の例では、setspn -L を使ってコンピューター オブジェクトの SPN を表示しました。SPN を追加するには、setspn -S も使用できます。たとえば、webserver1 というコンピューターに HTTP SPN を追加するには、次のコマンドを実行します:
setspn -S HTTP/webserver1.abcdomain.com abcdomain\serviceaccount
setspn -S コマンドは、新しい SPN を作成する前に、既存の同一 SPN があるかどうかを自動的に確認して、重複したエントリを防ぎます。
SPN を削除するには、setspn -D コマンドを使用します。SPN については、PowerShell でも複数の方法で対応できます。たとえば、次の PowerShell cmdlet は Active Directory に登録されているすべての SPN を見つけます：
Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName | Select-Object Name, servicePrincipalName
これは重複しているすべての SPN を検出します。
$SPNs = Get-ADObject -Filter {servicePrincipalName -like “*”} -Property servicePrincipalName |
Select-Object -ExpandProperty servicePrincipalName
SPN 登録のベストプラクティス
- SPN 登録のためのサービス アカウントには、必要最小限の権限だけを付与する
- 新しい SPN を登録する前に、PowerShell で重複を確認する：
- SPN を定期的に監査し、不必要または古くなったエントリを特定して削除する
- SPN を追加するときは、標準化された SPN 命名形式を使用します
一般的な SPN 問題のトラブルシューティング
重複した SPN は認証の失敗を引き起こす可能性があるため、必ず解決する必要があります。SPN の競合を示している場合があるため、ユーザーから断続的なアクセスの問題が報告されていないか注意してください。下のスクリーンショットに示すように、setspn -x コマンドを使用すると、単一ドメイン内の重複を見つけられます。
setspn -F コマンドを使用して、フォレスト全体を検索します。重複した SPN を解決するには：
- 重複した SPN を保持しているアカウントを特定します。
- どのアカウントが正当に SPN を保持すべきかを判断します。
- setspn -D <SPN> <AccountName> を使用して、誤ったアカウントから SPN を削除します8。
- setspn -S <SPN> <AccountName> を使用して、正しいアカウントに SPN を追加します
重複に加えて、その他のよくある SPN の誤設定には次のようなものがあります。
- サービス用の SPN が欠落している
- 誤ったアカウントに登録された SPN
- サーバー名変更後に残る古い SPN
（すでに取り上げた同じツールを、ここであらためて再掲する必要はありません）
高度な SPN の概念
複数サービスおよび複数ホスト環境における SPN の役割
サービスアカウントは、Windows Server 上で動作するサービスのために作成された専用のユーザーアカウントです。これにより、Internet Information Services (IIS) のような重要なアプリケーションにおいて、ドメイン アカウントを分離して保護するのに役立ちます。複雑な環境では、複数のサービスが同じマシン上で動作することがよくあり、それぞれが適切な認証のために異なる Service Principal Names (SPNs) を必要とします。
よくある例として、Web アプリケーションをホスティングするサーバーでは SQL Server と IIS の両方が動作することがあります。各サービスには、正しい Kerberos 認証を行うためにそれぞれ固有の SPN が必要です。:
- IIS の場合: HTTP/servername.domain.com
- SQL Server の場合: MSSQLSvc/servername.domain.com:1433
マルチホスト環境では、サービスがロードバランシングやフェイルオーバーのために複数のサーバーにまたがって稼働するため、SPN の設定はより複雑になります。たとえば、共有 DNS 名のもとで複数のサーバー（Web01、Web02、Web03）にまたがって Web アプリケーションがホスティングされているケースを考えてください。このシナリオでは、すべてのホスト間でシームレスな認証を可能にするために、SPN は 1 台のサービス アカウントに登録する必要があります。:
特殊なケース：HOST SPN とその固有の動作
HOST SPN は、Active Directory のコンピューター オブジェクトに自動的に登録される SPN の特別な種類です。これらは、マシンのローカル システムまたはネットワーク サービス アカウントの下で実行されるサービスに対するキャッチオール識別子として機能します。これにより、多くの標準的な Windows サービスの管理が簡単になり、手動での SPN 設定の必要性が減ります。
次の図で、HOST SPN と Custom SPN の使い分けの目安をまとめます：
ヒント：HOST SPN は AD によって管理されるため、手動で変更してはいけません。
SPN とセキュリティ上の影響
AD 環境において SPN を保護することが重要な理由
SPN に対するセキュリティが重要である理由は単純です。サービスアカウントは、多くの場合、昇格した権限を持ちます。さらに、ネットワーク内の重要なシステムに継続的にアクセスでき、作成された後は忘れられがちです。これらすべてにより、攻撃者にとって高価値の標的になります。SPN を侵害すると、重要なサービスへの不正アクセスにつながり、攻撃者がネットワーク内で横方向に移動して、権限を昇格できる可能性があります
脆弱な SPN はどのように悪用されるか
SPN が弱い設定になっている場合、Kerberoasting のような攻撃によって悪用される可能性があります。攻撃者がこのような攻撃を実行する手順は次のとおりです:
- ドメイン権限が最小の攻撃者でも、任意の SPN に対してサービスチケットを要求できます。Requests service tickets for these SPNs
- サービスアカウントのパスワードハッシュで暗号化されたサービスチケットは抽出でき、オフラインで解読（クラック）するために持ち出すことが可能です。
- これらに対してオフラインでパスワードのクラックを行います。パスワードが弱い場合、攻撃者はそれをクラックしてサービスアカウントにアクセスできる可能性があり、多くの場合、権限が昇格された状態になります。
攻撃者がサービスアカウントのパスワードをクラックし、そのアカウントが高い権限を持っている場合、ネットワーク内で横方向に移動したり、アクセス権限をエスカレーションしたりできます。
SPN とサービスアカウントを保護するためのベストプラクティス
SPN に関連するセキュリティリスクを軽減するためのベストプラクティスの一覧は以下のとおりです：
- SPN を持つアカウントには長く複雑なパスワードを使用し、定期的にローテーション（変更）してください
- Domain Admins などの高権限アカウントに SPN を割り当てないようにしてください
- サービスアカウントには、その機能を実行するために必要な権限のみに制限してください
- サービスアカウントの対話型ログオンを無効にしてください
- PowerShell で SPN 関連コマンドが想定外に使用されていないか監視してください。
- ドメイン認証を持つすべてのユーザーは SPN を検索できるため、Active Directory の権限を変更して、これらのクエリを実行できる対象を制限する必要があります。
SPN の悪用を検知し、軽減する
SPN 関連の活動を監視し、監査する
AD 環境を継続的に監視し、Kerberos 関連イベントを監査することは、SPN の悪用を防ぐうえで非常に有効である可能性があります。検知すべきものには、次のようなものがあります。
- 攻撃者がLDAPツールを使用してADに対してSPNを照会する可能性があるため、異常なSPN列挙リクエスト。
- サービスチケット要求が急に急増すると攻撃が進行中であることを示す可能性があるため、頻繁なKerberosチケット要求。
- 通常の指定された場所ではなく、想定外の場所からのサービスアカウントのログイン。
- 認証の失敗が繰り返される場合、password spraying やブルートフォースの試行が示唆されるため、認証失敗の試行。
SPNベースの攻撃に対する緩和策の実装
組織が Windows Active Directory 環境で運用している場合は、SPN の悪用や Kerberoasting 攻撃のリスクを最小限に抑えるために、次の予防的なセキュリティ対策を検討してください。
- サービス アカウントには長く複雑なパスワードを使用してください（絶対最低 14 文字）
- 異なるアカウント間でパスワードを使い回さず、パスワードを定期的にローテーションしてください
- 最小権限の原則 を適用して、アカウント権限を制限してください。
- 攻撃の猶予期間を最小化するために、Kerberos チケットの有効期間を短く強制してください
- 定期的にSPNを見直し、古くなった、または不要なSPNを削除します
- 強力なサービスアカウント管理、洗練された監視、定期的なトレーニングプログラムを組み合わせた多層防御戦略を採用してください。
グループ管理サービスアカウントと強力な暗号化方式の使用
自動化されたパスワード管理の利点を得るために、グループ管理サービスアカウント（Group Managed Service Accounts, gMSAs）を導入します。グループ管理サービスアカウント（Group Managed Service Accounts, gMSAs）は、従来のサービスアカウントと比べて強化されたセキュリティ機能を提供する、Active Directory の専用サービスアカウントです。これらは、SQL Server、IIS Web アプリケーション、スケジュールされたタスクなどのサービスを実行するドメイン参加サーバー、または特定の権限を持つセキュリティコンテキストで実行する必要があるその他のサービスに特に有効です。gMSAs を利用すると、手動でのパスワード割り当てが不要になり、資格情報の窃取リスクを低減できます。暗号化に関しては、Active Directory でより弱い DES と RC4 の暗号化タイプを無効化しつつ、強力な AES128/AES256 Kerberos 暗号化を適用してください。
実践的な適用例とユースケース
先述のとおり、SPN は Web アプリケーションやデータベースの Kerberos 認証に使用されます。IIS は「HTTP/ServerName」という形式の SPN を使用し、アプリケーション プールを実行するドメイン アカウントにマッピングされます。一方、「MSSQLSvc/host.domain.com:1433」は SQL サービス アカウントの例です。ただし、企業がますますハイブリッド ネットワーク アーキテクチャを採用するようになったことで、Service Principal Names (SPNs) の役割は従来の用途を超えて進化しています。現在では、SPN によりオンプレミスのリソースとクラウド ネイティブ アプリケーション間の安全な認証が可能になるケースも見られます。その他の例には次のようなものがあります:
- SPN は、コンテナ化された環境内に配置されたコンテナ化アプリケーションおよびサービスに対するアイデンティティとアクセスを管理するために使用されています。
- エッジ環境では、エッジ デバイスと集中管理されたクラウド リソース間の安全な通信を促進するために SPN が使用されます。
- Azure AD Connect は、オンプレミスの AD と Azure AD の間で同期サービスを行うために SPN を使用します。
今日では、企業環境内での SPN の利用も増えています。たとえば、セキュリティ チームは SPN の使用ログを監視して、不正なアクセス試行や Kerberos の失敗を検出しています。その他の例には次のようなものがあります:
- シングル サインオン（Single Sign-On、SSO）：SPN により、複数のアプリケーションやサービスにわたって Kerberos ベースの SSO を実現できます。
- アプリケーション統合：SPN は、異なるエンタープライズ アプリケーションやサービス間の安全な通信を促進します。
- 委任認証：SPN により、複数層のアプリケーションにおいてサービスがユーザーの代わりに認証を行えます。
結論
サービス プリンシパル名（Service Principal Names、SPN）は、Active Directory の登場以来ずっと Kerberos 認証の基盤を担ってきました。ネットワーク ユーザーが依存する多くの代表的なサービスにおいて、SPN は定番として利用されており、多数のバックグラウンド サービスにわたって安全かつシームレスな運用を実現するうえで重要な役割を果たします。組織が継続的に拡大・進化するにつれて、SPN の用途はクラウド統合や IoT といった分野にも広がっています。今日の企業ではセキュリティへの重要性が高まっているため、SPN は新しい技術や、拡大し続けるデジタル環境におけるセキュリティ課題に適応しながら、より大きな役割を担う可能性が高いでしょう。
SPNとは何ですか？
Service Principal Name（SPN）は、特定のサービスインスタンスを実行しているActive Directoryアカウントにリンクする一意の識別子です。SPNはActive Directoryフォレスト全体で一意でなければなりません。
2つのアカウントが同じSPNを持っている場合、ドメインコントローラーはどちらにチケットを発行すべきか判断できず、認証に失敗します。SPNを持つアカウントがない場合、リクエストは完全に失敗し、クライアントは通常、独自のリスクを伴うNTLMにフォールバックします。
個人ユーザーアカウントに登録されたSPNは、管理対象サービスアカウントではないため、その攻撃が可能になります。防御策はサービスアカウントの衛生管理です。Group Managed Service Accountsを使用してください。SPNを保持しているアカウントには、長くランダムに生成されたパスワードを適用してください。攻撃を示すチケット要求の急増を検出するために、イベントID 4769を監視してください。
Kerberos認証におけるSPNの役割
これらはKerberoastingの攻撃対象面でもあります。ドメイン認証済みのユーザーは誰でもSPNを持つアカウントのKerberosサービスチケットを要求し、オフラインで解析してアカウントのパスワードを取得できますが、ロックアウト閾値は発動しません。
- クライアントはアクセスしたいサービスのSPNを構築します。
SQL Server、IIS、Exchange、およびカスタムアプリケーションを実行するActive Directory 環境では、各サービスがユーザーに毎回資格情報を求めたり、設定ファイルにパスワードを埋め込んだりせずに認証できる必要があります。Service Principal Names がそれを可能にします。
クライアントがサービスへのアクセスを要求すると、Kerberos認証フローは定義された順序に従います。
SPNはコンピューターオブジェクトとサービスアカウントに、servicePrincipalNameという複数値属性として存在します。この属性の各エントリは登録されたサービスを表します。複数のサービスを実行するアカウント、または複数のホスト名からアクセス可能なサービスは複数のSPNエントリを持ちます。
- クライアントは、そのSPNを使用してドメインコントローラーにサービスチケットを要求します。
- クライアントは認証のためにサービスにチケットを提示し、パスワードはネットワーク上で送信されません。
- ドメインコントローラーがActive DirectoryでSPNを検索します。
- 見つかると、ドメインコントローラーはサービスアカウントの資格情報で暗号化されたサービスチケットを発行します。
SPNの構造とコンポーネント
このシーケンスは、SPNの正確さが重要な理由を示しています。SPNが欠落、重複、または誤って構成されていると、ステップ3の検索が失敗し、認証が失敗するかNTLMにフォールバックします。
SPNの構成要素
SPNは単一の値ではなく、複数のコンポーネントで構成された構造化された文字列です。その構造を理解することは、正しい登録、トラブルシューティング、およびセキュリティレビューに不可欠です。
各SPNは、サービス、実行されているホスト、およびオプションで使用するポートを識別する定義済みの形式に従います。構成要素は次のとおりです：
Active Directory の一般的な SPN 形式
- アカウント: サービスに関連付けられたActive Directoryアカウントです。これはSPN文字列自体の一部ではなく、SPNが登録されているオブジェクトです。
- ポート（任意）： サービスが標準以外のポートで実行されている場合に含まれます（例：
MSSQLSvc/host.domain.com:1433）。 - サービスクラス: サービスの種類の名前、例えば
MSSQLSvcは Microsoft SQL Server 用、またはHTTPはウェブサービス用です。 - ホスト名: サービスが実行されているサーバーまたはホストで、NetBIOS名（例：
FileServer）または完全修飾ドメイン名（例：fileserver.company.com）として表されます。
フォーマット ServiceClass/Hostname: Port はサービスの種類にわたって予測可能で認識しやすい文字列を生成します。一般的な例は以下の通りです：
- ウェブサービス:
HTTP/webserver.netwrix.com - SQL Server:
MSSQLSvc/myhost.redmond.microsoft.com:1433 - ファイル共有:
CIFS/fileserver.contoso.com - リモートデスクトップサービス:
TERMSRV/rdserver.abcdomain.com
Active DirectoryがSPNを保存および解決する方法
Netwrix Threat ManagerはオンプレミスのActive DirectoryとEntra ID全体で資格情報の盗難、横移動、権限昇格をマッピングします。デモをお試しください。
- LDAP認証:
LDAP/domaincontroller.fabrikam.com
servicePrincipalName 属性
SPNは、ユーザーアカウント、サービスアカウント、またはコンピューターオブジェクトなどのADオブジェクトに関連付けられた属性です。これらは、どのサービスがどのアカウントで実行されているかを示すラベルとして機能します。この接続により、コンピューターはパスワードをネットワーク上で送信することなく、Kerberosを使用して安全に認証できます。
サービスをインストールまたは構成すると、Kerberosが認証要求を正しいアカウントにマッピングできるようにSPNが登録されます。適切に構成されたSPNがない場合、Kerberos認証は失敗し、認証エラーやサービスの中断が発生する可能性があります。
クライアントがサービスへのアクセスを要求すると、そのサービスのSPNを作成し、ドメインコントローラーに送信します。DCはディレクトリでそのSPNを検索し、見つかればKerberosサービスチケットを発行します。パスワードはネットワーク上で送信されません。
SPNの一意性が正しいサービス解決を可能にする方法
setspn –L hostname コマンドを使用して、AD オブジェクトの SPN を表示できます。以下の例では、ドメインコントローラーが ABCDomain.com というドメインのために生成した SPN のリストを表示するためにこのコマンドが使用されました。
SPNは、オブジェクトのservicePrincipalName属性の一部としてActive Directoryに保存されます。この属性はコンピューターアカウントおよびサービスアカウントに存在し、そのオブジェクトに登録されているすべてのSPNのリストを含みます。オブジェクトのプロパティのタブから確認できます。Active Directory Users and Computersのスクリーンショットは以下の通りです。
HOST SPNs と AD が自動的に管理する場合
以下の表は、HOST SPNs とカスタム SPNs を使用するタイミングをまとめたものです。
HOST SPNは、Active Directoryによってコンピューターオブジェクトに自動的に登録される特別なSPNのカテゴリです。これは、マシン上でLocal SystemまたはNetwork Serviceアカウントの下で実行されているサービスの普遍的な識別子として機能し、多くの標準的なWindowsサービスを手動のSPNエントリなしでカバーします。
認証問題をトラブルシューティングする際、重複したSPNは最初に確認すべき項目の一つです。setspn -X を使用してドメイン内の重複を検出し、setspn -F を使ってフォレスト全体を検索します。
各SPNはActive Directoryフォレスト全体で一意でなければなりません。この一意性により、Kerberos authenticationがサービス要求を正しいアカウントにルーティングできます。同じSPNを持つアカウントが2つあると、ドメインコントローラーはどちらを使用するか判断できず、認証失敗、断続的なログインエラー、サービス接続の障害が発生します。
HOST SPNを手動で変更しないでください。Active Directoryが自動的に管理しており、変更すると主要なサービスに支障をきたす可能性があります。
SPNの設定と管理方法
ステップ1：サービスとターゲットアカウントを特定する
ステップ2：既存または重複するSPNを確認する
正しいSPNの構成は、Kerberos認証が機能するための前提条件です。このプロセスはサービスの種類に関係なく一貫した順序で進み、手順を飛ばすことがSPN関連の問題の最も一般的な原因です。
登録する前に、SPNが他のアカウントに既に存在しないことを確認してください。ディレクトリを照会するには、次のコマンドを使用します：
重複したSPNを登録すると認証エラーが発生し、その後の診断が困難になることがあります。
ステップ3：setspnでSPNを登録する
SPNを登録する前に、2つのことを特定してください：必要なサービスクラスとフォーマット、およびサービスを実行するActive Directoryアカウントです。標準サービス（SQL Server、IIS、Exchange）の場合、サービスクラスはよく文書化されています。アカウントについては、専用のActive Directory service account または可能であれば、共有または個人アカウントではなくGroup Managed Service Account（gMSA）を推奨します。
標準でないポートで実行されているSQL Serverの場合：
SPNを登録するには setspn -S（安全に追加）を使用します。-Sフラグはエントリを作成する前に重複を自動的にチェックし、古い-Aフラグよりも安全です：
ステップ4：登録を確認する
PowerShellのSet-ADUserまたはSet-ADComputerコマンドレットを使用してSPNを登録することもでき、スクリプトによる展開や一括登録に便利です。
PowerShellを使って確認することもできます：
登録後、SPNが正しいアカウントに表示されていることを確認してください:
出力には、新しく登録されたSPNと、そのアカウントにすでに割り当てられている他のSPNが一覧表示される必要があります。
ステップ5：Kerberos認証をテストする
一般的なSPNの誤設定の修正
ほとんどのSPNの問題は少数のカテゴリに分類されます。各々に対して的確な修正が必要です：
Windowsイベントビューアでは、Kerberosサービスチケットの要求が成功するとイベントID 4769として表示されます。認証がNTLMにフォールバックする場合、SPNが欠落しているか、形式が不正、または誤ったアカウントに登録されている可能性があります。
SPNが登録されたら、Kerberos認証が成功するかテストします。ドメイン資格情報を使ってサービスに接続し、次に klist を実行して、DCがKerberosサービスチケット（NTLMチケットではない）を発行したことを確認します。
SPN登録のベストプラクティス
- 重複したSPN: 次のコマンドを使用してください
setspn -Dで誤ったアカウントからSPNを削除し、正しいアカウントに残っていることを確認します。サーバー名の変更やアカウントの移行後に重複がよく発生します。 - サーバー名変更後の古いSPN: 以前のホスト名を参照する古いSPNは削除し、現在の名前で新たに登録する必要があります。
- 不足しているSPN: Kerberosが失敗してNTLMにフォールバックする場合は、
setspn -QコマンドでSPNが存在するか確認してください。存在しなければ登録してください。 - 誤ったアカウントに登録されたSPN: 次のコマンドで削除してください
setspn -Dそして正しいサービスアカウントに再登録してください。
SPN管理の一貫した実践を確立することで、運用上の失敗とセキュリティリスクの両方を減らせます:
- 不適切なアカウントに登録されているSPNを特定するために、定期的にPowerShell監査を実行してください。
- SPNは個人ユーザーアカウントやDomain Adminアカウントではなく、専用のサービスアカウントに割り当ててください。
- 重複登録を防ぐために、登録時には
setspn -S（-Aではなく）を使用してください。 - 監査を簡素化するために、環境全体で標準化された命名形式を使用してください。
誤設定されたSPNのセキュリティリスク
Kerberoasting
- アカウントには必要最低限の権限を付与してください。SPN登録には
servicePrincipalName属性への書き込みアクセスが必要であり、広範囲に付与すべきではありません。
SPNに関連付けられたサービスアカウントは、Active Directoryで最も標的にされやすいIDの一つです。標準のユーザーアカウントとは異なり、これらはしばしば高い権限を持ち、重要なシステムへの持続的なアクセスを維持し、作成後はほとんど見直されません。この組み合わせが、誤設定されたSPNに関連するセキュリティリスクを生み出します。
シルバーチケット攻撃
攻撃者はチケットを要求し、抽出してオフラインでパスワードクラッキングを実行できますが、ロックアウトを引き起こしたり、ネットワークに大きなノイズを発生させたりしません。
Kerberoasting は最も一般的なSPNベースの攻撃手法です。ドメイン認証されたユーザーであれば、権限の低いアカウントを含め、ディレクトリ内の任意のSPNに対してKerberosサービスチケットを要求できます。そのチケットはサービスアカウントのパスワードハッシュで暗号化されています。
RC4暗号化により、この攻撃は大幅に高速化されます。RC4で暗号化されたKerberosチケットは、最新のAES保護チケットよりも解析が容易なため、MicrosoftはAD環境でRC4の廃止を積極的に進めています。
サービスアカウントが弱いまたは再利用されたパスワードを使用している場合、攻撃者は平文の資格情報を回復し、しばしば昇格した権限でサービスにアクセスできます。
侵害されたサービスアカウントによる横移動
SPNベースの攻撃から守る方法
高権限SPNによる権限昇格
過剰な権限を持つアカウント、特にDomain Admin権限や重要なシステムへの無制限アクセス権を持つアカウントに登録されたSPNは、最もリスクの高い構成を表しています。これらのアカウントの1つに対するKerberoasting攻撃が成功すると、サービスの侵害にとどまらず、攻撃者にドメインレベルの制御権を与える可能性があります。
KerberoastingおよびSPN列挙の検出
Kerberoastingの自然な続きはsilver ticket攻撃です。攻撃者がサービスアカウントのパスワードハッシュを解読すると、ドメインコントローラーと追加のやり取りをせずに完全にオフラインでKerberosサービスチケットを偽造できます。これらのsilver ticketは対象サービスへの永続的なアクセスを許可し、DCを完全にバイパスするため検出が非常に困難です。
サービスアカウントは通常、複数のシステムへのアクセス権を持っています。攻撃者が1つを侵害すると、横移動が環境全体で可能になります。サービスアカウントは標準の監視および異常検知ルールから除外されることが多いため、この移動は長期間気付かれないことがあります。
AD環境の継続的な監視は最初の防御線です。注目すべき指標には以下が含まれます：
SPNベースの攻撃に対する防御は、早期の悪用検出、発生時の効果的な対応、およびインシデント発生前に攻撃対象範囲を減らすための環境強化の3つの領域で行われます。
- 異常なSPN列挙クエリ。攻撃者は通常、偵察中にドメイン内のすべてのSPNを一覧表示するためにLDAPツールを使用します。
- 予期しないホストや異常な時間帯からのサービスアカウントログイン。
Active Directoryの権限を変更してSPNを照会できるユーザーを制限すると、権限の低い攻撃者が利用できる偵察時間が短縮されます。
SPNの悪用の封じ込めと対応
- イベントID 4769（Kerberosサービスチケット要求）の急増、特にRC4暗号化（暗号化タイプ0x17）を使用するものは、攻撃者がより速い解析のためにRC4チケットを好むため、Kerberoastingを強く示しています。
- 繰り返される認証失敗は、ブルートフォース攻撃や password-spraying 攻撃 による資格情報の漏洩を示している可能性があります。
SPNベースの悪用が検出された場合、優先すべきは攻撃者が侵害された資格情報を使用する能力を制限することです：
- 影響を受けたサービスアカウントのパスワードを、長くランダムに生成された資格情報で直ちにリセットしてください。
- アカウントがその機能に必要以上の権限を持っていないか確認し、権限を減らしてください。
- サービスアカウントがアクセスできるすべてのシステムを確認し、横方向の移動の兆候がないか最近の活動を監査してください。
SPN対応サービスアカウントの強化
プロアクティブな強化により、SPNベースの攻撃を可能にする多くの条件が排除されます：
- サービスアカウントには長くランダムに生成されたパスワード（最低25文字）を使用し、定められたスケジュールで変更してください。
- アカウントに発行された有効なKerberosチケットをすべて取り消すには、アカウントのKerberos暗号化キーをリセットします（silver ticketの緩和にはkrbtgtのリセットは不要です。サービスアカウントのパスワードをリセットすると偽造チケットが無効になります）。
- サービスアカウントの対話型ログインを無効にして、侵害された場合の有用性を制限します。
- 最小権限の原則を適用してください。最小権限の原則。サービスアカウントは、その機能に必要なシステムとデータにのみアクセスすべきです。
gMSAとAES暗号化を使用して常駐リスクを排除する
- 可能な限り Group Managed Service Accounts に移行してください。これによりパスワード管理が自動化され、Kerberoastingが大幅に困難になります。
Group Managed Service Accounts (gMSA) は、手動のパスワード管理の必要性を完全に排除する専門のサービスアカウントです。Active Directory は gMSA のパスワードを自動的に管理し、サービスおよびドメイン管理者が直接見ることも扱うこともない、長くランダムに生成された資格情報を定められたスケジュールでローテーションします。
ハイブリッドおよび最新環境のSPN
デフォルトでは、Windowsは30日ごとにgMSAのパスワードをローテーションし、その間隔はmsDS‑ManagedPasswordInterval属性（またはgMSA作成時のManagedPasswordIntervalInDaysパラメーター）によって制御され、作成時にのみ設定可能です。
gMSAをサポートしないサービスには、AES-128またはAES-256のKerberos暗号化を適用し、Active Directoryでより弱いRC4およびDES暗号化タイプを明示的に無効にしてください。RC4暗号化はKerberoasting攻撃でデフォルトで使用されており、これを削除するとAESの使用が強制され、オフラインクラッキングに対して大幅に耐性が向上します。
- Domain Admin またはその他の高権限グループに所属するアカウントに SPN を割り当てないでください。
SPN と Microsoft Entra Connect
組織がハイブリッドアーキテクチャやコンテナ化されたワークロードを採用するにつれて、SPNの役割は従来のオンプレミスActive Directoryを超えて拡大しています。SPNはKerberos認証が使用される場所で引き続き重要であり、一部の新しいコンテキストでは、元のAD設計にはなかった認証パターンを可能にします。
コンテナ化環境におけるSPN
マルチティアアプリケーションにおける委任認証
Microsoft Entra Connect は、オンプレミスの Active Directory と Entra ID（旧 Azure AD）間の同期サービスに SPN を使用します。同期サービスアカウントは、両方のディレクトリに認証するために正しく構成された SPN を必要とします。誤って構成された、または欠落している SPN は、ディレクトリ同期を静かに停止させ、ハイブリッド環境全体でアイデンティティデータが古くなる原因となります。
Kerberos委任は、サービスがユーザーに代わって下流のリソースに認証することを可能にします。これは、WebフロントエンドがユーザーのIDをバックエンドデータベースに渡す必要があるマルチティアアプリケーションで一般的です。
Windows Server上で実行されるコンテナ化されたワークロードは、gMSAおよび拡張としてSPNをActive Directory securityに使用できます。ドメインに参加しているホスト上のKubernetesおよびDockerの展開は、gMSA資格情報を要求するように構成でき、コンテナ化されたサービスはコンテナイメージに資格情報を埋め込むことなくKerberosを使用してAD統合リソースに認証できます。
SPNはこれにおいて中心的な役割を果たします。委任はSPNを保持するサービスアカウントで設定され、認証チェーンの各段階は正しく登録されたSPNに依存します。
SPNは基盤であり、ますます標的にされています
サービスが任意のユーザーになりすまして任意のリソースにアクセスできる制限なしの委任は、重大な攻撃対象となるため、可能な限り制限付きまたはリソースベースの制限付き委任に置き換えるべきです。
Service Principal Namesは、Active Directoryの開始以来、Kerberos認証の基盤となっています。正しく構成され、定期的に監査され、厳格に管理されている場合にのみ、企業環境全体で安全なパスワード不要のサービス認証を可能にします。
Netwrixは、最優先のSPNセキュリティ課題である進行中の攻撃検出とリスクをもたらすADの変更の可視性維持のために特化したツールを提供します。
Netwrixが支援できる方法
組織がハイブリッドインフラストラクチャ、コンテナ、およびクラウド統合Identityシステムに拡大するにつれて、SPNはより多くの場所に現れ、これまで以上に広範なアクセス権を持つアカウントに結び付けられています。
脅威の計算はそれに応じて変化しました。Kerberoastingは、SPNが広く存在し監視が不十分であるため、企業の侵害において最も一般的に観察される横方向移動技術の一つとなっています。かつて認証失敗を引き起こしていた誤設定は、現在攻撃面の一部となっています。
SPNの構造、ADがそれを解決する方法、攻撃者が弱い構成を悪用する方法を理解することは、それらを保護するための第一歩です。本記事で説明した運用手順が基礎を提供します。これに基づき、継続的な監視、定期的なSPN監査、および可能な場合はgMSAへの移行が組織が脅威に先んじるのに役立ちます。
Netwrix Threat Manager はオンプレミスのActive DirectoryおよびEntra ID全体で、Kerberoasting、SPN列挙クエリ、疑わしいサービスチケット要求を含むIDベースの攻撃を検出します。
アカウントレベルでの異常な活動と相関しています。権限の低いユーザーが突然50件のサービスチケットを要求すると、セキュリティチームはそれを個別のログエントリではなく、単一の統合アラートとして認識します。
デモをリクエストして、NetwrixがSPNの悪用を検出し、ADの変更をリアルタイムで監査し、攻撃者が悪用する前に攻撃対象範囲を減らす方法をご覧ください。
Netwrix Auditor は、AD環境全体のservicePrincipalName属性のすべての変更を、変更前後の値と各変更の責任アカウントとともに追跡します。高権限アカウントにSPNが登録された場合やサービスアカウントから予期せず削除された場合、Auditorはその変更を即座に表示します。
SPNとActive Directoryおよびセキュリティにおけるその役割に関するよくある質問。
共有する
もっと詳しく
著者について
Joe Dibley
セキュリティリサーチャー
Netwrix のセキュリティリサーチャーであり、Netwrix Security Research Team のメンバーです。Joe は Active Directory、Windows、およびさまざまなエンタープライズソフトウェアのプラットフォームとテクノロジーの専門家であり、新たなセキュリティリスク、複雑な攻撃手法、そしてそれに関連する緩和策と検知について研究しています。