Active Directory のアカウント設計

扱う範囲

Active Directory（AD）のアカウント設計を、運用者と攻撃者の両方の視点から見ていきます。アカウントは、認証情報と権限を結び付けるセキュリティ主体です。設計するときは、誰がアカウントを作り、どの経路で、どの権限に到達できるかを確認します。

発行・紐付け・利用・監査で考える

判断に迷ったときは、次の四つに分けて考えると整理できます。

発行：誰がアカウントや認証情報を作れるか。
紐付け：認証情報の持ち主をどう特定するか。
利用：どのサービスや権限に到達できるか。
監査：いつ、誰が、どこで利用したかを追えるか。

ID の発行と紐付け

flowchart TB
    subgraph Issuers["発行主体 (Issuers)"]
        DC["DC/KDC (Domain Controller)"]
        CA["AD CS / CA (Certificate Authority)"]
    end
    Account["Account (User/Computer/Service)"]
    SID["SID (Security Identifier)"]
    SPN["SPN (servicePrincipalName)"]
    Ticket["Kerberos Ticket (TGT/TGS)"]
    Cert["Certificate (X.509)"]
    Resource["Resource / Service"]

    Account --> SID
    Account --> SPN
    DC --> Ticket
    CA --> Cert
    Ticket --> Resource
    Cert --> Resource
    SID --> Resource

DC の KDC は Kerberos チケットを、CA は証明書を発行します。どちらも本人確認の起点になるため、発行権限とアカウントへの紐付けを確認する必要があります。

基礎概念

SID とアカウントの関係（識別子と名前の違い）

SID (Security Identifier) は、AD 内で一意な識別子です。ACL (Access Control List) は名前ではなく SID に結びつきます。

名前 (SamAccountName/UPN) は運用上変更可能だが、SID は原則不変。
同名アカウントでも SID が異なれば別主体。逆に名称変更しても SID が同じなら権限は維持される。
SIDHistory は移行時に便利だが、悪用されると権限継承の抜け道になり得る。

設計の意味: 「アカウント名はラベル、SID は実体」という前提を持つと、証明書マッピングや権限監査の判断軸が明確になります。

SPN (servicePrincipalName) と「SPN 密度」

SPN は「サービスを提供するアカウント」を Kerberos が特定するための属性です。SPN の登録先アカウントが、Kerberos チケット (TGS) の受け手になります。

SPN が多いアカウントは、複数サービスの認証窓口を一つに集約している。
SPN が重複すると Kerberos は曖昧になり、認証が破綻する。

なぜ SPN 密度が「被害増幅点」になるのか

SPN 密度が高いアカウントは、攻撃者にとって「一度の侵害で複数サービスへ波及できる接点」です。例えば Kerberoasting (Kerberos Ticket のオフライン解析) でそのアカウントの認証情報を奪われると、紐づいた全サービスが同時に危険に晒されます。

flowchart LR
    svc["svc-app (Service Account)"]
    spn1["SPN: HTTP/app01"]
    spn2["SPN: MSSQLSvc/db01"]
    spn3["SPN: HOST/file01"]
    svc --> spn1
    svc --> spn2
    svc --> spn3

Kerberos 認証の前提となる考え方

Kerberos は「チケットで本人性を証明する」プロトコルです。認証の前提は次の通りです。

KDC (Key Distribution Center) は DC 上にあり、ドメイン内の本人性発行の中心。
クライアントとサーバーは SPN を介して互いを特定する。
時刻同期 (Time Sync) が崩れるとチケットが無効化される。
PAC (Privilege Attribute Certificate) に SID とグループ情報が入り、権限判定の根拠となる。
TGT (Ticket Granting Ticket) と TGS (Service Ticket) が認証の流れを構成する。

設計の意味: Kerberos を前提とする設計では「SPN が正しく管理されていること」「DC が信頼境界の中心であること」が絶対条件です。

アカウント種別ごとの設計

ユーザーアカウント

運用者の視点

ユーザーアカウントは業務の入口であり、最も数が多く、運用コストが高い対象です。ID ライフサイクル管理 (Lifecycle Management) とアクセス制御 (Access Control) がそのままリスク管理になります。

攻撃者の視点

攻撃者にとってユーザーアカウントは初期侵入 (Initial Access) の主戦場です。認証情報の再利用、フィッシング、MFA (Multi-Factor Authentication) 回避などで侵害されると、横展開 (Lateral Movement) の足がかりになります。

設計時の判断

推奨：管理者用アカウントと通常業務アカウントを分離し、Tiering (Tier 0=AD 基盤/Tier 1=サーバー/Tier 2=クライアント) を徹底する。
推奨：無効化・退職アカウントの棚卸しを自動化し、放置アカウントを作らない。
避けること：共有アカウントの運用を常態化しない。
避けること：通常ユーザーに Domain Admin などの永続的権限を付与しない。

computer account

運用者の視点

computer account は「ドメイン参加端末の身分証」です。GPO (Group Policy Object) 適用、証明書配布、Kerberos 認証の主体にもなるため、サーバー設計と密結合です。

攻撃者の視点

侵害端末の computer account は、ドメイン内認証に使える資格情報です。特にサーバーの computer account が持つ権限や委任設定が過剰だと、横展開や委任悪用 (Delegation Abuse) に直結します。

設計時の判断

推奨：端末種別 (Client/Server/Infrastructure) ごとに OU (Organizational Unit) を分け、GPO と委任範囲を分離する。
推奨： Resource-based Constrained Delegation (RBCD) は委任先が許可を持つ仕組みだと理解し、利用範囲を最小化する。
避けること：重要な computer account に業務アプリ用の権限を混在させない。
避けること：不要なサーバーをドメイン参加させて管理範囲を広げない。

サービスアカウント

運用者の視点

サービスアカウントは「人がログインしない ID」であり、長期運用で権限が肥大化しやすい領域です。SPN 管理とパスワード管理が設計の中核になります。

攻撃者の視点

サービスアカウントは Kerberoasting や資格情報ダンプの主要ターゲットです。SPN 密度が高いアカウントを奪取すれば、複数サービスへ即座に展開できます。

設計時の判断

推奨：サービスごとに専用アカウントを割り当て、SPN を分散させる。
推奨：可能なら gMSA へ移行し、手動パスワード運用をやめる。
避けること： 1 つのアカウントに多くの SPN を集約しない。
避けること：サービスアカウントに対話ログオン (Interactive Logon) を許可しない。

gMSA

運用者の視点

gMSA はパスワード自動管理と Kerberos 前提の設計により、運用負荷と漏洩リスクを大きく下げます。重要なのは「誰がそのパスワードを取得できるか」です。

攻撃者の視点

gMSA 自体は安全でも、パスワード取得権限 (Read msDS-ManagedPassword) が広いと、侵害ホストから横展開できます。許可グループ設計が防衛線です。

設計時の判断

推奨： gMSA 利用ホストを最小グループに限定し、OU 単位で権限を委任する。
推奨： gMSA の用途・紐付く SPN・利用ホストをドキュメント化する。
避けること： gMSA を「万能なサービス ID」として流用しない。
避けること：監査ログなしで gMSA のホスト追加を運用しない。

Domain Controller (DC)

運用者の視点

DC は KDC の役割を持つ「本人性発行の心臓部」です。ここに不正ログオンを許せば、全アカウントの信頼性が崩れます。

攻撃者の視点

DC 侵害は DCSync (Directory Replication API の悪用) などでドメイン全体の秘密情報を取得できる「最終到達点」です。DC への一時的な侵入ですら致命的です。

設計時の判断

推奨： DC を Tier 0 として隔離し、管理端末 (PAW: Privileged Access Workstation) からのみ管理する。
推奨： DC に対話ログオンを許可するユーザーを厳格に制限する。
避けること： DC で一般アプリや役割 (例: ファイルサーバー) を併用しない。
避けること： DC に不要なサービスアカウントを常駐させない。

認証局（AD CS / CA: Certificate Authority）

運用者の視点

AD CS (Active Directory Certificate Services) は証明書を通じて「別経路の本人性発行」を提供します。Kerberos と並ぶ認証基盤であるため、CA の運用は AD の安全性に直結します。

攻撃者の視点

証明書発行を悪用できれば、パスワードを触らずに高権限ログオンが可能になります。ESC 系の誤設定は「本人性の偽造」を許します。

設計時の判断

推奨： CA を Tier 0 として隔離し、テンプレート変更権限を最小化する。
推奨：強固な証明書マッピング (Strong Certificate Mapping: SID ベースの厳格なマッピング) を有効化し、SID 拡張を活用する。
避けること：権限の広いテンプレートに対し、広範な Enrollment 権限を付与しない。
避けること： Web Enrollment (AD CS Web) を無警戒に公開しない。

AD CS の攻撃経路を分類する

AD CS に対する ESC 攻撃は、単なるテクニック集ではなく「本人性の発行経路の破壊」と理解するのが重要です。ESC1〜ESC8 は次のように分類できます。

分類	破られる境界	代表する ESC	影響
テンプレート／登録フローの本人性崩壊	Subject/UPN/SAN/EKU/Enrollment の不整合	ESC1-ESC4	別アカウントの証明書発行が可能になる
CA 管理・プロトコル経路の侵害	CA 権限、Web Enrollment、NTLM Relay (NTLM 中継) など	ESC5-ESC8	CA 自体の支配や発行経路の乗っ取り

補足: Subject/UPN/SAN は証明書の「本人性表示」、EKU (Extended Key Usage) は「証明書の用途制限」、Enrollment は「申請/発行の権限」です。ここが緩いと「誰の証明書か」が崩れます。

ESC16（SID セキュリティ拡張無効化）の意味と危険性

ESC16 は「証明書に SID が適切に紐付かない」状況を指します。SID 拡張が無効、もしくは検証されない場合、証明書の Subject/UPN のみでマッピングが成立し、別アカウントへの成りすましが容易になります。

設計上の含意: SID を中心に据える AD の設計思想が崩れ、「証明書の見た目だけで本人性が決まる」状態になるため、CA の運用は DC と同等に厳格であるべきです。

アカウント設計とセキュリティの関係

アカウント設計は、以下の 3 つの問いに対する回答を組織に与えます。

「誰が本人性を発行できるのか」: DC と CA の運用境界をどう守るか
「何が本人性を保証するのか」: SID・SPN・証明書マッピングの整合性
「侵害時にどこまで波及するのか」: SPN 密度や権限設計が爆風半径を決める

これらはすべて「アカウント運用の設計」によって決まります。だからこそ、AD のアカウント設計はセキュリティそのものです。

PKINIT と TGT の発行

概念

短い要約:

PKINIT は証明書で AS-REQ を行う初期認証方式。
証明書が TGT になるのではなく、KDC が TGT を発行する。
TGT 取得後はパスワードでも証明書でも同じ流れで、PAC が認可を運ぶ。

PKINIT (Public Key Cryptography for Initial Authentication in Kerberos) は、初期認証 (AS: Authentication Service) の「事前認証 (Pre-Authentication)」をパスワードではなく証明書で行う方式です。AS-REQ/AS-REP (Authentication Service Request/Response) はこの初期認証の要求/応答です。ここで重要なのは「証明書そのものが TGT (Ticket Granting Ticket) になる」のではなく、「証明書を材料に KDC が TGT を発行する」点です。

KDC (Key Distribution Center) は krbtgt (KDC の長期鍵を保持するサービスアカウント) を用いて TGT を署名します。PAC (Privilege Attribute Certificate) も KDC の署名で信頼され、以後の認可 (Authorization) に影響します。つまり、信頼境界は KDC/krbtgt と PAC 署名にあるという前提を外してはいけません。

UPN (User Principal Name) はアカウントの一意なログオン名で、altSecurityIdentities は証明書マッピング用属性、userAccountControl (UAC) はアカウント制御フラグです。KDC はこれらのディレクトリ情報を使って証明書とアカウントを結びつけます。

ASCII 図: 通常の AS-REQ/AS-REP と PKINIT の対比（KDC 視点）

(通常: パスワード由来の事前認証)
[Client] --AS-REQ (PA-ENC-TIMESTAMP)--> [KDC/krbtgt]
                [KDC] --(AD参照: SID/UPN/userAccountControl/Group)--> [Directory]
[Client] <--AS-REP (TGT + PAC)--------- [KDC/krbtgt]

(PKINIT: 証明書による事前認証)
[Client(cert+private key)] --AS-REQ (PA-PK-AS-REQ)--> [KDC/krbtgt]
                     [KDC] --(AD参照: UPN/altSecurityIdentities/userAccountControl)--> [Directory]
[Client] <--AS-REP (TGT + PAC)----------------------- [KDC/krbtgt]

*注: 証明書は「本人性の材料」であり、TGT は KDC が発行する認可トークン。

補足: PA-ENC-TIMESTAMP はパスワード由来の事前認証データ、PA-PK-AS-REQ は証明書由来の事前認証データです。

ASCII 図: PKINITで証明書がTGTを生む瞬間

(準備) Clientは 1) 証明書 2) 秘密鍵 を持つ

[Client] --AS-REQ(+PA-PK-AS-REQ: 証明書/署名/鍵交換)--> [KDC/krbtgt]
              |
              | KDC側でやること (重要)
              | - 証明書チェーンが信頼できるか
              | - 証明書の用途(EKU等)がログオンに適切か
              | - 証明書が "どのADアカウント" に対応するか (マッピング)
              | - (ポリシー次第で) 失効確認(OCSP/CRL) など
              v
[Client] <--AS-REP(TGT + session key)------------------ [KDC/krbtgt]
                ^ ここが「証明書がTGTを生む瞬間」

ここがキモ: TGT が出た後は証明書の文脈が薄れ、以後は TGT/PAC が認可の材料になります。パスワード由来でも証明書由来でも、TGT 取得後の流れは同じです。

[Client] --TGS-REQ (TGT提示)--> [KDC] --TGS-REP (TGS)--> [Client]

この性質が「設定ミスが致命傷になりやすい」理由です。KDC が誤って TGT を発行すると、その後の認可が TGT/PAC の情報で回り続けるため、影響が広く長く残ります。

実装観点

PKINIT では、クライアントは証明書で署名した AS-REQ を送信し、KDC は証明書を検証した上で TGT を発行します。KDC の判定ポイントは「証明書が信頼できるか」「その証明書がどの AD アカウントに紐付くか」「そのアカウントがログオン条件を満たすか」の 3 層です。

KDC の判定ポイント（要約）

チェーン検証: 発行元 CA が信頼されているか、証明書チェーンは正しいか
失効検証: CRL (Certificate Revocation List) / OCSP (Online Certificate Status Protocol) による失効確認が成立しているか
用途検証: EKU/KU が Kerberos ログオンに適合するか
マッピング: UPN (User Principal Name) / SID / altSecurityIdentities (証明書マッピング用属性) などでアカウントが一意に解決できるか
アカウント状態: userAccountControl (UAC: アカウント制御フラグ) の制約やログオン制限に抵触しないか
ポリシー: 強固な証明書マッピング (Strong Certificate Mapping) 要件を満たすか

擬似コード (KDC 側の判断フロー)

if not verify_cert_chain(cert): reject
if is_revoked(cert): reject
if not eku_allows_logon(cert): reject
account = map_cert_to_account(cert, directory)
if account is None: reject
if account.uac_disallows_logon(): reject
if not strong_mapping_ok(cert, account): reject
issue_tgt_with_pac(account, krbtgt_key)

運用観点

運用の要点は「CA 側の発行設定」と「KDC 側の評価ルール」の両方を守ることです。証明書テンプレートが緩くても、KDC が厳密に評価すれば防げます。逆に、KDC のマッピングが弱いと「見た目だけの証明書」が通るリスクが高まります。

信頼境界: KDC/krbtgt が発行した TGT と PAC の署名が信頼の根拠である。
設計リスク: 強固なマッピング無効化、証明書テンプレートの Subject/SAN 供給許可、失効確認の形骸化は、KDC の判定をすり抜ける原因になる。
監査連携: CA 側のテンプレート変更、発行ログ、KDC 側のログオンイベントを相関できるようにする。

監査観点

監査では「誰がどの証明書を発行でき、どの条件で KDC が受理するか」を追跡します。LDAP で見えるテンプレート設定と、KDC のマッピング/ポリシー設定の両方を確認するのが鍵です。

トラブルシュート観点

証明書ログオンの失敗は、KDC の評価で止まるケースが多いです。原因 -> 確認 -> 対処の順に整理します。

原因: チェーン不信 -> 確認: CA 信頼ストア/中間証明書 -> 対処: ルート/中間の配布
原因: EKU 不一致 -> 確認: 証明書の EKU/KU -> 対処: テンプレート修正/再発行
原因: マッピング不可 -> 確認: UPN/altSecurityIdentities の一致 -> 対処: マッピング規則見直し
原因: 失効確認失敗 -> 確認: CRL/OCSP 到達性 -> 対処: 失効基盤の可用性改善
原因: 時刻ずれ -> 確認: NTP/AD 時刻同期 -> 対処: 時刻ソースの修正

監査チェックリスト（PKINIT）

KDC 側で Strong Certificate Mapping が有効か
CA/テンプレートが Kerberos ログオン用途に限定されているか
失効確認 (CRL/OCSP) が常時機能する設計か
証明書マッピング (UPN/SID/altSecurityIdentities) が一意になるか

よくある落とし穴（運用）

失効確認の到達性を確保せずに PKINIT を必須化する
テンプレートの Subject/SAN を要求者入力にし、KDC 側のマッピング条件を緩める
KDC のログと CA の発行ログを別運用にして相関できない

KDC から見た AD CS のテンプレート

概念

AD CS のテンプレートは「CA の設定」に見えますが、KDC が直接読むわけではありません。テンプレートが生成する証明書の性質を KDC が評価するという構造です。したがって、テンプレートは「KDC が受け入れる証明書を作る設計書」と捉えます。

ASCII 図: テンプレートと KDC 評価の関係

[Template] --(設定)--> [CA] --(証明書発行)--> [Client]
                                     |
                                     v
                          [KDC] --(証明書評価)--> TGT/PAC

実装観点

KDC 視点の 5 つの質問に落とし込むと、テンプレートの評価が明確になります。

チェーンは信頼できるか (Chain Trust)
用途はログオンに適合するか (EKU/KU)
どのアカウントに紐付くか (Mapping)
制約は十分に効いているか (Policy/Restriction)
失効/有効期限は安全側か (Revocation/Validity)

テンプレート属性カテゴリ別の読み解き

以下では「証明書への反映 -> KDC への影響 -> 運用上の意味」の順で整理します。

EKU / KeyUsage
- 反映: 証明書の用途 (Client Authentication/Smartcard Logon など) と鍵用途が確定する。
- KDC への影響: ログオンに必要な EKU が無いと拒否される。用途が広いほど許容範囲が広がる。
- 運用の意味: 最小用途を原則とし、ログオン用途は限定したテンプレートに閉じる。
Subject/SAN 生成規則 (SAN: Subject Alternative Name; Name Flag: Subject/SAN の自動生成ルール)
- 反映: UPN や DNS 名が証明書に入る。
- KDC への影響: マッピングに使われるため、要求者入力が許されると本人性が崩れる。
- 運用の意味: Subject/SAN はディレクトリ由来の自動生成を基本とし、手入力を避ける。
Enrollment Flag (AutoEnroll: 自動発行など)
- 反映: 自動発行の可否が決まる。
- KDC への影響: KDC は直接見ないが、発行対象が広がるほど攻撃面が増える。
- 運用の意味: AutoEnroll は対象を最小化し、必要な OU/グループに限定する。
発行ゲート (Manager Approval / Authorized Signatures)
- 反映: 手動承認や署名の要件が加わる。
- KDC への影響: 発行が抑制されるため、誤発行リスクが低下する。
- 運用の意味: 高リスク用途は承認フローを挟む設計が望ましい。
Validity / Renewal / KeyLength
- 反映: 証明書の有効期間と鍵強度が決まる。
- KDC への影響: 長期有効は侵害時の影響時間を延ばす。
- 運用の意味: 有効期間を短めに設計し、更新運用を回す。
Permissions (Enroll/AutoEnroll/Write/Owner)
- 反映: 誰が発行できるか、誰がテンプレートを変更できるかが決まる。
- KDC への影響: KDC は直接見ないが、発行者の範囲が広いほどリスクが増える。
- 運用の意味: Enroll/AutoEnroll とテンプレート変更権限は最小限に絞る。

運用観点

テンプレート設計は「KDC に受け入れられる証明書の仕様書」として運用します。KDC の信頼境界 (TGT/PAC 署名) を守るために、証明書の発行条件を狭く、マッピングを強固にすることが重要です。

架空テンプレート例: CORP-User-Logon-v1

属性カテゴリ	設定例	KDC 視点の意味
EKU	Client Authentication, Smartcard Logon	ログオン用途に限定
Subject/SAN	UPN を AD から自動生成	マッピングが一意になりやすい
Enrollment	AutoEnroll = 有効	対象範囲を限定する必要
発行ゲート	Manager Approval = 無効	運用負荷は低いが誤発行の制御が弱い
Validity	1 年 / Renewal 6 か月	侵害時の影響時間を短縮
KeyLength	2048	鍵強度の最低ライン
Permissions	Enroll: GRP-User-Logon, Write/Owner: PKI-Admins	発行権限と変更権限を分離

読み解き (KDC 視点): UPN 自動生成によりマッピングが明確化される一方、AutoEnroll が広いと誤発行のリスクが増える。発行ゲートが無い場合、監査で発行履歴の確認を強化する必要がある。

監査観点

テンプレートは LDAP で参照可能な設定であり、監査の主戦場です。KDC がどの証明書を受け入れるかは「テンプレート設定の総和」に依存するため、テンプレートの変更履歴とアクセス権を重点監査します。

トラブルシュート観点

証明書ログオンで起きる典型的な失敗を、原因 -> 確認 -> 対処で整理します。

原因: EKU 不一致 -> 確認: 証明書の EKU/KU -> 対処: テンプレート修正
原因: マッピング不可 -> 確認: UPN/SAN と AD の一致 -> 対処: Name Flag 修正
原因: チェーン不信 -> 確認: CA 証明書の信頼状態 -> 対処: ルート/中間配布
原因: 失効確認失敗 -> 確認: CRL/OCSP の到達性 -> 対処: 失効基盤の可用性改善
原因: テンプレート権限の誤付与 -> 確認: Enroll/AutoEnroll/Write ACL -> 対処: 権限縮小

監査チェックリスト（テンプレート）

Enroll/AutoEnroll の対象が最小化されているか
Subject/SAN が要求者入力に開放されていないか
EKU/KU がログオン用途に限定されているか
テンプレート変更権限 (Write/Owner) が過剰でないか
有効期限/鍵長が組織ポリシーに合致しているか

よくある落とし穴（運用）

「CA 側の設定だから KDC と無関係」と誤解する
AutoEnroll を広く開けてしまい、発行対象が無秩序に増える
テンプレートの変更権限を運用グループに広く委任する

LDAP の情報が Kerberos チケットに反映されるまで

概念

LDAP は「プロトコル」であり、重要なのは ディレクトリ情報そのもの です。KDC は LDAP を通じてディレクトリ情報を読み取り、TGT/TGS/PAC を生成します。TGS (Ticket Granting Service) はサービスチケット発行のフェーズです。つまり、LDAP は観測窓であり、Kerberos はその情報をチケットに変換する仕組みです。

TGS-REQ/TGS-REP (Ticket Granting Service Request/Response) はサービスチケットの要求/応答です。

ASCII 図: Directory 情報が Kerberos チケットに変換される流れ

AS (認証)
[Client] --AS-REQ--> [KDC] --(read Directory attrs)--> [Directory]
[Client] <--AS-REP (TGT + PAC)------------------------ [KDC]

TGS (サービスチケット)
[Client] --TGS-REQ--> [KDC] --(read SPN/Delegation)--> [Directory]
[Client] <--TGS-REP (Service Ticket)----------------- [KDC]

Authorization (認可)
[Service] --(PAC/ACL 参照)--> [Directory/Local ACL]

実装観点

LDAP で見える情報と Kerberos で使われる情報の対応表

LDAP 属性	Kerberos での使われ方	監査・防御観点
userPrincipalName (UPN)	証明書/ログオン時のマッピングに利用	一意性と命名規則の徹底
sAMAccountName	旧形式ログオン名、チケット内の識別に利用	重複や命名衝突の監査
objectSid	PAC に含まれる主キー	SIDHistory の管理と棚卸し
memberOf	PAC のグループ情報に反映	過剰なグループ付与の監査
primaryGroupID	既定グループの SID 計算に使用	レガシー互換性の整理
servicePrincipalName (SPN)	TGS 発行先の特定	SPN 重複の検出と解消
userAccountControl	ログオン可否/委任/事前認証などに影響	DONT_REQ_PREAUTH (事前認証不要) / TRUSTED_FOR_DELEGATION (委任許可) の棚卸し
msDS-AllowedToDelegateTo	制約付き委任 (Constrained Delegation)	委任先の最小化、棚卸し
msDS-AllowedToActOnBehalfOfOtherIdentity	RBCD (Resource-based Constrained Delegation)	委任権限の過剰設定監査
altSecurityIdentities	証明書マッピングに利用	証明書ログオン対象の監査

LDAP で見えないが Kerberos の安全性に直結する情報

krbtgt の秘密鍵やアカウント秘密情報: TGT 署名の根拠であり、漏洩はドメイン全体の信頼崩壊に直結する。
パスワードハッシュ/暗号鍵: LDAP から直接は見えないが、KDC は認証に利用する。
KDC の内部ポリシー/キャッシュ: 強固なマッピングや失効チェックの挙動に影響する。

運用観点

LDAP の属性設計がそのまま Kerberos の挙動を決めるため、ディレクトリ情報の整合性が最重要です。KDC/krbtgt の信頼境界を守るには、SPN・グループ・委任属性の設計を最小権限で管理する必要があります。

監査観点

監査の焦点は「ディレクトリ上の設定がチケットにどう反映されるか」です。特に SPN、委任属性、証明書マッピング属性は、攻撃の拡大を防ぐための主要監査対象です。

トラブルシュート観点

ディレクトリ属性の不整合は Kerberos の失敗や誤認可につながります。原因 -> 確認 -> 対処で整理します。

原因: SPN 重複 -> 確認: SPN 一覧の重複検出 -> 対処: SPN 再配置
原因: グループ情報の不整合 -> 確認: memberOf/primaryGroupID -> 対処: グループ設計修正
原因: 委任属性の誤設定 -> 確認: msDS-AllowedToDelegateTo/RBCD -> 対処: 委任範囲縮小
原因: 証明書マッピング不備 -> 確認: altSecurityIdentities/UPN -> 対処: マッピング規則の統一

監査チェックリスト（LDAP と Kerberos 対応）

SPN 設計の整合性（重複・過密の排除）
グループ/権限の過剰付与の棚卸し
委任設定 (Constrained Delegation/RBCD) の棚卸し
証明書マッピング (altSecurityIdentities/UPN) のルール確認

よくある落とし穴（運用）

LDAP の属性変更が Kerberos 認可に与える影響を見落とす
SPN の重複を「動いているから良い」と放置する
委任設定の例外を恒久化し、棚卸しが形骸化する

用語集と参考文献

用語集

PKINIT (Public Key Cryptography for Initial Authentication in Kerberos): 証明書を使って AS-REQ を行う初期認証方式。
AS-REQ/AS-REP (Authentication Service Request/Response): 初期認証の要求/応答。
TGT (Ticket Granting Ticket): KDC が発行する認証チケット。以後の TGS 発行の根拠。
TGS (Ticket Granting Service): サービスチケット発行のフェーズ。
PAC (Privilege Attribute Certificate): SID/グループ情報を含む権限証明。KDC 署名で信頼される。
krbtgt: KDC が TGT を署名するための長期鍵を保持するアカウント。
EKU (Extended Key Usage): 証明書の用途制限。
KU (Key Usage): 証明書鍵の用途制限。
RBCD (Resource-based Constrained Delegation): リソース側が委任を許可する委任方式。
Strong Certificate Mapping: SID 拡張などを用いて証明書とアカウントを厳格に紐付ける方式。

参考文献

RFC 4120: Kerberos Version 5
RFC 4556: PKINIT (Public Key Cryptography for Initial Authentication in Kerberos)
RFC 4762: Microsoft Kerberos PAC
Microsoft Docs: Kerberos Authentication in Active Directory
Microsoft Docs: Active Directory Certificate Services Overview
Microsoft Docs: Certificate Templates in Active Directory Certificate Services
Microsoft Docs: Strong Certificate Mapping and SID Extension
Microsoft Docs: Service Principal Names (SPN) and Kerberos Authentication