Ask the Network & AD Support Team

2019 年 1 月 8 日の更新プログラムを適用すると、ファイルサーバーへの通信やリモートデスクトップ接続が不可能となる

jpnetds — Thu, 10 Jan 2019 23:55:21 GMT

こんにちは。Windows プラットフォームサポートです。 2019 年 1 月 8 日の更新プログラムをファイルサーバーやリモートデスクトップ接続先のコンピューターへ適用すると、そのファイルサーバー、リモートデスクトップ接続先のコンピューターへのアクセスに失敗することがあるという問題が判明しましたので、本ブログで問題の内容と対応策をご案内します。 [問題の概要] 2019 年 1 月 8 日公開の以下の更新プログラムのいずれかをファイルサーバー (共有フォルダーを保持するコンピューター) もしくはリモートデスクトップ接続先のコンピューターに適用後、そのコンピューターに対して Administrators グループに所属しているローカルユーザーを用いてアクセスすると、接続に失敗するという事象が発生します。これにより、共有フォルダーへのアクセスできない、ネットワークプリンターに接続できない、リモートデスクトップ接続ができないといった問題が発生します。 // Windows 7 SP1/Windows Server 2008 R2 SP1 向けの更新プログラム January 8, 2019—KB4480970 (Monthly Rollup) https://support.microsoft.com/en-us/help/4480970 January 8, 2019—KB4480960 (Security-only update) https://support.microsoft.com/en-us/help/4480960 // Windows Server 2008 SP2 向けの更新プログラム January 8, 2019—KB4480968 (Monthly Rollup) https://support.microsoft.com/en-us/help/4480968 January 8, 2019—KB4480957 (Security-only update) https://support.microsoft.com/en-us/help/4480957 本事象はあくまでも接続先のコンピューター上のローカルの Administrators グループに所属するローカルアカウントを用いてアクセスした場合に発生し、接続先のコンピューター上のローカルの Administrators グループに所属しないローカルアカウントでアクセスした場合や、ドメインアカウントを用いてアクセスした場合には、この事象は発生しません。 [対象 OS]

Windows 7 SP1

Windows Server 2008 R2 SP1

Windows Server 2008 SP2

** Windows 8/Windows Server 2012 以降の OS では本問題は発生しません。

[原因]

ファイルサーバーもしくはリモートデスクトップ接続先のコンピューターにアクセスする際における、NTLM 認証の問題が原因となり本事象が発生することが判明しています。 [回避策] 接続先コンピューターにアクセスする際に、Administrators グループに所属しないローカルアカウントを用いるか、ドメインアカウントを用います。 [対応策] 本問題の修正プログラムを以下のとおり公開しています。

OS バージョン	問題の発生する更新プログラム	修正プログラム
Windows 7 SP1 / Windows Server 2008 R2 SP1 (Monthly Rollup)	KB4480970 (Monthly Rollup)	KB4487345 または KB4480955 (Preview of Monthly Rollup)
Windows 7 SP1 / Windows Server 2008 R2 SP1 (Security-only update)	KB4480960 (Security-only update)	KB4487345
Windows Server 2008 SP2 (Monthly Rollup)	KB4480968 (Monthly Rollup)	KB4487354 または KB4480974 (Preview of Monthly Rollup)
Windows Server 2008 SP2 (Security-only update)	KB4480957 (Security-only update)	KB4487354

<2/14 更新> 米国時間 2 月 12 日付けで、 2019 年 2 月の月例更新プログラムが公開されました。 "マンスリーロールアップ"、"セキュリティのみの更新プログラム" いずれにつきましても、本問題に対する修正が含まれますので、こちらの適用にて対応いただくことが可能です。

OS バージョン	問題の発生する更新プログラム	修正プログラム
Windows 7 SP1 / Windows Server 2008 R2 SP1 (Monthly Rollup)	KB4480970 (Monthly Rollup)	KB4486563 (Monthly Rollup)
Windows 7 SP1 / Windows Server 2008 R2 SP1 (Security-only update)	KB4480960 (Security-only update)	KB4486564 (Security-only update)
Windows Server 2008 SP2 (Monthly Rollup)	KB4480968 (Monthly Rollup)	KB4487023 (Monthly Rollup)
Windows Server 2008 SP2 (Security-only update)	KB4480957 (Security-only update)	KB4487019 (Security-only update)

- 問題の発生する更新プログラムを適用済みの場合追加で修正プログラムを適用ください。 - これから問題の発生する更新プログラムを適用する場合問題の発生する更新プログラムと修正プログラムを同時に適用ください。 - WSUS をご利用の場合修正プログラムは "更新" の分類で Microsoft Update カタログに公開されています。 WSUS を利用している環境で、"更新" の分類を同期対象としてない場合には、手動でのインポートが必要になります。 - Windows Update でマンスリーロールアップのプレビューを適用する手順 Windows Update でマンスリーロールアップのプレビューをインストールする場合は、以下の手順を実施します。 1. [コントロールパネル] を起動します。 2. [システムとセキュリティ] - [Windows Update] と進みます。 ※ "カテゴリ" 表示ではない場合は、[Windows Update] をクリックします。 3. [xx 個のオプションの更新プログラムが利用可能です] をクリックします。 4. 1 月のマンスリーロールアップのプレビュー (KB4480955) にチェックを入れ、[OK] をクリックします。 5. [更新プログラムのインストール] をクリックします。 6. 更新プログラムのインストール処理が開始されます。 7. インストール処理完了後、[今すぐ再起動] をクリックして再起動します。 [更新履歴] 2019/01/10: 本ブログの公開 2019/01/11: [対応策] の欄を追記 2019/01/15: [対応策] の欄を更新 2019/01/17: [対応策] の注釈を更新 2019/01/18: [対応策] の欄を更新 2019/01/19: [対応策] の欄を更新 2019/02/14: [対応策] の欄に 2 月の月例更新プログラムについて追記 [補足] 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

証明機関の CA 証明書の書き換えについて

jpnetds — Fri, 28 Dec 2018 19:28:52 GMT

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

AD CS サービスで構築した CA サーバーの CA 証明書の更新の動作についてお問い合わせいただくことがございます。

そのため、今回はメッセージの意味と選択肢における動作の違いについて紹介いたします。

<目次>

CA 証明書の書き換えについて
CA 書き換え時のオプション
対処策後の動作

1 . CA 証明書の書き換えについて

Windows OS で提供されている "Active Directory 証明機関サービス" で証明機関を構築すると、CA 証明書には有効期間が設定されます。

CA 証明書の有効期限を更新されたい場合は [証明機関] の管理コンソールより [CA 証明書の書き換え] から有効期限の延長を行うことができます。

また、CA 証明書を書き換えるシナリオとして、CA の証明書の有効期間を延長する以外に、CA 証明書のキーペアとなる秘密キーが漏洩する等、セキュリティ上の理由から行う場合もございます。

先ずは、CA 証明書の秘密キーが漏えいすることのリスクについてご説明をします。

秘密キーは、証明機関で発行する証明書に付与するデジタル署名に利用されます。

そのため、以下の図の通り、秘密キーが漏洩してしまうと悪意を持った第三者が証明書を偽造することができます。

証明書のデジタル署名の検証には信頼している CA 証明書が使用されますが、同じ秘密キーを用いて署名しているため、一般のユーザーは正規の証明書と偽造された証明書を見分けることができません。

そのため、偽造された証明書も正当な証明書として信頼してしまう恐れがあります。

偽造された証明書を使うと悪意を持った第三者は、社内ネットワークに不正に入りこんだり、不正な Web サーバーを構築して悪用することも可能です。

そのため、秘密キーに何等かのセキュリティ被害を受けた場合は、一般的にはキーペアを再作成して CA 証明書を発行し、それまでに発行された証明書は失効させて、新しく再発行した証明書を配布する等の対処をとります。

2. CA 書き換え時のオプション

次に "Active Directory" で構築した証明機関にて、CA 証明書を更新する手順についてご説明します。

1) CA サーバーに管理者権限をもつユーザーでログオンします。

2) [管理ツール] より [証明機関] を開きます。

3) 証明機関の画面の左ペインより、[証明機関(ローカル)] - [名>] を右クリックして [すべてのタスク] -

[CA 証明書の書き換え] をクリックします。

4) CA 証明書の書き換えの処理の間、Active Directory 証明書サービスが一時的に停止することを警告する

メッセージが表示されたら、[はい] をクリックします。

5) CA 証明書の書き換えにあたり、以下のようなメッセージが表示されます。

このメッセージが CA 証明書の書き換えにあたって、CA 証明書に紐づくキーペアとして (公開キーと秘密キーのペア)の書き換えを行うかどうかを確認するためのメッセージとなります。

・[はい] を選択した場合: キーペアを新たに作成した上で CA 証明書を発行します。

・[いいえ] を選択した場合：現行のキーペアのままで CA 証明書を発行します。

先の通り、現行のキーペアにセキュリティ上の懸念がある場合は、[はい] を選択してキーペアの書き換えを行います。

また、CA 証明書の有効期間を更新することが目的であれば、基本的には [いいえ] を選択して、現行のキーペアを使用したままで CA 証明書を発行します。

キーペアを変更すると新規の CA 証明書では、既存の発行済みの証明書の検証はできませんので、基本的には全ての証明書を発行しなおすことが前提となりますので、一般的にはキーペアの書き換えは行いません。

オプションを選択したら、[OK] をクリックして CA 証明書の書き換えを行います。

3. 対処策後の動作

先ほどの秘密キーが第三者に漏洩した場合の対処として、キーペアの書き換えを行った後の動作を確認します。

キーペアを書き換えた新しい CA 証明書を発行すると、それ以降は証明機関は証明書を新たに発行するとき、新しいキーペアの秘密キーでデジタル署名を行うようになります。

セキュリティの懸念がある旧 CA 証明書は信頼されない証明書として配布し、これまでに発行済みの証明書は全て失効して利用できないように構成します。

失効した各証明書を新たに再発行すると新たなキーペアの秘密キーで署名されるので、信頼できる CA 証明書として配布している新 CA 証明書で検証が成功します。

一方、旧 CA 証明書は "信頼できない証明書" として配布されておりますので、偽造された証明書の検証は失敗するようになります。

Windows 10 version 1803 から version 1809 にアップグレードするとビルトイン Administrator が無効化される

jpnetds — Fri, 28 Dec 2018 18:09:59 GMT

Windows 10 version 1803 をご利用されている方で、version 1809 にアップグレードをご検討されている方がいらっしゃいましたら、意図せずビルトイン Administrator アカウントが無効化されてしまう問題が報告されていますので、ご注意いただけますようお願い申し上げます。この問題は以下の条件がともに成り立つ時に、Windows 10 version 1803 から version 1809 にアップグレードすると発生することが分かっています。 // 本問題の発生条件 (以下の条件の両方ともに合致する場合に本事象が発生します) * ビルトイン Administrator アカウントが有効である。 * 他にも Administrators 権限を持っているローカルのアカウントが存在している。つまり、AdministratorsグループにビルトインAdministrator 以外に、ローカルユーザのアカウントが存在する場合のみ、この問題が発生します。現在、Windows 10 version 1803 から version 1809 にアップグレードする時に、自動的に修正が適用され、本不具合の発生を回避できます。 2019 年 1月 22 日以降、Windows Updateを使用する場合1809にアップグレードする過程で本問題を修正する処理が行われるようになっており、事象は発生いたしません。留意点といたしましては、この修正は、アップグレードの際のみ適用可能であり、通常の更新プログラムのように事前に Windows Update から適用することはできません。 SCCMやWSUSを利用して1809にアップグレードするお客様は事象が発生してしまい、事前予防の解決策はありません。もし、事象が発生した場合は、事象発生後にその他の管理者ユーザーでログオンし、必要に応じてビルトインのAdministratorを有効化する必要があります。適用方法といたしましては、インターネットにつながる環境にて、Windows 10 version 1809 にアップグレードを開始し、以下の画面が表示されましたら、「更新プログラム、ドライバー、オプション機能をダウンロードする (推奨)」を選択してください。

Appidcertstorecheck.exe が大量に起動する問題について

jpnetds — Thu, 18 Oct 2018 11:36:21 GMT

こんにちは。Windows サポートチームの依田です。今回は、ある特定の条件下で、Appidcertstorecheck.exe というプロセスが大量に起動してしまう問題についての原因と対処策についてご案内します。 ============================== ■ 事象概要と事象が発生した時の影響 ============================== Windows 10 / Windows Server 2016 端末にて、ある特定の条件下で、上の図の様に Appidcertstorecheck.exe というプロセスが大量に起動してしまう事象が発生することがあります。このプロセスが大量に起動することで、対象端末のメモリが逼迫し、システムに影響を及ぼす可能性があります。 ============================== ■ 事象発生原因と対処策の概要 ============================== Appidcertstorecheck.exe は、Applocker と呼ばれるアプリケーションの実行を制御する為の OS の機能が、証明書のチェックを行う際に呼び出される実行ファイルです。今回の Appidcertstorecheck.exe が大量に起動してしまう事象は、後述の “事象の発生条件” に合致している環境下で、証明書の検証時にクライアントからインターネット上のサイト “https://ctldl.windowsupdate.com” に公開されている ”Pinrulesstl.cab” という名前のファイルにアクセスが出来ないことが原因で発生します。その為、結論としては、”Pinrulesstl.cab” をクライアントが参照できるようにすることで事象は解消されます。 ============================== ■ 事象の発生条件 ============================== ・ OS バージョンが Windows 10 / Windows Server 2016 以上・インターネット上のサイト “https://ctldl.windowsupdate.com” に直接アクセスが出来ない・ AppLocker の機能が有効・ルート証明書更新プログラムが有効 ※ ルート証明書更新プログラムの詳細につきましては、記事の末尾の “参考サイト” をご参照ください。 - 補足情報クライアントが直接インターネット上のサイト “https://ctldl.windowsupdate.com” にアクセスできなかったとしても、社内のファイルサーバーに、本来 “https://ctldl.windowsupdate.com” から取得する情報を予めダウロードしておき、信頼されているルート証明書のリスト、および信頼されていない証明書のリストをクライアントに確認させる運用をされているお客様もいらっしゃるかと思います。その様な状況においても、ファイルサーバー上に ”Pinrulesstl.cab” が存在しない場合、Windows 10 / Windows Server 2016 以上の OS では、今回の問題が発生します。 ============================== ■ 事象の発生経緯 ============================== Windows 10 / Windows Server 2016 からは、セキュリティ強化を目的として、ルート証明書更新プログラム実行時、証明書の検証を行う際に ”Pinrulesstl.cab” ファイルをチェックする要件が加わりました。 ”Pinrulesstl.cab” ファイルには証明書のチェーン情報が格納されており、こちらのファイルを確認することで、内部のドメイン名が意図しない証明書や不正に発行された証明書にチェーンするのを防ぐことができ、man-in-the-middle 攻撃を減らすことが可能となっております。そして、Windows 10 / Windows Server 2016 以上の OS が、この ”Pinrulesstl.cab” ファイルにアクセス出来ない場合の具体的な動作は以下の通りです。

”Pinrulesstl.cab” にアクセスが出来ないと、アクセスに失敗したタイミングでレジストリ "PinRulesLastError" の値が更新されます。
レジストリ "PinRulesLastError" の値が書き換わると、CryptSvc サービスが、appidsvc (Application Identity Service) サービスを呼び出します。
呼び出された appidsvc サービスが、appidcertstorecheck.exe を起動させるタスクを実行します。
appidcertstorecheck.exe が起動します。

上記の動作は、”事象の発生条件” に合致した端末上で、ルート証明書更新プログラムが実行される度に発生します。また、呼び出された appidcertstorecheck.exe が自動的に終了することはなく、OS が起動している間はタスクリストに溜まり続けることとなります。その結果、appidcertstorecheck.exe が大量に滞留し、結果としてタスクマネージャ―上に appidcertstorecheck.exe が大量に表示される状況となります。 ============================== ■ 事象の対処策 ============================== 本事象を解消させる方法は、大きく分けて以下 3 点の内 “いずれか” となります。 [A] ルート証明書更新プログラムを無効化する [B] “pinrulesstl.cab” ファイルを、社内の共有フォルダに配置する [C] クライアントから直接インターネット上の “https://ctldl.windowsupdate.com” にアクセス出来るようにする上記 3 点の、具体的な対処手順は以下の通りです。 ----------------------------------------------------------------------------------------------------------------------- [A] ルート証明書更新プログラムを無効化する ----------------------------------------------------------------------------------------------------------------------- こちらは、インターネットに接続できないクローズドの環境、且つ信頼されているルート証明書のリスト、信頼されていない証明書のリストを社内のファイルサーバーにダウンロードして、各クライアントに参照させる運用をされていない環境において有効な対処策です。上述の通り、"ctldl.windowsupdate.com" への通信や、”Pinrulesstl.cab” ファイルのチェックは、各端末の “ルート証明書更新プログラム” と呼ばれる機能が有効である場合に自動で行われます。 ※ ルート証明書の自動更新プログラムは、Windows Update とは異なる機能ですが、アクセスする URL は上記の通り "https://ctldl.windowsupdate.com" であり、WindowsUpdate のサイトになります。その為、“ルート証明書更新プログラム” 自体を無効化することで、”Pinrulesstl.cab” のチェックは行わなくなりますので、今回の事象を回避することが可能です。 // ルート証明書更新プログラムの無効化手順 --------------------------------------------------------------------------- ルート証明書更新プログラムは、以下のグループポリシー、もしくは後述のレジストリを直接編集することで無効化することが可能です。 <グループポリシー> [コンピュータの構成] - [ポリシー] - [Windowsの設定] - [セキュリティの設定] - [公開キーのポリシー] - [証明書パス検証の設定] - [ネットワークの取得] タブで [これらのポリシーの設定を定義する] にチェックを入れた上で、[Microsoft ルート証明書プログラムで証明書を自動更新する] のチェックを外します。 <レジストリ> キー： HKEY_LOCAL_MACHINE\Software\policies\Microsoft\SystemCertificates\AuthRoot REG_DWORD： DisableRootAutoUpdate 値： 1 // ルート証明書更新プログラムを無効化することによる影響 --------------------------------------------------------------------------- ルート証明書更新プログラムを無効化することによる影響としては、ルート証明書更新動作が行われず、必要に応じてルート証明書を取得する動作が発生しなくなります。ルート証明書更新プログラムを無効化が許容される環境としましては、明示的に必要なルート証明書が既に端末にインポートされている環境や、アプリケーション側で証明書エラーとなった際もそれを無視するような例外設定を行っている環境等です。もしルート証明書更新プログラムが無効で、且つ端末の証明書ストアにも必要なルート証明書がインポートされていない場合は、証明書エラーとなり必要な通信が行えない状況となる可能性がございます。 (証明書エラーとなった際の処理はアプリケーションに依存いたします。) なお、インターネットに接続できないクローズドの環境、且つ信頼されているルート証明書のリスト、信頼されていない証明書のリストを社内のファイルサーバーにダウンロードして、各クライアントに参照させる運用をされていない環境においては、(元々 "ctldl.windowsupdate.com" 内のコンテンツは参照されませんので) 無効化いただくことによる影響はございません。 ----------------------------------------------------------------------------------------------------------------------- [B] “pinrulesstl.cab” ファイルを、社内の共有フォルダに配置する ----------------------------------------------------------------------------------------------------------------------- こちらは、信頼されているルート証明書のリスト、および信頼されていない証明書のリストを社内のファイルサーバーにダウンロードし、各クライアントに参照させている場合に有効な対処策です。 Windows Vista SP2 / Windows Server 2008 SP2 以降、インターネットに接続されている端末にて「certutil -syncwithwu」コマンドを実行することで、インターネット上のサイト “https://ctldl.windowsupdate.com” に公開されている情報を、任意のローカルフォルダーにダウンロードすることが可能となりました。 ※ Windows 8 / Windows Server 2012 までの OS でこの機能を有効化する為には、セキュリティアドバイザリ2854544 (KB2813430) の適用が必要。 ※ こちらの動作の詳細につきましては、記事の末尾の “参考サイト” をご参照ください。ただし、Windows 10 / Windows Server 2016 未満の OS 上で「certutil -syncwithwu」コマンドを実行しても、”Pinrulesstl.cab” ファイルはダウンロードされません。その為、Windows 10 / Windows Server 2016 以上の端末から「certutil -syncwithwu」コマンドを実行して、”Pinrulesstl.cab” ファイルを社内の共有フォルダーに配置していただけます様お願いいたします。手順は以下の通りです。 // ”Pinrulesstl.cab” ファイルを社内の共有フォルダーに配置する手順 ------------------------------------------------------------------------------------ 1. インターネットに接続可能な Windows 10 / Windows Server 2016 以上の端末を用意します。 2. 上記端末に、管理者権限を保持するアカウントでログオンします。 3. コマンドプロンプトを開き、以下のコマンドを実行します。 certutil -syncwithwu 4. にダウンロードされた ”Pinrulesstl.cab” ファイルを、社内の共有フォルダにコピーします。なお、既存の自動更新端末を Windows 10 / Windows Server 2016 以上の端末に変更して、を社内の共有フォルダに直接指定していただくことで、”Pinrulesstl.cab” ファイルをコピーする工数がなくなります。将来的な運用工数削減の為に、こちらも併せてご検討ください。 ----------------------------------------------------------------------------------------------------------------------- [C] クライアントから直接インターネット上の “https://ctldl.windowsupdate.com” にアクセス出来るようにする ----------------------------------------------------------------------------------------------------------------------- こちらは、クライアントから直接インターネット上の “https://ctldl.windowsupdate.com” にアクセスできるように、構成を変更することが可能な場合に有効な対処策です。 OS バージョンが Windows 10 / Windows Server 2016 以上の端末が、直接インターネットサイトにアクセス出来るようにすることで、“https://ctldl.windowsupdate.com” から、必要に応じて ”Pinrulesstl.cab” ファイルのチェックを行うことが可能となります。ただし、クライアントが直接インターネットにアクセスできる環境である場合でも、プロキシサーバーを中継している場合は注意が必要です。ルート証明書更新プログラムにおける “https://ctldl.windowsupdate.com” へのアクセスは WinHTTP が利用されます。 WinHTTP では、ブラウザのプロキシ設定は利用されず、別途 WinHTTP の為のプロキシ設定が必要です。こちらの、WinHTTP のプロキシ設定がされていない為に、”https://ctldl.windowsupdate.com” へのアクセスが拒否され、”Pinrulesstl.cab” にアクセスが出来ない為に、結果的に今回の事象に発展します。こちらが原因で事象が発生している場合は、以下の手順で WinHTTP のプロキシ設定を行うことで、事象が改善される可能性がございます。 ----------------------------------------- WinHTTP プロキシの設定手順 ----------------------------------------- // Internet Explorer のプロキシ設定を、そのまま WinHTTP プロキシ設定に取り込む場合 ------------------------------------------------------------------------------------------------------------- 1. 対象の全社端末にログオンの上、コマンドプロンプトを起動します。 2. 以下のコマンドを実行します。 netsh winhttp import proxy source=ie 3. 以下のコマンドで現在の WinHTTP プロキシ設定を確認し、意図したサーバーの IP アドレス (もしくは FQDN) が設定されているか確認します。 netsh winhttp show proxy // Internet Explorer とは別のプロキシを設定する場合 ------------------------------------------------------------------------------------------------------------- 1. 対象の全社端末にログオンの上、コマンドプロンプトを起動します。 2. 以下のコマンドを実行します。 ※ ここでは、例として "testproxy.example.com" というプロキシサーバーを 8080 番ポートで設定しています。 netsh winhttp set proxy proxy-server="testproxy.example.com:8080" 3. 以下のコマンドで現在の WinHTTP プロキシ設定を確認し、意図したサーバーの IP アドレス (もしくは FQDN) が設定されているか確認します。 netsh winhttp show proxy // WinHTTP のプロキシ設定のリセット手順 ------------------------------------------------------------------------------------------------------------- WinHTTP のプロキシ設定をリセット (空の状態に) したい場合は、以下のコマンドを実行します。 netsh winhttp reset proxy 以上です。 <参考情報> - ルート証明書プログラム URL:https://docs.microsoft.com/ja-jp/security-updates/planningandimplementationguide/28561627 - Windows PKI – その2 – ルート証明書更新プログラムとは？ URL:https://blogs.technet.microsoft.com/jpntsblog/2009/12/24/windows-pki-2/ - セキュリティアドバイザリ2854544 (KB2813430) ～ルート証明書更新プログラムの管理強化 URL:https://blogs.technet.microsoft.com/jpsecurity/2013/06/11/2854544-kb2813430/ 特記事項 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

Windows 10 RS5 (1809) における移動ユーザープロファイルの問題について

jpnetds — Wed, 17 Oct 2018 14:54:59 GMT

こんにちは。Windows サポートチームの矢澤です。 Windows 10 RS5 (1809) における移動ユーザープロファイルの問題が報告されておりますので、本 blog にてご案内いたします。(2018/11/14 追記) 1. 事象 RS5 の端末において、%USERNAME% などの環境変数を利用して移動ユーザープロファイルを構成すると移動ユーザープロファイルが利用できません。 2. 原因 %USERNAME% や %LOGONSERVER% などの環境変数が testuser などのユーザー名に変更されず、%USERNAME% や %LOGONSERVER% という文字列として認識されてしまいます。 3. 回避策 グループポリシーにて移動ユーザープロファイルを設定している場合には回避策はございません。 Active Directory 上のユーザーオブジェクトのプロパティに直接設定している場合には環境変数を利用せず、直接実ユーザー名や実サーバー名を入力することで回避が可能です。ユーザー数が多い場合には、以下のサンプルスクリプトにてプロパティを設定してください。

for /f "delims=" %i in ('dsquery user "<移動プロファイル対象ユーザーの OU の DN 名>"') do dsmod user %i -profile <移動プロファイルのパス>

例) test.local ドメインの test OU 配下のユーザーの移動プロファイルのパスを一括で変更する場合 for /f "delims=" %i in ('dsquery user "OU=test,DC=test,DC=local"') do dsmod user %i -profile \\FILESVR\profile\$username$

4. 対処策 (2018/11/14 追記) 2018 年 11 月 14 日にリリースされた累積更新プログラム KB4464455 を適用することで事象が改善されます。なお、同日に RS5(1809) が再リリースされており、この OS イメージでは今回の修正が含まれているため事象は発生いたしません。

Windows 10 のバージョンアップを行った際にファイアウォールの許可規則が削除されてしまう

jpnetds — Mon, 15 Oct 2018 16:13:36 GMT

皆様、こんにちは。Windows プラットフォームサポートです。今回は Windows 10 のバージョンアップを行った際にファイアウォールの許可規則が削除されてしまうという事例を紹介します。 [現象] Windows 10 のバージョンアップを行った際にファイアウォールの許可規則が削除されてしまう場合があります。 [原因] アプリケーションパッケージに対するファイアウォールの規則をカスタマイズし、その規則がアプリケーションパッケージの通信を許可するうえで不完全な規則と判断した場合に削除されます。この動作は想定された動作です。例としてリモートデスクトップを取り上げます。リモートデスクトップアプリケーションパッケージへのファイアウォール許可規則は下図のように “リモートデスクトップ - シャドウ (TCP 受信)”, “リモートデスクトップ - ユーザーモード (TCP 受信)”, “リモートデスクトップ - ユーザーモード (UDP 受信)” の 3 個のファイアウォール規則にて構成されます。一部の規則を無効化していても使い方によっては問題なくリモートデスクトップ接続が可能ですが、リモートデスクトップアプリケーションパッケージに対する通信許可規則としては 3 個すべての規則が有効化されている必要があり、一部が無効化されていた場合には不完全と判断されます。

不完全と判断されていることは [許可されたアプリ] から確認することが出来ます。下図はリモートデスクトップアプリケーションパッケージの許可規則が不完全と判断されている例です。チェックボックスにチェックが入っていますが、チェックボックスの背景がグレーに塗りつぶされています。不完全と判断されている場合にこのように表示されます。 [対応策] バージョンアップ前に、不完全なファイアウォールの規則が無いかご確認ください。不完全なファイアウォールの規則が存在する場合は、対象のチェックボックスを 2 回クリックし、無効化／有効化をします。チェックが入り、チェックボックスの背景が白抜けになっていることを確認します。また、ファイアウォールの規則が削除されたことをバージョンアップ後に確認された場合には、改めて登録ください。 [特記事項] 本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

モバイルブロードバンド接続 (LTE 等) の ”自動接続を抑止する" 手順について

jpnetds — Thu, 27 Sep 2018 17:23:38 GMT

皆様、こんにちは。Windows プラットフォームサポート担当の永谷です。今回はモバイルブロードバンド接続 (LTE 等) の "自動接続を抑止する" 手順を紹介します。 - 対象の環境 Windows 10 v1607 (RS 1) 以降の OS にてモバイルブロードバンド接続をご利用頂いている環境今回の Blog では、弊社サポート部門へのお問合せも数多くお寄せいただいておりますモバイルブロードバンド接続の自動接続設定を [無効] にする設定をご案内致します。自動的にモバイルブロードバンド接続が行われてしまう動作を抑止したいお客様は是非お役立てください。 =============================== 設定方法 =============================== 下記レジストリ値を端末に設定いただくことでモバイルブロードバンド接続が "自動的に接続すること" を抑止することが可能です。 - レジストリ：キー : HKLM\Software\Policies\Microsoft\Windows\WwanSvc\GroupPolicy 名前 : DisableWwanAutoConnect 種類 : REG_DWORD 値 : 1 (補足) ・レジストリパスについては、WwanSvc キーは既定では存在しないキーのため、WwanSvc キーより新規で作成いただく必要がございます。・レジストリ設定後は OS、または WwanSvc サービスの再起動が必要です。・本設定を実施した場合、モバイルブロードバンド接続 (LTE) の自動接続が行われなくなります。・当該レジストリで LTE の自動接続設定を [有効] に強制することはできません。・設定を元に戻す際には、"値" を 0 にして端末を再起動して下さい。特記事項本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。

2018 年 9 月 11 日の更新プログラムを Hyper-V ホストに適用すると、NLB ユニキャストモードの仮想マシンが通信不可となる

jpnetds — Tue, 25 Sep 2018 10:13:13 GMT

こんにちは。Windows プラットフォームサポートです。 2018 年 9 月 11 日公開の更新プログラムを適用すると、以下の問題が発生することが判明しましたので、本 Blog で問題の内容と対応策をご案内します。 [ 問題の概要 ] 2018 年 9 月 11 日公開の更新プログラムを Hyper-V ホストに適用後、NLB ユニキャストモードを構成している仮想マシンを再起動すると、その仮想マシンへの通信ができなくなります。 ※ NLB マルチキャストモードまたは IGMP マルチキャストモードを利用している仮想マシンは影響ありません。 ※ Hyper-V 以外の仮想化環境は影響ありません。 [ 対象 OS ] この現象は、現在サポートしているすべての OS バージョンで発生します。 [ 原因 ] Hyper-V ホストで MAC アドレススプーフィング機能が動作しなくなることで発生します。仮想マシンで NLB をユニキャストモードで構成している場合、本来は仮想マシン上のネットワークアダプタの MAC アドレスが NLB ユニキャストモードの仮想 MAC アドレス (02-BF-XX-XX-XX-XX) に変更されます。しかし、Hyper-V ホストで MAC アドレススプーフィング機能が動作しなくなると、仮想マシン上のネットワークアダプタの MAC アドレスが実 MAC アドレス (例 : 00-15-5D-XX-XX-XX) となります。これにより、NLB ユニキャストモードを構成した仮想マシンへの通信ができなくなります。 [ 対応策 ] 本問題が発生した場合、以下のように対応ください。 1. Hyper-V ホストで、問題が修正された更新プログラムを適用するか、または、問題の発生する更新プログラムをアンインストールして、OS 再起動します。 2. 1 の完了後に、NLB ユニキャストモードを構成している仮想マシンで OS 再起動します。

OS バージョン	問題の発生する更新プログラム	問題が修正された更新プログラム
Windows 10 1803	September 11, 2018—KB4457128	September 20, 2018—KB4458469
Windows 10 1709	September 11, 2018—KB4457142	September 20, 2018—KB4457136
Windows 10 1703	September 11, 2018—KB4457138	September 20, 2018—KB4457141
Windows Server 2016 RTM (1607)	September 11, 2018—KB4457131	September 20, 2018—KB4457127
Windows 10 RTM	September 11, 2018—KB4457132	October 9, 2018—KB4462922
Windows Server 2012 R2 (Monthly Rollup)	September 11, 2018—KB4457129	September 20, 2018—KB4457133 (Preview of Monthly Rollup) October 9, 2018—KB4462926 (Monthly Rollup)
Windows Server 2012 R2 (Security-only update)	September 11, 2018—KB4457143	October 9, 2018—KB4462941 (Security-only update)
Windows Server 2012 (Monthly Rollup)	September 11, 2018—KB4457135	September 20, 2018—KB4457134 (Preview of Monthly Rollup) October 9, 2018—KB4462929 (Monthly Rollup)
Windows Server 2012 (Security-only update)	September 11, 2018—KB4457140	October 9, 2018—KB4462931 (Security-only update)
Windows Server 2008 R2 (Monthly Rollup)	September 11, 2018—KB4457144	September 20, 2018—KB4457139 (Preview of Monthly Rollup) October 9, 2018—KB4462923 (Monthly Rollup)
Windows Server 2008 R2 (Security-only update)	September 11, 2018—KB4457145	October 9, 2018—KB4462915 (Security-only update)
Windows Server 2008 SP2 (Monthly Rollup)	September 11, 2018—KB4458010	October 9, 2018—KB4463097 (Monthly Rollup)
Windows Server 2008 SP2 (Security-only update)	September 11, 2018—KB4457984	October 9, 2018—KB4463104 (Security-only update)

[ 更新履歴 ] 2018/09/25 : 本 Blog の公開 2018/10/10 : 問題が修正された更新プログラムの一覧を更新 [ 補足 ] 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。

Windows Server 2012 に WSUS から KB2992611 が再配信されてしまう事象について

jpnetds — Fri, 14 Sep 2018 18:47:50 GMT

こんにちは。Windows サポートチームの矢澤です。今回は Windows Server 2012 のサーバーに WSUS から KB2992611 が再配信されてしまう以下の公開情報に記載されいる以下の既知の問題 4 について本 blog にて補足します。

この更新プログラムを置き換える KB3042058 または別の更新プログラムをインストールして、置き換えられた更新プログラムが削除されると、KB2992611 が既にインストールされていても Windows Update から KB2992611 が提示されます。この問題は、置き換えられた更新プログラムの削除処理で (KB2992611 と共にインストールされる) 更新プログラム KB3018238 が削除されたために発生します。

Title: [MS14-066]SChannel の脆弱性により、リモートでコードが実行される(2014 年 11 月 11 日)　 URL:https://support.microsoft.com/ja-jp/help/2992611/ms14-066-vulnerability-in-schannel-could-allow-remote-code-execution-n [1] KB2992611 について Windows Server 2008 R2 および Windows Server 2012 向けの KB2992611 は KB3018238 を含んだ形となっている特殊な更新プログラムです。 [2] KB3018238 について 既知の問題 2 に記載されている通り、KB3018238 は暗号スイートに関する更新プログラムとなり、Windows Server 2008 R2 および Windows Server 2012 向けとして KB2992611 に内包されてリリースされております。

2014 年 11 月 18 日に、Windows Server 2008 R2 および Windows Server 2012 用のリリースに新しい二次パッケージが追加されました。この新しいパッケージは更新プログラム 3018238 です。更新プログラム 3018238 は、セキュリティ更新プログラム 2992611 と共に自動的かつ透過的にインストールされます。

[3] StartComponentCleanup について Windows 8 / Windows Server 2012 から StartupComponentCleanup という機能が実装されました。この機能は新しい更新プログラムによって置き換えできる更新プログラムがインストールされていることを検知した場合には、端末の容量削減のために古い更新プログラムを自動的に削除する機能となります。なお、削除された更新プログラムはインストール済の更新プログラムからも削除されます。 Title: StartComponentCleanup タスクによる、不要な更新プログラムの削除について URL:https://blogs.technet.microsoft.com/askcorejp/2015/12/03/startcomponentcleanup/ [4] StartComponentCleanup が動作する仕組み StartComponentCleanup タスクによって更新プログラムが削除される要件としては以下の 2 点となりますので、上書きするような更新プログラムをインストールしたからといって即座に置き換え対象の更新プログラムが削除されるわけではありません。・更新プログラムの適用後 30 日以上であること・30 日経過以後に、更新プログラムの適用や削除が実行されること [5] 既知の問題 4 について KB2992611 がインストールされている環境において、KB3018238 を置き換えるような更新プログラムがインストールされ、[4] の条件が満たされると、StartComponentCleanup が動作し KB3018238 を削除します。StartComponentCleanup によって KB3018238 が削除されると、この更新プログラムを内包している KB2992611 が完全にインストールされていないとみなされ、WSUS から KB2992611 が再配信されます。これが既知の問題 4 に記載されている内容となり、StartComponentCleanup の機能を持つ Windows Server 2012 のみで事象が発生します。 [6] 対処策1：対象の更新プログラムを「拒否」にする 以下の手順により KB2992611 を WSUS 上で「拒否済み」状態とし、KB2992611 の再配信を停止します。 1. WSUS 管理コンソールを起動して、左ペインのツリーより [更新] をクリックします。 2. 右ペインの [検索] をクリックします。 3. 検索ボックスに 2992611 を入力して [検索] をクリックします。 4. 検索結果に一致する更新プログラムが表示されますので、KB2992611 を右クリックし [拒否] をクリックします。 [7] 対処策2：配信された更新プログラムを「非表示」にする WSUS から配信された更新プログラム KB2992611 をクライアント側で「非表示」にして、自動適用や表示上の対象外とします。下記の公開情報にて紹介している手順にて、更新プログラムを「非表示」にすることが可能です。クライアント OS 向けに公開している情報となりますが、Windows Server 2012 でも同様の手順となります。 Title: Windows 7 の Windows Update で更新プログラムが検出された場合に、更新プログラムを非表示に設定することでインストール対象から除外する方法 URL:https://support.microsoft.com/ja-jp/help/2463965 [8] その他の事例 2018 年 9 月現在、他の更新プログラムによって同様の事象が発生したという報告は確認できておりません。

Windows Hello における多要素のロック解除について

jpnetds — Wed, 05 Sep 2018 18:43:39 GMT

こんにちは。Windows サポートチームの矢澤です。今回は RS3 (1709) から新しく実装された Windows Hello の多要素認証についてご紹介します。詳細は以下の公開情報に記載されておりますが、わかりにくい点もありますのでこちらの blog にて補足します。 Title: 多要素のロック解除 URL:https://docs.microsoft.com/ja-jp/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock ◆動作◆ 「最初のロック解除要素である資格情報プロバイダー」「2 番目のロック解除要素である資格情報プロバイダー」にて設定されたプロバイダー (PIN、顔、指紋、信頼された信号) から一つずつ要素を利用して、ログオンおよび画面ロックの解除において二要素認証を実現します。 ◆設定方法◆ ローカルグループポリシーエディター (gpedit.msc) では以下のパスで指定します。 [コンピューターの構成] - [管理用テンプレート] - [Windows コンポーネント] - [Windows Hello for Business] - [デバイスのロック解除要素を構成する] 設定名は Windows Hello for Business ですが、通常の Windows Hello (WorkGroup, ドメイン環境) でも動作し、設定後は再起動などは不要で、[スタート] + L の画面ロックをすることですぐに設定した内容での動作を確認できます。また、少なくともどちらかの設定に PIN が含まれている必要があります。 ◆GUID◆ 既定では「最初のロック解除要素である資格情報プロバイダー」に [PIN/顔/指紋] が登録され、「2 番目のロック解除要素である資格情報プロバイダー」に [PIN/信頼された信号] が登録されますので、追加、削除などしたい場合には以下の GUID を参照いただき、設定を変更ください。 PIN: {D6886603-9D2F-4EB2-B667-1971041FA96B} 顔：{8AF662BF-65A0-4D0A-A540-A338A999D36F} 指紋：{BEC09223-B018-416D-A0AC-523971B639F5} 信頼された信号：{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD} ◆適用順序◆ 「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」という名称ですが、どちらのリストから開始されても問題ありません。例えば、「PIN/顔」＋「PIN/指紋」と設定した場合には先に「2 番目のロック解除要素である資格情報プロバイダー」に設定されている指紋認証からでも認証を開始することができ、その後に顔認証でロックが解除される状態となります。なお、最初は必ず顔認証してから、次に指紋認証、などといった順序を厳密に定義することはできません。 ◆両方のリストに含まれる要素◆ 「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」の両方に含まれる要素があった場合、両方に含まれる要素を最初に利用した場合は、「最初のロック解除要素である資格情報プロバイダー」と「2 番目のロック解除要素である資格情報プロバイダー」に設定されている残りの要素を追加認証で利用することができます。例えば、「PIN/顔」＋「PIN/指紋」と設定した際に、先に PIN にて認証をした場合は、追加の要素としては「顔」「指紋」の両方が利用可能です。なお、この設定では、以下のような形で認証が可能です。・PIN + 顔・PIN + 指紋・顔 + PIN ・顔＋指紋・指紋＋ PIN ・指紋＋顔 ◆生体認証のロック◆ 生体認証に 3 回失敗した場合には、使用した生体認証(顔認証 or 指紋認証) にロックがかかり PIN を入力しないと解除されません。多要素ロックの設定をしている場合には、追加要素の認証が成功してデスクトップ画面が表示されないと、生体認証が再度認識されません。例えば、「PIN/顔」＋「PIN/指紋」と設定した際に、指紋認証に 3 回間違えてロックがかかり、PIN にて解除した場合には、PIN にて認証したことになりますので、「顔」もしくは「指紋」にて追加の要素で認証する必要がありますが、「指紋」はロックがかかっているため、「顔」を使用して認証する必要があります。 ◆パスワード◆ サインインオプションとしてパスワードのアイコンは必ず表示されますので、多要素のロック解除の設定をした場合でもパスワードのアイコンをクリックし、パスワードを入力することで 1 要素のみでロックを解除することができます。