こんにちは、プラットフォーム クリティカル レスポンス チームの姚 (ヨウ) です。

今日は少し前にお客様よりお問い合わせいただいた Windows Server 2008 R2 のクラスター環境で発生した事象を紹介いたします。

はじめにこの事象について説明いたします。

Windows Server2008 R2 のクラスターのファイル サーバー リソース グループにて、クラスターの共有ディスクにある既存のフォルダーをファイル サーバー リソースの共有フォルダーに追加する際に以下のエラーとなり、追加に失敗する事象です。

“共有フォルダーの準備ウィザードを完了できませんでした。具体的なエラーについては [エラー] タブを参照してください。”

 
  
  
"SMB 共有フォルダーのフラグは構成できません。この共有リソースは存在しません。"

また、該当のフォルダをエクスプローラーで共有しようとした場合も以下のエラーが発生し、共有できません。

"フォルダーを共有できません。"

さらにプロパティにて “詳細な共有” にて共有を設定しようとした場合でも以下のエラーが発生し、共有できません。

 "COM Surrogate は動作を停止しました"

この事象は、該当のフォルダの NTFS のアクセス権限に SYSTEM アカウントのアクセス権限が付与されていないことが原因で発生いたします。

Windows Server 2008 および Windows Server 2008 R2 (Windows Server 2012 については今回は除外とさせていただきます) のクラスター環境では、クラスター サービスはクラスター ノードの SYSTEM アカウントの権限で起動/動作します。

ファイルサーバーリソースの共有フォルダーを共有させる場合、クラスター サービスが共有処理を実施しますが、SYSTEM アカウントが該当のフォルダーに対してアクセス権限がないために、正常にフォルダを共有できず、今回の事象が発生します。

この事象を解消するためには、SYSTEM アカウント、SYSTEM アカウントが所属する以下のグループまたはこれらのグループが所属するグループに対して読み取り以上の権限を付与することによって解消できます。

BUILTIN\Administrators

Everyone

NT AUTHORITY\Authenticated Users  

また、別のパターンとして、すでに作成されたファイル共有リソースの共有フォルダーから SYSTEM アカウントのアクセス権限を削除し、再度ファイル共有リソースをオンラインにしようとした場合にも、以下のエラーが発生し、リソースが障害になります。

 “操作は失敗しました。”

この場合、リソースを正常にオンラインにするためには同じように該当の共有フォルダーに対して SYSTEM アカウントへのアクセス権限を付与する必要があります。

お話させていただきました事象は Windows Server 2008 のクラスタ環境でも同様に発生することを検証環境にて確認しております。

Windows Server 2003 のクラスター環境では発生しません。

なお、Windows Server 2003 のクラスター環境にて、共有フォルダーの NTFS アクセス権限から SYSTEM アカウントを削除し、フォルダへのアクセスを細かく制限している環境を アクセス権限を含めて WindowsServer 2008 / R2 のクラスター環境に移行した場合、今回の事象が発生する可能性がありますので、ご注意いただければと思います。

- 参考情報

Description of the failover clustersecurity model in Windows Server 2008

https://support.microsoft.com/kb/947049/en-us

Understanding Requirements for Failover Clusters 

https://technet.microsoft.com/en-us/library/cc771404.aspx

今日は最近複数のお客様からお問い合わせ頂いた Windows Server 2003 のストップエラーが頻発する現象についてお話しします。

インストールしているドライバも更新していないし、ハードウェアにも問題がない。それにも関わらずブルースクリーンが頻発するようになった。そんな状況に陥ったら一度、サポート技術情報 948289 を確認してみてください。

Error message on a Windows Server 2003-based computer: "Stop error code 0x00000019"

https://support.microsoft.com/kb/948289

このサポート技術情報を理解するためには、ショートファイル名を知っておく必要があります。

Windows OSで使用しているファイルシステムでは、空白などを含む長いファイル名（ロングファイル名）を扱えますが、以前の MS-DOSでは 8.3形式の短いファイル名（ショートファイル名）しか使用できませんでした。

8.3形式は、ファイル名の部分が最大8文字、拡張子が最大で3文字のファイル名の形式です。現在の Windows ではこのショートファイル名 8.3形式ではなく、ロングファイル名を使用できますが、下位互換性のためにデフォルトではロングファイル名とショートファイル名の両方が管理されています。

ショートファイル名を確認したい場合、dir /x コマンドで見ることができます。

この例ではロングファイル名 testfile1.dat のファイルを dir /x コマンドで確認すると、このファイルはショートファイル名では TESTFI~1.DAT となっている事が確認できます。このようにショートファイル名は同一フォルダ内で重複しないようにチルダ記号 ~ の後に追番を付ける形で８.３形式で作成されます。

通常の運用では問題ありませんが、一部アプリケーションソフトウェアなどで単一のフォルダー配下に極端に大量のファイルを作成してしまう場合があります。

このような場合、Windows Server 2003 ではこの追番が長くなりすぎる事を想定していないため、8.3形式に収まらず、関係ないメモリ管理領域まで破壊してしまう場合があります。結果としてプールの管理領域が破壊された事を意味するストップエラー 0x19 (BAD_POOL_HEADER) が発生してしまいます。

ブルースクリーンの左上に BAD_POOL_HEADER と表示されている事が確認できます。

この問題に対して残念ながら修正プログラムを提供しておりませんが、ショートファイル名の生成を行わないようにする事で現象を回避する事ができます。

まずブルースクリーンが頻発して起動できない場合は、起動時に F8 を押下して Windows 拡張オプションメニューを表示し、セーフモードで起動します。通常起動できるのであれば敢えてセーフモードで起動する必要はありません。

起動したらログオンを行い、コマンドプロンプトからfsutil behavior set disable8dot3 1と入力します。

あとは再起動をすればファイルシステムがショートファイル名を生成しないようになり、今までのようにストップエラーが発生しなくなります。

この現象の詳細はサポート技術情報948289 に詳しく記載されておりますので、合わせてご確認下さい。

この回避手順を行ったことでショートファイル名の作成は行われなくなりますが、この事でアプリケーションソフトウェアに予期せぬ影響などがでた場合、

fsutil behavior set disable8dot3 0 と入力し再起動すればデフォルトの状態に戻すことができます。

補足

この現象が発生した際、あらかじめメモリダンプを出力するように設定している場合はメモリダンプファイルが出力されます。このダンプファイルをデバッカーで解析すると、前述の現象が発生している事が簡単に確認でき、サポート技術情報948289 に合致しているか確認する事ができます。

まずバグチェックコードが 0x19 BAD_POOL_HEADER である事を確認します。

続けてコールスタックを確認するとプール解放中に問題が検出された事が確認でき、IRP から処理しているファイル名はロングファイル名でcore_etest_20131231255999.dmpである事が確認できます。

もう一度バグチェックコードを確認し、第２引数には問題を検出したプール領域アドレスが格納されている事を確認します。今回の例ではe142ee08 が問題が検出された領域になります。

問題が検出されたプール領域の付近を !pool 確認すると破損が検出されます。

それでは、もう少し詳細に確認していきましょう。

プール領域e142ee08 は0x68 バイト確保されている事がわかりますので、e142ee08 から内容を表示してみますと、先ほどのロングファイル名core_etest_20131231255999.dmp を変換したと考えられるCORE_E~1000005.DMP の文字列が確認できます。

しかしながら赤い部分が 0x68 バイトになりますので、この0x68 バイト分で確保したプール領域を超えて、直後の黄色の管理領域まで上書きしてしまった事が確認できます。このような状態であればサポート技術情報948289 の現象と同一であると判断する事ができます。

今日は、最近お客様からお問い合わせいただいた Windows Server 2008 Failover Cluster において発生したネットワーク障害についてお話します。

はじめに現象について説明します。

Windows Server 2008 の 2 ノード (NodeA と NodeB とします) の Failover Cluster 環境で、両ノードで、DHCP Client サービスと IPv6 を無効に設定します。
両ノードを順番に再起動すると、後に起動してくるノードがクラスタに参加できない現象が発生します。

この現象を回避するためには、DHCP Client サービスまたは IPv6 を有効にするか、両方を有効に設定する必要があります。

この現象が発生する理由について説明しますが、はじめにクラスタ ノードがクラスタ参加する際のノード間通信の設立について簡単にお話します。

Windows Server 2008 Failover Cluster ではノード間通信は、Microsoft Failover Cluster Virtual Adapter (netft.sys) を使用し、行います。
ノードがクラスタに参加するとき、以下の流れで通信を設立します。

1. Microsoft Failover Cluster Virtual Adapter に、IPv6 のおよび IPv4 のリンクローカル アドレスを設定します。
このとき、以下のような内容がクラスタ ログに記録されます。

INFO  <StartupConfig localNodeId='1' testMode='false' newCluster='false'
INFO      <ClusterName> CLSx86 </ClusterName>
INFO      <PaxosTag> 82:82:1785 </PaxosTag>
INFO      <ConfiguredNodes> (0 1 2) </ConfiguredNodes>
INFO      <NodeWeights> (0) </NodeWeights>
INFO      <Nodes>
INFO          <Node name='NODE1x86' id='1'/>
INFO          <Node name='node2x86' id='2'/>
INFO      </Nodes>
INFO      <LocalHiveFile> C:\Windows\Cluster\CLUSDB </LocalHiveFile>
INFO      <LocalHiveKey> Cluster </LocalHiveKey>
INFO      <ParametersKey> System\\CurrentControlSet\\Services\ClusSvc\Parameters </ParametersKey>
INFO      <Virtual IPv6> fe80::68f0:c2dd:c460:f67d%13:~3343~ </Virtual IPv6>
INFO      <Virtual IPv4> 169.254.1.57:~3343~ </Virtual IPv4>
INFO      <NoVersionCheck> false </NoVersionCheck>
INFO      <Cookie> c44b87ae-5519-48a5-afff-c54763b5f175 </Cookie>
INFO      <ClusterGuid> 8351ad75-0996-4635-b11f-f5af8fc70c17 </ClusterGuid>
INFO      <WitnessHiveFile> \\?\Volume{573709c3-984e-11df-83df-00155d51bb6d}\Cluster\0.hive </WitnessHiveFile>
INFO      <WitnessHiveKey> 0.Cluster </WitnessHiveKey>
INFO      <WitnessResourceId> bb70571c-3adc-4d9d-abb0-37611adf6719 </WitnessResourceId>
INFO  </StartupConfig>

また、Microsoft Failover Cluster Virtual Adapter の通信で IPv4 と IPv6 のどちらを使用するかを選出します。
このとき、以下のログが記録されます。
Microsoft Failover Cluster Virtual Adapter は自身の IPv6 (リンクローカル アドレス) を優先的に使用いたします。

INFO  [HM] Trying to select best endpoints among 169.254.1.57:~3343~, fe80::68f0:c2dd:c460:f67d:~3343~ (first pair) and 169.254.2.180:~3343~, fe80::29bd:9e63:ede9:6456:~3343~ (second pair)
INFO  [StreamDb] Route virtual fe80::68f0:c2dd:c460:f67d:~0~ to virtual fe80::29bd:9e63:ede9:6456:~0~ added

2. ノード上で別ノードと通信可能かつクラスタに使用できる物理 NIC およびその NIC の IP と別のノードの IP とのペアのルーチンを netft.sys のルーチンテーブルに登録します。
このとき、以下のような内容がクラスタ ログに記録されます。

以下のレジは、60.60.60.1 と 60.60.60.2 間のルーチンを追加しております。

INFO  [NETFT] Added route <struct mscs::FaultTolerantRoute>
INFO    <realLocal>60.60.60.1:~3343~</realLocal>
INFO    <realRemote>60.60.60.2:~3343~</realRemote>
INFO    <virtualLocal>fe80::68f0:c2dd:c460:f67d:~3343~</virtualLocal>
INFO    <virtualRemote>fe80::29bd:9e63:ede9:6456:~3343~</virtualRemote>
INFO    <Delay>1000</Delay>
INFO    <Threshold>5</Threshold>
INFO    <Priority>99</Priority>
INFO    <Attributes>1</Attributes>
INFO  </struct mscs::FaultTolerantRoute>

3. netft.sys のルーチンテーブルから最適なルーチンを選出し、このルーチンをトンネルとして Microsoft Failover Cluster Virtual Adapter のパケットを送信します。
これによって、ノード間通信が設立されます。

ノードの物理 NIC では、IPv4 か IPv6 のどちらの設定を使用しても動作は変わりません。

DHCP Client サービスを無効化に設定しますと、Microsoft Failover Cluster Virtual Adapter の DHCP 設定を実施できなくなり、netft.sys は Microsoft Failover Cluster Virtual Adapter 間の IPv4 の通信ができないとして判断いたします。
IPv6 を無効化に設定しますと、Microsoft Failover Cluster Virtual Adapter 間の IPv6 の通信ができなくなります。

DHCP Client サービスと IPv6 がどちらかが有効であれば、ノード通信が可能なので、問題はありません。
しかし、DHCP Client サービスおよび IPv6 を同時に無効に設定したら、ノード間 (厳密に言えば netft.sys 間) の通信ができなくなりますので、クラスタ ノードの参加に失敗いたします。

また、クラスタの参加の失敗後、該当ノードのクラスタ サービスが起動できなくなる可能性もあります。

ちなみに、私の Windows Server 2008 R2 の環境でも同じ現象を確認しております。

クラスタ ノードの設定を再度確認していただければと思います。

IPv6 を有効または無効設定する手順は以下の技術公開情報を参照ください。

Windows Vista、Windows 7、および Windows Server 2008 で特定の IPv6 (Internet Protocol version 6) を無効にする方法
https://support.microsoft.com/kb/929852/ja

- 参考情報
Windows Server 2008 Failover Clusters: Networking (Part 1)
https://blogs.technet.com/b/askcore/archive/2010/02/12/windows-server-2008-failover-clusters-networking-part-1.aspx

Windows Server 2008 Failover Clusters: Networking (Part 2)
https://blogs.technet.com/b/askcore/archive/2010/02/22/windows-server-2008-failover-clusters-networking-part-2.aspx

■ Windows 7 クライアント

次のディレクトリおよびファイルが除外されるように構成します。

	パス	対象ファイル
Windows Update 関連ファイル	%windir%\SoftwareDistribution\Datastore	Datastore.edb
	%windir%\SoftwareDistribution\Datastore\Logs	*.log *.jrs Edb.chk Tmp.edb
[セキュリティの構成と分析] で確認できるセキュリティ ファイル	%windir%\Security\Database	*.edb、*.sdb *.log *.chk *.jrs
グループ ポリシー関連ファイル	%allusersprofile%	NTUser.pol
	%Systemroot%\System32\GroupPolicy\Machine	Registry.pol
	%Systemroot%\System32\GroupPolicy\User	Registry.pol

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows
https://support.microsoft.com/kb/822158

■ Windows Server 2008 / 2008 R2 メンバー サーバー

上記表にプラスして、インストールされているアプリケーション毎の対処を行います。
今回はフェールオーバー クラスタの機能と Hyper-V サービスについてそれぞれアンチウイルス スキャン対象から除外したいファイルやフォルダをご紹介します。

フェールオーバー クラスタが稼動している場合

次のディレクトリおよびファイルが除外されるように構成します。

	パス	対象ファイル
フェールオーバー クラスタ	Q:\cluster 以下 (クォーラムがQ:\の場合)	すべて
	%systemroot%\Cluster	すべて

Antivirus software that is not cluster-aware may cause problems with Cluster Services
https://support.microsoft.com/kb/250355/en-us

Hyper-V サービスが稼動している場合

次のディレクトリおよびファイルが除外されるように構成します。

	パス	対象ファイル
既定の仮想マシン構成ディレクトリ	C:\ProgramData\Microsoft\Windows\Hyper-V	すべて
カスタム仮想マシン構成ディレクトリ	設定された場所	すべて
既定の仮想ハード ディスク ドライブ ディレクトリ	C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks	すべて
カスタム仮想ハード ディスク ドライブ ディレクトリ	設定された場所	すべて
スナップショット ディレクトリ	設定された場所	すべて
実行ファイル	C:\windows\system32	Vmms.exe、Vmwp.exe
Windows Server 2008 R2 でクラスターの共有ボリューム (CSV) と一緒にライブ マイグレーションを使用する際	C:\Clusterstorage	すべて

Error code when you create or start a virtual machine on a Windows Server 2008-based computer that has Hyper-V or on a Microsoft Hyper-V Server 2008-based computer: "0x800704C8", "0x80070037" or "0x800703E3"
https://support.microsoft.com/kb/961804

■ Windows Server 2008 / 2008 R2 ドメイン コントローラー

次のディレクトリおよびファイルが除外されるように構成します。

	パス	対象ファイル
Active Directory データベース関連	%windir%\Ntds	Ntds.dit *.log *.jrs Temp.edb Edb.chk
SYSVOL / FRS / DFS 関連	Managing Antivirus Software on Active Directory Domain Controllers https://technet.microsoft.com/en-us/library/cc816917(WS.10).aspx
DHCP 関連	%systemroot%\System32\DHCP	*.mdb *.edb *.pat *.log *.jrs *.chk
DNS 関連	%systemroot%\System32\Dns	*.log *.dns BOOT
WINS 関連	%systemroot%\System32\Wins	*.mdb *.chk *.log *.jrs

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows
https://support.microsoft.com/kb/822158

■ 参考情報

Virus scanning recommendations for Enterprise computers that are running currently supported versions of Windows
https://support.microsoft.com/kb/822158

Managing Antivirus Software on Active Directory Domain Controllers
https://technet.microsoft.com/en-us/library/cc816917(WS.10).aspx

What Anti-Virus scanning exclusions should be considered for system and servers?
https://myitforum.com/cs2/blogs/scassells/archive/2007/05/14/what-anti-virus-scanning-exclusions-should-be-considered-for-system-and-servers.aspx

Windows Server 2008 Security Guide - Overview
https://technet.microsoft.com/ja-jp/library/cc264463(en-us).aspx

Planning for Hyper-V Security
https://technet.microsoft.com/ja-jp/library/cc974516(en-us).aspx

■ 免責事項

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」

はじめまして。
Critical response team の夜間を担当しています、馬場と申します。

ドメイン管理者のみなさんは、以下のような経験をされたことはありませんか？

ドメイン コントローラのディスクが破損してしまった！
ドメイン コントローラのデータベースが破損し、起動しなくなった！
ドメイン コントローラ間で複製が長期間できておらず、ドメイン コントローラとして機能していなかった！

このような時に限ってバックアップがなかったり、バックアップ自体が破損してしまっているというような悲惨な自体が起きることがあります。 幸いなことに、正常なドメイン コントローラが 1 台でも残っていれば、Active Directory のデータはそこから複製させることが可能です。 しかし、ドメイン コントローラが破損してしまった場合、通常の DCPROMO のウィザードを使用することでドメイン コントローラを降格することができないシチュエーションが多々あります。例えばディスクが壊れてしまった場合、OS からインストールを行う必要があります。 ディスクが破損してしまったドメイン コントローラはネットワークからはいなくなっていても、ドメイン コントローラの降格を行っていないため、他のドメインコントローラはまだ問題が発生したドメイン コントローラはいると認識してしまっています。つまり、すでに存在しないドメイン コントローラの情報がいつまでも他のドメイン コントローラでは残ってしまっているのです。 このような場合には、その情報を手動で削除する必要があります。手動で削除する方法をメタデータ クリーンアップと呼びます。すでに、実施されたことがある方もたくさんいらっしゃるかもしれませんが、以下に Windows Server 2008 、Windows Server 2003 SP2 、Windows 2000 Server SP4 でのメタデータ クリーンアップの作業を動画でアップしてみたので、参考いただければと思います。

注意: 動画はあくまでもサンプルですので、詳しい手順につきましては以下の弊社技術情報をご確認ください。

ドメイン コントローラの降格に失敗した後、Active Directory のデータを削除する方法
https://support.microsoft.com/kb/216498/ja

○ Windows Server 2008

○ Windows Server 2003 SP2

○ Windows 2000 Server SP4

Critical response team の昼間を担当しています、松木と申します。

前回に引き続き、「Windows でやってみよう PKI シリーズ 2」 ですが、もう少し私の業務内容に関わりがあり、緊急対応でもお問い合わせいただきます EFS （暗号化ファイル システム）と回復エージェントについてご紹介したいと思います。 （この EFS の動作は Windows Server 2008 R2 でも動作に変更がありません。）

昨今のセキュリティ強化の一環として、メールファイルや重要なフォルダを EFS によって暗号化していただいている環境も多いかと思います。ここで使用されております EFS とは、NTFS 標準の機能となりまして、FAT または FAT32 ファイル システムではサポートしておりません。

まず、 EFS における回復エージェントの動作についてご説明させていただきたいと思います。

EFS では、以下の二つの暗号化の技術が使われています。

1. 共有鍵暗号

2. 公開鍵暗号

これらの暗号化の技術の詳細は別途ご確認いただければ幸いです。（話がそれ過ぎるので暗号化の詳細については次回とさせて下さい。）

それぞれの暗号化技術の概念は読んで字のごとく、

1. 鍵を共有する。

2. 公開鍵と秘密鍵を分けて使用する。公開鍵のみ第三者に公開する。

Windows にてファイルのプロパティ等からファイルやフォルダを暗号化して保存すると、ランダムな暗号化ジェネレータによって一意のファイル暗号化キーFEK (=共有鍵 ） が生成されます。　EFS.sys (ドライバー) はファイルに以下のヘッダーを追加し、そのヘッダー内に FEK を格納します。

DDF (Data Decryption Field)

ここで、ユーザーの公開鍵を使って暗号化された FEK が格納されます。 その後、ユーザーによってファイルが復号化される際には、一旦、この暗号化された FEK を公開鍵暗号方式における秘密鍵を用いて復号化し、暗号化されていない FEK を取り出します。そして、この FEK を用いて実際のデータ部分を復号化していきます。 (つまり、鍵を二つ作り、それぞれ別の用途で使っているんですね。)

このように、EFS では二つの暗号化技術がハイブリッドで用いられているのですが、これは実際のファイルに対する処理速度と、鍵の秘匿性を含めた安全性のどちらも実現できるようにするためで、Windows に限らず PKI では広く見受けられます。実際にはこの二つの暗号化技術が併用されている場合が多いのです。

と、ここまでは実際にファイルを暗号化したユーザーでのみ復号化が可能です。しかし、鍵の紛失や暗号したユーザーが退職されてファイルの復号化ができない、といったシチュエーションもあります。ここで、Windows ドメイン環境下では、回復エージェントという概念を用いてそのシチュエーションの回避を行っています。

（前回のキーのアーカイブとはちょっと違うアイディアになります。）

実際の動作をご説明します。

ファイルが暗号化される際、EFS はファイルに以下のヘッダーを追加し、そのヘッダー内にも FEK を格納します。

DRF (Data Recovery Field)

DRF には　"Default Domain Policy" にて割り当てられた回復エージェントごとに、その証明書内の公開鍵を使用し暗号化された FEK が格納されます。回復エージェントは複数指定することが可能ですので、DRF は複数存在する場合も十分考えられます。ファイルの復号化時には、いずれかのヘッダー（DRF）が解読できた場合のみ、FEK が取り出せますので、その場合はその FEK を用いて暗号化されたファイルを復号化し、実際のファイルにアクセス可能、となります。

色々鍵が出てまいりますが、秘密鍵はユーザーのプロファイル内に実際のファイルとして格納されています。場所は、 \Documents and Settings\<username>\ApplicationData\Microsoft\Crypto\RSA です。ユーザーがログオフするか、コンピュータを再起動するまでの間ずっと読み込まれた状態になります。

ちなみに、一番に昇格したドメインコントローラを、Administrator の秘密鍵を取り出す前に撤去される場合も十分ありますよね。

初めてドメイン コントローラに昇格した時点で、"Default Domain Policy"　に、回復エージェントが指定されます。この証明書はドメイン Administrator から取得されますが、それに対応する秘密キーもドメインコントローラ上のユーザープロファイル内に格納されておりますため、「この証明書に対応する秘密キーを持っています。」と表示されます。但し、上述の通り、EFS に必要なのは、回復エージェントに指定された証明書の公開キー（cer ファイル）のみとなりますため、ポリシーを表示した際、「この証明書に対応する秘密キーを持っています。」と表示される必要はありません。

- まだ信頼されていない証明書

- 証明書をインストールした場合

-  自己署名証明書を信頼された CA のストアにインストールした場合

- Editors Note (編集後記)

実は意外とお問い合わせに多いのが「回復エージェントの秘密鍵がない」なんです。最初に構築したドメイン コントローラの Administrator アカウントのプロファイルはマシンの撤去等で存在しない場合もあります。その場合、やはり Windows OS から復旧することができません。場合によっては大きな問題になりかねませんので、回復エージェントに指定された証明書の秘密鍵を確認し、安全な場所に保存していただければ幸いです。

ちなみに、Cipher コマンドを使用して 100 年ものの自己署名証明書を作成した際、100 年後の日付から 25 日前が期限切れになります。これは、Cipher コマンドでうるう年を考慮していないためです (すみません。) さて、「Windows でやってみよう PKI シリーズ 」 ですが、次は Windows における証明書の署名と暗号化の違いについてお話したいと思います。

- 免責事項

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」 ]]> https://docs.microsoft.com/archive/blogs/jpepscrt/windows-server-2003-r2-id-1034 Sun, 21 Mar 2010 10:28:56 GMT https://blogs.technet.microsoft.com/jpepscrt/2010/03/21/windows-server-2003-r2-id-1034/ Windows Server 2003 R2 までのクラスタ構成環境下において、次のような状況後、物理ディスク リソースがオンラインにならない場合や、クラスタ サービスを開始できない場合があります。

• 故障したハード ディスクを交換したり、共有ディスク リソースのドライブを (別の SCSI ID や SCSI ラックの物理的に別の場所に) 変更した場合
• ディスク障害等でクラスタ サービスが当該ディスクを見つけられない場合
• ディスクの署名が意図せず変更されてしまった場合

これは、クラスタ側で認識しているディスク署名と、実際の物理ディスクのディスク署名が異なってしまったために発生します。
物理ディスク クラスタ リソースがオンラインにならない場合には、システム イベント ログに ID 1034 エラー イベントが記録されます。

クラスタ サービスを開始できない場合は、クラスタ アドミニストレーター内で次のエラーが出力されます。

また、クラスタ ログには以下のログが記録されます。

ERR  Physical Disk <Disk Q:>: [DiskArb] Signature of disk has changed or failed to find disk with id, old signature 0xf06047dd new signature 0xf06047de, status 0
ERR  Physical Disk <Disk Q:>: SCSI: Attach, error attaching to signature f06047dd, error 2.
ERR  Physical Disk <Disk Q:>: Arbitrate: Unable to attach to signature f06047dd. Error: 2.
INFO [MM] MmSetQuorumOwner(0,0), old owner 1.
ERR  [FM] FmGetQuorumResource failed, error 2.
ERR  [INIT] ClusterForm: Could not get quorum resource. No fixup attempted. Status = 5086
INFO [INIT] Cleaning up failed form attempt.
ERR  [INIT] Failed to form cluster, status 5086.
ERR  [CS] ClusterInitialize failed 5086
WARN [INIT] The cluster service is shutting down.

[対処方法]
対処方法としては、問題の起きている物理ディスクが OS で認識されている事を確認し、ディスク署名を正常に稼動していた時と同じ番号に変更します。
まず準備として、２つの情報と1つのツールを用意します。

• [ディスクの管理] 管理コンソールから問題の起きているディスク ドライブのディスク番号を記録します。例: ディスク 1
• イベント ID 1034 エラー メッセージの "説明" 部分からディスク署名を取得します。例 : "ディスクの予期された署名は、12345678 です。"
• Dumpcfg.exe ツールを用意します。Dumpcfg.exe は Windows 2000 リソース キットから入手できます。

※    Windows 2000 リソース キットのものはX86 版になります。
※    x64、IA64 環境下の場合は、それぞれに対応したDumpcfg.exe ツールがあります。マイクロソフト サポート サービス <https://www.microsoft.com/japan/customer/contract/default.aspx> を通じて入手下さい。

それを踏まえ以下の作業を実施します。

(1) クラスタ セットの中で稼動しているノードを一つだけの状態にします。
(2) 稼動ノード上で、クラスタ サービスを [自動] から [手動] にします。再起動後にクラスタ サービスが自動で起動しないようにするためです。

(3) 稼動ノード上で、クラスタ ディスク ドライバを [システム] から [無効] にします。これも再起動後にクラスタ ディスク ドライバが起動しないようにするためです。
[デバイス マネージャ] 管理コンソールを起動し、メニュー バーの [表示]-[非表示のデバイスの表示] にチェックを入れます。すると、右ペインに [プラグ アンド プレイではないドライバ] が表示されますので、それを展開し、[クラスタ ディスク ドライバ] のプロパティにて設定します。

(4) システムを再起動します。
(5) 再起動後、管理者でログオンし、コマンド プロンプトを起動します。
(6) 問題の起きているディスクの署名を、正常稼動時に認識していた番号に戻すために、以下のコマンドを実行します。 <ディスク署名> <ディスク番号> は準備時に用意した情報を使用します。

＞ dumpcfg.exe –s <ディスク署名> <ディスク番号>

例：

※ Windows 2003 リソースキットの Clusterrecovery.exe を使用しても良いですが英語環境下に限定されます。日本語環境下においては以下のサポート技術情報 843295 から修正された ClusterRecovery.exeを入手し使用して下さい。
リソースキットツール ClusterRecovery.exe の日本語環境での使用について
https://support.microsoft.com/kb/836503/ja

(7) 手順 2 と 3 で設定変更したクラスタ サービスとクラスタ ディスク ドライバの変更を元に戻します。

(8) システムを再起動します。
(9) 再起動後、クラスタ サービスや物理ディスク リソースが正常稼動していることを確認して下さい。

(10) クラスタ セットに参加している他のノードも起動します。

[参考情報]

ディスクを交換した後 MSCS の共有ディスクでイベント ID 1034 が発生する
https://support.microsoft.com/kb/243195/ja

サーバー クラスタでイベント ID 1034 から回復する
https://support.microsoft.com/kb/280425/ja

Windows 2000 または Windows Server 2003 サーバー クラスタでディスクを交換する方法
https://support.microsoft.com/kb/305793/ja

[追加情報]
最後に、Windows Server 2008 以降のフェールオーバー クラスタリングではどうでしょうか。
明示的なディスク署名の変更は不要となっています。自己修復するロジックに変更されていますので、上記でご紹介した作業は必要ありません。

Windows Server 2008 フェールオーバー クラスタリングの概要
https://technet.microsoft.com/ja-jp/magazine/2008.07.failover.aspx

Windows Server 2008 Failover Clustering Architecture Overview - p.17
https://download.microsoft.com/download/3/b/5/3b51a025-7522-4686-aa16-8ae2e536034d/Windows%20Server%202008%20Failover%20Clustering%20Architecture%20Overview.doc

Sorting out some myths and facts concerning Windows Server 2008 Failover Clustering
https://blogs.technet.com/askcore/archive/2009/01/26/sorting-out-some-myths-and-facts-concerning-windows-server-2008-failover-clustering.aspx

こんにちは。

Critical response team の昼間を担当しています、松木と申します。

今回は緊急対応でもお問い合わせいただきます証明書、Windows PKI について「Windows でやってみよう PKI シリーズ」 というお題目でお話させていただきます。

PKI とは、IT 用語辞典等を検索しますと、以下のような意味で定義されています。

「PKI とは、公開鍵暗号を用いた技術・製品全般を指す言葉。RSAや楕円曲線暗号などの公開鍵暗号技術、SSLを組みこんだWebサーバ/ブラウザ、S/MIME・PGPなどを使った暗号化電子メール、デジタル証明書を発行する認証局 (CA) 構築サーバなどが含まれる。」

Windows OS では、現在 （2010-03-18）、Windows Server 2003 そして Windows Server 2008 が CA 構築する際の OS としてサポートされています。

どちらを選択されるかはお客様の環境によって様々だと思いますが、以下に Windows 2008 PKI からの新機能について書かれた文書（英語です、すみません。）がありますので、ご一読いただければと。

（一番の目玉はOnline Certificate Status Protocol <OCSP> , ネットワーク デバイスの登録サービス <NDES> がサポートされるようになったことでしょうか。）

「PKI Enhancements in Windows」
https://technet.microsoft.com/en-us/magazine/cc137986.aspx

ここから、最新バージョンの OS であります Windows Server 2008 R2 から追加された証明機関（CA） の新機能について少し書かせていただきたいと思います。

1. Cross-Forest enrollment

フォレスト間での証明書の発行が可能となりました。これにより、マルチフォレスト環境のお客様でも CA を統合管理することが出来るようになりました。つまりは、ユーザーアカウントとリソースアカウントでドメインやフォレストを分けて運用されている環境でも、リソースフォレストに Windows CA を統合構築していただくことが可能となります。

2. Certificate Enrollment Web Service and Policy Service

Web インターフェースから証明書を取得することができます。この機能により、クライアントは CA や Active Directory と同一物理ネットワークにいなくても証明書の取得が可能です。

3. Non-persistent certificates (not stored in the CA database)

証明書テンプレートの設定により、証明書に記載するユーザー固有のデータ等を削除することが出来ます。この機能が追加されたことで多数の証明書を発行するようなCA環境ではパフォーマンスの向上が見込めます。

- 補足情報 (エディション情報)

Windows Server OS には以下のエディションがあります。

「Standard」「Enterprise」「Datacenter」

ちなみに、以下の機能は、「Enterprise」 と 「Datacenter」 エディションのみがサポートしており、Standard エディションはサポートしていない機能となります。

• テンプレートの複製や編集
• 証明書自動発行
• キーのアーカイブ

CA を構築する際には、エンタープライズとスタンドアロンと二種類の CA が選択可能です。要件次第ではありますが、自動で色々設定してくれるのはエンタープライズ CA といえると思います。また、管理者がしっかりと管理できるのが、スタンドアロン CA とも言えます。ちなみに、エンタープライズ CA は構成情報をActive Directory から自動で取得してくれますが、スタンドアロンの場合、要求ファイルを作成しなければならないといった点も比較要件として考えられます。また、失効確認リスト（CRL） や機関情報アクセス (AIA) ポイントといった PKI にとって必要な情報の管理や設計も、CA を構築する際の要注意ポイントとなります。

上記にて機能として、キーのアーカイブについてちょっと触れましたが、外部に証明書の発行を生業とされている CA 会社様の場合、秘密鍵は一切残さないというのがポリシーのようです。つまり、ユーザー情報入力作業と、証明書発行作業を完全に分離し、かつ、秘密鍵は残さないよう設計されているということになります。住基ネットなどは恐らく（すいません、未確認です）秘密鍵は残さないというポリシー設計されていると思います。公的機関から個人の秘密鍵情報が漏洩してしまうととんでもないことになります。

これは、Windows CA の場合でも全く同様で、上記キーのアーカイブ機能を使用すると、Key Recovery Manager という機能によって暗号処理をされて秘密鍵情報が CA データベース内にアーカイブされることになります。つまり、暗号されているとはいえ、秘密鍵の情報は CA データベースに残ることになります。ちょっと考えるだけでも恐いですが、便利な機能でもあります。実際問題、秘密鍵の紛失のお問い合わせはよく耳にしますし、ファイルシステム上削除されてしまった情報を、Windows OS からは復旧させることができません。サードパーティ製品に秘密鍵ファイルがディスク上に残っている場合のみ復旧できるといったアプリケーションもありますが、公開鍵、秘密鍵ともに管理がますます大切になってきています。

- 参考資料

「Key Archival and Management in Windows Server 2003」

https://technet.microsoft.com/en-us/library/cc755395.aspx

「Implementing Key Archival Walkthrough」

https://technet.microsoft.com/en-us/library/cc738977.aspx

「Troubleshooting」

https://technet.microsoft.com/en-us/library/cc787039.aspx

- Editors Note (編集後記)

「Windows でやってみよう PKI シリーズ」 と大げさなタイトルではじめてしまったため、PKI / CA からお話させていただきました。こうはじめて見ると、PKI という分野はあまりに範囲が広く、今後に続きとさせていただきたいと思います。ちなみに、お急ぎのお客様は私よりも専門性の高いエンジニアさんの資料や Blog 等、是非ご参考にされて CA 構築いただければと思います。次はポイントを少し絞って、Windows 標準機能である EFS  （暗号化ファイル システム） についてお話したいと思います。

- 補足参考資料

Active Directory 証明書サービス

https://technet.microsoft.com/ja-jp/library/cc770357(WS.10).aspx

Version 3 Certificate Templates

https://technet.microsoft.com/en-us/library/cc730826.aspx

New Certificate Templates

https://technet.microsoft.com/en-us/library/cc730826.aspx

Network Service permissions can be configured on Version 3 Templates

https://technet.microsoft.com/en-us/library/cc725621.aspx

- 免責事項

「コミュニティにおけるマイクロソフト社員による発言やコメントは、マイクロソフトの正式な見解またはコメントではありません。」