Microsoft Remote Server Administration Tools (RSAT)

みなさん、こんにちは! 今日は、お使いになると便利な管理ツールのインストール手順をご紹介します。 もうすでにご活用いただいている皆様も多いかと思いますが、すこし手順が複雑なツールなので、おさらいとしてもお役に立てれば幸いです。わたしもこの手順をすっかり忘れていて苦労したことがあります。。。   Windows Vista / Windows Server 2008 においては、新しい管理ツールMicrosoft Remote Server Administration Tools (RSAT) をご用意しています。 このツールは、以前のバージョンの OS において Administration Pack として提供されていたツールの後継版で、同様に以前のバージョンの OS にありました Support Tools に含まれている一部のツールも同梱されています。 (Windows Vista 以降は、Administration Pack や Support Tools はインストールできません。) このツールを導入することで、管理者はサーバを管理するための様々な機能を使用することができます。 Active Directory環境においては、NETDOM, NLTEST などのコマンドや、グループ・ポリシー・管理コンソール(GPMC)を利用される管理者の方が多いかと思いますが、これ等のツールは RSATに含まれています。   特にVista RTMでは GPMCがインストールされていますが、SP1 を適用すると GPMC が削除されてしまいます。このため、Vista SP1 においては、RSAT を導入していただく必要があります。突然 GPMCが消えてしまった!と驚いた皆様、RSAT にてご用意しておりますので、インストールくださいますようお願いします。  …

3

予期せぬ挙動が!? 新機能 Scalable Networking Pack をご存知ですか?

目次 概要 種類 Receive Side Scaling TCP Chimney Offload Network Direct Memory Access 既定値 既定の設定値 設定値と実効状態 TCP Chimney Offload と NetDMA の排他制御 Automatic Mode (自動モード) Itanium 版 設定方法 Windows Server 2003、Windows Server 2003 R2、Windows XP における設定 RSS TCP Chimney Offload NetDMA Windows Server 2003 の更新プログラムによる無効化 Windows Server 2003、Windows Server 2003 R2、Windows XP における設定確認 Windows Server…

2

Windows PKI – その2 – ルート証明書更新プログラムとは?

みなさん、こんにちは。 Windows プラットフォーム 村木由梨香です。   Windows におけるPKI についてのご説明、本日は、ルート証明書更新プログラムについて、ご案内します 前回の記事にて、PKI のイントロダクションにて、証明書が信頼されるために欠かせない点として以下をご紹介しました。 ・証明書を信頼するにあたっては、その証明書発行元の認証局が信頼された認証局であることが重要 ・Windowsでは 信頼された認証局かどうかは、「信頼されたルート証明機関」に CA 証明書が含まれているかどうか、で確認する さて、では、どうやって CA 証明書を「信頼されたルート証明機関」にインストールすればいいのでしょうか? 訪れる WEB サイトのすべての発行元 CA 証明書を、手動でインストールする、、、なんて大変ですよね。また、本当にその CA 証明書を信頼していいかの判断も、難しいかもしれません。 Microsoft では、Windows Update を利用して、必要に応じてお使いの Windows 端末の「信頼されたルート証明機関」に CA 証明書を配布する仕組みを提供しています。この仕組みをお使いいただくことで、ユーザーの皆様の手を煩わせることなく、自動的に信頼された CA 証明書をお使いの Windows 端末にインストールすることができます。   ============================== Microsoft ルート証明書更新プログラムとは何か? ============================== ●Microsoft ルート証明書更新プログラムとは? Microsoft ルート証明書更新プログラムとは、Windows Updateを利用したルート証明書の配布プログラムです。 約 100 以上もの公的証明機関や商用証明機関がこのプログラムに参加しています。 これらの証明機関の CA 証明書をあらかじめ信頼されているものとして定義しておき、必要になった際に、Windows 端末に Windows…

2

ドメインにログオンできない ~ セキュア チャネルの破損 ~

はじめまして! Windows プラットフォーム サポート担当の石丸 宰 (いしまる つかさ) です。今日は、“セキュア チャネルの破損” が原因でドメインにログオンできなくなる現象について、その見分け方と対処方法をご紹介したいと思います。1. “セキュア チャネル” と “コンピューター アカウント パスワード”Active Directory ドメインのメンバーとなっているクライアントは、ドメインコントローラー (以下 DC と記述) との間の通信を保護するために、セキュア チャネルと呼ばれる通信チャネルを使用します。認証に使用される資格情報などはこのセキュアチャネルによって暗号化され、安全な状態でネットワークを経由してやりとりされます。セキュア チャネルは下の図のように、クライアントごとに個別に作成されます。* なお、 “クライアント” はドメインのメンバーを指しており、 Windows Server 2003 / 2008 も DC でなければ、以下の説明や図では、”クライアント” に含まれます。DC とクライアントはお互いに、セキュア チャネルを確立するために必要となる “コンピューター アカウント パスワード” を持ちあっています。このパスワードは、DC 上ではコンピューター アカウントの属性値に、クライアント上では LSA シークレットと呼ばれる領域にそれぞれ格納されています。クライアント コンピューターが起動すると、まず最初にコンピューターアカウントのパスワードを用いて資格情報を生成し、DC にコンピューター認証の要求を送信します。認証に成功すると、認証処理の中で生成されたセッション・キーを用いてクライアントと DC の間にセキュア チャネルが確立されます。前述の通り、ユーザーのドメインへのログオン要求などの通信はセキュア チャネルを用いて行われるような仕組みになっているので、コンピューター認証に失敗し、セキュアチャネルが確立ができないような状況ではユーザーはドメインにログオンすることはできません。何らかの理由によって DC とクライアントが保持するコンピューター アカウントのパスワードに不整合が生じた場合、セキュア…

1

どんなお問い合わせが多い?

こんにちは。そして、はじめまして。 Network & Active Directory 担当チームにて、前回の記事を担当しました 正木 と共にリーダーを務めています、三浦です。 リーダーということもあり、たま~に、どのようなお問い合わせを普段対応しているのですか ? というような質問を受けることがあります。今回は、お問い合わせが多いエリア (主にトラブル シューティング系) について、ざっくりと 5 つご紹介します。その上で、私たちから切り分けで無効にすることをお願いさせていただくことがある SNP (Scalable Networking Pack) という機能について、トラブル シューティングという観点から簡単にご紹介します。 では、早速。 1. ドメイン ログオン / ドメイン参加 ドメインへのログオンに時間がかかる、ログオンに失敗する、あるいはドメインの参加ができないなどのお問い合わせです。このような問題が発生した時には、 IP アドレスが取得できているか、 DNS への通信ができるのかなど、基本的なネットワークのトラブルシューティングと併せて、問題が発生している端末のイベント ビューアーを開き、システム イベントログに Netlogon のエラーなどが記録されていないか確認します。また、問題が発生している範囲、発生契機などを明らかにすることも重要です。私たちにお問い合わせいただきました際には、まず現象の発生状況を確認するために、前述のイベントログなどの情報を含む診断ログ、現象発生時の netlogon.log やネットワーク パケット データなどを解析させていただき、原因調査を実施しています。なお、Windows 7 におけるドメイン参加については、前回ご紹介させていただきましたので、まだご覧になっていない方は、是非ご参照ください。 2. グループ ポリシー Active Directory を使用するメリットとして、グループ ポリシーを使用して、クライアント端末を管理する / 設定を配布することができるということが挙げられます。管理者が作成したグループ ポリシーが正常に適用されるためには、DNS を使用した名前解決が正常にできていること、ドメイン コントローラから認証されていること、そしてもちろん、ネットワーク通信が正常にできていることが必須です。グループ…

1

“証明書のプライバシーを有効にする” オプション

皆様、こんにちは。Windows プラットフォーム サポートの下野です。   Windows 10 が公開されてから早 3 ヶ月が経ちましたが、お使いいただいてますでしょうか? Windows 7/8/8.1 をお使いの方は、2016 年 7 月 28 日までは無償アップグレードできますので、この機会にお試し下さい!   今回は、Windows 10 から追加されました 証明書エクスポート時の新オプション、“証明書のプライバシーを有効にする” オプションについてご紹介致します。   1. “証明書のプライバシーを有効にする” オプションとは   “証明書のプライバシーを有効にする” オプションは、証明書を秘密鍵付でエクスポートする際に、証明書の暗号化を秘密鍵の暗号化と併せて実施するかを制御するオプションとなります。        証明書を秘密鍵付きでエクスポートしますと、証明書と秘密鍵がセットになった、PFX と呼ばれる形式のファイルが生成されます。 Windows 10 よりも前の OS では、証明書と秘密鍵のどちらもが暗号化される動作となっていましたが、Windows 10 では証明書の暗号化をこちらのオプションにより制御できるように可能になっています。 既定の状態だと、こちらのオプションは無効となっている為、秘密鍵のみが暗号化され、証明書は判読可能な状態でエクスポートされます。       2. Windows 10 以前の OS との互換性について “証明書のプライバシーを有効にする” オプションを 有効…

0

Windows Server 2012 R2 のドメイン コントローラー環境にて、コンピューター名の変更に失敗するという問題につきまして

こんにちは。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 は、次の情報によって構成されております。 – サービスの名前…

0

LBFO と NLB を併用する場合の注意事項について

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 番ポート使用) を行った際の通信シーケンス例となります。クライアント、サーバー共に相手からの応答待ちで再送要求が発生し、通信遅延が発生していることが確認できます。同一構成で帯域制御装置のみ存在しない場合には通信遅延が発生しないことから、帯域制御装置の動作が影響して遅延が発生していることが想定されます。          表…

0

拡張したスキーマと昇格した機能レベルのロールバック

みなさま、こんにちは。 今回は Active Directory ドメイン サービスの移行にて、万が一作業が切り戻しになった場合のための、Windows Server バックアップを使用した切り戻し手順についてご案内いたします。 ドメイン コントローラー (DC) を新しい OS へ移行する場合、スキーマ拡張が伴い、必要に応じてフォレストおよびドメインの機能レベルの昇格をご実施される方も多いのではないかと思います。この記事では、拡張したスキーマを切り戻す手順、および昇格した機能レベルを切り戻す手順についてフォーカスして説明します。特に拡張したスキーマや昇格した機能レベルを切り戻すために、1 台の DC でリストアすれば良いのか、それともすべての DC でリストアすれば良いのかという点について、疑問をお持ちになった方がいらっしゃいましたら、ご一読いただければ幸いです。 —————————————-スキーマのロールバックについて—————————————-スキーマ拡張後、もしくは機能レベルの昇格後にもし作業が切り戻しとなった場合、拡張したスキーマまたは機能レベルをロールバックするためには、基本的にすべての DC においてリストアが必要になります。これは、任意の 1 台の DC でデータベースの状態が戻ったとしても、リストアした DC 以外が保持しているデータベースの方が新しい情報を保持していると判断され、リストアした DC のデータベースの内容が上書きされてしまうためです。 ここで、それでは 1 台の DC で権限のある復元 (Authoritative Restore) を実施すれば良いのかと思われる方もいらっしゃるかもしれません。残念ながら、スキーマ パーティションに対して権限のある復元を実施しても、スキーマ情報を完全にロールバックすることはできません。これは、権限ある復元では、復元対象のオブジェクトのバージョン番号を意図的に高い数値に設定することにより、他の DC から最新の情報が複製されないようにするといった仕組みが取られているためです。つまり、スキーマ拡張前の新しいスキーマ オブジェクトが存在しない段階では、そもそもオブジェクト自体が存在しないためにバージョン番号を増加させることができず、スキーマの状態を完全に元に戻すことができないのです。 この点については下記の参考資料にも記載がありますので、参考にしていただければ幸いです。 – 参考資料Active Directory Backup and Restorehttps://msdn.microsoft.com/en-us/library/bb727048.aspx // 該当部分の抜粋******************************An authoritative restore will not…

0

SHA-1 ハッシュ アルゴリズムによって署名された証明書の廃止について

こんにちは。プラットフォームサポートの工藤です。 本記事によって案内をしておりました SHA-1 ハッシュ アルゴリズムによって署名された証明書の廃止に関するアナウンスは、情報が更新されたため、以下のサイトをご確認くださいますようお願いいたします。   TITLE: Windows Enforcement of SHA1 Certificates URL: http://social.technet.microsoft.com/wiki/contents/articles/32288.windows-enforcement-of-sha1-certificates.aspx?PageIndex=2   日本語版では以下のサイト情報が最新となります。 TITLE: SHA-1 ウェブサーバー証明書は 2017 年2月から警告!ウェブサイト管理者は影響の最終確認を URL: https://blogs.technet.microsoft.com/jpsecurity/2016/11/25/sha1countdown/   以上、よろしくお願いいたします。                       2016 年 11 月 30 日追記     2016 年 1 月 1 日以降、 SHA-1 ハッシュ アルゴリズムによって署名されたコード証明書が廃止されます。   [IT 管理者向け] SHA-1 からの移行を推奨しています http://blogs.technet.com/b/jpsecurity/archive/2014/10/15/sha1-migration.aspx   この廃止に関しまして、マイクロソフトサポートでは多くのお客様からシナリオ別にご質問を頂いています。 この Blog では、お客様からよく頂戴するご質問に回答いたします。 ※以下の内容は 2016年 1…

0