MENU

TryHackMe Active Directory Basics — 学習メモ

目次

はじめに

Active Directory Basics の備忘録。
本記事は学習記録です。演習環境のターゲット名・IP・フラグは公開していません。

Active Directoryの基礎

Active Directoryとは

Active Directory は企業や組織のユーザーやパソコンをまとめて管理するサービス。

何ができるか

住所録の役割
・社員(ユーザー)
・パソコンやサーバー(コンピューター)
・プリンタなどの機器
これらを「誰が」「どこに」「どういう権限で」存在するのか、まとめて記録。

鍵の役割
・社員が会社のパソコンにログインするとき
・社員が社内のファイルサーバーにアクセスするとき
IDとパスワードをチェックし、その人が使えるものだけ使わせるように制御。

Active Directory の主な機能

ユーザー管理:社員アカウントを一元管理
コンピューター管理:PCやサーバーをまとめて管理
認証(ログインチェック):誰が正しいユーザーか確認
権限付与(アクセス制御):どこまで操作できるか決定
ポリシー配布(GPO):全社PCに一括でルール設定(例:パスワードは10文字以上)

Windowsドメインとは

組織全体のPCとユーザーをまとめたグループ。

ドメインコントローラー(DC)

ドメインの中心にいるのが ドメインコントローラー (Domain Controller, DC)。
これは Active Directory が入った Windows サーバーで、以下の役割がある。

誰がログインできるか認証する
ユーザーやPCの情報を記録する
セキュリティポリシーを配布する

ドメインに参加するとどうなるか

会社のPCを「ドメインに参加」させると、
そのPCはドメインコントローラーのルールに従うようになる。

社員がどのPCからログインしても、同じIDとパスワードで入れる
営業部の人だけ営業フォルダを見れる、といった権限管理ができる
パスワードの長さやWindows Updateの設定を一括で適用できる

Active Directory のオブジェクト

Active Directory の世界ではネットワーク上に存在するものはすべて「オブジェクト」 として管理される。

代表的なオブジェクト

ユーザー (User)
社員や管理者など人を表すオブジェクト
ユーザーはセキュリティプリンシパル(認証され、権限を持てるオブジェクト)
ユーザーは2種類に分けられる
People:社員など、人間がログインするためのユーザー
Services:サービス(IIS、MSSQL など)を動かすために使うユーザー

コンピュータ (Computer)
ドメインに参加したPCやサーバーを表すオブジェクト
例:PC01$ のように末尾に「$」が付く
OS自身が使うアカウントで、人間が直接ログインすることは想定されていない

セキュリティグループ (Security Groups)
複数のユーザーやコンピュータをまとめて管理する入れ物
1人ずつ権限を与えるよりグループ単位でアクセス制御する方が効率的

OU(組織単位:Organizational Unit)
部署やチームごとにユーザーやコンピュータをまとめる入れ物
例:「IT部門」「営業部門」など
OUにポリシーを適用すると所属するユーザーやPCに自動で反映される

セキュリティグループ (Security Groups)

アクセス権限をまとめて管理するためのグループ。

代表的なデフォルトセキュリティグループ

グループ名役割
Domain Adminsドメイン全体の管理者。DCを含めて何でもできる最強権限
Enterprise Adminsフォレスト全体を管理できる。複数ドメイン環境で使う
Server OperatorsDCの管理が可能。ただしグループ管理は不可
Backup Operatorsファイルの権限に関係なくバックアップが取れる
Account Operatorsユーザーやグループの作成・管理が可能
Domain Usersすべての通常ユーザーが所属。デフォルトでログオン可能
Domain Computersドメインに参加したすべてのコンピュータ
Domain ControllersDCだけが入るグループ

GPO(Group Policy Object)とは

Windowsドメイン環境でユーザーやコンピュータに対して一括で設定を配布する仕組み。

何ができるか

セキュリティ系
パスワードポリシー(長さ・複雑さ・有効期限など)
アカウントロックアウトの回数制限
Windows Updateの自動適用

ユーザー環境系
デスクトップの壁紙を会社のロゴに固定
コントロールパネルの使用禁止
特定のアプリケーション起動を制御

コンピュータ設定系
共有フォルダの自動マウント
スクリーンセーバーや自動ロックの設定
ファイアウォールやサービスの動作ルール

GPOの適用対象

GPOは「どこにリンクするか」で適用対象が決まる。

ドメイン全体(例:すべてのユーザーにパスワードポリシーを適用)
OU単位(例:営業部PCだけUSBメモリを禁止)
サブOUも継承(OUにリンクしたら、その下のOUにも適用される)

仕組み

1.管理者が GPMC(Group Policy Management Console) でGPOを作成
2.そのGPOをOUやドメインにリンクする
3.ドメインに参加しているユーザーやPCが定期的にGPOを取得(gpupdate)
4.自動的に設定が適用される

配布される仕組みは SYSVOL 共有フォルダ(ドメインコントローラ上)を通じて行われる。

認証方法

Kerberos認証

Active DirectoryでユーザーがログオンするときWindowsは内部で「Kerberos(ケルベロス)認証」という仕組みを使っている。

Kerberosとは

Kerberosはネットワーク上で「安全に」「何度もパスワードを送らずに」認証を行うためのプロトコル。
Windowsドメインでは標準の認証方式として使われている。

例えば、会社のパソコンで一度ログインした後、ファイルサーバーやプリンタ、社内サイトにアクセスしても再びパスワードを入力する必要がないのはこのKerberosが動いているから。

Kerberosの仕組み

用語

Client(クライアント):ユーザーが操作するPC
KDC(Key Distribution Center):認証の中心となる仕組み。ドメインコントローラー(DC)上で動作
Service(サーバー):ファイル共有やデータベースなどの利用したいリソース
TGT(Ticket Granting Ticket):サービス用チケットをもらうためのチケット
TGS(Ticket Granting Service Ticket):実際にサービスへアクセスするためのチケット

仕組み

Step 1:TGT(チケット発行チケット)をもらう

ユーザーはまず「ユーザー名」と「タイムスタンプ(時刻情報)」を自分のパスワードから作られた鍵で暗号化してKDCに送る。これが「TGTをください」というリクエスト。

KDC(ドメインコントローラー)はユーザー情報を確認し、
TGT(Ticket Granting Ticket)
セッションキー(Session Key)
をユーザーに返す。

TGTは「krbtgt」という特別なアカウントのパスワードハッシュで暗号化されており、
ユーザー自身は中身を確認できない。

Step 2:TGS(サービス用チケット)をもらう

次にユーザーが特定のサービス(例えば「ファイル共有サーバー」や「MSSQL」)を使いたいとき、
手に入れたTGTを使ってKDCにリクエスト。

リクエストには以下が含まれる:
ユーザー名とタイムスタンプ(セッションキーで暗号化)
取得済みのTGT
SPN(Service Principal Name:接続したいサービス名)

KDCはそれを受け取り、
TGS(サービスチケット)
サービスセッションキー(Svc Session Key)
を発行して返す。

TGSはそのサービスの「所有者アカウント(Service Owner)」のハッシュで暗号化されており、
サービスだけが中身を復号できる。

Step 3:サービスへのアクセス

最後にユーザーは受け取ったTGSを使ってサービスに接続。
サービスは自分の「Service Owner Hash」でTGSを復号し、ユーザーを認証。

これによりパスワードを再送することなく、安全にサービスを利用可能。

要約

Client

KDCさん、私は Username + Timestamp を自分のパスワード鍵で暗号化して送ります。身分証(TGT)をください!

KDC

確認できました。これは TGT と Session Key です。TGT は krbtgt のハッシュ で暗号化してありますよ。

Client

今度は SPN=MSSQL/SRV に接続したいです。TGT と Session Key を使って TGS をお願いします!

KDC

了解。これは TGS と Service Session Key。TGS はサービス所有者のハッシュで暗号化済みです。

Client

サーバさん、これが TGS とタイムスタンプです。

Service(サーバー)

TGS を私のハッシュで復号…OK!認証成功。どうぞ接続してください。

遊園地に例えてみると

Client

こんにちは!この遊園地に入りたいので、チケットをください。

KDC

いらっしゃいませ。身分証を確認しますね。……はい、問題なし!
こちらがあなたのフリーパス(TGT)です。
これを持っていれば、もう一度身分証を見せる必要はありませんよ。

Client

ジェットコースターに乗りたいんですけど、このTGTで乗れますか?

KDC

ジェットコースター専用のチケット(TGS)が必要です。
あなたのTGTを確認しました、はい、これが TGS(サービスチケット) です!

Client

ジェットコースターのチケットを持ってきました。入ってもいいですか?

Service(サーバー)

TGSを確認しますね……OK!あなたは正規のチケットを持っています。
どうぞ乗車をお楽しみください!

NTLM認証

Windowsで使われる認証プロトコル(認証の仕組み)のひとつで特に古いバージョンのWindowsネットワークやファイル共有(SMB)などで利用されることがある。

NTLMとは

Microsoftが開発したWindows専用の認証プロトコル。
主にWindows NT時代(1990年代)に登場し、Active Directoryが登場する前に使われていた。

今でも以下のような場面ではNTLMが動いていることがある。
ドメイン外のPCが共有フォルダにアクセスする場合
Kerberosが利用できない古いシステムやアプリ
ローカル認証や一部のリモート接続(RDP)など。

仕組み

Step 1:認証要求(Authentication Request)

クライアント(ユーザー)はサーバーに対して「ログインしたい」というリクエストを送る。
この時点では、まだパスワードやハッシュは送られない。

Step 2:サーバーからチャレンジ(Challenge)

サーバーはクライアントに対して、ランダムな値(チャレンジ)を送る。
この値は毎回異なり、使い回し(リプレイ攻撃)を防ぐためのもの。

Step 3:レスポンスの生成と送信(NTLM Response)

クライアントは自分のパスワードから生成したNTLMハッシュ(NTLM Hash)を使って、
サーバーから受け取ったチャレンジを暗号化。

Step 4:サーバー→ドメインコントローラーへ送信

サーバーは受け取ったチャレンジとレスポンスをドメインコントローラー(DC)に転送。
実際のパスワード情報はDCが保持しているため、サーバー自身では判定できない。

Step 5:ドメインコントローラーで検証

DCは保存してあるユーザーのNTLMハッシュを使い同じチャレンジを自分でも暗号化。
生成されたレスポンスがクライアントの送ったものと一致すれば認証成功。

Step 6:認証結果をサーバーに返す

DCは認証結果(成功または失敗)をサーバーに返し、
サーバーはその結果に応じてクライアントのアクセスを許可または拒否。

要約

Client

サーバーさん、ログインしたいです!認証をお願いします!

Server

了解しました。それではこちらのチャレンジ(Challenge)をお渡しします。
この値を正しく処理して返してください。

Client

分かりました。
自分のパスワードから作られたNTLMハッシュを使って、
このチャレンジを暗号化します!

Client

Challenge + NTLM Hash → Responseを作って…

Client

できました!これが私のレスポンス(Response)です!

Server

ありがとうございます。このChallengeとResponseをドメインコントローラー(DC)に確認してもらいますね。

DC

なるほど…。
こちらでも保存しているNTLMハッシュを使って同じチャレンジを暗号化してみましょう。

DC

NTLM Hash + Challenge → 自分でResponseを作って…

DC

お、クライアントのResponseと一致!これは本人ですね。

Server

DCが認証OKだそうです!
クライアントさん、ログインを許可します。ようこそ!

Active Directoryの拡張構造

Active Directory(以下AD)では単一のドメインで始まった環境をツリーやフォレストとして拡張することで、大規模組織にも対応できる。

ドメインとは

ドメインはADの管理単位。
ユーザー、コンピュータ、サーバーなどのオブジェクトをまとめて管理できる。

ツリー(Tree)とは

例えば、企業が海外展開して「UK支社」「US支社」ができた場合、それぞれのITチームが独自に管理したい。
このとき、以下のようなサブドメイン構成にすることで管理を分けられる:

thm.local(ルートドメイン)
├─ uk.thm.local(UK支社)
└─ us.thm.local(US支社)

これを「ツリー構造(Domain Tree)」と呼ぶ。
同じ名前空間(thm.local)を共有しており、各サブドメインが独立して管理可能。

各ドメインには Domain Admins(ドメイン管理者)が存在
全体を統括できるのがEnterprise Admins(エンタープライズ管理者)

つまり:
UK支社の管理者 → UK内のDCを管理
Enterprise Admin → 全支社を統括できる

フォレスト(Forest)とは

フォレストは、異なるドメインツリーをまとめた最上位の構造。
例えば、会社「THM Inc.」が「MHT Inc.」を買収した場合:

🟩 フォレスト(Forest)
 ┣ 🌳 ツリー1:THM.local
 ┃ ┣ 🍃 uk.thm.local
 ┃ ┗ 🍃 us.thm.local
 ┗ 🌳 ツリー2:MHT.local
   ┣ 🍃 asia.mht.local
   ┗ 🍃 eu.mht.local

この2つを同じネットワーク内で統合したものが「フォレスト(Forest)」。
フォレスト内では、複数のツリーが異なる名前空間でも共存できる。

トラスト関係(Trust Relationship)とは

フォレストやツリーを構成すると別ドメイン間でリソース共有が必要になる。
このときに必要なのが トラスト(信頼)関係 。

一方向トラスト(One-way Trust)
片方のドメインがもう片方のドメインを「信頼する」関係。
例えば:
THM.local → MHT.local を信頼

双方向トラスト(Two-way Trust)
お互いに信頼する関係です。
例えば:
THM.local → MHT.local を信頼
THM.local ← MHT.local を信頼

これにより両方のドメインのユーザーが互いのリソースにアクセス可能となる。
(フォレストやツリーを構築するとデフォルトで双方向トラストが形成される。)

トラスト関係=自動アクセスではない。
トラスト関係を結んだからといって自動的に全リソースにアクセスできるわけではない。
トラストは「認証を認める」仕組みであり、実際のアクセス権は別途設定が必要。

実際に動かしてみる

Task3 実演

1.OU(Organizational Units)の作成

THM OU に「Students」を作成。

左ペインで THM OU を探して右クリック。
コンテキストメニューから新規作成(New)→組織単位 (Organizational Unit) を選択。

OU作成

名前を「Students」と入力して OK。

Students作成

Task4 実演

1.不要なOUの削除
シナリオ:ある部門が予算削減のために閉鎖された。ルーム Task4 のチャートを確認して、不要な部門を削除する。

1-1.OUは誤って削除されないようにデフォルトで保護がかかっているので、まずはプロパティから保護を解除する。

現状では削除しようとしてもエラーになる。

OU削除エラー

表示(View)→Advanced Features(高度な機能)

Advanced Features

プロパティ(Properties)→オブジェクト(Object)→オブジェクトを誤削除から保護する(Protect object from accidental )deletion のチェックを外す。

プロパティ
プロテクト解除

1-2.保護が外れたのでOUを削除。

保護が外れているので削除確認画面が表示される。

OU削除
OU削除確認画面

2.委任
シナリオ:ITサポート担当者の「Phillip」に「Sales」、「Marketing」、「Management」のパスワードリセット権限を付与する。
※今回は「Sales」のみ実演。

2-1. 「制御の委任(Delegate Control)」から「Phillip」にパスワードリセット権限を付与する。

 OUを右クリックして制御の委任(Delegate Control)。

制御の委任(Delegate Control)

「Add」→「Phillip」と入力して「名前の確認(Check Names)」をクリック→OK→Next

ユーザー名を追加
ユーザー名を追加、名前の確認
次へ

「ユーザーのパスワードをリセットし、次回ログオン時にパスワード変更を強制する(Reset user passwords and force password change at next logon)」にチェックを入れ、Next。

パスワードリセット権限付与

2-2. 「Phillip」でログインし、Sales 部門のユーザー「Sophie」のパスワードリセットを実行する。

まずは、「Phillip」でログイン。

xfreerdp3 /v:IPアドレス /u:'THM¥ユーザー名' /p:'パスワード'

PowerShell からパスワード変更。
※7文字以上、大文字・小文字・数字・記号を混ぜたパスワード推奨。簡単すぎるとエラーになる。

PS C:\Users\phillip> Set-ADAccountPassword sophie -Reset -NewPassword (Read-Host -AsSecureString -Prompt 'New Password') -Verbose

New Password: **********

VERBOSE: Performing the operation "Set-ADAccountPassword" on target "CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

一緒にパスワードの強制リセットも設定。次回ログイン時にパスワード変更が必須になる。

PS C:\Users\phillip> Set-ADUser -ChangePasswordAtLogon $true -Identity sophie -Verbose

VERBOSE: Performing the operation "Set" on target "CN=Sophie,OU=Sales,OU=THM,DC=thm,DC=local".

2-3.「Sophie」でログインし、フラグを取得。

まずは、「Sophie」でRDPログイン。

xfreerdp3 /v:IPアドレス /u:'THM¥ユーザー名' /p:'パスワード'

パスワードの強制リセットが反映されている。任意のパスワードを設定し、ログイン。

強制パスワード変更

デスクトップにフラグを発見。

Sophieのデスクトップ

Task5 実演

1.コンピューターの移動
シナリオ:デフォルトでDCを除くすべてのマシンは「Computers」コンテナに配置される。最適なOUを作成し、各マシンを配置しなおす。

1-1.まずは「Workstations」と「Servers」OUを作成。

OU作成

1-2.次に適切なOUにマシンを移動。

マシンの移動

Task6 実演

1.コントロールパネルへのアクセス制限
シナリオ:コントロールパネルへのアクセスをIT部門のユーザーのみに制限したい。

1-1.GPO「Restrict Control Panel Access」を作成。

Group Policy Management → 「Group Policy Objects」を右クリック → New

「Restrict Control Panel Access」を作成

「Restrict Control Panel Access」→ OK

「Restrict Control Panel Access」を作成

1-2.「Restrict Control Panel Access」ポリシーを編集。

「Restrict Control Panel Access」を右クリック → Edit

「Restrict Control Panel Access」ポリシーを編集

User Configuration → Policies → Administrative Templates → Control Panel に移動。
「Prohibit access to Control Panel and PC settings」 を Enabled(有効) にする。

「Restrict Control Panel Access」ポリシーを編集

1-3.「Restrict Control Panel Access」をリンク。

Marketing、Management、Sales に「Restrict Control Panel Access」をドラック&ドロップ。

「Restrict Control Panel Access」をリンク

2.すべてのマシンに自動ロックを適用する
シナリオ:すべてのマシンに5 分間のアイドルで自動ロックの設定をする。

2-1.GPO「Auto Lock Screen」を作成。

Group Policy Management → 「Group Policy Objects」を右クリック → New → Auto Lock Screen → OK

GPO「Auto Lock Screen」を作成

2-2.「Auto Lock Screen」ポリシーを編集。

Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → Interactive logon: Machine inactivity limit → 値を 5 分(=300 秒) に設定し、OK。

「Auto Lock Screen」ポリシーを編集

2-3.「Auto Lock Screen」をリンク。

thm.local(ルートドメイン)に「Auto Lock Screen」をドラック&ドロップ。

「Auto Lock Screen」をリンク

3.GPOが適用されているか確認。

まずは、「Mark」でRDPログイン。

xfreerdp3 /v:IPアドレス /u:'THM¥ユーザー名' /p:'パスワード'

gpupdate /force でポリシーを即時適用。

gpupdate /force

コントロールパネルを開こうとするとエラーになる。

コントロールパネルエラー

後は、5分放置して画面が自動ロックになるか確認して終了。

つまづいたこと

グループとOUの違い

グループもOUも同じもののように見えた。
例えば、営業部のAさんがいたとして
グループ:営業
OU:営業
権限:営業
となると、OUとグループの役割が重複しているのでは?と思った。
ChatGPTに聞いてみた結果

  • Aさんのアカウント → OU「営業」に所属
    • → 営業部用のポリシー(例:USB禁止、壁紙設定など)が自動適用
  • Aさんのアカウント → グループ「営業」にも所属
    • → 営業フォルダのアクセス権限を持つ

👉 つまり「OUとグループは別の役割を持っていて、重複して使うものではない」んです。

とのこと。自身で調べてみても間違ってはいなさそう。
ざっくり
OU = GPOを適用
グループ = フォルダアクセス権を適用 の違いがあることは覚えた。

よかったらシェアしてね!
  • URLをコピーしました!
  • URLをコピーしました!

この記事を書いた人

勉強中のセキュリティエンジニアです。
初心者の目線で学んだことをまとめています。

コメント

コメントする

CAPTCHA


目次