ADごみ箱（Active Directory Recycle Bin）は、誤って削除したユーザー、グループ、コンピューター、OU を戻しやすくする機能です。結論から言うと、誤削除対策としては有効性が高い一方で、フォレスト全体に効く・有効化後は無効に戻せない・各ドメイン コントローラーの NTDS.DIT が大きくなるという影響を理解せずに入れるべき機能ではありません。しかも、復元できるのは有効化後に削除されたオブジェクトだけで、保持期間を過ぎたものは ADAC から戻せません。 (Microsoft Learn)
もう一点だけ先に押さえておくと、ADごみ箱は「削除された個別オブジェクトを戻す」ための仕組みです。属性変更の巻き戻し、ドメイン コントローラー障害、侵害後のフォレスト復旧まで代替するものではありません。そこを切り分けて考えると、導入判断を誤りにくくなります。 (Microsoft Learn)
ADごみ箱を有効化すると何が変わるか
ADごみ箱が無効な環境では、削除されたオブジェクトは tombstone として扱われます。ADごみ箱を有効化すると、削除直後は deleted-object として保持され、削除前の状態をほぼ保ったまま復元しやすくなります。deleted-object の保持期間を過ぎると recycled-object に変わり、その段階では簡単な復元はできません。 (Microsoft Learn)
| 観点 | ADごみ箱が無効 | ADごみ箱が有効 |
|---|---|---|
| 削除直後の状態 | tombstone | deleted-object |
| 属性の保持 | 制限あり | 削除前の状態をほぼ保持 |
| グループ所属の復元 | 手間がかかる | 戻しやすい |
| 復旧の主手段 | バックアップ + authoritative restore が中心 | ADAC または Restore-ADObject を使いやすい |
| 保持期間経過後 | tombstoneLifetime 後に削除 | deleted-object lifetime 経過後に recycled-object へ移行 |
| 適用範囲 | なし | フォレスト全体 |
| 有効化の取り消し | – | 不可 |
※表の内容は Microsoft Learn の公開仕様と管理ガイドをもとに整理しています。 (Microsoft Learn)
ADごみ箱を有効化する前に知っておきたい6つの影響
フォレスト全体に効き、一度有効化すると戻せない
ADごみ箱はフォレスト全体の optional featureです。ドメイン単位やサーバー単位で「まず一部だけ試す」という入れ方はできません。しかも一度有効化すると無効化はできません。変更管理の観点では、単なる便利機能の追加ではなく、フォレスト設計に関わる不可逆変更として扱うべきです。 (Microsoft Learn)
さらに、ADAC 自体も「すべてのドメイン コントローラーに構成変更がレプリケートされるまで、ADごみ箱は完全には機能しない」と案内しています。つまり、有効化そのものよりも、有効化を流してよいフォレスト状態かどうかのほうが重要です。 (Microsoft Learn)
機能レベルだけでなく、レプリケーション健全性も前提条件になる
現在の Microsoft Learn では、ADごみ箱の前提条件としてフォレスト機能レベルとドメイン機能レベルが Windows Server 2008 R2 以上であることが示されています。これを満たしていないなら、まずそこからです。 (Microsoft Learn)
ただし、実務で見落としやすいのは機能レベルよりレプリケーションです。長期未同期のドメイン コントローラーがあると、tombstone lifetime を超えたあとに残留オブジェクト問題が起きることがあります。ADごみ箱を入れる前に、「止まっている DC がないか」「長く倉庫に置かれた DC がないか」を確認しておくほうが安全です。 (Microsoft Learn)
NTDS.DIT とディスク使用量は確実に増える
ADごみ箱を有効化すると、Microsoft はフォレスト内のすべてのドメイン コントローラーで NTDS.DIT のサイズが増えると案内しています。削除されたオブジェクトとその属性データを保持するため、ディスク使用量は時間とともに増えます。容量設計の公式ガイドでも、AD Recycle Bin を有効にするとデータベース サイズに影響し得るとされています。 (Microsoft Learn)
この影響は、特に次のような運用で大きくなりやすいです。人事異動が多く、退職者アカウントや端末アカウントを定期削除する環境。OU 再編が多い環境。Exchange や独自アプリで属性が厚い環境です。「削除件数は少ないから平気」とは限らず、1 オブジェクトあたりの属性量でも効くと考えたほうが実務的です。 (Microsoft Learn)
まず確認したい2つの値
ADごみ箱の保持設計で特に重要なのは、tombstoneLifetime と msDS-DeletedObjectLifetime です。msDS-DeletedObjectLifetime が未設定なら、deleted-object lifetime は tombstoneLifetime を引き継ぎます。Windows Server 2003 SP1 以降で新規作成されたフォレストでは tombstoneLifetime の既定が 180 日ですが、古いフォレストをアップグレードしてきた環境では実効値が 60 日のまま残っている可能性もあります。「普通は 180 日」と思い込まず、実値を見て判断するのが正解です。 (Microsoft Learn)
$dn = "CN=Directory Service,CN=Windows NT,CN=Services,$((Get-ADRootDSE).configurationNamingContext)"
Get-ADObject $dn -Properties tombstoneLifetime,'msDS-DeletedObjectLifetime' |
Select-Object tombstoneLifetime,'msDS-DeletedObjectLifetime'msDS-DeletedObjectLifetime が空欄なら、実効の復元可能期間は tombstoneLifetime と同じです。ここを確認せずに有効化すると、「思ったより短い」「逆に長すぎて容量が増えた」というズレが起きやすくなります。 (Microsoft Learn)
復旧できるのは「有効化後」「保持期間内」「対象に応じた手段があるもの」だけ
ADごみ箱で戻せるのは、有効化後に削除されたオブジェクトだけです。有効化前に消えたものは対象外です。また、deleted-object lifetime を過ぎたオブジェクトは recycled-object となり、ADAC には表示されず、ADAC からは復元できません。 (Microsoft Learn)
さらに見落としやすいのが、GUI で戻せる範囲です。ADAC はドメイン パーティションの復元には強い一方、Configuration、Domain DNS、Forest DNS パーティションの削除オブジェクトは GUI だけでは扱えず、Restore-ADObject が必要です。ユーザーや OU の誤削除対策としては強力でも、AD 統合 DNS や構成情報まで全部 GUI で戻せるわけではない点は、導入前に期待値を合わせておくべきです。 (Microsoft Learn)
OU をまとめて戻すときは、親から順に復元する前提で考える
「OU を誤削除したら、配下のユーザーや子 OU もワンクリックで丸ごと戻せる」と思っていると、実際の復旧時にハマります。Microsoft は、ADAC ではネストしたツリーを単一操作で確実に復元できないと明示しており、親 OU を先に戻し、そのあと子 OU、さらにその子、という順番を推奨しています。 (Microsoft Learn)
実務上の失敗パターンは、「親がまだ Deleted Objects にあるのに子だけ先に戻そうとして失敗する」ことです。OU 単位の削除事故があり得る環境では、親子関係を意識した復旧手順をあらかじめ文章化しておくと、深夜対応でも迷いにくくなります。 (Microsoft Learn)
大規模グループやリンク数が多いオブジェクトでは、削除そのものが重くなることがある
通常のユーザーやコンピューター削除では大きな問題になりにくい一方、メンバー数が極端に多いグループなど、forward link を大量に持つオブジェクトは別です。Microsoft のトラブルシューティング情報では、member などのリンクが多いオブジェクトを削除すると、レプリケーション失敗が起きることがあり、問題が見え始めるリンク数は5 万程度からでも起こり得るとされています。 (Microsoft Learn)
しかも ADごみ箱が有効な場合、この種の問題は「削除直後」ではなく、deleted-object が recycled-object へ移るタイミングで表面化することがあります。大規模グループ整理や RODC 関連の削除を定期的に行う環境では、ADごみ箱の是非そのものというより、削除設計と事前検証が必要だと考えるべきです。 (Microsoft Learn)
どんな環境なら ADごみ箱を前向きに判断しやすいか
| 状況 | 判断の目安 |
|---|---|
| 誤削除の主対象がユーザー、グループ、コンピューター、OU | 前向きに検討しやすい |
| 機能レベルが要件を満たし、レプリケーションも安定している | 前向きに検討しやすい |
| 各 DC のディスクに余裕がある | 前向きに検討しやすい |
| GUI だけで DNS/Configuration パーティションまで戻せると思っている | 期待値の修正が必要 |
| 長期未同期の DC や倉庫 DC がある | 先に是正したい |
| 数万メンバー規模のグループ削除があり得る | 先に検証したい |
| バックアップ手順が曖昧 | ADごみ箱より先に整備したい |
※判断基準は Microsoft Learn の仕様と運用上の前提を、現場向けに落とし込んだものです。 (Microsoft Learn)
ADごみ箱の代替策と併用策
期限切れや未有効化環境では、authoritative restore が必要になる
ADごみ箱が未有効化の環境、または復元対象が保持期間を過ぎている環境では、削除オブジェクトの復旧はバックアップを使った authoritative restoreが中心になります。Microsoft のユーザー アカウント管理ガイドでも、ADごみ箱が有効でなければ、対象アカウントを含む AD DS バックアップを使って authoritative restore が必要だと案内されています。 (Microsoft Learn)
つまり、ADごみ箱は便利ですが、古い削除や未設定環境まで救う万能策ではありません。導入判断では「入れるか、入れないか」ではなく、「入れたうえで、入っていない場合の復旧手段も残す」が正解です。 (Microsoft Learn)
障害・侵害・フォレスト全体の問題には、バックアップと forest recovery が必要
フォレスト障害の復旧は、少なくとも各ドメインで 1 台以上のドメイン コントローラーを信頼できるバックアップから復元する前提です。これは ADごみ箱の守備範囲ではありません。Azure Backup の AD ガイドも、削除オブジェクトには AD Recycle Bin を使えるが、破損・侵害・災害に備えるには明確な DR 計画とバックアップが必要だとしています。 (Microsoft Learn)
仮想化基盤のスナップショットだけに頼るのも危険です。Microsoft は、virtualized domain controller safe restore は System State backup や AD DS Recycle Bin の代替ではないと明記しています。仮想 DC を使っている環境ほど、「スナップショットがあるから大丈夫」と考えないほうが安全です。 (Microsoft Learn)
そもそも削除しにくい運用を作る
誤削除対策は、復旧のしやすさだけでなく、削除そのものを減らす運用とセットで考えると効果が高くなります。Microsoft のユーザー管理ガイドでも、削除前にいったんアカウントを無効化するのがベスト プラクティスとされています。削除ではなく「無効化 + 保留期間」を挟むだけで、事故の多くは未然に止められます。 (Microsoft Learn)
あわせて、重要なユーザー、グループ、OU には Protect object from accidental deletion を使う価値があります。Microsoft Learn では、この設定は削除だけでなく、属性を変更できる権限を持つユーザーが保護を解除しない限り、別 OU への移動も防ぐと説明されています。ADごみ箱は「戻す」仕組み、誤削除防止は「消させない」仕組みとして、両方を使い分けるのが現実的です。 (Microsoft Learn)
結局、ADごみ箱は有効にすべきか
結論として、ユーザー・グループ・コンピューター・OU の誤削除対策を主目的にするなら、ADごみ箱はかなり有力です。削除後の復旧を、バックアップ前提の重い作業から、より扱いやすい運用に寄せられるからです。反対に、レプリケーションが不安定、ディスクが逼迫、DNS や Configuration パーティションの復旧も GUI で済むと思っている、大規模グループ削除が多い、という環境では、そのまま有効化すると期待外れになりやすいです。 (Microsoft Learn)
いま判断するなら、次の順番で進めるのが堅実です。
- まず FFL/DFL と
tombstoneLifetime、msDS-DeletedObjectLifetimeの実値を確認する。 - 次に、全 DC のレプリケーション健全性とディスク余力を確認する。
- 主な復旧対象が user/group/computer/OU なら、有効化を前向きに検討する。
- DNS/Configuration パーティションの復旧や巨大グループ削除があるなら、
Restore-ADObjectを含む手順を先に整備する。 - 有効化後も、System State バックアップ、authoritative restore、forest recovery の手順は残しておく。
この5つを押さえられるなら、ADごみ箱は「入れるか迷う機能」ではなく、誤削除対応を現実的にするための基盤機能として扱いやすくなります。
コメント