Windows 10 Professional ビルド 1607 (RS1) 以降では適用されなくなったグループ ポリシーについて

こんにちは。Windows Platform サポート チームの樋口です。   今回は本来 Windows 10 Enterprise や Windows 10 Education でしか適用されないはずである一部のグループ ポリシーが、Windows 10 Professional のビルド 1511 (TH2) 以前では誤って適用されてしまうことがあるという問題についてお伝えいたします。 本来であれば Windows 10 Professional では適用されるべきではないグループ ポリシーであるため、Windows 10 Professional のビルド 1607 (RS1) 以降では適用されないように動作変更されていますが、これによって今まで適用できていたポリシーが適用できなくなってしまったというお問い合わせをお客様からいただいております。   ここでは Windows 10 Professional RS1 以降では適用されないように動作変更されていることが、弊社サポート部門でも実際に確認できているグループ ポリシーをご紹介させていただきます。 ご利用の Windows 10 を RS1 にアップグレードいただける際には、必要に応じてご留意いただければ幸いです。   問題の内容 例えば、下記の [Microsoft コンシューマー エクスペリエンスを無効にする] というグループ ポリシーの説明文を見ると、Enterprise…

0

ルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性

こんにちは、Windows プラットフォーム サポートの串田です。 今回は、先日総務省より通達があった DNSSEC を利用する際に使用されているルート ゾーン KSK の更新に伴う Windows の DNS サーバー上での対策の必要性の確認方法についてご紹介いたします。   ICANN は、ルートゾーン KSK と呼ばれる、DNSSEC で使用される暗号化鍵のペアを更新することをアナウンスしました。 ルート DNS サーバーを経由する、DNSSEC を利用したインターネット上の名前解決には、ルートゾーン KSK が利用されるため、適切な対策が求められています。 これを受けて 2017 年 7 月 14 日(金) に、総務省からも対策の必要性が発表されています。   現在、サポート チームではそもそも運用環境にて DNSSEC を利用しているのか?利用していない場合でも対策が必要なのか?というご質問が多く寄せられています。 そこで以下では、Windows の DNS サーバーにおいて、ルート KSK の更新に伴う対策の必要性、および注意事項についてご案内いたします。   Q1. Windows の DNS サーバーにおいてルート ゾーン KSK の更新に伴い、対策を実施する必要があるのか。 A1. 結論として、Windows…

0

Creators Update 直後に Smart Card サービスが起動しない事象

こんにちは。Windows Platform サポートチームです。 本ブログでは、Windows 10 における Smart Card サービスの起動障害について記載致します。 なお、このブログにおける情報につきましては、以下の点にご留意ください。 [留意事項] 本情報の内容(添付文書、リンク先などを含む)は、作成日時点でのものであり、予告なく変更される場合があります。 [問題の概要] Windows 10 において Creators Update(v1703)のインストールを行った場合、インストール直後に Smart Card サービスが起動しない事象が確認されています。 この事象を再現させるために、現在確認できている手順を以下に記載致します。 – 再現手順 1. Windows10 Creators Update (V1703) をクリーン インストールします。 2. インストール完了後、初回サインイン(ようこその画面が表示されます)を行います。 3. 端末にスマート カード リーダー/ライターを接続します。ここでは、Smart Card サービスが起動します。 4. 端末からスマート カード リーダー/ライターを切り離します。ここでは、Smart Card サービスが停止します。 5. 再度、端末にスマート カード リーダー/ライターを接続すると、Smart Card サービスが起動しません。<<<<< 事象再現 ※ 本事象は、Windows 10…

0

セキュリティが強化された Windows ファイアウォールで、Quick Mode の整合性アルゴリズムに SHA-256 を選択できない

こんにちは。Windows Platform サポートチームです。 セキュリティが強化された Windows ファイアウォールの GUI上から、Quick Mode の整合性アルゴリズムの既定値 (SHA-1) をカスタマイズする場合、SHA-256 を選択することができない現象が報告されています。 本件につきまして、最新情報をご案内いたします。   問題の概要 Windows Vista SP1 および Windows Server 2008 SP1 以降の Windows OS においては、 下記技術情報に記載の通り、IPsec のデータ保護設定 (Quick Mode) の整合性アルゴリズムに、 SHA-256 を利用することがサポートされております。   ** 技術情報 Description of the support for Suite B cryptographic algorithms that was added to IPsec in Windows Vista Service…

0

Kerberos の制限付き委任におけるネガティブ キャッシュの動作

こんにちは。 本日は、複数のフォレストおよびドメインが存在する環境での委任の動作についてお知らせします。   Active Directory ドメイン環境上では、フォレストを跨いだ Kerberos の制限付き委任を利用することが可能です。この Kerberos の制限付き委任ですが、別フォレストのユーザーからの認証が行われると内部的にネガティブ キャッシュが生成され、それまで正常に動作していた認証処理が失敗することがあります。 例えば以下のような構成を想定します。 双方向のフォレストもしくは外部信頼を結んだ 2 つのフォレストが存在する (contoso.com と adatum.com)。 contoso.com には、以下のようなマシンが存在している。 Active Directory Domain Controller SQL Server (リンク サーバー) プロシージャーが配置されている SQL Server adatum.com には、以下のようなマシンが存在している。 Active Directory Domain Controller   上記構成において、SQL Server で委任が設定されており、リンク サーバー経由のプロシージャーを実行できるとします。 この状態で、contoso.com ドメイン上のクライアントで SQL Server Management Studio を起動し、SQL Server (リンク サーバー) に接続するとします。 このとき以下のようになります。 contoso.com…

0

Hyper-V 上のゲスト OS 内に LBFO によるチーミングを構成した場合、ユニキャスト モードの NLB は利用出来ません。

こんにちは。Windows プラットフォーム サポート チームです。 Hyper-V 上のゲスト OS 内に LBFO によるチーミングを構成した場合、セキュリティ上の理由により、チーミング NIC に割り当てられる MAC アドレスは、対象の仮想マシンに対して事前に割り当てられていた MAC アドレスの範囲内に制限されています。 ユニキャスト モードの NLB が用いる独自の (“02:BF” から始まる) MAC アドレスについても例外ではなく、チーミング NIC に対する制限対象に該当するため、Hyper-V 上のゲスト OS 内においては LBFO によるチーミングとユニキャスト モードの NLB とを同時に利用することは出来ません。 この挙動は製品上のデザインに因るものです。

0

Windows 10/Windows Server 2016 の環境における ADMT を使用する場合の対応状況について

こんにちは。Windows プラットフォーム サポート チームです。 今回は Windows 10/Windows Server 2016 が存在する環境において、Active Directory 移行ツール (ADMT) を使用する場合の対応状況についてお知らせいたします。 まず初めに、残念ながら、現在最新のバージョンである ADMT 3.2 においても、Windows 10/Windows Server 2016 が存在する環境での移行は動作保証されていません。 これは、最新版の ADMT がリリースされた時点では、まだ Windows 10/Windows Server 2016 がリリースされていなかったため、Windows 10/Windows Server 2016 が存在する環境を前提として ADMT はテストされていないためです。 具体的には、下記のいずれの場合においても、ADMT を用いた移行は動作保証されていません。 ADMT を Windows Server 2016 にインストールする。 Windows Server 2016 のドメイン コントローラーで構成されたドメイン (移行元ドメイン、移行先ドメイン問わず) で移行を実施する。 ドメインにメンバーとして参加している Windows 10/Windows Server…

0

Windows 10 (x64) に Creators Update (v1703) を適用すると、ダイヤルアップ接続に失敗します

  こんにちは。Windows Platform サポートチームです。   昨今、Windows 10 (x64) に Creators Update (v1703) を適用すると、 ダイヤルアップ接続が失敗する事象について、お問い合わせを複数件いただいております。 本事象につきまして、以下にご案内します。   問題の概要 Windows 10 (x64) に Creators Update (v1703) を適用後、ダイヤルアップ接続を行うと、エラー 633 により失敗します。 この現象は、Windows 10 (x86) では発生しません。   エラー 633: モデム (またはほかの接続デバイス) は既に使用中か、正しく構成されていません。   原因 本現象は、製品の問題により、RASMAN サービスがデバイス(モデム)ドライバをロードする処理に失敗するために発生します。   対処方法 本件の修正を含む累積更新プログラム (KB4025342) は、Windows Update にて自動配信が開始されております。   2017 年 7 月 11 日…

0

まれに SSL/TLS 通信が bad mac record のエラーで失敗する

こんにちは。Windows プラット フォーム サポートの馬場です。 今回は、鍵交換を DHE 方式で行う場合に、Web サーバー等の SSL/TLS サーバーへの接続にまれに失敗する問題について紹介します。   どのような問題なのか? ———————– Web サーバーへの HTTPS 通信など、SSL/TLS を用いてサーバーに接続することがあると思います。 この時、クライアント PC と非 Windows の TLS サーバー製品間の通信で、数百回に 1 回の頻度で SSL/TLS 通信に失敗するという事象が報告されています。 これは、SSL/TLS ハンドシェイクにおける鍵交換の際に、クライアントとサーバー間でやり取りされる public share もしくは premaster secret の先頭バイトに対する処理について、Windows OS や他ベンダーで差異があるためです。 その影響により、まれに TLS 通信が bad mac record のエラーで失敗します。 Windows OS ではこの処理の差異を、Windows 10 TH2 にて修正しており、サーバーでは Windows Server 2016…

0