こんにちは。ネットワークサポート担当の比留間 友一です。

夏です。クラウドが熱いです。私たちのサポートチームでも、弊社で公開している Microsoft Azure の仮想マシンや仮想ネットワークについてのお問い合わせを担当させていただいております。Azure のお問い合わせをいただいた際に、「あれ？どこかで見かけたヤツが出てきたな？」と思われるお客様もいらっしゃるかもしれませんが、どうぞ今後ともよろしくお願いいたします。

さて、本日のお題は、Azure 仮想ネットワークにおける VNET to VNET （VNET間の接続） です。

VNET to VNET とは？

Azure の仮想ネットワークの機能のリリース以来、「仮想ネットワーク同士を接続する方法はないのか？」というお問い合わせをしばしばいただいておりました。このご要望にお応えする形で2014 年 5月のアップデートにて追加されたのが、「仮想ネットワーク同士をサイト間 VPN で接続する方法」、つまり VNET to VNET です。同時期のアップデートにて、一つの仮想ネットワークから複数のネットワークに VPN 接続を行うことができる、Multi Site VPN も追加されております。

設定方法は？

注意：以降の記載は、2014 年 7 月現在の Microsoft Azure の仕様に基づいて作成されております。将来的に予告なく変更される場合がございますので、予めご承知おきください。

今回の記事では、以下のようなシナリオを考えてみます。

• 東日本リージョンに構築された、既存の Azure 仮想ネットワーク VNET-JAPAN (172.17.0.0/16)
• 既存の社内ローカルネットワーク OnPremise (192.168.180.0/24)
• VNET-JAPAN と社内ネットワーク OnPremise は、既にサイト間 VPN 接続の設定がなされている。
  （ただし、ゲートウェイが動的ルーティングモードであるものとします。動的ゲートウェイが作成されていないと、VNET-JAPAN に複数の VPN 接続を作成することができません。）
• ここに新たに、東アジアリージョンに仮想ネットワーク VNET-ASIA (172.18.0.0/16)を追加し、VNET-JAPAN (172.17.0.0/16)と接続します。

VNET to VNET の要点は、2つの仮想ネットワークのサイト間接続となります。
これを実現するためには、以下のような設定をする必要があります。

• VNET-ASIA　からは、VNET-JAPAN をローカルネットワークとみなしてサイト間接続する。
• VNET-JAPAN からは、VNET-ASIA をローカルネットワークとみなしてサイト間接続する。

つまり、VNET-JAPAN と VNET-ASIA ともに、仮想ネットワークとしての本来の設定と、ローカルネットワークとしての設定の 2つ を定義する必要があります。

整理すると、既存の状態から以下の各設定を実施する必要があります。

• ローカルネットワークとしての VNET-JAPAN の定義の追加
• ローカルネットワークとしての VNET-ASIA の定義の追加
• 仮想ネットワークとしての VNET-ASIA の定義の追加と、ローカルネットワークとしての VNET-JAPAN とのサイト間接続
• 仮想ネットワークとしての VNET-JAPAN と、ローカルネットワークとしての VNET-ASIA のサイト間接続

ローカルネットワークの定義は、管理ポータルの [+新規] ⇒ [ネットワーク サービス] ⇒ [仮想ネットワーク] ⇒ [ローカルネットワークの追加] で行うことができます。
ここでは、ローカルネットワークとしての VNET-JAPAN の定義を、LOCAL-JAPAN、ローカルネットワークとしての VNET-ASIA の定義を LOCAL-ASIA とします。

LOCAL-JAPAN の定義の追加

仮想ネットワーク VNET-JAPAN のダッシュボードから確認できるゲートウェイアドレスを設定します。仮にここでは、VNET-JAPAN のダッシュボードに表示されているゲートウェイアドレスが、X.X.X.X であるものと想定します。

VNET-JAPAN のアドレス空間 (172.17.0.0/16) を設定します。

LOCAL-ASIA の定義の追加

ゲートウェイアドレスはひとまず仮のものを入力しておきます。（後から変更します。）

VNET-ASIA のアドレス空間 (172.18.0.0/16) を設定します。

仮想ネットワークとしての VNET-ASIA の定義の追加

VNET-ASIA の仮想ネットワークを東アジアリージョンに作成します。

サイト間接続を有効にし、接続先のローカルネットワークを LOCAL-JAPAN とします。

アドレス空間は 172.18.0.0/24、ゲートウェイサブネットも作成しておきます。

仮想ネットワークが作成できたら、ゲートウェイを作成します。（ゲートウェイ作成時に動的ルーティングを選択するのをお忘れなく！）
VNET-ASIA のゲートウェイが作成できたら、ゲートウェイのIP アドレスを控えておきます。（仮に Y.Y.Y.Y とします）

ゲートウェイの作成まで終わると、ダッシュボードの表示は以下のようになります。

あらかじめ作成しておいた LOCAL-ASIA の設定を開き、[VPN デバイスの IPアドレス] を Y.Y.Y.Y に変更します。

VNET-JAPAN と VNET-ASIA 間の接続

ここまでできたら、あとは VNET-JAPAN と VNET-ASIA を接続する作業です。以降の作業には、仮想ネットワークの構成ファイルの編集が必要になります。
仮想ネットワークのダッシュボードから [ダウンロード] を選択すると、XML ファイル (NetworkConfig.xml) がダウンロードできます。いざという時の切り戻し用に、このファイルは保管しておくことをお勧めします。
ここまでの作業で、構成ファイル NetworkCOnfig.xml の内容は以下のような感じになっているはずです。

VNET-JAPAN の定義セクションの中に、以下の3行を追加します。
これで、仮想ネットワーク VNET-JAPAN が、既存のローカルネット OnPremise に加え、LOCAL-ASIA と接続されるようになります。

            <LocalNetworkSiteRef name="LOCAL-ASIA">
              <Connection type="IPsec" />
            </LocalNetworkSiteRef>

ファイル全体は以下のような形になります。

完成した構成ファイルは、管理ポータルの [+新規] ⇒ [ネットワーク サービス] ⇒ [仮想ネットワーク] ⇒ [構成のインポート]からアップロードすることができます。仮想ネットワークの設定変更中は一時的にネットワーク接続が切れる場合がございますので、作業前には予めご注意ください。

ゲートウェイの事前共有キーを合わせる

構成のアップロードが成功したら、VNET-JAPAN と VNET-ASIA 間の接続について、ゲートウェイの事前共有キーを同じものに合わせます。
これには、Windows Azure PowerShell の Get-AzureVNetGatewayKey を使用します。

まず、Get-AzureVNetGatewayKey で、VNET-JAPAN のゲートウェイの事前共有キーを取得します。

Value として表示された bwQctCrC4xUPsfkybexxkHmSP5LdXVwL が事前共有キーになりますので、これを控えておきます。

次に、VPN-ASIA 側の、VPN-JAPAN に対するゲートウェイの事前共有キーを、Set-AzureVNetGatewayKey を使用して設定します。

管理ポータルに戻って VNET-ASIA の設定を見ると、LOCAL-JAPAN （つまり VNET-JAPAN）と VPN 接続が行われているのが確認できます。

VNET-JAPAN も、OnPremise と VNET-ASIA の双方と接続された状態になっています。

 まとめ

ご覧いただきましたように、仮想ネットワークの構成ファイルを編集することによって、仮想ネットワーク間であっても VPN 接続を行うことができます。今回は、極力管理ポータルの操作を併用しましたが、慣れてくれば、構成ファイルを直接編集することでも今回のような構成を作成することが可能です。また、上記の例で、更に VNET-ASIA の定義に、ローカルネットワーク OnPremise との定義を追加すれば、三角形のトポロジーを生成することも可能です。
（お使いの VPN 装置が、複数の VPN トンネルに対応しているかどうかは事前にご確認ください。この場合も、事前共有キーを合わせることが必要です。）

VNET to VNET の要点は、とにかく仮想ネットワークとしての本来の設定と、ローカルネットワークとしての設定の 2つ を定義し、お互いを接続する という点にあります。

参考：

Configure a Multi-Site VPN

Configure a VNet to VNet Connection

VNET 間接続: 異なるリージョン間での Azure Virtual Network の接続

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

こんにちは。Windows サポートチームの石井です。

皆さんも Microsoft アカウント使っていますか？

私もメールや One Drive などを複数のデバイスで利用する為に、Microsoft アカウントの関連付けを活用しています。

最近では、個人での利用だけでなく、業務でもMicrosoft アカウントを活用しているというありがたい声も頂いています。

今回は、Microsoft アカウントをローカルユーザーに関連付けて使用している状態で、ファイル サーバーや SQL サーバーを利用する場合の注意点についてご案内します。

ワークグループ環境では、サーバーにアクセスする際には認証が求められますが、クライアント、サーバーに共通するユーザー名 / パスワードのアカウントを用意することで、資格情報の入力を求められる事なくアクセスできるように構成する事ができます。

これによりドメイン環境でなくても、いちいち認証情報を入れることなくファイルサーバーや、IIS で構成したWeb サーバー、SQL サーバーへのアクセスが可能です。

しかし、 Microsoft アカウントを関連付ける事によって、クライアントは、ログオンしているローカル アカウントの情報ではなく、"Microsoft アカウント"  の情報をサーバーに渡すよう動作が変わります。

このため、クライアントとサーバーで共通するユーザー名 / パスワードが利用されなくなり、アクセスに問題が発生します。

下の図は Microsoft アカウントを関連付けた端末がファイルサーバーにアクセスする際の動作を Network Monitor でキャプチャしたものです。

資格情報として Microsoft アカウントを使っている様子を確認する事ができます。

この動作は、ローカル アカウントに Microsoft アカウントを関連付けることで、その端末に、Microsoft アカウントのパスワードを用いてログオンできるようになり、使用される資格情報が切り替わることで発生します。

なお、Active Directory ドメイン環境では、Microsoft アカウントでログオンするように構成できませんので、特に心配する必要はありません。

[回避策]

“資格情報マネージャー” を利用して予め資格情報を登録すれば回避できます。 

手順をご説明します。

1. コントロールパネル を開きます。

2. [ユーザーアカウントとファミリーセーフティ] を選択します

3. [資格情報マネージャー] > [Windows 資格情報の管理] を選択します。

4. [Windows 資格情報の追加] を選択します

5. 保存する資格情報を入力し、[OK]を選択します
インターネットまたはネットワークのアドレス：接続先サーバー名のホスト名やIP アドレスを入力します。
   ※接続先に実際にアクセスする際に利用する名前を登録する必要があります
   アプリケーションによっては手で入力した名称に自動で文字列を付与している場合などもあるのでご注意ください。
    例)SQL Management Studio でアクセスする場合は利用するポート番号(既定で1433) が”:<ポート番号>”の形で付与されます。

ユーザー名：接続に利用する “ユーザー名” を入力します。
パスワード： “ユーザー名” で入力したユーザーのパスワードを入力します。

6. 登録した情報が追加されている事を確認します

以上で設定は完了です。

設定後、再度ファイルサーバーにアクセスしてみると、サーバーに渡す資格情報が登録されたものに切り替わっている事が確認できます。

Microsoft アカウントを活用する際に、参考になれば幸いです。

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

はじめまして。Active Directory を担当しております 鴻巣です。

日々、お客様からのお問い合わせを対応していて「仮想化」ということがとても一般的になっていることを実感しています。

今回は Active Directory の仮想化対応状況につきまして表形式でまとめてさせていただきました。

仮想化については、 Windows Server 2008 R2 以前と Windows Server 2012 以降では大きく対応状況が変わっており Windows Server 2012 以降ではさらに仮想化への対応が進んでおります。代表的なものとしては、よく知られていますが VM-Generation ID の機能があります。これについて簡単に説明すると、、、

Active Directory は通常、複数のドメイン コントローラー間でデータベースを複製しながら動作している為、既存のドメイン コントローラーを複製して新たにマシンを構成したり、スナップ ショットを利用して環境を以前の状態に戻しますと USN ロールバックと呼ばれるデータベースの不整合が発生することがございます。しかし Windows Server 2012 以降では、スナップショットからのドメイン コントローラーの復元に対応するようになり、Windows Server 2012 における Hyper-V 3.0  と Windows Server 2012 の Active Directory の組み合わせでは VM-generation ID とよばれる識別番号を利用し、不整合が発生しないよう実装が変更されました。

これから仮想化技術の導入が進んでいく中で本情報が少しでもお役に立てますと幸いです。

Active Directory の仮想化につきましては以下の公開情報も参考ください。

Title: Things to consider when you host Active Directory domain controllers in virtual hosting environments 
URL: http://support.microsoft.com/kb/888794/en-us

Title: Running Domain Controllers in Hyper-V Guide
URL: http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(v=ws.10).aspx

Title: Running Domain Controllers in Hyper-V 
URL: http://technet.microsoft.com/en-us/library/virtual_active_directory_domain_controller_virtualization_hyperv(WS.10).aspx
 
Title: Introduction to Active Directory Domain Services (AD DS) Virtualization (Level 100) 
URL: http://technet.microsoft.com/en-us/library/hh831734.aspx
 
Title: Support for using Hyper-V Replica for virtualized domain controllers 
URL: http://technet.microsoft.com/en-us/library/dn250021.aspx

こんにちは 

Windows サポート チームの石井です。 

今回は Windows Server 2003 で構築された Active Directory 環境に、Windows Server 2012 R2 をドメインコントローラーとして追加した場合に生じる問題 (サポート技術情報 2989971) について取り上げます。

この問題は、ドメインに参加しているコンピューター (ドメインコントローラーを含む) において、Kerberos 認証が正常に行えず、ログオンができないなどの障害を引き起こします。

詳細はサポート技術情報にも記載されていますが、改めて問題の概要とその対処策を整理してお伝えします。

1. 問題の概要
===============================

Windows Server 2003 で構成された Active Directory ドメインに Windows Server 2012 R2 のドメイン コントローラーを追加します。

追加後、 おおよそ 2 ヶ月程度経過後に、ドメインのメンバー、ドメイン コントローラーで Kerberos 認証が正常に行えなくなります。

障害は、Windows Server 2003 で構成されていたドメインにおける Windows Server 2012 R2 ドメイン コントローラーのコンピューター パスワード更新処理に問題があるため発生します。

具体的には更新処理の結果、本来必要な暗号化キーが各メンバー コンピューター上に生成されないことが障害の原因です。

- 詳細
各メンバーは、既定で 30 日毎に自動的にコンピューター パスワードを変更しますが、この変更のタイミングでは暗号化キーの生成もおこなわれます。

Windows Server 2008 以降のドメイン コントローラーは新しく AES という暗号化方式をサポートしており、この新しい暗号化方式に対応している場合、 AES 用のキーも生成されます。

新しい暗号化方式によるキーが作成され、利用されるようになるのは、 Windows Server 2008 以降のドメイン コントローラーが追加されてから 2 回目のコンピューター パスワード変更後からです。

コンピューター パスワード変更の処理後、AES に対応した暗号化キーについても各メンバーは生成する必要がありますが、これを生成させるための Windows Server 2012 R2 のドメイン コントローラー側の処理に問題があり、暗号化キーが生成されないという問題が発生します。 

コンピューターにユーザーがログオンするときには、そのコンピューターに対応した Kerberos チケットの取得と提示を実施し、認証されることが必要です。提示を受けたメンバー コンピューターが認証を成功させるためには、 Kerberos チケットの復号をおこないます。この復号処理では、適切な暗号化キーを保持している必要があります。

この問題が発生すると、メンバー コンピューターに暗号化キーが存在しないため、 Kerberos チケットの復号に失敗するため、認証に失敗し、結果としてログオンに失敗します。

この問題はサポート技術情報 2989971 として公開しており、修正プログラムについても入手が可能です。 

-----------------
文書番号 : 2989971
Can't log on after changing machine account password in mixed Windows Server 2012 R2 and Windows Server 2003 environment
http://support.microsoft.com/kb/2989971/en
-----------------

-----------------
文書番号 : 2989971  (日本語版)
Windows Server 2012 R2 と Windows Server 2003 の混在環境でのコンピューター アカウントのパスワードを変更した後にログオンできない
http://support.microsoft.com/kb/2989971/jp 
-----------------

なお、この修正プログラムは 9 月のロールアップにも含まれていますので、Widows Update を通して適用する事も可能です。 
-----------------
Windows RT 8.1、8.1 の Windows、および Windows Server 2012 の R2 用の更新プログラムのロールアップ
2014年 9 月
http://support.microsoft.com/kb/2984006/ja 
-----------------

2. どういったことが起こるか
===============================

事象が発生した端末では、ドメインユーザーによるログオンが行えなくなります。

また、当該の端末がサービスを提供するサーバーであった場合は、Kerberos 認証を利用しているサービスにアクセス出来ないといった問題が生じる可能性もあります。

3. 対象の OS
===============================

この事象は Windows Server 2012 R2 のドメインコントローラーの動作に問題があるため発生しますが、影響を受ける (ログオン障害が発生する) のは、ドメイン コントローラーを含むドメイン メンバーです。その対象 OS は AES を利用できるもの全てで、以下のとおりです。

Windows Server 2008
Windows Server 2008 R2
Windows Server 2012
Windows Server 2012 R2
Windows Vista
Windows 7
Windows 8
WIndows 8.1

4. 対処方法
===============================

現象が発生してしまった場合には、対象のコンピューターを再起動します。

再起動することで、起動時に対応した暗号化キーを生成するため、問題が解消します。

問題が発生するのを未然に防ぐためには、次の対応を実施します。

1. KB2989971 を全ての Windows Server 2012 R2 のドメイン コントローラーに適用します。 

-----------------
Windows Server 2012 R2 と Windows Server 2003 の混在環境でのコンピューター アカウントのパスワードを変更した後にログオンできない
http://support.microsoft.com/kb/2989971
-----------------

2. 全てのドメイン コントローラーに対する修正プログラムの適用処理 (再起動を含む) が完了後にドメイン コントローラーを含む全メンバー コンピューターを再起動します。

注意:

KB 2989971 の修正プログラムを適用するためには、下記の 2 点の条件が必要です。
・ KB 2919355 が適用されている事
・ Active Directory ドメインサービスがインストールされている事
    ※ 役割が追加されていれば、必ずしもドメインコントローラーに昇格している必要はありません。
    ※ KB2919355 は Windows Update にて配信されているプログラムとなります。

   こちらを Windows Update から適用したうえで、以下の修正プログラムを適用ください。

-----------------
 Windows RT 8.1、8.1 の Windows および Windows Server 2012 の R2 の更新プログラム:
 2014 年 4 月
http://support.microsoft.com/kb/2919355/ja
-----------------

5.その他の注意事項
===============================

・ 技術情報には”混在” と記載がありますが、Windows Server 2012 R2 の追加後、すでに Windows Server 2003 のドメイン コントローラーが降格していてもこの問題は発生する可能性があります。

 ・ Windows Server 2012 R2 のドメイン コントローラーが存在しており、ログオンができないメンバー上でシステム イベントログに Microsoft-Windows-Security-Kerberos の ID 4 のイベントが記録されている場合には、この問題に合致している可能性が高いと判断できます。

 ・ 可能であれば、Windows Server 2012 R2 に Active Directory ドメイン サービスをインストールし、ドメイン コントローラーへの昇格を実施する前に修正プログラムを適用することをお勧めします。

以上です。

- 変更履歴

2014年10月15日  初回投稿

2014年10月16日  タイトルを変更しました。

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

こんにちは。Windows サポート チームの戸室です。

 今回はパスワードの複雑さの要件における注意事項について紹介します。

このポリシーを有効化した場合、パスワードの作成時や変更時に複雑さの要件を満たせなければ、パスワードを登録することができません。

 既定の状態は以下のようになります。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

ドメイン コントローラーの場合: 有効

スタンドアロン サーバーの場合: 無効

** ドメイン内のメンバー コンピューターは、既定で Default Domain Policy に複雑さの要件が有効化されております。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

パスワードの複雑さの要件は、グループ ポリシーやローカル ポリシーで以下のパスを開いて設定することができます。

[コンピューターの構成] - [ポリシー] - [Windows の設定] - [セキュリティの設定]

- [アカウント ポリシー] - [パスワードのポリシー] - [複雑さの要件を満たす必要があるパスワード]

そして、設定箇所内にあるヘルプの文章では以下のように記載されております。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このポリシーが有効な場合、パスワードは次の最小要件を満たす必要があります。

 ・ユーザーのアカウント名またはフル ネームに含まれる 3 文字以上連続する文字列を使用しない。

・長さは 6 文字以上にする。

・次の 4 つのカテゴリのうち 3 つから文字を使う。

英大文字 (A ～ Z)

英小文字 (a ～ z)

10 進数の数字 (0 ～ 9)

アルファベット以外の文字 (!、$、#、% など)

複雑さの要件は、パスワードの変更時または作成時に強制的に適用されます。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

今回は上述のヘルプの文章について、一部補足させていただきます。

補足する文章は以下の 2 つで、文章ごとに分けて補足させていただきます。

補足 1: 長さは 6 文字以上にする

補足 2: ユーザーのアカウント名またはフル ネームに含まれる 3 文字以上連続する文字列を使用しない。

==========================================

補足 1: 長さは 6 文字以上にする

==========================================

こちらはポリシーの説明表記と動作に相違がございます。

パスワードの長さが 6 文字未満でも、以下の 4 つのカテゴリの内、3 つのカテゴリを使用してユーザー アカウントを設定できてしまうことです。

・英大文字 (A ～ Z)

・英小文字 (a ～ z)

・10 進数の数字 (0 ～ 9)

・アルファベット以外の文字 (!、$、#、% など)

こちらは最新の OS である Windows Server 2012 R2 でも表記については修正されていない状況です。

そのため、パスワードの長さをポリシーの要件とする場合には、[複雑さの要件を満たす必要があるパスワード] ではなく [パスワードの長さ] を設定いただく必要が御座います。

"複雑さの要件を満たす必要がある" を有効にしてもパスワードの長さを 6 文字以上にする必要が無い

http://support.microsoft.com/kb/2617632/ja

==========================================

補足 2: ユーザーのアカウント名またはフル ネームに含まれる 3 文字以上連続する文字列を使用しない。

==========================================

こちらは、ドメインに参加していないローカル ユーザーの場合と、Active Directory に参加しているドメイン ユーザーの場合、共通している部分に分けてご案内差し上げます。

2-1. ローカル ユーザーの場合

2-2. ドメイン ユーザーの場合

2-3. 共通している部分

--------------------------------------------------

2-1. ローカル ユーザーの場合

--------------------------------------------------

ローカル ユーザーの場合、下記のルールにてパスワードが複雑さの要件を満たしているかのチェックを行います。

パスワードの複雑さのチェックのルール

<ユーザー名>

・ユーザー名の長さが 3 文字未満の場合、ユーザー名に対してはチェックが行われません。

・ユーザー名がそのままパスワードに使われている場合は要件を満たさず、パスワードとして利用する事が出来ませんが、1 文字でも不足している文字列が含まれる場合はパスワードとして利用する事が可能です。

<フル ネーム>

・ユーザーの作成時にフル ネームに入力する値はチェックが行われません。

・フル ネームのパスワード変更時はそのままチェックが行われるわけではなく、スペース、タブ、改行などの空白、またはコンマ (,)、ピリオド (.)、ハイフン (-)、アンダースコア (_)、番号記号 (#) のいずれかの文字を区切りとして扱い「トークン」と呼ばれる単位に分割します。

・分割されたトークンの内、3 文字未満のトークンはチェックの対象から外れ、3 文字以上の長さを持つ各トークンに対してチェックが行われます。

・対象のトークンごとに文字列がパスワード内に存在するかのチェックが行われ、そのままパスワードに使われている場合は要件を満たしませんが、1 文字でも不足している場合はパスワードとして利用する事が可能です。

パスワード チェックの例

ユーザー名、フル ネームの双方で要件を満たさなければ、そのパスワードは設定できません。

<ユーザー名の場合>

ユーザー名に対してチェックを実行するときは、区切り文字はないため、ユーザー名に設定された文字列が対象となります。

例 1: ユーザー名の値が "TESTUSER_24" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このユーザーは "TESTUSER_24" が含まれるパスワードを利用することができません。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

<フル ネームの場合>

以下の例は、パスワード変更時の動作になります。

例 2: フル ネームの値が " James_24" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1) " James”、"24" の 2 つのトークンに分割されます。

2) 1 番目のトークンである "James" が含まれるパスワードを利用することができません。

* " Jame" や "ames" が含まれるパスワードは利用できます。

3) このユーザーは "24" は 3 文字未満のため、パスワードに含める事が可能です。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

例 3: フル ネームの値が "Erin M. Hagens" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1) " Erin"、"M"、"Hagens" の 3 つのトークンに分割されます。

2) 2 番目のトークンである "M" は 3 文字未満のため、除外されます。

3) このユーザーは "Erin" "Hagens" が含まれるパスワードを利用することができません。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

よって、ローカル ポリシーを利用した場合の「複雑さの要件を満たす必要があるパスワード」は以下の説明として解釈いただき、パスワードを設定ください。

<複雑さの要件を満たす必要があるパスワード> ポリシーの説明

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このポリシーが有効な場合、パスワードは次の最小要件を満たす必要があります。

・「ユーザー名」 を 3 文字以上に設定している場合、その文字列をそのままパスワードに使用しない。

・「フル ネーム」のトークンが 3 文字以上の場合、その文字列をそのままパスワードに使用しない。

・次の 4 つのカテゴリのうち 3 つから文字を使う。

英大文字 (A ～ Z)

英小文字 (a ～ z)

10 進数の数字 (0 ～ 9)

アルファベット以外の文字 (!、$、#、% など)

複雑さの要件は、パスワードの変更時または作成時に強制的に適用されます。

** 「フル ネーム」のパスワード チェックは、パスワード変更時にのみ行われます。

** トークン: 「フル ネーム」内の区切り単位です。

** 区切り単位: 「フル ネーム」の一部を 3 文字以上の英数字として定義し、スペース、タブ、改行などの空白、またはコンマ (,)、ピリオド (.)、ハイフン (-)、アンダースコア (_)、番号記号 (#) のいずれかの文字で前後両方を区切ります。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

続いて、ドメイン ユーザーの場合のパスワード チェックの動作についてご説明致します。

 --------------------------------------------------

2-2. ドメイン ユーザーの場合

--------------------------------------------------

"ユーザーのアカウント名またはフル ネーム" を指す属性は以下のとおりです。

ユーザーのアカウント名: sAMAccountName

フル ネーム: DisplayName

パスワードが複雑さの要件を満たしているかは、上記の sAMAccountName、DisplayName を使用してチェックが行われます。

** 上記の属性値は、ADSI エディターを開いて各ユーザーのプロパティから確認することができます。

パスワードの複雑さのチェックのルール

属性によって複雑さをチェックするルールが異なりますので、それぞれ以下のようになります。

<sAMAccountName の場合>

・sAMAccountName の値の長さが 3 文字未満の場合、sAMAccountName に対してはチェックが行われません。

・sAMAccountName がそのまま使われている場合は要件を満たさず、パスワードとして利用する事も出来ませんが、  1 文字でも不足している文字列が含まれる場合はパスワードとして利用する事が可能です。

<DisplayName の場合>

・DisplayName はそのままチェックが行われるわけではなく、スペース、タブ、改行などの空白、またはコンマ (,)、ピリオド (.)、ハイフン (-)、アンダースコア (_)、番号記号 (#) のいずれかの文字を区切りとして扱い「トークン」と呼ばれる単位に分割します。

・分割されたトークンのうち、3文字未満のトークンはチェックの対象から外れ、3 文字以上の長さを持つ各トークンに関してチェックが行われます。

・対象のトークンごとにパスワード内に存在するかのチェックが行われ、そのままパスワードに使われている場合は要件を満たしませんが、1 文字でも不足している場合はパスワードとして利用する事が可能です。

** ユーザー アカウントを新規作成する際に、「フル ネーム」は、「姓」「名」「イニシャル」で入力した値をスペース区切り、最後にピリオド (.) が自動で入力されます。

パスワード チェックの例

sAMAccountName DisplayName 双方で要件を満たさなければ、そのパスワードは設定できません。

<sAMAccountName の場合>

** sAMAccountName 属性に対してチェックを実行するときは、区切り文字はないため、 samAccountName に設定された文字列が対象となります。

例 1: sAMAccountName の値が "James_24" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このユーザーは "James_24" が含まれるパスワードを利用することができません。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

<DisplayName の場合>

 例 1: DisplayName の値が "James_24" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1) "James”、"24" の 2 つのトークンに分割されます。

2) 1 番目のトークンである "James" が含まれるパスワードを利用することができません。

* "Jame" や "mes" が含まれるパスワードは利用できます。

3) このユーザーは "24" は 3 文字未満のため、パスワード チェックの対象外となります。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

例 2: DislayName の値が "Erin M. Hagens" の場合

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

1) " Erin"、"M"、"Hagens" の 3 つのトークンに分割されます。

2) 2 番目のトークンである "M" は 3 文字未満のため、除外されます。

3) このユーザーは "Erin" "Hagens" が含まれるパスワードを利用することができません。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

 よって、ドメイン ユーザーにおける「複雑さの要件を満たす必要があるパスワード」は、以下の説明として解釈いただきパスワードを設定くださいますようお願い申し上げます。 

<複雑さの要件を満たす必要があるパスワード> ポリシーの説明

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

このポリシーが有効な場合、パスワードは次の最小要件を満たす必要があります。

・「ユーザー ログオン名 (Windows 2000 より前)」 を 3 文字以上に設定している場合、その文字列をそのままパスワードに使用しない。

・「フル ネーム」のトークンが 3 文字以上の場合、その文字列をそのままパスワードに使用しない。

・次の 4 つのカテゴリのうち 3 つから文字を使う。

英大文字 (A ～ Z)

英小文字 (a ～ z)

10 進数の数字 (0 ～ 9)

アルファベット以外の文字 (!、$、#、% など)

複雑さの要件は、パスワードの変更時または作成時に強制的に適用されます。

** トークン: 「フル ネーム」内の区切り単位です。

** 区切り単位: 「フル ネーム」の一部を 3 文字以上の英数字として定義し、スペース、タブ、改行などの空白、またはコンマ (,)、ピリオド (.)、ハイフン (-)、アンダースコア (_)、番号記号 (#) のいずれかの文字で前後両方を区切ります。

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

-------------------------------

2-3. 共通している部分

-------------------------------

パスワードの複雑さのチェックのユーザー名の比較では、大文字 / 小文字の区別は行われません。

例えば、以下のような場合では「パスワードの複雑さの要件」を満たしていないため、パスワードを設定することができません。

アカウント名: TESTUSER001

パスワード: TestUser001a!

** 大文字 / 小文字を区別しないため、アカウント名がそのままパスワードに組み込まれていることから、複雑さの要件を満たしていないと判断しパスワードが設定できません。

パスワードの複雑さの要件についての補足は以上となります。

また、以下の技術情報も併せてご確認いただき、パスワードを設定くださいますようお願い申し上げます。

パスワードは、複雑さの要件を満たす必要がある

http://msdn.microsoft.com/ja-jp/library/cc786468(v=ws.10).aspx

Passwords must meet complexity requirements

http://technet.microsoft.com/en-us/library/cc786468(WS.10).aspx

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

皆様、こんにちは。

Windows プラットフォーム サポート担当の藤田と申します。

今回は 497 日問題の修正についてお話しさせていただきます。

497 日問題そのものの修正は以下の修正モジュールをご適用いただくことで現象を回避することができます。

================================================================================================

- KB2553549

All the TCP/IP ports that are in a TIME_WAIT status are not closed after 497 days from system startup in Windows Vista, in Windows 7, in Windows Server 2008 and in Windows Server 2008 R2

http://support.microsoft.com/kb/2553549/en-us

================================================================================================

497 日問題は Tcpip.sys そのものと依存関係のあるモジュールに修正が加えられています。

しかし、上記の修正モジュールがリリースされてから、Tcpip.sys の修正もどんどん Update されています。

つまり KB2553549 を適用しなくても、497 日問題を回避することができます。

497 日問題が対処されているか気になったら、以下の修正モジュールが適用されているかどうか、実際に Tcpop.sys　のバージョンは KB2553549 の時のモジュールよりも更新されているかどうかご確認いただけますと幸いです。

KB2553549 の公開情報に Tcpip.sys 以外にも Fwpkclnt.sys のバージョンが更新される旨、記載されておりますが、Tcpip.sys と Fwpkclnt.sys は依存関係にあるモジュールであり、Tcpip.sys のバージョンが更新されると必然的に Fwpkclnt.sys のバージョンも更新されます。

よって、KB2553549 の問題が修正されているかどうか確認するにあたっては、Tcpip.sys のバージョンのみをご確認いただくことで問題ございません。

===============================================

Windows 7

===============================================

Windows 7 では以下のセキュリティパッチによって KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

MS12-032: Vulnerability in TCP/IP could allow elevation of privilege: May 8, 2012

http://support.microsoft.com/kb/2688338/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-018: Vulnerability in TCP/IP could allow denial of service: February 12, 2013

http://support.microsoft.com/kb/2790655/en-us

--------------------------------------------------------------------------------------------------------------------------------

セキュリティパッチ以外でも以下の修正モジュールにて KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

http://support.microsoft.com/kb/2459530

--------------------------------------------------------------------------------------------------------------------------------

An IPsec connection to back-end databases from a WTT application times out in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2524732/en-us

--------------------------------------------------------------------------------------------------------------------------------

Slow failover operation if no router exists between the cluster and an application server

http://support.microsoft.com/kb/2582281/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP/IP packets that are received out of sequence are discarded in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2634907/en-us

--------------------------------------------------------------------------------------------------------------------------------

Multicast packets are dropped in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2639824

--------------------------------------------------------------------------------------------------------------------------------

Slow data transfer speed in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2675785

--------------------------------------------------------------------------------------------------------------------------------

Stop error when a Windows 7-based or Windows Server 2008 R2-based computer crashes randomly

http://support.microsoft.com/kb/2719347/en-us

--------------------------------------------------------------------------------------------------------------------------------

Default gateway is set to 0.0.0.0 if you start a Windows Vista-based, Windows 7-based, Windows Server 2008-based or Windows Server 2008 R2-based computer from an iSCSI boot device

http://support.microsoft.com/kb/2727330/en-us

--------------------------------------------------------------------------------------------------------------------------------

Incorrect time is displayed in a device that uses ICMP to synchronize time information with a Windows 7-based or Windows Server 2008 R2-based computer

http://support.microsoft.com/kb/2733445/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP SACK option is always set to "true" after you enable the TCP/IP Offloading feature in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2741850/en-us

--------------------------------------------------------------------------------------------------------------------------------

FTP client does not establish a passive-mode FTP connection to an IPv4 FTP server in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2754804/en-us

--------------------------------------------------------------------------------------------------------------------------------

Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2786464

--------------------------------------------------------------------------------------------------------------------------------

Memory leak when an application uses the FwpsNetBufferListAssociateContext0 function in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2789378/en-us

--------------------------------------------------------------------------------------------------------------------------------

===============================================

Windows Server 2008 R2

===============================================

Windows Server 2008 R2 では以下のセキュリティパッチによって KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

MS12-032: Vulnerability in TCP/IP could allow elevation of privilege: May 8, 2012

http://support.microsoft.com/kb/2688338/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-018: Vulnerability in TCP/IP could allow denial of service: February 12, 2013

http://support.microsoft.com/kb/2790655/en-us

--------------------------------------------------------------------------------------------------------------------------------

セキュリティパッチ以外でも以下の修正モジュールにて KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

http://support.microsoft.com/kb/2459530

--------------------------------------------------------------------------------------------------------------------------------

An IPsec connection to back-end databases from a WTT application times out in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2524732/en-us

--------------------------------------------------------------------------------------------------------------------------------

Slow failover operation if no router exists between the cluster and an application server

http://support.microsoft.com/kb/2582281/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP/IP packets that are received out of sequence are discarded in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2634907/en-us

--------------------------------------------------------------------------------------------------------------------------------

Multicast packets are dropped in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2639824

--------------------------------------------------------------------------------------------------------------------------------

Slow data transfer speed in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2675785

--------------------------------------------------------------------------------------------------------------------------------

Stop error when a Windows 7-based or Windows Server 2008 R2-based computer crashes randomly

http://support.microsoft.com/kb/2719347/en-us

--------------------------------------------------------------------------------------------------------------------------------

Default gateway is set to 0.0.0.0 if you start a Windows Vista-based, Windows 7-based, Windows Server 2008-based or Windows Server 2008 R2-based computer from an iSCSI boot device

http://support.microsoft.com/kb/2727330/en-us

--------------------------------------------------------------------------------------------------------------------------------

Incorrect time is displayed in a device that uses ICMP to synchronize time information with a Windows 7-based or Windows Server 2008 R2-based computer

http://support.microsoft.com/kb/2733445/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP SACK option is always set to "true" after you enable the TCP/IP Offloading feature in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2741850/en-us

--------------------------------------------------------------------------------------------------------------------------------

FTP client does not establish a passive-mode FTP connection to an IPv4 FTP server in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2754804/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP packets sent from Windows Server 2008 R2 are retransmitted when SACK is disabled on the client computer

http://support.microsoft.com/kb/2764305/en-us

--------------------------------------------------------------------------------------------------------------------------------

Data is corrupted when there is insufficient memory on a Windows-based computer

http://support.microsoft.com/kb/2785146/en-us

--------------------------------------------------------------------------------------------------------------------------------

Memory leak when an application uses the FwpsNetBufferListAssociateContext0 function in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2789378/en-us

--------------------------------------------------------------------------------------------------------------------------------

Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2786464

--------------------------------------------------------------------------------------------------------------------------------

===============================================

Windows 7 (SP1)

===============================================

Windows 7 (SP1) では以下のセキュリティパッチによって KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

MS12-032: Vulnerability in TCP/IP could allow elevation of privilege: May 8, 2012

http://support.microsoft.com/kb/2688338/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-018: Vulnerability in TCP/IP could allow denial of service: February 12, 2013

http://support.microsoft.com/kb/2790655/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-049: Vulnerability in kernel-mode driver could allow denial of service: June 11, 2013

http://support.microsoft.com/kb/2845690/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-065: Vulnerability in ICMPv6 could allow denial of service: August 13, 2013

http://support.microsoft.com/kb/2868623/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS14-031: Description of the security update for TCP for Windows: June 10, 2014

http://support.microsoft.com/kb/2957189/en-us

--------------------------------------------------------------------------------------------------------------------------------

セキュリティパッチ以外でも以下の修正モジュールにて KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

http://support.microsoft.com/kb/2459530

--------------------------------------------------------------------------------------------------------------------------------

An IPsec connection to back-end databases from a WTT application times out in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2524732/en-us

--------------------------------------------------------------------------------------------------------------------------------

Slow failover operation if no router exists between the cluster and an application server

http://support.microsoft.com/kb/2582281/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP/IP packets that are received out of sequence are discarded in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2634907/en-us

--------------------------------------------------------------------------------------------------------------------------------

Multicast packets are dropped in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2639824

--------------------------------------------------------------------------------------------------------------------------------

Slow data transfer speed in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2675785

--------------------------------------------------------------------------------------------------------------------------------

Stop error when a Windows 7-based or Windows Server 2008 R2-based computer crashes randomly

http://support.microsoft.com/kb/2719347/en-us

--------------------------------------------------------------------------------------------------------------------------------

Default gateway is set to 0.0.0.0 if you start a Windows Vista-based, Windows 7-based, Windows Server 2008-based or Windows Server 2008 R2-based computer from an iSCSI boot device

http://support.microsoft.com/kb/2727330/en-us

--------------------------------------------------------------------------------------------------------------------------------

Incorrect time is displayed in a device that uses ICMP to synchronize time information with a Windows 7-based or Windows Server 2008 R2-based computer

http://support.microsoft.com/kb/2733445/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP SACK option is always set to "true" after you enable the TCP/IP Offloading feature in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2741850/en-us

--------------------------------------------------------------------------------------------------------------------------------

FTP client does not establish a passive-mode FTP connection to an IPv4 FTP server in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2754804/en-us

--------------------------------------------------------------------------------------------------------------------------------

Memory leak when an application uses the FwpsNetBufferListAssociateContext0 function in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2789378/en-us

--------------------------------------------------------------------------------------------------------------------------------

Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2786464

--------------------------------------------------------------------------------------------------------------------------------

MS13-018: Vulnerability in TCP/IP could allow denial of service: February 12, 2013

http://support.microsoft.com/kb/2790655/en-us

--------------------------------------------------------------------------------------------------------------------------------

===============================================

Windows Server 2008 R2 (SP1)

===============================================

Windows Server 2008 R2 (SP1) では以下のセキュリティパッチによって KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

MS12-032: Vulnerability in TCP/IP could allow elevation of privilege: May 8, 2012

http://support.microsoft.com/kb/2688338/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-018: Vulnerability in TCP/IP could allow denial of service: February 12, 2013

http://support.microsoft.com/kb/2790655/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-049: Vulnerability in kernel-mode driver could allow denial of service: June 11, 2013

http://support.microsoft.com/kb/2845690/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS13-065: Vulnerability in ICMPv6 could allow denial of service: August 13, 2013

http://support.microsoft.com/kb/2868623/en-us

--------------------------------------------------------------------------------------------------------------------------------

MS14-031: Description of the security update for TCP for Windows: June 10, 2014

http://support.microsoft.com/kb/2957189/en-us

--------------------------------------------------------------------------------------------------------------------------------

セキュリティパッチ以外でも以下の修正モジュールにて KB2553549 の tcpip.sys を置き換えています。

--------------------------------------------------------------------------------------------------------------------------------

Event ID 5719 and event ID 1129 may be logged when a non-Microsoft DHCP Relay Agent is used

http://support.microsoft.com/kb/2459530

--------------------------------------------------------------------------------------------------------------------------------

An IPsec connection to back-end databases from a WTT application times out in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2524732/en-us

--------------------------------------------------------------------------------------------------------------------------------

Slow failover operation if no router exists between the cluster and an application server

http://support.microsoft.com/kb/2582281/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP/IP packets that are received out of sequence are discarded in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2634907/en-us

--------------------------------------------------------------------------------------------------------------------------------

Multicast packets are dropped in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2639824

--------------------------------------------------------------------------------------------------------------------------------

Slow data transfer speed in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2675785

--------------------------------------------------------------------------------------------------------------------------------

Stop error when a Windows 7-based or Windows Server 2008 R2-based computer crashes randomly

http://support.microsoft.com/kb/2719347/en-us

--------------------------------------------------------------------------------------------------------------------------------

Default gateway is set to 0.0.0.0 if you start a Windows Vista-based, Windows 7-based, Windows Server 2008-based or Windows Server 2008 R2-based computer from an iSCSI boot device

http://support.microsoft.com/kb/2727330/en-us

--------------------------------------------------------------------------------------------------------------------------------

Incorrect time is displayed in a device that uses ICMP to synchronize time information with a Windows 7-based or Windows Server 2008 R2-based computer

http://support.microsoft.com/kb/2733445/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP SACK option is always set to "true" after you enable the TCP/IP Offloading feature in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2741850/en-us

--------------------------------------------------------------------------------------------------------------------------------

FTP client does not establish a passive-mode FTP connection to an IPv4 FTP server in Windows 7 or in Windows Server 2008 R2

http://support.microsoft.com/kb/2754804/en-us

--------------------------------------------------------------------------------------------------------------------------------

TCP packets sent from Windows Server 2008 R2 are retransmitted when SACK is disabled on the client computer

http://support.microsoft.com/kb/2764305/en-us

--------------------------------------------------------------------------------------------------------------------------------

Data is corrupted when there is insufficient memory on a Windows-based computer

http://support.microsoft.com/kb/2785146/en-us

--------------------------------------------------------------------------------------------------------------------------------

Hotfix enables the configuration of the TCP maximum SYN retransmission amount in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2786464

--------------------------------------------------------------------------------------------------------------------------------

Memory leak when an application uses the FwpsNetBufferListAssociateContext0 function in Windows 7 or Windows Server 2008 R2

http://support.microsoft.com/kb/2789378/en-us

--------------------------------------------------------------------------------------------------------------------------------

こんにちは。Windows サポート チームの望月です。

ネットワーク管理者であれば一度は使用したことがあるコマンド、『 route add 』 。

route add  コマンドでスタティック ルートを追加する場合、下記技術情報にあるとおり IF オプションを使用して、明示的にアクティブ ルートが割り当てられるインターフェイスを指定することをお勧めしております。

・KB 2161341 : Active Route removed on Windows Server Failover Cluster

・KB 2469100 : Manually added route table entries are deleted unexpectedly when you delete an additional IP address in Windows Vista, in Windows 7, in Windows Server 2008 or in Windows Server 2008 R2

上記の内容のほかに、もう一点、IF オプションを指定することをお勧めする理由を以下にご紹介致します。

下記に、ルート テーブルの例を示します。

Windows OS では、通信先の IP アドレスに従ってパケットを送出するインタフェースを選択する際、自身のルート テーブルを参照します。

上記の場合において、IP アドレス 192.168.1.20 宛に ping を実行する場合、上図の上から 5 番目のアクティブ ルートが選択され、IP アドレス 192.168.1.16 が設定されているインターフェイスよりパケットが送出されます。

次に、IP アドレス 172.16.1.10 宛に ping を実行する場合を考えます。

上記の場合において、アクティブ ルートに IP アドレス 172.16.1.10 と一致するルートが存在しないため、デフォルト ゲートウェイが使用されます。

この時、『 route add 』 コマンドを使用して固定ルート (スタティック ルート) を追加することで、特定の宛先に対してパケットを送信させることが可能です。

例えば、以下のコマンドを実行します。

route -p add 172.16.1.0 mask 255.255.255.0 192.168.1.20

実行後のルート テーブルは以下の通りです。 

IP アドレス 172.16.1.10 宛に ping を実行すると、上図の上から 5 番目のアクティブ ルートが選択され、IP アドレス 192.168.1.20 宛に、IP アドレス 192.168.1.16 が設定されているインターフェイスよりパケットが送出されます。

このとき、送出元インターフェイスは、route add コマンドのゲートウェイとして指定した IP アドレス 192.168.1.20 と、各インターフェイスの IP アドレスとの Longest Match により判断されます。

Longest Match でも決まらない場合は、メトリック値の最も低いインターフェイスが選択されます。

しかしながら、Longest Match および メトリック値によってアクティブ ルート が追加されるのはコマンド実行時の挙動であり、OS 再起動または NIC の無効化 / 有効化を実施した場合には、ゲートウェイの IP アドレスと同一ネットワークに該当するインタフェース全てにアクティブ ルートが追加されます。

OS 再起動または NIC の無効化 / 有効化を実施した後のルート テーブルは以下の通りです。

IP アドレス 192.168.1.32 が設定されているインターフェイスにも、アクティブ ルートが追加されることが確認できます。

なお、この挙動は仕様です。

上記の状態で、IP アドレス 192.168.1.32 が設定されているインターフェイスのアクティブ ルートを削除したい場合、以下のコマンドを実行することで削除可能ですが、OS 再起動または NIC の無効化 / 有効化を実施すると再度上図の状況に戻ります。

route delete 172.16.1.0 mask 255.255.255.0 192.168.1.20 if <消したいインターフェイスの IF 番号>

例 : route delete 172.16.1.0 mask 255.255.255.0 192.168.1.20 if 10

上記の現象を回避するためには、以下コマンドにて該当のスタティック ルートを削除する必要がございます。

route delete 172.16.1.0 mask 255.255.255.0 192.168.1.20

このように、意図しないアクティブ ルートが登録されるといった現象を回避するためにも、route add コマンドでスタティック ルートを追加する際には IF オプションを指定することをお勧め致します。

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

皆様、こんにちは。Windows プラットフォーム サポートの高田です。今回は、Windows 7 におけるソフトウェア制限ポリシーが UAC に関する設定の状態によっては、正しく機能しない問題について取り上げます。

概要

Windows 7 において、UAC を [通知しない] に設定した場合、ソフトウェア制限ポリシーが正しく動作しません。

詳細

例えば、次のような設定を実施します。

• ソフトウェア制限ポリシーをユーザーの構成として作成し、"リモートデスクトップ接続" (mstsc.exe)
  の利用を禁止します。
•  ポリシーの適用対象ユーザーが Windows 7 マシンにログオンし、UAC を [通知しない] に指定します。

このような状況において、そのユーザーが mstsc.exe を管理者として実行すると、本来ポリシーで制限されている mstsc.exe が起動できる場合があります。

この事象は、UAC ならびにソフトウェア制限ポリシーの内部動作に製品の問題があるため発生することがわかっています。製品への修正を検討しましたが、 UAC という OS 全体のセキュリティ メカニズムに影響範囲が及ぶことから問題の修正は困難であるとの判断で見送りとなり、Windows 7 での修正予定はありません。なお、Windows 8 など他の OS では同様の報告は寄せられておりません。

回避策

この事象は以下の方法にて回避が可能です。

1.  AppLocker など代替となるテクノロジーを使用する
2. UAC を有効にする

皆様、こんにちは。
Windows サポートチームの山本です。

今回は、Windows Server の持つ負荷分散機能であるネットワーク負荷分散（以下、NLB）を
マルチキャスト モードで構成した際の注意点ならびに、ロードバランサーなどを用いて ADFS を導入
する際の要件について取り上げます。

NLB をマルチキャスト モードで構成した際に、お使いのルーターまたは L3 スイッチによっては、
静的に NLB ホストの仮想 IP アドレスおよび仮想 MAC アドレス（03-BF-xx-xx-xx-xx）を関連付ける
ARP エントリーを事前に登録しておかないと、正常に通信が出来ない場合がございます。

これは、仮想 MAC アドレス（03-BF-xx-xx-xx-xx）に関連付けられた ARP を認識しないために発生します。

また、ロードバランサーなどを用いて AD FS の負荷分散を行うためには、AD FS サーバーファームを構築します。
まずは、プライマリの AD FS サーバーを構築し、そのファームに追加するようにセカンダリの AD FS サーバーを構築します。
後は、ロードバランサーなどにより各サーバーへの分散を行うことで負荷分散を目的とした AD FS サーバーファームが構築できます。
AD FS の構築の際には、以下システム要件のページをご参照いただき、要件の不足がないように十分にご留意ください。

AD FS Requirements
https://technet.microsoft.com/en-us/library/dn554247.aspx

<関連キーワード>

Azure のサイト間接続に VPN トンネルを使用している場合に、「接続できない」または「接続できているように見えるが、不安定」といったお問い合わせをいただくことがあります。
私たちサポートチームにいただくお問い合わせの内容から、以下に傾向を整理してみました。
もしも同様の症状に直面された場合に、ご参考になれば幸いです。

注意：
インターネット VPN の性質上、設定の適合性や Azure 側の障害の有無如何によらず、経路上の状況によっては予期しない瞬断や性能の低下が発生する可能性があります。
より安定した接続性能を必要とするシステムでは、ExpressRoute のご利用もご検討ください。
また記載の内容は本稿作成時点の情報を基準としております。将来的に予告なく変更される可能性もありますことをご容赦ください。

1．VPN デバイス側の IPSec 設定パラメーターが、Azure が想定している値と一致していない。

「Azure 管理ポータル上のサイト間接続の状態が、接続と切断を繰り返す」といった状況の場合、VPNデバイスの設定パラメーターに問題がある場合がございます。

Azure とサイト間接続を構成する VPN デバイスの要件については、以下の技術情報をご参照ください。

https://msdn.microsoft.com/ja-jp/library/azure/jj156075.aspx

特に過去のお問い合わせでは、以下のような点が原因となっていた傾向がございます。

• ポリシーベースVPN(静的ルーティングゲートウェイに対応)とルートベースVPN (動的ルーティングゲートウェイに対応) の選択が、実際のAzure ゲートウェイの動作モードと一致していない。
• SA Lifetime の数値が一致していない。

なお、誠に恐れ入りますが、公開済みのテンプレート以外には、個々の VPNデバイスの設定方法については弊社サポートの範囲外となります。
VPN デバイスの設定方法については、各デバイスの供給元にご照会いただきますようお願いいたします。

2．オンプレミス側からAzure 仮想ネットワークまでの経路が循環している

「Azure 管理ポータル上はサイト間接続が行えているのに、仮想ネットワーク上の仮想マシンと全く通信ができない」といった場合、オンプレミス側のルーターの経路設定が循環している可能性があります。
オンプレミス側の端末より、仮想ネットワーク上の仮想マシンに対し、tracert や Ping を実行することで状況を切り分けることが可能です。

Windows OS に同梱されている ping コマンドの場合、以下のように「TTL が 期限切れになりました」といったメッセージが表示されます。

3． MTU の問題

「Ping は疎通するのに、VPN トンネルを経由したファイルのコピーなどが著しく遅い」といった状況の場合、経路上の MTU が影響している場合があります。
この事象と対策につきましては、以下のサポート技術情報をご参照下さい。

Microsoft Azure の VPN 接続が不安定になる問題
https://support.microsoft.com/ja-jp/kb/2902923/

4．Quick Mode  SA の Idle Timeout

現行のAzure ゲートウェイの仕様として、5分間 Idle (無通信) 状態になった Quick Mode SA を破棄いたします。「約5分おきに、VPNデバイスのログにSA破棄のログが記録される」という状況の場合、このパターンに該当している可能性があります。
再度通信が発生したタイミングで、Quick Mode SA の再作成が行われますが、Quick Mode SA の再作成が完了するまでの間、わずかな時間 Ping の疎通が失敗するといった現象が発生する場合があります。
オンプレミス側より定期的にAzure 仮想ネットワークに対してPingなどの通信を行うことで、Idle Timeoutを回避することができます。

5. サブネットの定義がAzure とオンプレミス側のデバイスで一致していない。（静的ルーティングゲートウェイ使用時）

静的ルーティングゲートウェイを使用している場合、Quick Mode SAの確立は ネットワークアドレス単位で行われます。
ネットワークアドレスに関する設定が、Azure 管理ポータル上で設定したものと、オンプレミス側の VPN デバイスの側で完全一致している必要があります。
これは、静的ルーティングゲートウェイ構成時に使用されるポリシーベース VPN の特性上、Quick Mode SA の確立に際して、ローカルネットワークとリモートネットワークのネットワークアドレス空間の情報が、認証情報 (Proxy-ID)として使用されるためです。

例えば、Azure 管理ポータル上で、仮想ネットワークのアドレス空間と、ローカルネットワークのアドレス空間として、以下の内容が定義されていたとします。

仮想ネットワーク側：
192.168.11.0/24
192.168.22.0/24

ローカルネットワーク：
192.168.88.0/24
192.168.99.0/24

この時、以下の計4本の Quick Mode SA が確立できるように VPN デバイスの設定を記述する必要があります。

 192.168.11.0/24 と 192.168.88.0/24
 192.168.11.0/24 と 192.168.99.0/24
 192.168.22.0/24 と 192.168.88.0/24
 192.168.22.0/24 と 192.168.99.0/24
 
 
「静的ルーティングゲートウェイを使用しており」かつ「仮想ネットワークまたはローカルネットワークにアドレス空間を増やした途端に不安定になった」という場合、このパターンに該当している可能性が高いと考えることができます。

なお、この事象については以下の点にご留意ください。

• VPN デバイスによっては、1本のVPNトンネルに対し、複数の QuickMode SA を確立させる機能が備わっていない場合があります。
• また、仮に設定が行える場合でも、設定の記述が複雑になりがちです。
  VPNデバイスが動的ルーティング（ルートベースVPN）に対応している場合は、ルートベースVPNを使用した方が一般的に VPN デバイス側の設定が簡易になります。

6．PFS に関する設定の不一致 （動的ルーティングゲートウェイ使用時）

2014 年末のアップデートにより、VPN トンネルのセキュリティを向上させるパラメーターとして、PFS (Parfect Forward Security) が使用できるようになりました。
VPN デバイスで PFS を有効にする場合、Azure ゲートウェイ側でも明示的に PFSを有効にする必要があります。
これには、以下のコマンドを実行します。

VPN デバイス側と Azure 側の設定が一致していない場合、確立していた VPN 接続が突然切断したままになるといった現象が発生することがあります。

PFS は VPN トンネルのセキュリティを向上させるテクノロジーですが、DH 鍵交換を定期的に実施するという性質上、処理上のオーバーヘッドが発生いたしますのでご留意下さい。Azure のサイト間接続においては、PFS の使用は必須ではありません。

こんにちは、Windows プラット フォーム サポートの進藤です。

Windows Server 2003 のサポート期限も間近に迫り、サーバーのアップグレード作業を実施されている方も多くいらっしゃるかと思います。

アップグレード作業では、新しいサーバーをドメインに追加した後に、それまで使用していたサーバーを降格するという方法が一般的ですが、その作業を実施した際に、新しいサーバーが正常にドメイン コントローラーとして機能していないというトラブルに見舞われることもあります。

このとき、新しいドメイン コントローラーでは SYSVOL や NETLOGON が共有されていない状態かもしれません。

そのような状況に陥らないように、また、陥った場合のトラブルシューティング方法として、FRS ジャーナル ラップ エラーについて取り上げます。

Active Directory の複製

Active Directory はマルチ マスタ レプリケーション モデルとなっているため、プライマリとバックアップという区別はなく、すべてのドメイン コントローラーがマスターとなります。このため、各ドメイン コントローラー間で情報の複製が行われていますが、複製は大きく 2 つに分かれており、ユーザーやコンピューターの情報が格納された「Active Directory のデータベース」の複製とグループ ポリシーの設定情報が格納された 「SYSVOL フォルダー」の複製がそれぞれ行われています。

この「SYSVOL フォルダー」の複製は FRS または DFSR というサービスにより実施されており、Active Directory おける下記の現象は、 FRS または DFSR の問題により発生していることもあります。

・ 新規で追加したドメイン コントローラーで SYSVOL と NETLOGON フォルダーが共有されない
・ クライアントにグループ ポリシーが思ったように適用されない

特に FRS を利用している環境では「ジャーナル ラップ エラー」が発生しているために FRS が正しく機能していないことがあり、ドメインの移行作業が失敗するというお問い合わせも多く寄せられています。

グループ ポリシーの仕組み

まずは「ジャーナル ラップ エラー」について説明する前に、グループ ポリシーの仕組みについて解説します。

Active Directory のグループ ポリシーの情報はリンク先の情報などが含まれている「Active Directory データベース」と、設定値などが含まれている「ファイル」の 2 つの組み合わせにより構成されています。

この「ファイル」の部分は、SYSVOL (%systemroot%\sysvol) というフォルダーに配置されていて、ファイル共有により、ドメインに所属しているクライアントやサーバーに提供されます。

ドメイン コントローラー上で SYSVOL や NETLOGON フォルダーが共有されているかどうかは、net share コマンドにより確認することができ、Active Directory の正常性確認項目の一つにもなっています。

正しくフォルダーが共有されている場合は、次のように net share コマンドの結果に、NETLOGON と SYSVOL の行が表示されます。

もしも、ドメイン コントローラーで SYSVOL フォルダーが共有されていないと、クライアントがグループ ポリシーを取得できず、更新されたグループ ポリシーの内容がクライアントに反映されなかったり、また、追加したドメイン コントローラーに SYSVOL の情報が複製されないといったことが起こります。

グループポリシーのレプリケーションの仕組み

グループ ポリシー管理エディタによりグループ ポリシーを編集すると、既定では PDC エミュレーターの役割を持つドメイン コントローラー上の SYSVOL フォルダー上にあるファイルが更新されます。

そして、ファイル レプリケーション サービスにより、その SYSVOL 内のファイルがドメイン内のすべてのドメイン コントローラーに複製されます。

ドメイン コントローラー間のファイル レプリケーションの方式は、冒頭でお伝えした通り、FRS と DFSR の 2 種類あり、Windows Server 2003 以前では FRS が、 Windows Server 2008 以降では FRS に加えて DFSR が使用可能です。

    - FRS (File Replication Service)
    - DFSR (Distributed File System Replication)

ただし、ドメイン コントローラーが Windows Server 2008 以降の OS しか存在していなかったとしても、その環境が Windows Server 2003 から移行された環境の場合には、引き続き FRS が使用されます。

また、FRS から DFSR へ移行することもできますので、移行方法や、現在どの方式を使っているかを確認したい場合は、過去の記事「FRS から DFSR への移行 (SYSVOL)」を参考にしてみてください。

  FRS から DFSR への移行 (SYSVOL)

  http://blogs.technet.com/b/jpntsblog/archive/2009/12/04/frs-dfsr-sysvol.aspx

トラブル シューティング

上述のように、ドメイン コントローラー上で SYSVOL や NETLOGON フォルダーが共有されていない、もしくは、ファイル レプリケーション サービスでエラーが発生していると、クライアントにて、グループ ポリシーの内容が反映されないといったトラブルが発生します。

このような現象が発生した場合は、一つの確認ポイントとして、ドメイン コントローラーで net share コマンドを実行して、SYSVOL と NETLOGON フォルダーが共有されているかどうか確認します。
また、サービスが起動しているか、またファイル レプリケーション サービスのイベントログにエラーが記録されていないか確認してみましょう。

サービスの起動状況は [スタート] - [管理ツール] - [サービス] から確認します。
FRS を使用している場合は "File Replication Service" が、DFSR を使用している場合には "DFS Replication" が "開始" になっていることを確認します。

イベントログは [スタート] - [管理ツール] - [イベント ビューアー] - [アプリケーションとサービス ログ] から確認します。
FRS を使用している場合は "ファイル レプリケーション サービス" を、DFSR を使用している場合には "DFS Replication" を確認します。

* ファイルの複製元のドメイン コントローラーでエラーとなっていることもあるため、すべてのドメイン コントローラーでサービスとイベントログを確認します。

ジャーナル ラップ エラーの例

FRS を利用している環境で特に多いエラーが「ジャーナル ラップ エラー」です。

ジャーナル ラップ エラーが発生すると、ファイル レプリケーション サービスのイベントログに、下記のような ID 13568 のイベントが記録されます。

また、ntfrsutl sets コマンドを使ってレプリカ セットを確認したときに、次のように「JRNL_WRAP_ERROR」と表示される場合は、FRS でジャーナル ラップ エラーが発生しており、ファイル レプリケーション サービスが正常に機能していない状態です。

なお、正常時にはこのように表示されます。

ntfrsutl.exe は Windows Server 2008 以降では標準で搭載されておりますが、Windows Server 2003 ではサポート ツールの中に含まれています。

  Windows Server 2003 Service Pack 2 32-bit Support Tools

  http://www.microsoft.com/en-us/download/details.aspx?id=15326

ジャーナル ラップ エラーとは

FRS サービスではファイルの複製を管理するために、ファイルやフォルダーの更新情報が記録されたジャーナル ログを利用しています。
しかし、このジャーナル ログは固定サイズの循環ログであるため、例えば、大量にファイルの更新処理が行われた場合には、ジャーナルが循環してしてしまい、最後に確認した情報を確認できないというエラーが発生する場合があります。これが、ジャーナル ラップ エラーという現象です。

このジャーナルラップエラーは一般的に、 FRS サービスの長期停止や、ウィルススキャンソフトによる属性変更による大量の変更検知によるジャーナルファイルの循環、また、予期せぬシャットダウンによるデータベースファイル破損等の理由により発生します。
ちなみに、ジャーナルラップエラーは、 DFSR では、自動回復機能がありますので、発生したとしても即座に回復処理がおこなわれるので、対処という観点で心配は不要です。

第二回目は、ジャーナル ラップ エラーの修復方法について解説します。

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

前回は、FRS ジャーナルラップエラーの概要とその確認方法について紹介しました。
続いて、今回は FRS ジャーナル ラップ エラーの具体的な対処方法について解説します。

ジャーナル ラップエラーの修復を行う前に確認すべきこと

修復作業を行う前に、次の点に問題がないか確認することが重要です。

  1.  各ドメイン コントローラーの SYSVOL の内容が同じであること
  2.  Active Directory の複製が正常に行われていること

以下に、その詳細と確認方法を紹介します。

1.  各ドメイン コントローラーの SYSVOL の内容が同じであること

ジャーナル ラップエラーの一般的な修復作業では、エラーが発生したドメイン コントローラー上の SYSVOL の内容を一旦削除して、複製パートナーから複製して修復を行います。

そのため、修復作業を行う前に、複製パートナーの SYSVOL の情報が正しい状態 (整合性がとれた状態) であることを確認する必要があります。

これは、ジャーナル ラップエラーが生じたドメイン コントローラーが、実は正しいデータを保持していた、という場合もあるためです。もしも、複製パートナーの SYSVOL の内容に一部不足が生じている場合は、不足している情報を手動でコピーした後に修復作業を行います。

- 確認方法

Windows Server 2003 では、リソース キットに入っている gpotool.exe を使用して、SYSVOL の整合性を確認することができました。

また、Windows Server 2012 以降では、グループ ポリシー管理コンソール (GPMC) が改良され、GUI を用いて整合性を確認できるようになっています。

  グループ ポリシー インフラストラクチャの状態を確認する

  https://technet.microsoft.com/ja-jp/library/jj134176.aspx

では、Windows Server 2008 や Windows Server 2008 R2 で確認する場合はどうするか？

Windows Server 2003 のリソース キットに入っている gpotool.exe を Windows Server 2008 や Windows Server 2008 R2 にコピーして使用すると、整合性に問題がないにも関わらず、エラーが表示されたりと、正しく結果が正しく表示されない場合があるため推奨していません。

過去に弊社のサポート サービスをご利用いただいた方でしたら、トラブルシューティングで利用する  MPS レポート ツールの中に Windows Server 2008 で正常動作する gpotool.exe が含まれていますので、そのレポート ツールを各ドメイン コントローラーで実行するのも一つの方法です。整合性が取れている場合は レポートの中に出力される gpotool の結果ファイルの最後の行に「Policies OK」と記載されます。

その他の方法としては、標準でインストールされている robocopy.exe コマンドを使用して、ドメイン コントローラー間で SYSVOL フォルダー内の内容に差異がないかを確認することも可能です。

robocopy.exe はファイルやフォルダーをコピーするためのツールですが、/L オプションを指定することで、コピーは行わずに、フォルダーの差分を確認することができます。

例えば、グループ ポリシーのファイルが編集される PDC エミュレーターの役割を持つドメイン コントローラー上で robocopy.exe を実行し、他のドメイン コントローラーの SYSVOL フォルダーと比較することで、整合性が取れた状態かどうかを確認することができます。

  Robocopy

  http://technet.microsoft.com/ja-jp/library/cc733145(v=ws.10).aspx

具体的には、ドメイン名が contoso.com で、比較先のドメイン コントローラーの名前が DC02 の場合は、下記のようなコマンドを実行します。

robocopy C:\Windows\SYSVOL\domain\Policies \\DC2\sysvol\contoso.com\Policies /V /L /E /COPYALL /LOG:C:\policies_diff.log

robocopy C:\Windows\SYSVOL\domain\Scripts \\DC2\sysvol\contoso.com\Scripts /V /L /E /COPYALL /LOG:C:\scripts_diff.log

「Policies」フォルダーには「グループ ポリシーの構成ファイル」が、「Scripts」フォルダーには「ログオンスクリプトなどのスクリプト」が格納されていますので、上記のコマンドでは各フォルダーで差分がないか確認しています。

/LOG オプションで指定したファイルの中に、ファイルやフォルダーの比較結果が記録されますので、「同じ」と記録されている場合は、ファイルが複製されて整合性が取れている状況を示します。

もしも、ジャーナル ラップ エラーが発生したドメイン コントローラー以外にファイルの整合性が取れていないサーバーが存在する場合は、ジャーナル ラップ エラーの復旧作業を行う前に、その原因について調べる必要があります。 

2.  Active Directory の複製が正常に行われていること

FRS の複製は、Active Directory データベースを複製する際のトポロジが利用されます。
そのため、FRS に関わるエラーを修復するためには、Active Directory データベースの複製も正常に行われている必要があります。

- 確認方法

ジャーナル ラップ エラーが発生したドメイン コントローラーで、コマンド プロンプトを起動して repadmin /showrepl コマンドを実行し、Active Directory のデータベースの複製が正常な状態であることを確認します。

もしも、複製が成功していない場合は、ジャーナル ラップ エラーの復旧作業を進めることができません。先に Active Directory データベースの複製エラーを復旧させる必要があります。

FRS ジャーナル ラップ エラーの復旧手順

ドメイン内のすべてのドメイン コントローラーで SYSVOL の整合性が取れており、Active Directory の複製が正常に行われている場合は、ジャーナル ラップ エラーを修復する準備が整った環境となりますので、続いて、修復作業に進みます。

burflags について理解しよう

ジャーナル ラップ エラーの復旧では、レジストリ値 burflags に D2 もしくは D4 のいずれかの値を設定して作業を行います。この burflags に D2 と D4 のどちらの値を設定するかについて、十分理解した上で作業を進める必要があります。

FRS はサービス起動時に burflags に設定された値を確認して、他のドメイン コントローラーから SYSVOL のファイルの複製を行うかどうかを判断しています。

burflags に D2 が設定されている場合は、ファイルの複製に関して権限がないことを示すため、サービス起動時に他のドメイン コントローラーから自身に対して SYSVOL のファイルの複製を行います。 一方、D4 が設定された場合は、自身がファイルの複製に関して権限がある (マスターである) ことを示し、サービス起動時は他のドメイン コントローラーから SYSVOL のファイルの複製は行いません。

burflags の設定例

burflags に D2 と D4 のどちらを設定するかは、ジャーナル ラップ エラーが発生した状況に応じて判断します。
以下に、3 つのシナリオにおける burflags の設定例と、復旧方法について説明します。

■  シナリオ1

ドメイン内にドメイン コントローラーが 1 台しか存在しておらず、そのサーバーでジャーナル ラップ エラーが発生している。

このシナリオの場合は、ジャーナル ラップ エラーが発生したドメイン コントローラーで burflags に D4 を設定して復旧を行います。これにより、エラーが発生したサーバーで FRS データベースの初期化が行われ、また自身をマスターとして起動させる処理が行われます。

* このシナリオには、これまでドメイン コントローラーを 1 台で運用しており、リプレースのため、新しくドメイン コントローラーを追加したものの、既存のドメイン コントローラーでジャーナル ラップ エラーが発生していた、というケースも含まれます。

この場合は、追加したドメイン コントローラーでは SYSVOL が共有されていない状況となっていることが想定されますが、ジャーナル ラップ エラーが解消されると、追加したドメイン コントローラー側で自動的に複製が開始されて、最終的に SYSVOL が共有されることが期待されます。

■  シナリオ2

ドメイン内にドメイン コントローラーが複数存在しており、その中の 1 台だけでジャーナル ラップ エラーが発生している。

この場合は、ジャーナル ラップ エラーが発生したドメイン コントローラーで、burflags に D2 を設定して FRS データベースの初期化を行い、他のドメイン コントローラーから SYSVOL の情報を複製して修復を行います。

■  シナリオ3

ドメイン内にドメイン コントローラーが複数台あり、全台のドメイン コントローラーでジャーナル ラップ エラーが発生している。

この場合は、通常、グループ ポリシーが編集される PDC エミュレーターの役割を持つドメイン コントローラーがマスターとなるため、PDC エミュレーター上で  burflags に D4 を設定して、その他のドメイン コントローラーで D2 を設定します。

ただし、この復旧作業を行う場合は、作業を行う順番に気を付ける必要があります。

まずは、すべてのドメイン コントローラーで FRS のサービスを停止させます。そして、マスターとなるサーバーで D4 を設定して FRS サービスを起動します。続いて、その複製パートナーとなっているサーバーで 1 台ずつ、D2 を設定して、FRS データベースの初期化と SYSVOL の初期化作業を行う作業を行います。その後、順番に、残りの複製パートナーで 作業を進めます。

以下に、各シナリオの具体的な対処方法を紹介します。
なお、シナリオ3 は稀であり、復旧するためにいろいろと考慮も必要になるため、手順は割愛します。(もしも該当してしまった場合には、弊社サポート サービスのご利用をご検討ください。復旧について支援させていただきます！)

- シナリオ1 の復旧手順

概要:

これまで運用してきた既存のドメイン コントローラーで FRS データベースの再作成を行い、SYSVOL のマスターにするフラグをセット (burflags に D4 を設定) して、他のドメイン コントローラーに SYSVOL の情報を複製させて復旧させます。

対処作業による影響:

この対処作業では FRS のサービスの再起動を行いますが、システムの再起動を行う必要ありません。 FRS サービスを停止させて作業を行うため、作業の間はドメイン コントローラー間のファイルの複製が行われなくなります。 ユーザーやコンピュータの認証へは影響はありません。

作業手順:

1. バックアップ
レジストリやコマンドによる作業となるため、万一の場合に備えて、ジャーナルラップエラーが発生したドメイン コントローラーでシステム状態 (System State) のバックアップを取得します。

    コマンド ラインを使用してシステム状態のバックアップを作成する

    https://technet.microsoft.com/ja-jp/library/cc753201.aspx
    ※「Windows Server バックアップ」の機能がインストールされていない場合は、機能の追加を行う必要があります。

また併せて、robocopy コマンドを使用して、SYSVOL フォルダー (%systemroot%\sysvol) を他の場所にバックアップします。下記は C:\SYSVOL_Backup というフォルダーにバックアップする例です。バックアップ先はお客様の環境に合わせて変更してください。

  robocopy %systemroot%\sysvol C:\SYSVOL_Backup\ /copyall /E

続いて、以下 2 から 7 までの作業をジャーナルラップエラーが発生したドメイン コントローラー上のみで行います。

2. NTFRS サービスの停止
コマンドプロンプトから net stop ntfrs を実行し、NTFRS サービスを停止します。

3. NTFRS の初期化
以下の 3 つのフォルダ配下のファイルを削除します。フォルダはそのまま残してフォルダ内のファイルのみを削除します。

%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domain

* フォルダやファイルが表示されない場合、メニュー バーの [ツール] - [フォルダ オプション] を選択し、[表示] タブから "すべてのファイルとフォルダを表示する" (Windows Server 2008 R2 以降の場合は "隠しファイル、隠しフォルダー、および隠しドライブを表示する" ) オプションを有効にし、"保護されたオペレーティング システム ファイルを表示しない" オプションを無効にします。
(フォルダ、ファイル等がない場合には省略して構いません)

図: %systemroot%\ntfrs\jet

図: %systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory

図: %systemroot%\sysvol\staging\domain

4. NTFRS 強制同期の設定
4-1. [スタート] - [ファイル名を指定して実行] の順に選択し、regedit と入力します。
4-2. レジストリ エディタの左ペインから、以下のレジストリ キーに移動します。
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backup/Restore\Process at Startup
4-3. レジストリ エディタの右ペインから以下の値をダブル クリックし、値を変更します。
  値 : burflags
  タイプ : REG_DWORD
  設定値 : D4 (16 進数。Default は 0)

5. FRS 再開
コマンドプロンプトで net start ntfrs を実行して NTFRS サービスを起動します。

6. FRS 再開の確認
イベント ビューアーを起動して [アプリケーションとサービス ログ] - [Microsoft] - [ファイル レプリケーション サービス] のイベントログに、ソース: NtFrs、ID: 13516 のイベントが記録されることを待ちます。

7. SYSVOL 共有の確認
コマンド プロンプトを起動し、net share コマンドを実行して、下記のように SYSVOL フォルダーと NETLOGON フォルダーが共有されていることを確認します。

他に、SYSVOL が共有されていないドメインコントローラーが存在する場合は、上記 6 と 7 の作業を、それらのドメイン コントローラー上でも行います。

最後に、下記の 8 の作業をジャーナルラップエラーが発生したドメイン コントローラー上で行います。

8. NTFRS を再起動します。
burflags = D4 を設定した DC では、サービスが終了するまで、マスタとなります。サービスが再起動されることによって自身の burflags 値を直ちにリセットします。
そのため、マスタ DC でコマンドプロンプトにおいて、net stop ntfrs && net start ntfrs を実行して NTFRS サービスの再起動を行います。

- シナリオ2 の復旧手順

概要:

この場合は、ジャーナルラップエラーの発生しているドメイン コントローラーにて、FRS データベースの再作成と SYSVOL の初期化を行い、権限がないことを示すフラグをセット (burflags に D2 を設定) して、複製パートナーのドメイン コントローラーから SYSVOL の情報を複製して復旧させます。

対処作業による影響:

この対処作業では FRS のサービスの再起動を行いますが、システムの再起動を行う必要ありません。
FRS サービスを停止させて作業を行うため、作業の間はドメイン コントローラー間のファイルの複製が行われなくなります。
ユーザーやコンピュータの認証へは影響はありません。

作業手順:

以下 1 から 8 までの作業をジャーナルラップエラーが発生したドメイン コントローラー上で行います。

1. バックアップ
レジストリやコマンドによる作業となるため、万一の場合に備えて、システム状態 (System State) のバックアップを取得します。

    コマンド ラインを使用してシステム状態のバックアップを作成する

    https://technet.microsoft.com/ja-jp/library/cc753201.aspx
    ※「Windows Server バックアップ」の機能がインストールされていない場合は、機能の追加を行う必要があります。

また併せて、robocopy コマンドを使用して、SYSVOL フォルダー (%systemroot%\sysvol) を他の場所にバックアップします。下記は C:\SYSVOL_Backup というフォルダーにバックアップする例です。バックアップ先はお客様の環境に合わせて変更してください。

  robocopy %systemroot%\sysvol C:\SYSVOL_Backup\ /copyall /E

2. (Windows Server 2008 R2 以降の場合) PsTools の入手とインストール
SYSVOL フォルダ配下に含まれるフォルダの削除のために PsTools に含まれる PsExec を使用します。作業に先立ち PsTools を以下のサイトからダウンロードし、任意のフォルダに展開します。

  PsExec

  http://technet.microsoft.com/ja-jp/sysinternals/bb897553(en-us).aspx

3. NTFRS サービスの停止
コマンドプロンプトから net stop ntfrs を実行し、NTFRS サービスを停止します。

4. NTFRS の初期化
以下の 3 つのフォルダ配下のファイルを削除します。フォルダはそのまま残してフォルダ内のファイルのみを削除します。

%systemroot%\ntfrs\jet
%systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory
%systemroot%\sysvol\staging\domain

* フォルダやファイルが表示されない場合、メニュー バーの [ツール] - [フォルダ オプション] を選択し、[表示] タブから "すべてのファイルとフォルダを表示する" (Windows Server 2008 R2 以降の場合は "隠しファイル、隠しフォルダー、および隠しドライブを表示する" ) オプションを有効にし、"保護されたオペレーティング システム ファイルを表示しない" オプションを無効にします。
(フォルダ、ファイル等がない場合には省略して構いません)

図: %systemroot%\ntfrs\jet

図: %systemroot%\sysvol\domain\DO_NOT_REMOVE_NtFrs_PreInstall_Directory

図: %systemroot%\sysvol\staging\domain

5. SYSVOL 配下のフォルダ、ファイルの削除
  %systemroot%\sysvol\domain 配下の下記フォルダをフォルダごと削除します。

  policies
  scripts
  policies_NTFRS_xxxxxxx
  scripts_NTFRS_xxxxxxx
  NtFrs_PreExisting__See_Evntlog
  (xxxxxxx は任意の英数字です。フォルダ、ファイル等がない場合には省略して構いません)

* Windows Server 2008 R2 以降の OS では、上記のフォルダを削除することができません。
2 でダウンロードした PsTools に含まれる PsExec を使用し、削除を実行します。

(Windows Server 2008 R2 以降の場合)

5-1. [スタート] - [コマンドプロンプト] を右クリックし、 [管理者として実行] をクリックします。

5-2. 1 で展開した PsTools のフォルダにカレント ディレクトリを移動します (例. cd c:\PsTools)。
5-3. 以下のコマンドを実行します。ソフトウェアのライセンスの画面が表示されましたら [Agree] をクリックします。
   Psexec.exe -i -s cmd

5-4. 新たに立ち上がったコマンドプロンプトにて rd /s コマンドを実行し、SYSVOL 内の次のフォルダおよび配下のファイルを削除します (例. rd %systemroot%\sysvol\domain\policies /s)。

  %systemroot%\sysvol\domain\policies
  %systemroot%\sysvol\domain\scripts
  %systemroot%\sysvol\domain\policies_NTFRS_xxxxxxx
  %systemroot%\sysvol\domain\scripts_NTFRS_xxxxxxx
  %systemroot%\sysvol\domain\NtFrs_PreExisting__See_Evntlog
  (xxxxxxx は任意の英数字です。フォルダがない場合には省略して構いません)

6. NTFRS 強制同期の設定
6-1. [スタート] - [ファイル名を指定して実行] の順に選択し、regedit と入力します。
6-2. レジストリ エディタの左ペインから、以下のレジストリ キーに移動します。
  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\NTFRS\Parameters\Backup/Restore\Process at Startup
6-3. レジストリ エディタの右ペインから以下の値をダブル クリックし、値を変更します。
  値 : burflags
  タイプ : REG_DWORD
  設定値 : D2 (16 進数。Default は 0)

7. FRS 再開
コマンドプロンプトで net start ntfrs を実行して NTFRS サービスを起動します。

8. FRS 再開の確認
イベント ビューアーを起動して [アプリケーションとサービス ログ] - [Microsoft] - [ファイル レプリケーション サービス] のイベントログに、ソース: NtFrs、ID: 13516 のイベントが記録されることを待ちます。

9. SYSVOL 共有の確認
コマンド プロンプトを起動し、net share コマンドを実行して、下記のように SYSVOL フォルダーと NETLOGON フォルダーが共有されていることを確認します。

- 補足
レジストリエディタの誤った使用は、システム全般に渡る重大な問題を引き起こす可能性があります。 こうした問題を解決するためには、Windows をインストールしなおさなければいけません。 Microsoft では、レジストリエディタを使用することによって引き起こされた障害の解決については、一切保証しておりません。 レジストリエディタを使用する場合には、お客様の責任において使用してください。

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

Windows プラットフォーム サポート担当の秋山です。

今日は、Active Directory オブジェクトにおけるアクセス許可リスト (ACL) の NTFS のアクセス権の場合とは異なる意外な動作についてご紹介したいと思います。
OU のプロパティの [セキュリティ] タブで、"すべての子オブジェクトの削除 - 拒否" のアクセス許可エントリ (ACE) を Everyone に対して設定したはずなのに、 OU 配下のユーザー オブジェクトを削除できてしまうのはなぜ？？という疑問をお持ちになったことのある方がいらっしゃいましたら、ご一読いただけますと幸いです。

1. 拒否よりも許可が優先される？ Active Directory オブジェクトにおける ACL の意外な動作
----------------------------------
Active Directory オブジェクトにおける ACL の動作は、NTFS アクセス許可とは少し異なります。
具体的には、継承された "拒否" の ACE よりも、オブジェクト自身に対して明示的に設定されている "許可" の ACE の方が優先されます (継承された拒否の ACE の優先度が低い)。

例えば、 OU のセキュリティ設定で "Everyone" に対して、"すべての子オブジェクトの削除 - 拒否" を設定した場合、 OU 配下のユーザー オブジェクトについても上位の OU から継承される "すべての子オブジェクトの削除 - 拒否" の ACE が設定されます。
この状態であれば、OU 配下のユーザー オブジェクトは削除できないようになったと感じます。

しかしながら、OU 配下の各ユーザー オブジェクト自身には、"Account Operators" グループに対して既定で "フル コントロール" の ACE が明示的に設定されています。
そのため、 "Account Operators" グループに所属するユーザーでは明示的な許可の ACE が優先され、 OU 配下のユーザー オブジェクトを削除できます。

このように、NTFS アクセス許可のように継承されてきた ACE も含めて拒否の ACE が許可の ACE よりも優先されるわけではありませんので、ご注意下さい。

2. Active Directory オブジェクトおける ACE の優先順位を決定するルールについて
----------------------------------
Active Directory オブジェクトおける ACE の優先順位は、下記にようなルールに基づいて決定されます。
(ここでは、上位 OU の配下に下位 OU が存在し、下位 OU の配下に対象のオブジェクトが存在していることを想定します。)

ルール 1:
ACE が継承されてきている場合、対象のオブジェクトに最も近い階層の ACE が優先されます。
つまり、対象のオブジェクトに直接設定されている ACE の方が、下位 OU に設定されている ACE よりも優先され、下位 OU に設定されている ACE の方が、上位 OU に設定されている ACE よりも優先されます。

ルール 2:
同じ階層で設定されている ACE に関しては、"許可" よりも "拒否" の方が優先されます。
つまり、例えば下位 OU において Account Operators に対しては "拒否" が設定されており、Everyone に対しては "許可" が設定されていた場合には、Account Operators に所属するユーザーに関しては "拒否" の方が優先されます。

3. 具体例
----------------------------------
最後に具体例を以下にまとめてみました。
A_OU という OU の配下に user1 というユーザー オブジェクトがあります。

- 例 1
A_OU: Account Operators に対して "すべての子オブジェクトの作成/削除" の許可を設定します。
user1: Account Operators に対して "フル コントロール" の許可を設定します。

この例の場合、user1 に明示的な "許可" が設定されていることにより、Account Operators に所属するユーザーは user1 を削除することができます。

- 例 2
A_OU: Account Operators に対して "すべての子オブジェクトの作成/削除" の許可を設定します。また、 Everyone に対して "すべての子オブジェクトの作成/削除" の拒否を設定します。
user1: 明示的な ACE は何も設定されていません。

この例の場合、Account Operators に所属するユーザーに関しては、A_OU に設定されている許可よりも A_OU に設定されている拒否の方が優先されるため、user1 を削除することはできません。

- 例 3
A_OU: Account Operators に対して "すべての子オブジェクトの作成/削除" の許可が設定します。また、 Everyone に対して "すべての子オブジェクトの作成/削除" の拒否を設定します。
user1: Account Operators に対して "フル コントロール" の許可が設定します。

この例は前述のルール 1 とルール 2 が混ざったパターンです。
A_OU に着目すると、許可の ACE よりも拒否の ACE の方が優先されます。
しかし、A_OU から継承されてきた拒否の ACE よりも、user1 に明示的に設定されている許可の ACE の方が優先されるため、Account Operators に所属するユーザーは user1 を削除できます。

- 参考資料
Subordinate Explicit Grant Overrides Inherited Denial
URL: <https://support.microsoft.com/en-us/kb/233419>

Access Control Entry Inheritance for Active Directory Objects
URL: <http://support2.microsoft.com/kb/221241/en-us>

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

こんにちは、Windows プラットフォームサポートの進藤です。

今回は、ユーザーやグループなどの管理者の方への Tips です。

Active Directory ユーザーとコンピューターで一覧を表示すると、既定では、下記のように [名前]、[種類]、[説明] が表示されます。

この一覧に表示される項目は、[表示] メニューの [列の追加と削除] から変更することができますが、[利用可能な列] に表示される項目は必ずしも全ての属性ではなく、一部の属性だけとなっています。

実は、Active Directory の構成情報を変更することで、[利用可能な列] に表示される項目をカスタマイズすることができます。

今回は、グループのプロパティにある [メモ] を追加する方法を例にとってカスタマイズする方法を解説します。

最終的には、下記のように一覧の中に [メモ] の列が表示されることを目指します。

1. 属性名の確認

1-1.  まずは ADSI エディターを使用して、[メモ] が登録されている属性名を確認します。

[スタート] - [管理ツール] - [ADSI エディター] を起動します。

ADSI エディターが起動したら、左ペインの [ADSI エディター] を右クリックして [接続] をクリックします。 

1-2.  [接続の設定] 画面が表示されたら、既定の状態のまま [OK] をクリックします。

1-3.  左パネルから、[メモ] に値が登録されているグループが所属している OU まで展開し、右側に表示されたグループを右クリックして、[プロパティ] を開きます。

1-4.  [属性] の一覧から、メモに登録された内容が入っている属性を探します。下記のように、メモは info という属性に入っていることが分かります。属性名を確認したら、[キャンセル] をクリックして、プロパティの画面を閉じます。

2. 既定で [列の追加と削除] に表示される値が入っている場所を確認

続いて、既定で [列の追加と削除] に表示される値が入っている場所を確認するため、もう一度、ADSI エディターの左ペインにある [ADSI エディター] を右クリックして [接続] をクリックします。 

2-1.  [既知の名前付けコンテキストを選択する] で [構成] を選択して、[OK] をクリックします。 

2-2. 左パネルから [構成] - [CN=Configuration,<ドメインの DN>,CN=DisplaySpecifiers,CN=411 を展開し、右パネルにある [CN=default-Display] を右クリックしてプロパティを開きます。

※ Active Directory ユーザーとコンピューターの表示は CN=DisplaySpecifiers の中で定義されています。日本語は CN=411 です。英語表記の場合は CN=409 になります。

2-3.  属性の一覧から extraColumns を右クリックしてプロパティを開きます。

2-4.  下記のように、CN=default-Display の extraColumns 属性の中に、既定で表示される項目が定義されています。

3. [列の追加と削除] のカスタマイズ

3-1.  続いて、[列の追加と削除] の項目のカスタマイズに進みます。

右パネルから CN=organizationalUnit-Display をクリックして、プロパティを開きます。

3-2.  属性の一覧にある extraColumns に [メモ] に関する値を設定することで、 [列の追加と削除] の一覧の中に [メモ] を追加することができます。

3-3.  次の形式で値を追加します。

<属性名>,<列の表示名>,<既定の表示可否>,<幅>,<未使用>

* <属性名> には、1-4. で確認した属性名を指定します。
* <列の表示名> には、列のヘッダーの表示に指定したい文字列を入力します。
* <既定の表示可否> は既定で表示させる場合は 1 を、非表示にする場合は 0 を設定します。
* <幅> は列の幅をピクセル単位で指定します。-1 を指定した場合は、列のヘッダーのサイズが指定されます。
* <未使用> は、使っていないため、0 を指定します。

値を入力したら、[追加] をクリックして、その後、[OK] をクリックします。

3-4.  Active Directory ユーザーとコンピューターを起動し直すと、一覧の中に [メモ] が表示されます。

3-5.  しかし、この状態で [列の追加と削除] を見てみると、[利用可能な列] が空になっています。

これは、3-3. の CN=organizationalUnit-Display の extraColumns に値を設定すると、その値が既定の値よりも優先されるためになります。

3-6.  もしも、これまで通り、[利用可能な列] に既定の項目も表示させるようにしたい場合は、2-4.  の CN=default-Display の中の extraColumns 属性に入っている値をコピーして、3-3. の CN=organizationalUnit-Display の extraColumns 属性に値を追加します。

CN=default-Display の extraColumns 属性に入っている値をすべて CN=organizationalUnit-Display の extraColumns 属性に追加すると、下記のように、既定の状態に [メモ] が追加された形になります。

補足) 上記の手順は OU における一覧の表示を変える方法となっており、Users などのコンテナーの一覧の表示は変わりません。もしも、Users などのコンテナーの一覧の表示も変えたい場合は、3-1. で CN=organizationalUnit-Display ではなく、CN=container-Display の extraColumns 属性を編集します。

-  参考情報
Modifying Existing User Interfaces

https://technet.microsoft.com/ja-jp/ms677291

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

こんにちは、Windows プラットフォームサポートの小幡です。

今回はワークグループ環境の Active Directory ライトウェイト ディレクトリ サービス (AD LDS) サーバー間でレプリケーションさせるための設定手順について紹介します。

Active Directory ドメイン環境に参加している AD LDS サーバー間でレプリケーションさせる場合とは異なり、下記のような前提条件が存在するため注意が必要です。

• 各 AD LDS サーバー上に同名、同パスワードのローカル ユーザーを作成し、そのユーザーをインスタンスのサービス アカウントとして設定する必要がある。
• 各 AD LDS サーバーを同一のネットワーク セグメントに配置する必要がある。(別々のネットワーク セグメントに配置する場合には、ドメイン環境が必要です。)
• 各 AD LDS サーバーのワークグループ名を同一にする必要がある。

下記に既存のワークグループ環境の AD LDS サーバーに対し、レプリケーション パートナーを追加するための具体的な設定手順を案内します。

- 手順概要

[A] 既存のワークグループ環境の AD LDS サーバーで新規ユーザーを作成する

[B] 新規に作成したユーザーに [サービスとしてログオン] のユーザー権利を与える

[C] 新規に作成したユーザーをインスタンスのサービス アカウントとして設定する

[D] 新規に作成したユーザーを AD LDS 管理者に追加する

[E] 新しく構築する AD LDS サーバーの準備をする

[F] 新規に構築する AD LDS サーバーで既存の AD LDS インスタンスのレプリカを作成する

----------------------------------------

[A] 既存のワークグループ環境の AD LDS サーバーで新規ユーザーを作成する

----------------------------------------

1. 既存のワークグループ環境の AD LDS サーバーにログオンします。

2. [ファイル名を指定して実行] から"lusrmgr.msc" を実行します。

3. 左ペインの [ユーザー] を右クリックし、[新しいユーザー] をクリックします。

4. [ユーザー名] に任意のユーザー名を入力し、パスワードを入力します。

5. [ユーザーは次回ログオン時にパスワードの変更が必要] のチェック ボックスをオフにします。

6. [パスワードを無期限にする] のチェック ボックスをオンにします。

7. [作成] をクリックします。

8. [閉じる] をクリックします。

9. 左ペインの [グループ] をクリックします。

10. 右ペインの [Administrators] を右クリックし、[グループに追加] をクリックします。

11. [追加] をクリックします。

12. 手順 3 ～ 7 で作成したユーザーを選択し、[OK] をクリックします。

13. [OK] をクリックします。

----------------------------------------

[B] 新規に作成したユーザーに [サービスとしてログオン] のユーザー権利を与える

----------------------------------------

1. 既存のワークグループ環境の AD LDS サーバーにおいて、[ファイル名を指定して実行] から"gpedit.msc" を実行します。

2. 左ペインのツリーを [コンピューターの構成] - [Windows の設定] - [セキュリティの設定] - [ローカル ポリシー] - [ユーザー権利の割り当て] の順に展開します。

3. 右ペインの [サービスとしてログオン] を右クリックし、[プロパティ] をクリックします。

4. [ローカル セキュリティの設定] タブの [ユーザーまたはグループの追加] をクリックします。

5. 手順 [A] で作成したユーザーを選択し、[OK] をクリックします。

6. [OK] をクリックします。

----------------------------------------

[C] 新規に作成したユーザーをインスタンスのサービス アカウントとして設定する

----------------------------------------

1. 既存のワークグループ環境の AD LDS サーバーにおいて、コマンド プロンプトを起動します。

2. カレント ディレクトリを %WINDIR%\ADAM へ移動させます。

3. net stop <インスタンス名> を実行し、インスタンスのサービスを停止します。

4. dsdbutil と入力し、Enter を押します。

5. activate instance <インスタンス名> を実行します。

6. change service account <手順 [A] 作成したユーザー名> <手順 [A] で作成したユーザーのパスワード> を実行します。

7. quit を実行します。

8. net start <インスタンス名> を実行し、インスタンスのサービスを起動します。

----------------------------------------

[D] 新規に作成したユーザーを AD LDS 管理者に追加する

----------------------------------------

1. 既存のワークグループ環境の AD LDS サーバーにおいて、[ファイル名を指定して実行] から"adsiedit.msc" を起動します。

2. 左ペインのツリーに表示されている [ADSI エディター] を右クリックし、[接続] をクリックします。

3. [既知の名前付けコンテキストを選択する] から [構成] を選択します。

4. [ドメインまたはサーバーを選択または入力する] を選択し、下のテキスト ボックスに localhost:<インスタンスのポート番号> を入力します。

5. [OK] をクリックします。

6. 左ペインのツリーを [ADSI エディター] - [構成 [localhost:<ポート番号>]] - [CN=Configuration,CN={<DN>}] - [CN=Roles] の順に展開します。

7. 右ペインの [CN=Administrators] を右クリックし、[プロパティ] をクリックします。

8. [属性エディター] 列から [member] を探し、その行をダブルクリックします。

9. [Windows アカウントの追加] をクリックします。

10. 手順 [A] で作成したユーザーを選択し、[OK] をクリックします。

11. [OK] を 2 回クリックします。

----------------------------------------

[E] 新規に構築する AD LDS サーバーの準備をする

----------------------------------------

前述の手順を参照していただき、新しく構築する AD LDS サーバー側の準備を行います。

* 手順 [A] を参照して、新しく構築する AD LDS サーバーにも、手順 [A] で作成したユーザーと同じ名前、パスワードの新規ユーザーを作成します。また、そのアカウントを新しく構築する AD LDS サーバーの Administrators グループに追加します。

* 手順 [B] を参照して、新しく構築する AD LDS サーバーにおいても、新しく作成したユーザーに [サービスとしてログオン] のユーザー権利を与えます。

* [役割の追加] から [Active Directory ライトウェイト ディレクトリ サービス] をインストールしておきます。

* 新しく構築する AD LDS サーバーを、既存のワークグループ環境の AD LDS サーバーと同じネットワーク セグメントに配置します。

* 新しく構築する AD LDS サーバーのワークグループ名を、既存のワークグループ環境の AD LDS サーバーと同じワークグループ名に設定します。

----------------------------------------

[F] 新規に構築する AD LDS サーバーで既存の AD LDS インスタンスのレプリカを作成する

----------------------------------------

1. 新規に構築する AD LDS サーバーにおいて、[管理ツール] から [Active Directory ライトウェイト ディレクトリ サービス セットアップ ウィザード] をクリックします。

2. [次へ] をクリックします。

3. [既存のインスタンスのレプリカ] を選択し、[次へ] をクリックします。

4. インスタンス名と説明を入力し、[次へ] をクリックします。

5. 使用する LDAP ポート番号と SSL ポート番号を入力し、[次へ] をクリックします。

6. [サーバー名] に既存の AD LDS サーバーのホスト名を入力し、[LDAP ポート番号] に既存の AD LDS インスタンスの LDAP ポート番号を入力し、[次へ] をクリックします。

7. [次のアカウント] を選択し、[ユーザー名] に<新規に構築する AD LDS サーバーのホスト名>\<手順 [E] で作成したユーザー名> を入力し、[パスワード] に手順 [E] で作成したユーザーのパスワードを入力し、[次へ] をクリックします。

8. アプリケーション ディレクトリ パーティションを選択し、[次へ] をクリックします。

9. データ ファイルとデータ回復ファイルを格納するパスを指定し、[次へ] をクリックします。

10. [次のアカウント] を選択し、[参照] をクリックします。

11. 手順 [E] で作成したユーザーを選択し、[OK] をクリックします。

12. [パスワード] に手順 [E] で作成したユーザーのパスワードを入力し、[次へ] をクリックします。

13. AD LDS の管理者権限を与えるユーザーを選択し、[次へ] をクリックします。

14. [次へ] をクリックします。

15. インスタンスの作成処理が開始されますので、処理が完了するまでお待ちください。

16. 処理が完了したら、[完了] をクリックします。

- 参考資料

Introduction to Administering AD LDS Replication and Configuration Sets

http://technet.microsoft.com/en-us/library/cc816622(v=ws.10).aspx

日本語の解説は、本記事の後半に記載しています。

Hello, my name is Kazuo Wakabayashi, Premier Field Engineer in Windows Platform technologies.  Today, I would like to explain how to analyze EventLogs easily using Microsoft Message Analyzer (MMA).  Microsoft Message Analyzer is a powerful tool for capturing, displaying, and analyzing data. You can download latest version (currently version 1.3.1) from download center.

Microsoft Message Analyzer

http://www.microsoft.com/en-us/download/details.aspx?id=44226

For more information about MMA, please see the Operating Guide or Message Analyzer team's blog.

Microsoft Message Analyzer Operating Guide

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

MessageAnalyzer (MessageAnalyzer team's blog)

http://blogs.technet.com/b/messageanalyzer/

I would like to resolve this request using MMA.

-Request

There are one Windows Server 2012 R2 Domain Controller, and many client computers. I would like to get information about logon to the domain.

I want to discover logon information about the Administrator. I can find that information by analyzing the EvengLog that is collected from a domain controller.

- Analysis example

I would like to explain an analysis method of security event ID 4768. Event ID 4768 is logged when user logs on to the domain.  A Kerberos authentication ticket (TGT) is requested at the first stage of the logon to the domain, and Event ID 4768 is logged.

Event ID 4768 contains data like:

• User name who logged on to the domain.

• IP address of the client computer

• Date and time

Using this information from Event ID 4768 you can answer questions like:

• Who did logon to domain?

• Where did user logon to domain?

• What time did user logon to domain?

Here is the example Event ID 4768.

Users can log on to the domain from various client computers. As a result, many Event 4768 IDs are logged.  In this case, 1296 events were recorded.  MMA can analyze the event log from the many angles. This request can also be analyzed quickly by MMA.

Let’s analyze the EventLog using MMA and answer the 4 questions.

Analysis Procedure

Overview:

• Step 1. Read security EventLog using MMA

• Alternate Step 1. Save Security Event Log to the evtx file on the domain controller

• Step 2. Analyze captured data or evtx file using MMA
   

Step1. Read security EventLog using MMA

MMA can read EventLog from a remote computer.  In this example, Message Analyzer will capture Event ID 4768 from the domain controller.  

1a. Click "New Session", and Click "Event Logs" in the Add Data Source

1b. In the "New Session" dialog, Check "Security", and type "Eventlog.EventID == 4768 " in filter window.  MMA will collect Event ID 4768 from the Computer you specify.

To read EventLog from remote computer, type the remote computer name next to “Computer” in the New Session dialog.

Note : You must allow "Remote Event Log Management" in the firewall rules.  Also, sometimes MMA can't display event descriptions.  If so, it's possible to gather the evtx logs manually using this alternate step..

Additional Step. Save Security EventLog to the evtx file on the domain controller

Save only Event ID 4768 to evtx file on the domain controller

1a. Log on to the domain controller, and start Event Viewer

Right click Windows Logs – Security, and click "Filter Current Log..."

1b. At the "Includes Event IDs", type 4768 and click OK.

1c. Right click Windows Logs – Security, and click "Save Filtered Log File As..."

(Save only Event ID 4768 to evtx file)

Setp2: Analyze Event Log using MMA

You should install MMA and analyze on a computer that is not the domain controller. If you collected the evtx file on the domain controller, copy it to the computer where MMA is installed.

 If you used MMA to collect the EventLog data remotely, skip to step 2b.

2a. Start MMA, and Open evtx file.

2b. Click a message in Analysis Grid and expand EventData (in Details view).

2c. Right click "TargetUserName ", and click "Add Grouping for 'TargetUserName'"

After step 2c, Data is classified by the TargetUserName in the Analysis Grid.  In this case, "EventData.TargetUserName (153): Administrator" means Administrator logged on 153 times.

Request 1 is resolved.

2-d. Right click "IpAddress ", and click "Add Grouping for 'IpAddress'"

After step 2d, Data is classified by the TargetUserName and 'IpAddress'.  In this case, "EventData.TargetUserName (6): Administrator" means Administrator logged on from 6 computers.

EventData.IpAddress shows IP address of computers.  In this case, " EventData.IpAddress (5) : ::ffff:192.168.1.3" means Administrator logged on 5 times from 192.168.1.3

Request 2 and 3 are now answered.

Expand EventData.IpAddress, You can also check the date and time logon generated.

I resolved all request.

Thank you. If this article is useful to you, I'm very happy.

Microsoft Message Analyzer でセキュリティログ解析

はじめまして。主に Windows プラットフォームを担当している、プレミアフィールドエンジニアの若林和雄です。

今回は、Microsoft Message Analyzer (MMA) を用いたイベントログ解析を紹介します。

Microsoft Message Analyzerは、Microsoft Network Monitor の後継ツールであり、また Network Monitor よりも機能を充実させた、調査支援ツールです。

現時点の最新バージョン 1.3.1 は、以下からダウンロード可能です。

Microsoft Message Analyzer

http://www.microsoft.com/en-us/download/details.aspx?id=44226

MMA では、従来の Nework Monitor では採取できなかった、Loopback Adapter のパケットを採取できる機能や、様々なログを多角的に診断できる機能が備わっています。

MMA に関する詳細情報は、以下 Operating Guide や MessageAnalyzer 開発チームの blog をご参照ください。

-参考情報 : Microsoft Message Analyzer Operating Guide

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

-参考情報 : MessageAnalyzer ( MessageAnalyzer 開発チームの blog )

http://blogs.technet.com/b/messageanalyzer/

今回は、次の依頼を MMA を利用して解決していきます。

-依頼内容

Windows Server 2012 R2 のドメインコントローラー 1 台、多数のクライアントがドメインに参加している環境における、ドメインへのログオン状況を調査したい。

依頼ですが、今回は Administrator のログオン情報を必要としています。ドメインコントローラーから採取したイベントログから、以下の情報が必要です。

-解析例

ドメインへログオンする際に記録されるEvent ID 4768 のセキュリティイベントログの分析方法を解説します。

ドメインへのログオンの最初の段階では、Kerberos認証チケット(TGT) が要求されます。このタイミングでセキュリティイベントログの Event ID 4768 が記録されます。

Event ID 4768 には、ログオンを開始したユーザーの名前や、ログオン操作を行ったクライアントコンピューターの IP アドレスなどがイベントデータに記録されます。

従って、いつ、誰が (どのユーザーが)、どこから (どのクライアントコンピューターから)ドメインへログオンしたのか、を追跡することができます。

以下、Event ID 4768 の一例です。

通常、ドメインには様々なユーザーが、様々なクライアントコンピューターからログオンするため、イベントID 4768 が大量に記録されます。

今回の依頼では、イベント ID 4768 が 1296 件記録されていました。

MMA を使用すれば大量に記録されたイベントログを解析し、様々な角度からデータを分類することができます。今回の依頼も MMA で素早く解析可能です。

今回は、次の 4 つの依頼について MMA で解析を行います。

次の手順で解析を進めます。

手順1. MMA からセキュリティイベントログを読み込み

参考手順.ドメインコントローラー上でセキュリティイベントログを evtx ファイルに保存

手順2. MMA から evtx ファイルを解析

手順1. MMA からセキュリティイベントログを読み込み

MMA では、任意のコンピューターのイベントログを読み込む事ができます。

ここでは、ドメインへコントローラーから ID 4768 のセキュリティイベントログを読み込みます。

1a. MMA の New Session をクリックし、" New Session " の画面の Add Data Source から" Event Logs " をクリックします。

1b. " New Session " の画面で" Security " をチェックし、フィルター条件に" Eventlog.EventID == 4768 " を指定し、Start をクリックします。セキュリティイベントログ、ID 4768 がMMA に読み込まれます。

上記" New Session " の Computer でリモートのコンピューターを指定し、別のコンピューターのイベントログを読み込む事ができます。この場合は、リモートのコンピューター (イベントのデータ元) のファイアーウォールで" リモートイベントのログ管理" の通信を許可して下さい。

また、リモートからイベントログを表示した場合、イベントの説明が表示されない場合があります。この場合、後述の参考手順の方法で対処する事ができます。

参考手順.ドメインコントローラー上でセキュリティイベントログを evtx ファイルに保存

ここでは、ドメインコントローラー上でイベントID 4768 の情報だけを evtx ファイルに保存します。

a. ドメインコントローラーにログオンし、イベントビューアを起動します。Windows ログのセキュリティを右クリックし、" 現在のログをフィルター (L)... " をクリックします。

b. "現在のログをフィルター" の画面の、"イベント ID を含める" の欄に 4768 を指定し、OK ボタンで適用します。

c. Windows ログのセキュリティを右クリックし、" フィルターされたログファイルの名前を付けて保存(G)... " から、イベントID 4768 の情報だけを evtx ファイルに保存します。

手順2.MMA から evtx ファイルを解析

MMA は、ドメインコントローラーとは別のコンピューターにインストールして実行してください。手順 1 で保存した evtx ファイルを、MMA が動作しているコンピューターへコピーし、次の手順を実行します。(MMA から直接イベントログを読み込んでいる場合、2a の手順は省略できます)

2a. MMA を起動し、Open から手順 1 で保存した evtx ファイルを開きます。

2b.画面中央に表示されるデータの中から任意のデータをクリックし、画面下側の"Details 1 " に表示されるデータの EventData を展開します。

2c. EventData を展開して表示される" TargetUserName " をポイントした状態で右クリックします。表示されるメニューの" Add Grouping for 'TargetUserName' " をクリックします。

2c の手順を実行すると、MMA の Grouping 機能により、データがユーザー単位で分類されます。

この例では、2008R2-2$ や 2012R2-DC$ や、Administrator などのユーザー単位で分類されています。末尾に $ がついたユーザーはコンピューターアカウントです。また、ユーザー名の前の () の数字は、各ユーザーのログオン回数を示しています。Administrator では" (153) "と表示されています。

これで、1 つ目の依頼に対する答えが出ました。

次に、ログオン操作が行われたクライアントコンピューターの IP アドレスの分類も追加します。

2d. EventData を展開して表示される " IpAddress " をポイントした状態で右クリックします。表示されるメニューの " Add Grouping for 'IpAddress' "をクリックします。

2d の手順を実行すると、データはユーザー単位と IP アドレス単位で分類されます。この例では、EventData.TargetUserName Administratorを展開しています。

ユーザー名の Administrator の前に" (6) " と表示されているため、Administrator は 6 台のコンピューターからドメインへのログオンを行ったことが解ります。

EventData.IpAddress の列には、ログオン操作を行ったクライアントコンピューターの IP アドレスが表示されます。この例では、Administrator は、IP アドレス 192.168.1.3 のコンピューターからは 5 回、ログオンを行っていることが解ります。

これで、2 と 3 の依頼に対する答えが出ました。

EventData.IpAddress の列を展開すれば、ログオンが発生した日時も確認する事ができます。

これで、全ての依頼に対する答えが出ました。

MMA を利用したセキュリティイベントログの解析例、最後まで読んで下さいましてありがとうございました。本記事が皆様のお役に立てば幸いです。

こんにちは。プラットフォームサポートの工藤です。

2016 年 1 月 1 日以降、 SHA-1 ハッシュ アルゴリズムによって署名されたコード証明書が廃止されます。

[IT 管理者向け] SHA-1 からの移行を推奨しています

http://blogs.technet.com/b/jpsecurity/archive/2014/10/15/sha1-migration.aspx

この廃止に関しまして、マイクロソフトサポートでは多くのお客様からシナリオ別にご質問を頂いています。

この Blog では、お客様からよく頂戴するご質問に回答いたします。

※以下の内容は 2015年 10 月時点での最新の情報になります。

※SHA-1 の脅威に応じて変更が行われる際には、本ページにて改めてアップデートいたします。

Q: 今回廃止の対象となるのは、どのような証明書になるのでしょうか？

A:

今回のSHA-1 廃止ポリシーの対象は、ルート証明書更新プログラムに参加している公的なルート証明機関から発行された SSL 証明書およびコード署名証明書です。

マイクロソフト ルート証明書プログラムに参加している公的な証明機関のリストは以下から確認いただけます。

 Windows and Windows Phone 8 SSL Root Certificate Program (Member CAs)

 http://social.technet.microsoft.com/wiki/contents/articles/14215.windows-and-windows-phone-8-ssl-root-certificate-program-member-cas.aspx

Q: 具体的には、いつ、どのようにして SHA-1 の証明書が廃止されるのでしょうか？

A:

WindowsUpdate 経由で更新プログラムが配信され、SHA1 ハッシュ アルゴリズムが廃止される予定となっております。

詳細な日程につきましては、Update 情報があり次第、情報更新させていただきます。

・ルート証明書更新プログラムに参加している公的なルート証明機関から発行された コード署名証明書

-> 2016 年 1 月 1 日以降に配信予定です。

Q: 独自に証明機関を構築し証明書の発行を行っているのですが、今回の廃止対象となるのでしょうか？

A:

いいえ、証明機関がマイクロソフト ルート証明書プログラムに参加していない場合や、プライベート CA にて発行した証明書については、今回の廃止の対象に該当しません。

Q: ドライバの署名に SHA-1 を利用しているのですが今後どう対応すればいいですか？

A:

カーネルモード ドライバーおよび、ユーザーモードドライバーの署名に関しましては、今回の SHA1 証明書の利用停止の措置の対象外です。

詳細につきましては、以下の  blog をご参照ください。

Windows 10 と SHA-1 廃止ポリシーによるドライバー署名への影響について

http://blogs.msdn.com/b/jpwdkblog/archive/2015/09/18/windows-10-sha-1.aspx

Q: アプリケーションの署名に SHA-1 コード署名証明書を利用しています。

2016 年 1 月 1 日以降に利用を継続するためにはどうすればいいですか？

ユーザー モード アプリケーションにつきましては、今回の SHA1 証明書の利用停止の措置の対象です。

ご利用いただいている OS によっては、ご利用を継続されるにあたり以下のような条件を満たす必要がございます。

Windows Vista および Windows Server 2008　にて

OS サポートが終了するまでの間、2016 年 1 月 1 日を過ぎましても、2020 年 1 月 14 日を迎えるまで、SHA-1 で発行されたコード署名証明書は継続利用いただけます。

※ルート更新プログラムに参加している証明機関も、Windows Vista/Windows Server 2008 で利用する場合に限り、SHA-1 の証明書を発行することが可能です。実際の方針については、ルート証明書更新プログラムメンバーの各証明機関に問い合わせください。

Windows Server 2008 R2 および Windows 7　以降

コード署名された日付が、2016 年 1 月 1 日以前のタイムスタンプとなっているプログラムのみ、2020 年 1 月 14 日までご利用可能となります。

2016 年 1 月 1 日以降は、ルート更新プログラムに参加している証明機関は、SHA1 での証明書の新規発行が不可能となりますので、継続的に利用を検討されている場合はこの日程までにコード署名を行っていただく必要がございます。

※2020 年 1 月 14 日という日程につきましては、SHA-1 に対する脅威の状況に応じて、早まる可能性があります。

Q: アプリケーションの署名に SHA-1 コード署名証明書を利用していますが、

タイムスタンプが存在しない場合はどうなりますか？

// Windows Server 2008 および Windows Vista

SHA1 証明書のご利用を許容しておりますため、2016 年 1 月 1 日以降も利用できる見通しです。

SHA-1 に対する脅威の状況に応じて、早まる可能性があります。

// Windows Server 2008 R2 および Windows 7以降

SHA-1 コード署名証明書にて署名されており、かつタイムスタンプが存在しない場合は、2016 年 1 月 1日以降、署名された証明書およびコードやアプリケーションは、信頼しない証明書・コードとみなされます。

そのため、2016 年 1 月 1 日以降は警告表示が現れるなど、場合によってはご利用になれない可能性がございます。

※参考情報

ルート証明書プログラム

https://technet.microsoft.com/ja-jp/library/cc751157.aspx

Windows PKI - その2 - ルート証明書更新プログラムとは？

http://blogs.technet.com/b/jpntsblog/archive/2009/12/24/windows-pki-2.aspx

マイクロソフト ルート証明書プログラムでの SHA-1 ハッシュ アルゴリズムの廃止

https://technet.microsoft.com/ja-jp/library/security/2880823

マイクロソフト セキュリティ アドバイザリ 3033929

Windows 7 および Windows Server 2008 R2 で SHA-2 コード署名サポートを利用可能

https://technet.microsoft.com/ja-jp/library/security/3033929.aspx

みなさま、こんにちは。

今回は Active Directory ドメイン サービスの移行にて、万が一作業が切り戻しになった場合のための、Windows Server バックアップを使用した切り戻し手順についてご案内いたします。

ドメイン コントローラー (DC) を新しい OS へ移行する場合、スキーマ拡張が伴い、必要に応じてフォレストおよびドメインの機能レベルの昇格をご実施される方も多いのではないかと思います。
この記事では、拡張したスキーマを切り戻す手順、および昇格した機能レベルを切り戻す手順についてフォーカスして説明します。
特に拡張したスキーマや昇格した機能レベルを切り戻すために、1 台の DC でリストアすれば良いのか、それともすべての DC でリストアすれば良いのかという点について、疑問をお持ちになった方がいらっしゃいましたら、ご一読いただければ幸いです。

----------------------------------------
スキーマのロールバックについて
----------------------------------------
スキーマ拡張後、もしくは機能レベルの昇格後にもし作業が切り戻しとなった場合、拡張したスキーマまたは機能レベルをロールバックするためには、基本的にすべての DC においてリストアが必要になります。
これは、任意の 1 台の DC でデータベースの状態が戻ったとしても、リストアした DC 以外が保持しているデータベースの方が新しい情報を保持していると判断され、リストアした DC のデータベースの内容が上書きされてしまうためです。

ここで、それでは 1 台の DC で権限のある復元 (Authoritative Restore) を実施すれば良いのかと思われる方もいらっしゃるかもしれません。
残念ながら、スキーマ パーティションに対して権限のある復元を実施しても、スキーマ情報を完全にロールバックすることはできません。
これは、権限ある復元では、復元対象のオブジェクトのバージョン番号を意図的に高い数値に設定することにより、他の DC から最新の情報が複製されないようにするといった仕組みが取られているためです。
つまり、スキーマ拡張前の新しいスキーマ オブジェクトが存在しない段階では、そもそもオブジェクト自体が存在しないためにバージョン番号を増加させることができず、スキーマの状態を完全に元に戻すことができないのです。

この点については下記の参考資料にも記載がありますので、参考にしていただければ幸いです。

- 参考資料
Active Directory Backup and Restore
https://msdn.microsoft.com/en-us/library/bb727048.aspx

// 該当部分の抜粋
******************************
An authoritative restore will not overwrite new objects that have been created after the backup was taken.
You can authoritatively restore only objects from the configuration and domain-naming contexts. Authoritative
restores of schema-naming contexts are not supported.
******************************

** 補足情報 **
スキーマを拡張する前に、予めスキーマ マスターの出力方向の複製を停止させておき、スキーマ拡張中、または拡張後に問題が発生した場合には、スキーマ マスターだけでリストアするという方法を取られるお客様もいらっしゃいます。
この方法であれば、特に大規模環境の場合、切り戻しに必要な工数を大幅に削減することができます。
しかしながら、出力方向の複製を再開させた後に問題が発覚した場合、スキーマ マスターだけでしかバックアップを取得していないと切り戻しが困難となってしまいます。
そのため、バックアップの取得に関しては、極力すべての DC でご実施されることをお勧めします。

----------------------------------------
機能レベルのロールバックについて
----------------------------------------
昇格したフォレストの機能レベル、ドメインの機能レベルをロールバックする場合においても、すべての DC でリストアが必要になります。

現在どのフォレストの機能レベル、ドメインの機能レベルに設定されているかという情報は、実は下記のオブジェクトの msDS-Behavior-Version という属性に格納されています。

- フォレストの機能レベル
CN=Partitions,CN=Configurations,<フォレスト ルート ドメインの識別名>

※ contoso.com というフォレスト ルート ドメインの場合には、<フォレスト ルート ドメインの識別名> は DC=contoso,DC=com となります。

- ドメインの機能レベル
<ドメインの識別名>

※ sub.contoso.com というドメインの場合には、<ドメインの識別名> は DC=sub,DC=contoso,DC=com となります。

上記のオブジェクトはバックアップを取得する時点で既に存在しているため、そのオブジェクトに対して権限のある復元を実施すれば、機能レベルをロールバックできるのではないかと思われるかもしれません。
しかしながら、権限のある復元で機能レベルをロールバックするという方法は想定されていないため、仮に権限のある復元で上記のオブジェクトの msDS-Behavior-Version の値がもとに戻ったとしても、機能レベルの昇格に伴って使用できるようになった機能に関しても、もとの動作に戻る保証はありません。
このことから、機能レベルをロールバックする際においても、すべての DC でバックアップから復元していただくことをご案内しています。

** 補足情報 **
以前の OS では機能レベルのロールバックはできませんでしたが、Windows Server 2008 R2 以降、条件さえ揃っていれば機能レベルを下げられるようになりました。
例えば、Active Directory のごみ箱が有効になっていないという条件を満たしていれば、Windows Server 2008 R2 の機能レベルから、Windows Server 2008 の機能レベルへ下げることができます。

下記にスキーマおよび機能レベルをロールバックするためのバックアップ手順、復元手順を紹介します。

----------------------------------------
ドメイン コントローラーのバックアップおよび復元方法 (Windows Server 2008 以降)
----------------------------------------
- 概要
Active Directory のデータベース、グループ ポリシーのための構成ファイルを格納した SYSVOL フォルダー配下など、DC が必要とする情報はシステム状態に含まれます。
下記の手順を実施することにより、システム状態のバックアップおよび復元を実施できます。

******************************
バックアップ手順
******************************
1.Windows Server バックアップのインストール
  1-1. バックアップを作成する DC でサーバー マネージャーを起動し、[機能] を右クリックし、表示されるメニューから [機能の追加] をクリックします。
    (* Windows Server 2012 以降では [管理] - [役割機能の追加] になります。)
 
  1-2. 機能の一覧から "Windows Server バックアップの機能" を選択し、[次へ] をクリックします。
    (* Windows Server 2012 以降では "Windows Server バックアップ" という表記になります。)
 
  1-3. [インストール] をクリックします。
 
  1-4. インストールが完了しましたら、[閉じる] をクリックします。

2. システム状態のバックアップ
  2-1. バックアップを作成する DC 上でコマンド プロンプトを起動します。
 
  2-2. 次のコマンドを実行し、システム状態データをバックアップします。
    wbadmin start systemstatebackup -backupTarget:<ボリューム名> -quiet
   
※ <ボリューム名> はバックアップ データ保存先を指定します。Windows Server 2008 R2 では、共有フォルダーのパスを指定することも可能です。

※ Windows Server 2008 で "エラー - バックアップの場所は重要なボリュームです" が表示された場合は、下記 URL をご参照ください。
Windows Server 2008 でシステム状態のバックアップを実行するとエラー メッセージ "エラー - バックアップの場所は重要なボリュームです" が表示される
http://support.microsoft.com/kb/944530

******************************
復元手順
******************************
※ 復元を実施される際は、リストア済みのコンピューターとリストア前のコンピューターの間で通信がされない状態してください。もしリストア前のものとリストア後のものの間で複製処理が実施されてしまうと、リストアした情報がリストア前の情報で上書きされてしまいます。

(a) ドメインに存在する DC 全てをバックアップから復元する場合の 1 台目、又はドメインに DC が 1 台のみの環境
1. 復元を行う DC を再起動します。

2. システム起動直後に、F8 キーを押し、詳細ブート オプション メニューを表示します。

3. [ディレクトリ サービス復元モード] を選択し、起動します。

4. コマンド プロンプトを起動します。

5. 次のコマンドを実行し、システム状態データの "バージョン識別子" を確認します。
  wbadmin get versions

6. 更に次のコマンドを実行し、システム状態データのリストアを行います。
  wbadmin start systemstaterecovery -version:<バージョン識別子> -authsysvol -quiet

7. 完了後、システムを再起動します。

(b) 他の DC が存在する場合
1. 復元を行う DC を再起動します。

2. システム起動直後に、F8 キーを押し、詳細ブート オプション メニューを表示します。

3. [ディレクトリ サービス復元モード] を選択し、起動します。

4. コマンド プロンプトを起動します。

5. 次のコマンドを実行し、システム状態データの "バージョン識別子" を確認します。
  wbadmin get versions

6. 更に次のコマンドを実行し、システム状態データのリストアを行います。
  wbadmin start systemstaterecovery -version:<バージョン識別子> -quiet

7. 完了後、システムを再起動します。

----------------------------------------
参考資料
----------------------------------------
Windows Server バックアップ
http://technet.microsoft.com/ja-jp/library/cc754572(WS.10).aspx

Windows Server 2008 における Active Directory のバックアップと復元
http://technet.microsoft.com/ja-jp/magazine/2008.05.adbackup.aspx

ステップ バイ ステップ ガイド - AD DS のバックアップと回復
http://technet.microsoft.com/ja-jp/library/cc771290(WS.10).aspx

システム状態データ
http://technet.microsoft.com/ja-jp/library/cc785306.aspx

コマンド ラインを使用してシステム状態のバックアップを作成する
http://technet.microsoft.com/ja-jp/library/cc753201(WS.10).aspx

AD DS の権限のない復元の実行
<http://technet.microsoft.com/ja-jp/library/cc730683(WS.10).aspx>

Network 担当の望月と申します。

今回は、LBFO (Load Balancing and Failover) と NLB (Network Load Balancing) を併用する際の注意事項についてご紹介致します。


1. 事例のご紹介



　　　　　　　　　　　　　　　　　図 1. ネットワーク構成例 (1)



　　　　　　　　　　　　　　　　　図 2. ネットワーク構成例 (2)


上記いずれの構成も、NLB クラスター IP アドレス宛の通信は、ルーター (L3 スイッチ) や L2 スイッチでパケットがフラッディングし、最終的に LBFO によってチーミングを構成する全ての NIC アダプターに到達致します。
このとき、NIC チーミングでスタンバイ アダプターを指定し、"アクティブ / スタンバイ" の構成を取っていたとしても、スタンバイの NIC アダプターで受信したパケットは破棄されず TCPIP.sys ドライバーに転送されます。
その結果、アクティブ アダプター経由およびスタンバイ アダプター経由で同一のパケットを重複して受信することとなります。

以下は、上述の構成において、クライアントからサーバーに Web アクセス (TCP 80 番ポート使用) を行った際の通信シーケンス例となります。
クライアント、サーバー共に相手からの応答待ちで再送要求が発生し、通信遅延が発生していることが確認できます。
同一構成で帯域制御装置のみ存在しない場合には通信遅延が発生しないことから、帯域制御装置の動作が影響して遅延が発生していることが想定されます。


　　　　　　　　　表 1. クライアント (10.100.192.100) 上で取得したパケット キャプチャー

※ Frame 2 で Reset を受信しておりますが、3 Way-hand-shake には影響はありません。
※ Frame 5 で HTTP Request を送信してますが、応答がなく再送を 3 回繰り返し、おおよそ 4 秒後にサーバーが応答している状況が確認できます。


　　　　　　　　　表 2. サーバー (10.120.172.101) 上で取得したパケット キャプチャー

※ Frame 1 および Frame 2 で、同時刻にクライアントから Syn を 2 つ受信しており、Frame 3 で Reset を応答しています。
※ Frame 4 にて Syn / Ack を送信するものの応答が無く、Frame 5 の再送後、約 4 秒後に HTTP Request を受信しています。

2. 対処方法について

上記のような通信遅延が発生する事例において、チーミング モードを "LACP" または "静的" として構成することで、現象が改善したという報告がございます。
当該事例では、チーミング モードを "LACP" または "静的" にて設定することで 2 つの Syn パケットを受信することが無くなり、その結果 Reset 応答をしなくなったことが改善の要因と考えられます。

以上より、LBFO と NLB を併用するような環境においては、チーミング モードは "LACP" または "静的" にて設定いただくことを推奨致します。


3. 参考

NIC チーミングの概要
https://technet.microsoft.com/ja-jp/library/hh831648.aspx

何でも屋: 可用性に対応する
https://technet.microsoft.com/ja-jp/magazine/jj149029.aspx

こんにちは。Windows プラットフォーム サポートの馬場です。

今回は Windows Server 2012 R2 (以降 2012 R2) のドメイン環境でコンピューター名を変更する際の注意点についてご紹介します。
※ “2012 R2 のドメイン環境” とは、 ドメイン コントローラーとして 2012 R2 が含まれているという意味で使用しています。
1 台でも 2012 R2 がドメイン コントローラーとして含まれている場合には、今回ご紹介します事象の影響を受ける可能性がございます。

どのような問題なのか？

サーバーの入れ替え作業で、一旦別名でサーバーを設定した上で、データの移行作業を完了してから移行対象のサーバー名に変更するなど、ドメインに参加したコンピューター名を変更することがあると思います。

ドメイン メンバーの名前変更により実行される処理は、各コンピューターのローカルに保持している情報を更新するだけでなく、
ドメイン コントローラーが保持するコンピューター オブジェクトの情報も更新する必要があります。

具体的には、コンピューター オブジェクトの名前変更だけでなく、そのオブジェクトに紐付けられた Kerberos 認証で利用する Service Principal Name (SPN) 情報の更新も含まれます。
Windows Server 2012 R2 のドメイン コントローラーでは、 SPN に含まれる情報のフォーマットを厳密にチェックしており、
本来ポート番号として数字が入る部分に、文字列が含まれているとコンピューター名の変更処理でエラーを返します。

結果としてコンピューター名を変更できない、あるいは中途半端なかたちで変更されることがあるという問題が生じます。
この問題が発生しないようにするためには、変更対象のコンピューターに問題を生じさせるような SPN が含まれていないか事前に確認する必要があります。

SPN は、次の情報によって構成されております。
 - サービスの名前 (ポート番号)
- サービスを実行するコンピューター
- サービス アカウント
 
SPN の一般的なフォーマットは以下の通りです。

 サービス アカウント / サービスを実行するコンピューター:ポート番号 / 識別名

 SPN のフォーマットの詳細については、英語の資料となりますが、以下の URL にも記載がございますので、こちらも併せてご参照ください。
 
[タイトル] Name Formats for Unique SPNs
[URL]　https://msdn.microsoft.com/en-us/library/ms677601(v=vs.85).aspx

以下に、どのような問題が発生するのか、具体的に示します。

1.  [コントロール パネル] の [システムとセキュリティ] - [システム] からコンピューター名を DOM1-HOST01 から DOM1-PC01 に変更します。

2. コンピューター名を変更し、[OK] をクリックし、名前変更を行おうとします。
以下のようなエラー メッセージが表示され、コンピューター名の変更に失敗します。

こちらの問題が発生している場合、コマンド プロンプト上から "netdom renamecomputername" コマンドによりコンピューター名の変更を行っても、同様に失敗します。

解決方法は？

1. 問題が発生しているコンピューターに登録されている SPN の一覧を確認し、本来ポート番号として、数字がくるべき個所に文字列がないか確認します。
コンピューターに登録されている SPN の一覧は、setspn コマンドで確認できます。

[問題のある SPN]

MSSQLSvc/DOM-HOST01.parsley01.local:SQLEXPRESSWINCXE

2. 問題を引き起こしている SPN を削除します。削除すると、無事、コンピューター名が変更できるようになります。

SPN の削除を行うコマンドは以下の通りです。

setspn -d <SPN> <コンピューター アカウント名>

- 参考情報
[タイトル] Setspn
[URL] https://technet.microsoft.com/ja-jp/library/cc731241(v=ws.10).aspx

- 初回投稿 : 2015 年 11 月 18 日