現在、Windows Server 2008 のAD設計のコース準備をしています。

そこでこんな記述があって悩んでいました。

・AD DSを復元するときの考慮事項というのがあり、削除後にAuthoritative restoreによって復元したユーザーオブジェクトのグループメンバシップの復元は、いつLVRを実装したかによって異なる

ん？なにが言いたいの？ということで調べてみるとこんな情報が・・

Authoritative restore issue with LVR enabled attributes

障害回復: Active Directory ユーザーとグループ

これらの情報から整理すると

■復元における問題

Authoritative restoreによる復元ではオブジェクトが持つ前方リンクを元の状態にきちんと戻すことができない。この問題は[W2000]のフォレスト機能レベルで運用していたフォレストを[W2003]のフォレスト機能レベルにアップした場合にのみ起こる。

特に、削除されたグループメンバーシップを回復するためにグループオブジェクトのAuthoritative restoreを行っても、[W2003]のフォレスト機能レベルにアップグレードする前に作成されたグループメンバシップ情報は復元されない

■シナリオ

AD管理者は１つのグループのメンバーから複数のユーザーを削除した(ユーザー自体の削除ではない。あくまでもグループメンバーからの削除)。ところがこれがミスオペだとわかり、管理者は元の状態に戻さなければならなくなった。

■管理者はどうすれば良いか

この状況から回復させる一つの方法は次の通り。

本番環境からは隔離された別のマシンにシステム状態の復元を行う。こうすれば、他のDCから複製により上書きされることは無い。

そして、ポイントはグループメンバーシップを復元するためにNtdsutilによって作成されるldfファイルを使用することだ。Ntdsutilによって作成されるldfファイルを本番環境に転送し、そして復元のためにインポートする。

■そもそもこんなことが起こらないようにする

フォレスト機能レベルがWindows server 2003以前に作成されたグループはLVRが有効になっても新しいレプリケーション メタデータが自動的に適用されるわけではない。あくまでもフォレスト機能レベルがWindows server 2003になってLVRが有効の状態でグループにユーザーを追加した時に、新しいレプリケーション メタデータが自動的に適用されることになる。

ここが問題になる。ということはAuthoritative restoreによる復元でグループを復元したとしても、ユーザー情報は復活しないということになる。

ということで、フォレスト機能レベルをWindows server 2003に上げたら、全てのグループのユーザーを入れなおす作業をしておいたほうがいいことになります。これはldifdeコマンドで簡単にできるでしょう。

グループのユーザーの数が少なければ手作業でもそんなに大変ではないのであまり問題にはならないかな？

あと2008ならADデータベースマウントツール（dsamain.exe）を使うことによって過去のスナップショットからグループの情報を参照できるので最悪の事態は避けられると思われます。

Windows Server 2008 R2テクノロジ入門 (マイクロソフト公式解説書) という書籍を読んでいたら、管理されたサービスアカウントなるものが新機能として追加されたことが書いてありました。これは知らなかったので調べてみました。

参考：サービス アカウントの新機能

Windows Server 2003 よりサービス専用アカウントとして、Local Service、Network Serviceというアカウントが追加されセキュアでローカルなサービスアカウントを使用できるようになりました。

よって、Windows Server 2003では

1. Network Service
2. Local Service
3. 自分で作成したサービスアカウント
4. Local System

の順にサービスアカウントを適用して試すことが推奨となっていましたね

Windows Server 2008 R2の新機能として、「管理されたサービス アカウント」と「仮想アカウント」の 2 種類の新しいサービス アカウントを使用できるようになりました。

管理されたサービス アカウント

ここでのポイントは3の自分で作成するサービスアカウントのことを指しています

例えば今までは、ドメインアカウント（もしくはローカルアカウント）を使用してサービスアカウントにしますが、ユーザー権限の割り当てを使用して最低限のセキュリティ設定を行う必要がありました。更に、パスワードの問題がありました。それはサービスアカウントのパスワード変更には多大な労力が発生していたことです。仮にサービスアカウントのパスワードを変更しようと思うと、ADのユーザー設定からパスワードを変更し、サービスの画面からサービスアカウントのパスワードを変更する必要がありました。そのようなことがあるので、多くの場合は無期限パスワードにしていた経緯があります。しかし、これはセキュリティの面から考えると脅威として認識しておく必要がありました。

今回の新機能である、「管理されたサービス アカウント」を使用すると、パスワードは定期的に自動変更されます。このメリットとして、ADのユーザーアカウントとサービスのパスワードの変更が自動的に反映されることになります。さらに対話的なWindows ログオンに使用することができないので、セキュリティ的にも強固になります。

作成方法

ADユーザーとコンピューターを使用して作成することはできません。このアカウントはPowerShellを使用する必要があります。

具体的なコマンドとしては

New-ADServiceAccount <アカウント名＞

プロパティを見るには

Get-ADServiceAccount <アカウント名＞

オブジェクトはADユーザーとコンピューターのManaged Service Accountコンテナに存在します。

このアカウントをドメインメンバーで使用するためには

Install-ADServiceAccount –Identity ‘<アカウント名＞’

を使用してインストールする必要があります。そして、通常のユーザーオブジェクトと同様に設定することができます。その際のパスワードはNull（空欄）にする。

仮想アカウント

参考URLを読むと次のように記載がありました。

以下抜粋

仮想アカウントを使用すると、パスワード管理を行わなくても済み、ドメイン環境内のコンピューターのアカウントの資格情報を使用してサービスがネットワークにアクセスできるようになるため、サービス管理が簡単になります。

ここまで

これって、何を言っているの？ということで、よくわからないのでいろいろ調べてみると・・・・以下のようなことがわかりました。

Windows7とWindows Server 2008 R2では仮想アカウントというアカウントが導入された。

このアカウントは、ビルトインの「Network Service」アカウントを使用するサービスのログを追跡できるようにすることを目的としたものである。

「Network Service」アカウントはW2003で導入された。このアカウントは従来の「LocalSystem」アカウントに代わるものとして使用され、ローカルマシンに対しては完全なローカルシステム権限を持ち、ネットワークアクセスに関してはコンピュータアカウントの資格情報を使用する。

ところで、「Network Service」アカウントを使用するサービスが、数多くマシン上に構成されている場合、各サービスが実際何のリソースにアクセスし、何の操作を実行しているのか追跡することはほぼ無理である。なぜなら、それらすべてのサービスが「Network Service」アカウントを使用しているため、どのサービスのログか区別できないからである。

仮想アカウントは、サービスのインスタンスごとに一意となる「Network Service」アカウントの作成をエミュレートする。つまり、同じサービスであっても別インスタンスであれば、それぞれ別の「Network Service」アカウントとなる形である。これによりサービスごとの監査やログ追跡が容易になる。

ということになりますね。

システム要件

Windows Server 2008 R2 にドメインコントローラーがインストールしてあること。ただし、必ずしも最新のドメイン機能レベルでなくてもよい。ポイントとしてはR2の新機能が使用できるようにスキーマ拡張が行われていればよい。

＊例外としてはDCがR2以外で、R2のスキーマ拡張が行われている場合は「管理されたサービスアカウント」を使用することはできるが、定期的なパスワード変更などは行われないので手動で行う必要があるとあるが、これって無理では（DCで変更されたパスワードが判らないと思う）・・・

まとめ

「管理されたサービスアカウント」は、自分で作成するサービスアカウントのセキュリティ機能向上を目的として使用され、「仮想アカウント」はNetwork Serviceアカウントの監査やログ追跡を容易にさせる目的で使用される

Technet フォーラム や 国井さんのブログを読んでいて、AdminSDHolderについての話が書いてありました。おはずかしながら、私はその存在自体知りませんでした。そもそもAdminSDHolderって何から勉強してみました。

シナリオから

まずはOU1というOUを作成し、User1とUser2が存在します。OU_Adminsグループに対して委任の設定を行い、OU1の管理者とする。その際にOU1内のユーザーパスワードリセットの権限を付与した。

ou1adminはOU_adminsのメンバーなのでOU1の管理者である。よって、User1及びUser2のパスワードリセットができるはず・・・

しかし、実際にはUser2のパスワードリセットができない

このようなシナリオがあります。

これはなぜ？ということろから話を始めます。

実はUser2がAccount Operatorsのメンバーになっていることが原因なんです。

これは管理者グループのメンバーに対して、1時間に1回PDCエミュレーターがSDPROP(Security Descriptor PROPagator)という機能を利用してAdminSDHolderオブジェクトのアクセス許可を管理者グループのアクセス許可にコピーすることによるものです。

＊AdminSDHolderオブジェクトは、管理者グループに対するアクセス許可を管理しています。そのことから管理者グループのアクセス許可設定は、通常のアクセス許可画面から設定することができません。

AdminSDHolderオブジェクトはActive DirectoryドメインパーティションのSystemコンテナの中にあります。そのセキュリティ設定が管理者グループのアクセス権のひな型になるのです。

よって、このアクセス権が管理者グループにコピーされます。

では管理者グループとは一体どのグループかというと、グループの属性にAdminCountという属性がありますが、この属性値が1になっているグループが対象になります

これは国井さんのブログで紹介されていました～

ADFind
http://joeware.net/freetools/tools/adfind/index.htm

このようなコマンドをたたくと

Using server: london.contoso.com:389
Directory: Windows Server 2008 R2

dn:CN=Administrator,CN=Users,DC=contoso,DC=com

dn:CN=Administrators,CN=Builtin,DC=contoso,DC=com

dn:CN=Print Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Backup Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Replicator,CN=Builtin,DC=contoso,DC=com

dn:CN=krbtgt,CN=Users,DC=contoso,DC=com

dn:CN=Domain Controllers,CN=Users,DC=contoso,DC=com

dn:CN=Schema Admins,CN=Users,DC=contoso,DC=com

dn:CN=Enterprise Admins,CN=Users,DC=contoso,DC=com

dn:CN=Domain Admins,CN=Users,DC=contoso,DC=com

dn:CN=Server Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Account Operators,CN=Builtin,DC=contoso,DC=com

dn:CN=Read-only Domain Controllers,CN=Users,DC=contoso,DC=com

dn:CN=clientpush,OU=SCCM,DC=contoso,DC=com

dn:CN=user2,OU=OU1,DC=contoso,DC=com

dn:CN=ac1user,OU=OU1,DC=contoso,DC=com


16 Objects returned

このような結果が・・・ユーザーも入っていますが、管理者グループの一員になるとAdminCount=1となり、アクセス権もコピーされるということになります。

ちなみにUser1とUser2の属性を比べてみます

User2のadminCount属性が1になっていることが確認できます。

このような理屈によって、上記シナリオのような現象が起きているのですね！

さて、次のシナリオとしてはOU_Adminsの権限が管理者グループのユーザーに対して継承されないので、これをどうするか？

どうしてもOU管理者に管理者グループのユーザーも管理させたい場合にはAdminSDHolderに対して権限を付与する必要があります。今回の例ではこんな感じですね。

dsacls.exe CN=AdminSDHolder,CN=System,DC=contoso,DC=com /g contosoou1_admins:CA;”Reset Password”;

ただし、考慮しなくてはいけないのが全ての管理者グループにこの権限がコピーされることです。更にadministratorがもしこのOU1に存在する場合は、administratorのパスワードリセットもできてしまうということ。このようなリスクを認識して運用する必要がありますね。

ですので、通常はこのAdminSDHolderの権限変更は行わないと考えます。

更に注意点があります。

今回の例では、User2をAccount OperatorsのメンバーからはずせばUser1と同様にパスワードリセットができるはずですが、これができません。なぜなら、adminCount属性が変わらず、継承もブロックされたままだからです。

委任されたアクセス許可を利用できず継承が自動的に無効になる
http://support.microsoft.com/default.aspx/kb/817433/ja

一旦管理者グループに入れたユーザーは、単に管理者グループから削除しても元に戻らないので、上記KBに書いてあるような方法を使用して元に戻す必要があります。

バックアップの有効期限についての考察をしてみます

参考：
削除された Active Directory オブジェクトを復元するシナリオの概要
http://technet.microsoft.com/ja-jp/library/dd379542(WS.10).aspx

バックアップ有効期間の値は、削除されたオブジェクトの有効期間が格納されている msDS-deletedObjectLifetime 属性と、リサイクルされたオブジェクトの有効期間が格納されている tombstoneLifetime 属性の 2 つの属性の小さい方の値になります。

よって、デフォルトでは180日がバックアップの有効期間ということになります。（ここでいう有効期間とはマイクロソフトがサポートするという意味）

しかし、裏技的な方法で180日が経過したバックアップでも復元は可能です。それは国井さんのブログで紹介されていますのでそちらにお任せいたします。

Active Directory Recycle Binで救えなかったオブジェクトを救出する

例えば　Deleted Object Lifetime =3 と Tombstone Lifetime=180 の場合、削除して 4 日たったオブジェクトは既に isRecycled=TRUE であり、バックアップから復元しても本属性値は変更されません。そのため、バックアップの有効期限は 3 日となります。

逆にDeleted Object Lifetime =180 と Tombstone Lifetime=3 の場合、採取後 3 日以上のバックアップは、以前までの動作と同じ理由で有効なバックアップではありません。

ごみ箱を有効にした場合マイクロソフトとしては、Deleted Object Lifetime 期間の間に復元することを想定しているので、その期間を超えたオブジェクトの復元は推奨していないということになります。

＊Authoritative restoreには「Toggle recycled objects flag」コマンドが新設されていているので、上の例として挙げた Deleted Object Lifetime =3 と Tombstone Lifetime=180 の場合においては、このコマンドを利用することで、isRecycled 属性値を変更することでバックアップからの復元が可能と考えられます。ただし、このコマンドは利用を推奨しないコマンドとしての連絡がありました～

Active Directory Recycle Binに関してのまとめ

1. Active Directory Recycle Binを有効にするとデフォルトでは180日間は全ての属性値が入った状態でのデータベースからの復元が可能
2. 180日以後のデータベースおよびバックアップからの復元は想定していない
3. バックアップの有効期間はデフォルト180日
4. マイクロソフトでは180日以上たったバックアップからの復元は推奨していない

ということかな

特に1番が大きなメリットになります。今までは全ての属性値を含んだオブジェクトを復元しようとすると、Authoritative restoreを実行するためにディレクトリ サービス復元モード (DSRM) による起動が必要だったのでそのためのダウンタイムと、復元オブジェクトが存在するバックアップデータが必要でした。これらの作業を行うことなしに完全復旧ができるのはいいですね。

ふ～、これでActive Directory Recycle Binの話題は一旦終了します。

Active Directory Recycle Binに関して深掘りして調査してもらいました。その結果を書いておきます。

オブジェクトが完全に削除されるまでの期間

• ゴミ箱が無効な場合には Tombstone Lifetime
• ゴミ箱が有効な場合には Deleted ObjectLife time +Tombstone Lifetime

となります。

それぞれの属性は

• Deleted Object Lifetime (msDS-deletedObjectLifetime 属性)
• Tombstone Lifetime (tombstoneLifetime 属性)

となります。

ゴミ箱が無効な場合、オブジェクトが削除されるとすぐに isDeleted=TRUE 、isRecycled=TRUE の状態になります。ここから Tombstone Lifetime (既定で 180 日) が経過した後のガベージ コレクションにてデータベースから削除されます。

ゴミ箱が有効な場合、オブジェクトが削除されると isDeleted=TRUE 、isRecycled は設定されません。ここから Deleted Object Lifetime (既定で 180 日) を経過した後、isRecycled=TRUE が設定されます。

そこからさらに Tombstone lifetime (既定で 180 日) が経過後のガベージ コレクションにてオブジェクトはデータベースから削除されます。

Windows Server 2008 R2ではmsDS-deletedObjectLifetime属性やtombstoneLifetime属性は既定ではNULLになっています。既定でNULLになっているのでTombstone Lifetime (tombstoneLifetime 属性)はハードコートされた180日が設定されているということになります。

ではActive Directory Recycle Binを有効にした場合Deleted Object Lifetime (msDS-deletedObjectLifetime 属性)がNULLで設定されていますが、削除されたオブジェクトの有効期間は、廃棄済みオブジェクト (Tombstone) の有効期間の値に設定されますので、結果的に180日が使用されることになります。

設定を変更するにはPowerShellを使用するのが推奨となります

削除済オブジェクト の ライフタイム を変更するには以下のコマンドを使用

Set-ADObject -Identity“CN=Directory Service, CN=Windows NT,CN=Services,CN=Configuration,DC=mydomain,DC=com”-Partition“CN=Configuration,DC=mydomain,DC=com”-Replace:@{“msDS-DeletedObjectLifetime”= 60}

リサイクル済オブジェクトのライフタイムを変更するするには以下のコマンドを使用

Set-ADObject -Identity“CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=mydomain,DC=com”-Partition“CN=Configuration,DC=mydomain,DC=com”-Replace:@{“tombstoneLifetime”= 365}

ここで注意しなくてはいけないのが、リサイクル済オブジェクトのライフタイムであるTombstone Lifetime (tombstoneLifetime 属性)のみ変更した場合は、Deleted Object Lifetime (msDS-deletedObjectLifetime 属性)はNULLのままなので、結果的に削除済オブジェクト の ライフタイムも同じ値になるということです。

参考：

付録 A: Active Directory のごみ箱の追加作業
廃棄済みオブジェクト (Tombstone) の有効期間および削除されたオブジェクトの有効期間を変更する
http://technet.microsoft.com/ja-jp/library/dd392260(WS.10).aspx