こんにちは、System Center サポート部の石井です。

コンピューターのベアメタル リカバリー (BMR) バックアップを取得するというのは、昨今どのサーバーにおいても重要です。タイトルには DPM とありますが、DPM に限らず、様々な形で実施いただいていることかと存じます。

今回は、BMR をどの程度の頻度で取ったほうがいいのかという観点からご説明します。


    ご参考: 前回のポストでは、ベアメタル リカバリー (BMR) の仕組みやベストプラクティスについてご紹介しています。併せてご参考下さい。

    [DPM] ベアメタル リカバリー (BMR) バックアップの仕組みとベストプラクティスについて
    http://blogs.technet.com/b/systemcenterjp/archive/2012/10/10/3525106.aspx

 

- 要点: コンピューター パスワードを注意したバックアップの必要性について

BMR のバックアップの時、注意すべきなのは OS のコンピューター パスワードの更新です。

ドメイン傘下のコンピューターは、それぞれのマシンごとに 30 日に 1 度、コンピューター パスワードの更新を行っています。
この動作は自動的に行われるので、ユーザーが普段使っていて通知がされたり目に見えたりということが無いので意識しづらいものです。

BMR のリストアの際、コンピューター パスワードが変更されてしまっていると、ドメイン認証が行えない状態となり、ドメインへの再参加が必要となります。
通常、再参加で問題がおきることは少ないのですが、再参加に伴い問題が生じると、最悪の場合、サーバー アプリケーションが使えない状態となってしまい再構築が必要となりますので、注意が必要です。
今回は、このようなトラブルを避けてバックアップをするための情報をご紹介します。


- コンピュータ パスワード変更の罠: BMR バックアップのリストア時、ドメイン ログオンができない問題について

コンピューターごとに保持するパスワード変更前のバックアップ データのリストアを行った場合には、「ドメイン コントローラーとの信頼関係が失敗しました」と出て、ログオンが出来ません。
結果、一度ワークグループに戻し、ドメインに再参加する必要性が発生します。

BMR バックアップをつい 2 日前にとったとしても、コンピューター パスワードのリセット動作が 1 日前に行われた場合、2 日前のデータのリストアを行うと本問題が発生します。

補足:
ドメインに所属するコンピューター毎に保持しているコンピューター パスワードは、現在のものと過去 1 つのもの、あわせて 2 世代分となります。
ただし、ドメイン コントローラーで認証可能な現行のパスワードは現行の 1 つのみとなります。

BMR  リストアにて認証がうまくいかない場合の例:
--------------------------------------------------
1. コンピューターの BMR バックアップを取得。(新パスワード:P1, 旧パスワード:P0 を保持)
 -> このとき、DC では P1 を用いて認証している。
2. コンピューター パスワードの更新が実行される。(新パスワード:P2, 旧パスワード:P1 を保持)
 -> この時点で、DC では P2 を用いないと認証できない。
3. BMR リストアを実行。(新パスワード:P1, 旧パスワード:P0 を保持)
 -> DC では P2 を要求するが、リストアしたコンピューターは P1 と P0 しかもっておらず、認証できない。
--------------------------------------------------

※ 各コンピューターにて旧パスワードを保持する目的は、ドメイン コントローラー自体のリストアを行い、旧パスワードでしか認証ができなくなった場合への対応となります。

- 対策: コンピューター パスワードの変更を意識したバックアップ方法

BMR バックアップを取得する前に、コンピューター パスワードをリセットすれば、以後 30 日は自動的にコンピューター パスワードがリセットされない状態となります。
コマンドを実行する必要があるのは、バックアップ対象の各マシンです。


コンピューター パスワードの変更コマンド例:

----------------------------------------------
Nltest /SC_CHANGE_PWD:<ドメイン名>
----------------------------------------------


コマンド実行後、以下のようなエントリーが出れば成功です。(OS バージョンによって若干差がある可能性がありますが、Success の文字列や、エラー コード 0 = 成功 を意味している内容であれば問題ありません。)

----------------------------------------------
フラグ: 0
接続 Status = 0 0x0 NERR_Success
コマンドは正常に完了しました
----------------------------------------------

このコマンドを実行した上で、BMR バックアップを取得いただければ、その後 30 日以内は本バックアップのリストアによってコンピューター パスワードの問題が生じないことが保証されます。

※ DPM など、スケジュールにてバックアップを作成するソフトに合わせて、バックアップ スケジュールの数分前に上記コマンドをタスク スケジューラーで定期実行するよう設定しておくと便利です。(バックアップ対象の各サーバーで設定します。)

タスク スケジューラーに登録するバッチファイル例:
----------------------------------------------
Echo [%date% %time%] >> nltest.log
nltest /SC_CHANGE_PWD:<ドメイン名> >> nltest.log
exit
----------------------------------------------
※ パスワードの更新を行った場合には、イベント ログ等には記録はされません。このため、タスク スケジューラーに登録いただく際に、コマンド実行結果をファイル出力するよう工夫をしています。
ログが不要な場合、"nltest /SC_CHANGE_PWD:<ドメイン名>" コマンド 1 行で問題ありません。

-  リストア時問題発生した場合: コンピューター パスワードが変更する前の状態のマシンをリストアした場合の対応について

コンピューター パスワード変更前の BMR バックアップのデータをリストアした場合にはドメインに再参加する必要があります

ここで懸念されるのは、ドメイン再参加、あるいはバックアップ・リストア時における様々な対応過程で、AD 上のコンピューターの SID が変化してしまうという事で問題が生じるパターンがあるということです。

SID というのは、AD 上のコンピューターやユーザー アカウントと紐づける一意 (ユニーク) な ID です。
例えば、サーバー A のコンピューター アカウントからの操作を許可するため、サーバー B 上のローカル Administrators グループに、サーバー A のコンピューター アカウントを追加するとします。
この際に、サーバー B の Administrators には、実際にはサーバー A の名前ではなく、サーバー A に対応する SID が保存されています。

さて、ここでサーバー A の SID が何らかの作業、例えばバックアップ リストア時に誤って AD からサーバー A のコンピューター アカウントを削除してしまったとします。
サーバー A からは、ドメイン ログオン出来なかったので、一度ワークグループに戻してドメインに再参加しましたので、サーバー A のコンピューター アカウントは再作成されています。
その場合、サーバー B の Administrators には、サーバー A の旧 SID が登録されているのみであり、同じ名前の AD 上のサーバー A のコンピューター アカウントは別物であると認識されます。
このため、サーバー A とサーバー B のアプリケーション間の通信がうまく出来ず、サーバー・クライアント型のアプリケーションがうまく動作しない、といった問題となります。

原則として、AD のコンピューター アカウントを削除・新規作成しない限りはドメインの再参加によって SID が変化することはありません。
AD 上にコンピューター アカウントが存在している限り、例えば BMR のリストアではなく、同一名称のコンピューターを OS インストールから再構築し、ドメインに参加したとしても SID は変化しません。
問題がおきた事例の多くはおそらく、障害に伴った復旧作業の過程で、ドメイン AD 上のコンピューター アカウントを削除してしまった (消滅してしまった) といった類であると考えられます。

このことから、SID の変化がおきることは極めて少なく、ドメイン再参加によって問題無く OS とアプリケーションが使用可能であるという事例が多い状況です。
しかし、何らかのきっかけで、SID が変化してしまった場合には以下のように、あらゆるコンピューター アカウント関連の認証情報の再設定が必要となる可能性があります。

1. 他コンピューターのローカル セキュリティ グループ上に設定されている、リストアしたコンピューターのアカウント

2. 他コンピューターの SQL サーバーのログインなど、アプリーション固有の認証設定
3. DCOM のセキュリティ権限
4. AD のコンテナ上のアクセス許可

アプリケーションによっては、様々な内部動作から、UI 上確認が困難な箇所にてこういった認証情報を保存するものが存在しますので、ドメイン再参加により、万が一 SID 変化が生じると個別対応が困難な状況となります。
上記のような箇所を手動で変更し、運良く一見、動作するようになったとしても、今後、正常動作し続ける保証がどこにもない、という点も不安要因です。

このため、可能な限り、コンピューター パスワードが失効しない状態でのバックアップ・リストアのプランを立てていただきますようお願いいたします。

補足: コンピューター パスワード失効に伴うドメイン再参加のサポートについて

コンピューター パスワード失効に伴うドメイン再参加をサポートするかどうかはアプリケーションに依存しますが、原則としてはドメイン再参加にて SID が変わらない事が前提となっています。
SID が変化した場合には、アプリケーションにて想定していない障害発生状態となりますため、最悪の場合、アプリケーションの再構築が必要です。


- ドメイン内の単独の (あるいは一部の) コンピューターのみ、コンピューター パスワードの自動変更を無効化する方法について

コンピューター パスワードの更新は、AD の既定の設定では 30 日に一度となっています。
この更新動作を行わせたくないコンピューターについては、適宜 OU を作成の上、下記グループ ポリシーの設定を "有効" に設定して下さい。

----------------------------------------------
[コンピューターの構成]-[Windows の設定]-[セキュリティの設定]-[ローカル ポリシー]-[セキュリティ オプション]
"ドメイン メンバ: コンピューター アカウント パスワード: 定期的な変更を無効にする"
----------------------------------------------

※ 上記ポリシーは、ローカル ポリシーで個別のマシンでの設定も可能ですが、AD のポリシーにて "未定義" 状態であることが前提となります。もし AD のグループ ポリシーで、"無効" となっていた場合、ローカル ポリシーでは上書き出来ません。
また、コンピューター パスワードのクラッキングに対してのリスクが高くなるため、通常はお奨めできません。セキュリティ要件とバックアップ プランに応じてご判断ください。