Kerberos認証の流れ
１．AS Request(SSO可能)
KDC(AS)に対して、TGTの発行を要求
２．AS Response(SSO可能)
要求者が本人であることを確認、TGTを発行
３．TGS Request
リソースにアクセスするために、KDC(TGS)に対して、取得済みのTTをそえてSTを要求
４．TGS Response
アクセスを要求されているリソースの情報を確認、STを発行
５．AP Request
アクセスするリソースへSTを提示して、サービスの利用を要求
６．AP Response
提示されたSTを確認、アクセスを許可。これでKerberos認証完了。
▼詳細
Kerberos（ケルベロス）認証をより直感的に理解するために、
「テーマパークの入園とアトラクション」に例えて解説します。
## わかりやすい例え：ディズニーランドの仕組み
Kerberosのやり取りは、まるで大きなテーマパークで遊ぶ時の流れと同じです。
KDC（チケット売り場）: パークの運営事務局
TGT（入園パスポート）: 園内ならどこでも持ち歩ける「本人確認済み」の証
ST（アトラクション利用券）: 「スプラッシュマウンテン専用」など、特定のリソースに入るための券
リソース（アトラクション）: 実際に使いたいサーバーやファイル
## 認証のステップ（ストーリー仕立て）
1 & 2：まずは「入園パスポート(TGT)」をもらう
AS Request / Response
何をしているか: あなたがチケット売り場（AS）に行って、身分証を見せます。
結果: 「よし、君は本人だね」と認められ、TGT（入園パスポート）をもらいます。
これで園内の「中」には入れますが、まだ個別の乗り物には乗れません。
3 & 4：乗りたい物の「利用券(ST)」に引き換える
TGS Request / Response
何をしているか: 園内の案内所（TGS）へ行き、TGT（パスポート）を見せて
「このファイルサーバー（アトラクション）を使いたい」と言います。
結果: 案内所はパスポートを確認し、そのサーバー専用のST（利用券）をくれます。
5 & 6：いよいよ「サービス」を利用する
AP Request / Response
何をしているか: 目的のサーバー（アトラクションの入り口）へ行き、ST（利用券）を見せます。
結果: サーバー側は「その券は本物だね、どうぞ！」と許可し、ついにデータにアクセスできます。
ワンポイント・アドバイス：
「TGT」は「入園パスポート」、「ST」は「各施設の入場チケット」と考えると、
AD（アクティブディレクトリ）の環境でなぜ2種類のチケットが必要なのかがよりスッキリ理解できるはずです。
[0回]
PR
ADDS（Active Directory Domain Services）について
1. ドメインコントローラ（DC）の本質
DCは、ネットワーク内の「お役所」兼「警察署」のような存在です。
ntds.dit（住民基本台帳）： 誰がどこに住んでいるか
（ユーザー名、パスワード、所属部署）を記録した巨大なデータベースです。
SYSVOL（校則・ルールブック）： 「壁紙はこれにする」「パスワードは10桁以上」といった
グループポリシー（GPO）の実体ファイルが置かれる共有フォルダです。
2. FSMO（フィスモ）を「役割」で理解する
ADは基本的に、どのDCで情報を書き換えても全体に同期される
「マルチマスター方式」ですが、「同時にあちこちで変えると困る重要な仕事」
だけは、特定の1台が担当します。これがFSMOです。
5つの役割を、もう少し直感的に分類してみましょう。
A. フォレストに1台だけの「大きな決断」担当
スキーママスター
「名簿の項目」を決める人。住所や電話番号のほかに「血液型」という項目を増やす、といったデータベースの構造変更を管理します。
ドメイン名前付けマスター
「支店（ドメイン）」の増設担当。フォレスト内に新しいドメインを作る際、名前が重複しないように管理します。
B. 各ドメインに1台ずつの「日常業務」担当
PDCエミュレーター
「時間の番人」兼「最後の審判者」。
ドメイン内の時計を合わせるリーダーであり、パスワード変更の即時反映も行います。
FSMOの中で最も忙しく、止まると影響が大きい役割です。
RIDマスター
「IDの発行機」。
ユーザー作成時に必要な「背番号（SID）」の元ネタを、各DCに束で配ります。
これが枯渇すると新しいユーザーが作れなくなります。
インフラストラクチャマスター
「外部参照の整理係」。他のドメインのユーザーが自ドメインのグループに
入っている時、その名前変更などを追いかけて整合性を保ちます。
さらに理解を深めるポイント
なぜFSMOを分けるのか？
通常は1台のDCが5つの役割をすべて兼任していますが、
大規模環境では負荷分散や障害対策のために役割を分散させることがあります。
グローバルカタログ (GC)
まとめにはありませんが、ADを語る上で「GC」も重要です。
これはフォレスト全体の情報を検索しやすくするための
「索引（インデックス）」の役割を持ち、ログイン処理を高速化します。
[0回]
パッチ適用テスト
物理PCを一台ずつ手作業で検証するよりも、
仮想環境でゴールデンイメージ（マスターイメージ）を
更新してテストする方が、はるかに効率的で安全です。
AVDと一般的なVDIの違い
ざっくり言うと、「全部自分で管理するプロ仕様のVDI」か、
「Microsoftにお任せできるクラウド版VDI」か、という違いです。
Azure Virtual Desktop = AVD
slmgr /ipk
というコマンドを叩くことがよくあります。
この ipk も「Install Product Key」の略[0回]
Windowsの更新プログラム（アップデート）の種類について
1. Bリリース (B-release)
一般的に「パッチチューズデー（火曜日のパッチ）」と呼ばれる、最も重要な更新プログラムです。
配信時期: 毎月第2火曜日（米国時間）。日本時間では第2水曜日の未明に配信されます。
内容: セキュリティの脆弱性修正（セキュリティ更新）と、過去に配信された修正をまとめた累積的な更新が含まれます。
特徴: 強制適用: セキュリティ維持のため、Windows Updateで自動的にインストールされる設定になっていることが多いです。
すべてのユーザーが受け取る「本番」の更新です。
2. Cリリース (C-release)
主に翌月のBリリースに向けた「プレビュー版」という位置づけの更新プログラムです。
配信時期: 毎月の第3または第4週。
内容: セキュリティ以外の修正（バグ修正や新機能の先行導入）が含まれます。
特徴: オプション提供: 自動ではインストールされず、
設定画面で「ダウンロードしてインストール」を手動でクリックしたユーザーにのみ適用されます。
IT管理者や「最新の状態をいち早く試したい」ユーザーが、翌月の本番配信前にテストするために利用されます。
3. OOB (Out-of-Band)
「帯域外」、つまり定例のスケジュールを外れて急遽配信される例外的な更新プログラムです。
配信時期: 不定期（緊急時）。
内容: 悪用が始まっている深刻な脆弱性の修正や、多くのユーザーに影響を与える致命的な不具合の解決など。
特徴: 次の「Bリリース」を待てないほど緊急性が高い場合にのみ発行されます。
非常に重要な内容であるため、速やかな適用が推奨されます。
更新リリースの比較まとめ
| 種類 | 通称 | 配信時期 | 重要度・目的 |
| Bリリース | 定例アップデート | 第2火曜日（米） | 高い（セキュリティ修正） |
| Cリリース | プレビュー更新 | 第3・4週 | 中（バグ修正の先行テスト） |
| OOB | 緊急パッチ | 随時 | 極めて高い（緊急の脆弱性対策） |
[0回]
Microsoft Intune の Windows Update for Business (WUfB) は、WSUS（Windows Server Update Services）等の不要なローカルサーバーを介さず、Intune経由でWindows 10/11の更新（品質/機能）をクラウドから直接、管理・展開・制御できる機能です。更新のタイミングや強制再起動のスケジュールを詳細に設定し、組織全体のセキュリティとパフォーマンスを最適化できます
[0回]
