Hebikuzure's Tech Memo

2018年8月29日

非管理者ユーザーにセーフモードでサインインさせない

Filed under: Windows Tips — タグ: , , , , , — hebikuzure @ 5:06 午後

Windows 10 を含めて Windows 7 以降のバージョンでは、Windows をセーフモードやセーフモードとネットワークで起動した場合、管理者権限の有無を問わずどのユーザーでもサインイン(ログオン)が可能です。しかしセーフモードでは通常起動の際には自動的に動作するサービスやプログラムが起動していない状態になるため、挿入しているセキュリティ ソリューションが無効になってしまう場合があります。またセーフモードでは通常アクセスできない機能などにアクセスできる場合もあります。

こうしたことを考えると、管理者権限を持たない通常のユーザーがセーフモードでサインインできなくすることは、コンピューターのセキュリティ強化に繋がるといえます。

非管理者にセーフモードでサインインさせない設定

管理者権限を持たないユーザーをセーフモードでサインインできなくするには、以下のレジストリを構成します。
※Windows 7 / Windows Server 2008 R2 の場合は SP1 の適用が必要です

キー:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System
名前:SafeModeBlockNonAdmins
種類:REG_DWORD
データ:1

ドメイン環境であれば、このレジストリ構成をグループポリシーで配布できます。

コンピューターの構成 > 基本設定 > Windows の設定 > レジストリ
image

参考情報

広告

2018年8月26日

BitLocker の回復パスワードを確認する

Filed under: Windows Tips — タグ: , , , — hebikuzure @ 2:15 午後

Windows のセキュリティー機能にディスクを暗号化する BitLocker があります。

BitLocker と「回復パスワード」

BitLocker 暗号化では復号のために必要となるキーを TPM チップに格納して、暗号化したディスクが同じデバイスに接続されている限りは透過的に復号が行われるようになってるため、ユーザーは普段は復号のための操作をする必要はありません。

追加の構成で TPM チップではなく USB ドライブを使用したり、起動時にパスワードや PIN を求めるようにすこことも可能です。
BitLocker についての詳細は Microsoft Docs の「BitLocker」を参照してください。

ただしデバイスのブート構成が変更された場合や、PC が起動できなくなってドライブを別のデバイスで読み取る必要がある場合、また上記の追加の構成で USB ドライブを紛失したり PIN を忘れたりした場合、「回復パスワード」を使うことで暗号化されたディスクにアクセスすることが可能になります。回復パスワードは 48桁の数字からなるパスワードです。

回復パスワードだ求められる場合については「BitLocker 回復ガイド」の「BitLocker 回復が実行される原因」を参照してください。

BitLocker を有効にする場合、次のようなメッセージが表示されて「回復キー」の保存を求められますが、ここで保存できるのが「回復パスワード」です(資料や UI、実際のデータで用語が混乱していますが、ここで「回復パスワード」が自動生成され、指定した方法で保存できます)。

image

この他に Active Directory ドメインに参加している PC の場合は、ドメイン内のサーバーに自動的に保存されるよう構成できます。
AzureAD に参加している PC では AzureAD に保存することもできます。

回復パスワードが不明になったら

さて、何らかの理由でここで保存した回復パスワードの情報が利用できなくなった場合、例えば利用していた Microsoft アカウントが利用できなくなったり、保存したファイルや印刷物を紛失した場合、設定済みの回復キーを調べなければならなくなります。

回復パスワードを求めれれる状況にならなければ通常の使用には問題ないのですが、ひとたび回復パスワードを求められると、それを入力しない限りそのディスクを読み取ることはできなくなります。

参考:BitLocker 回復キーを探す

参考資料に書かれているように、起動ディスクが暗号化されていて回復パスワードが分からない場合、PC を初期化しなければ利用できなくなります。当然ディスクに保存していたデーターもすべて失われます。

回復パスワードを調べる

設定済みの回復パスワードを調べるには管理者コマンドプロンプトで以下のコマンドを実行します。

manage-bde.exe –protectors –get C:
(C ドライブを暗号化した場合)

これで最初に保存した時と同じ ID とパスワードを表示することができます。改めてファイルに保存したり印刷したりして、大切に保管しておきましょう。

2018年4月4日

2018年2月11日

「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」を制御する

Filed under: Windows Tips — hebikuzure @ 2:03 午後

「更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します」の機能を制御する方法についてまとめました。

機能の概要

Windows 10 では、更新プログラムのインストール後や手動での再起動の際に、ユーザーが意図的にサインインしなくとも、再起動後に再起動前にサインインしていたユーザーは自動的にサインイン処理が行われます。実際にはサインインが行われるとすぐにロックがおこなわれ、ユーザーにはロック画面が表示されますがそのバックグラウンドでサインイン後の処理が行われます。ここで行われる処理は以下のようなものです。

  • ユーザー権限で起動するスタートアップ プログラムの起動
  • サインイン(ログイン)がトリガーになるタスクの実行
  • Windows 10 Fall Creators Update 以降では再起動開始時に起動していたアプリケーションの復元

この機能はユーザー単位で有効/無効を切り替えできます。これを有効にしておくことでユーザーは再起動時に時間を無駄にすることなく、ロックを解除すればすぐに作業が再開できるのですが、以下のような問題もあります。

  • 再起動前に複数のユーザーがサインインしていた場合、再起動を開始したユーザー以外のユーザーのサインイン処理も同時に行われる(不要なサインインであったり、処理の負荷が高くなったりします)
  • ローカル セキュリティ ポリシーで「対話型ログオン:最後のユーザ名を表示しない」を構成しても、(表示されるのはサインイン画面ではなくロック画面なので)無意味になる

そのためこの動作を無効にしたい場合もあるでしょう。

機能の無効化

通常これを無効にするには、ヘルプ記事

に書かれているように

Windows 10 Fall Creators Update (バージョン 1709) の場合は、[スタート] [設定][アカウント][サインイン オプション] の順に選び、[更新または再起動の後にサインイン情報を使ってデバイスのセットアップを自動的に完了します] をオフにします

Windows 10 Creators Update (バージョン 1703) 以前のバージョン場合は、[スタート] – [設定] – [更新とセキュリティ] – [Window Update][詳細オプション] の順に選び、[更新後にサインイン情報を使ってデバイスのセットアップを自動的に完了します] の横にあるチェック ボックスをオフにします

それではこの機能をグループポリシーなどで一括して制御したい場合はどうすれば良いでしょうか。グループポリシー エディターなどでポリシーを探しても、これを制御できるポリシーは見つかりません。

実は上記のヘルプ記事に書かれているようにこの機能は Active Directory ドメインに参加しているコンピューターでは自動的に無効になります。そのためこの動作はグループポリシーで制御する必要がない(意味が無い)ということです。また Active Directory ドメインに参加しているコンピューターだけでなく、上記ヘルプ記事にあるように「作業やメールのポリシーが組織によってデバイスに適用されている場合」= Azure AD Join している場合や、[設定][アカウント][職場または学校にアクセスする] で Azure AD アカウント(Office 365 などの組織アカウント)に接続している場合も、この機能は無効になります。

レジストリ情報

上記のようにグループポリシーでこの機能を制御する必要はないのですが、ワークグループ環境でも何らかの理由で管理者などがこの機能の有効/無効を他のユーザーに対して設定したい場合があるでしょう。その場合、この設定は以下のレジストリ エントリに保存されているので、これを(スクリプトや reg ファイルなどで)構成します。

  • キー:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon\UserARSO\<ユーザーの SID >
  • 名前:OptOut
  • 種類:REG_DWORD
  • データ:0(機能オン)/ 1(機能オフ)
    ※ オプトアウトを指定する項目なので、0 がオプトアウトしない=機能有効、1 がオプトアウト=機能無効、となります

参考:TechNet フォーラム「【サインインオプション】グループポリシーでの設定

2018年1月25日

2018年1月18日

Windows 10 スタート画面のピン留めアプリの AppID を取得する

Filed under: Windows Tips — タグ: , , — hebikuzure @ 5:35 午後

Windows 10 のスタート画面のカスタマイズについて確認していた時に調べた自分用のメモですが、公式ドキュメントだとちょっと不親切なので分かりやすくまとめてみました。

概要

Windows 10 でスタート画面のカスタマイズを展開する場合、スタート画面にピン留めされているデスクトップ アプリケーションの DesktopApplicationID を取得しなければならない場合があります。その DesktopApplicationID は PowerShell を利用して取得できます。

詳細

Windows 10 でスタート画面(スタートメニュー)のカスタマイズを他のコンピューターに展開するには、カスタマイズ内容を XML ファイルにエクスポートし、それを被カスタマイズ対象のコンピューターでインポートするという作業が必要です。この作業については

に解説されています。ただこの記事でも書かれているように、スタート画面にデスクトップ アプリケーションがピン留めされている場合、エクスポートした XML ファイルを編集して DesktopApplicationLinkPath を DesktopApplicationID に変更しなければなりません。

上のページには

重要
エクスポートするスタート画面のレイアウトに、デスクトップ (Win32) アプリのタイルや .url リンクが含まれている場合、結果ファイルでは Export-StartLayout で DesktopApplicationLinkPath が使用されます。 テキスト エディターまたは XML エディターを使用して、DesktopApplicationLinkPath を DesktopApplicationID に変更してください。

と記載されています。

この変更ですが、上記ページからリンクされている

を見ると

注意
Windows 10 バージョン 1703 のスタート画面のレイアウトでは、グループ ポリシーまたは MDM を使用してスタート画面のレイアウトを適用しており、アプリケーションがユーザーの初回サインイン以降にインストールされている場合は、DesktopApplicationLinkPath ではなく、DesktopApplicationID を使用してください。

と書かれていて、より条件が明確になっています。プロビジョニングパッケージによる展開以外の方法(グループ ポリシーまたは MDM)で XLM を展開する場合で、ユーザープロファイルが生成された以降にインストールされたデスクトップ アプリケーション(と .url リンク)については、DesktopApplicationLinkPath から DesktopApplicationID への書き換えが必要ということです。

またこの記事では DesktopApplicationID は Get-StartApps コマンドレットを使用して取得できると書かれています。この取得の操作は以下の手順で行えます。

操作

  1. スタート画面のカスタマイズを構成するマスター コンピューターで、カスタマイズを行うユーザーでサインインします
  2. PowerShell を起動します
  3. 次のコマンドを実行してスタート画面にピン留めされているアプリ名の一覧を取得します
    Get-StartApps | ft Name
  4. 前の実行結果から、DesktopApplicationID を取得したいアプリケーションの Name 属性を確認します
  5. 次のコマンドを実行して Neme のアプリケーションの DesktopApplicationID を取得します
    Get-StartApps -Name (AppName) | ft AppID

例えば

PS > Get-StartApps -Name “Microsoft Azure Storage Explorer” | ft AppID
AppID
—–
{7C5A40EF-A0FB-4BFC-874A-C0F2E0B9FA8E}\Microsoft Azure Storage Explorer\StorageExplorer.exe

のように DesktopApplicationID を取得します。

2017年9月22日

Windows に接続したモニターを再認識させる

Filed under: Windows Tips — hebikuzure @ 7:45 午後

Windows が動作している PC にモニターを接続すると、解像度などのモニターの情報が自動認識されてすぐに利用可能になります。これは便利なことではありますが、まれにこの自動認識で不適切な情報が構成されてしまい、本来設定できる解像度が設定できない、マルチ モニター構成でプライマリ モニターとセカンダリーモニターが意図通りに設定されない、などのトラブルが発生します。こうした場合に認識済みのモニターの構成情報を削除して、強制的に再認識させる方法を解説します。

一度接続したことがあるモニターの構成情報はレジストリに登録され、新しいモニターが接続されるごとに登録が追加されていきます。この情報は削除されることがなく、またモニターの組み合わせごとに作成されるので、ノート PC を色々な外部モニターに接続していると、非常に多くの情報が登録されることになります。

例えば仕事柄色々な場所で外部モニター(プロジェクターなど)に接続する私のノート PC では、

image

こんな感じで大量のエントリが記録されています。

モニターを強制的に再認識させるには、これらのレジストリ エントリを手動で削除します。実際にはエントリが登録されている以下のキー全体を削除すれば良いでしょう。

HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Configuration
HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Connectivity

これらのキーは(作業時点で接続している)モニターが再認識されたタイミングで自動的に再生成されます。その後、再認識させたい外部モニターなどがあれば、順に接続していきます。

個別に特定のモニター(モニターの組み合わせ)だけを削除したいという場合は、以下のような方法で該当するエントリを探すことも可能です。ただしエントリが多数ある場合はかなり面倒なので、特段の理由がなければまとめて削除した方がよいでしょう。

エントリを特定するには、いくつかの情報を総合することになります。エントリのキー名は

MEI96A20_00_07DD_11*SHP109F0_00_07DC_4F^2392D524F1666208AC7A949449A77697

のようになっており、このうち “MEI96A2” と “SHP109F” の部分はレジストリ

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\DISPLAY

に同録されているモニター デバイスの名前(キー名)になっています。そしてこの名前は、デバイス マネージャーで [モニター] 配下にある各モニター(現在接続されていないモニターは [非表示のデバイスの表示] を有効にしないと見えません)の [プロパティ] – [詳細] で [ハードウエア ID] で表示されます。

image

そしてこのモニターについては同じプロパティで [初回インストール日付] や [最後に接続した日] を確認することができます。これらの情報から具体的にどのモニターを示しているのかを推定することができるでしょう。
※ただし [初回インストール日付] については Windows のアップグレード(Windows 10 の機能アップグレードを含む)のような Windows 側の更新などでハードウエアの再認識が行われると、その日付に変わってしまうので、実際のその PC に最初に接続した日ではない場合があります。

image

また

HKLM\Systems\CurrentControlSet\Control\GraphicsDrivers\Configuration

配下のサブキーには Timestamp という値が格納されており、これでそのエントリが最初にいつ登録されたか(いつそのモニターの組み合わせが認識されたか)を確認できます。ただしこの値は NT タイムエポック形式で記録されているので、日時を確認するには NT エポックタイムから通常の時刻形式への変換が必要です。

image

NT エポックタイムから通常の時刻形式に変換するには、コマンドプロンプトで w32tm コマンドを利用します。上のスクリーンショットでは Timestamp 値が 1d037a7d21bbfb3 (130665583117844403) となっていますので、

C:\WINDOWS\system32>w32tm /ntte 130665583117844403
151233 07:31:51.7844403 – 2015/01/24 16:31:51

のように /ntte オプションを付けて、10進数の Timestamp 値を引数にして実行します。

以上のような情報からいつどのモニターの組み合わせを認識させたのかという情報から、対応するエントリ(サブキー)を推定することが可能でしょう。

2016年10月8日

TCP ポート 445 がブロックされていると Windows 10 に更新後共有フォルダーにアクセスできない

Filed under: Windows Tips — hebikuzure @ 6:43 午後

これも「MS16-110 適用後 NAS などの共有フォルダーに接続できない問題」の調べもの中に見つけた情報です。

Windows のファイル共有に利用される SMB ではサーバー側の待ち受けポートてして TCP 445 番ポートが利用されますが、445 番ポートが何らかの理由でブロックされている場合はレジストリの構成で 445 番の代わりに 139 番ポートを使うよう構成することができました。

構成するレジストリは以下の通りです。

キー : HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters
名前 : EnableNetBTForSmb2
種類 : DWORD
設定値 : 1

参考情報 : TCP 445 番ポートが遮断されていると Windows 8、Windows Server 2012 以降の OS からファイル共有通信ができない

しかしこのレジストリ構成をして共有に接続していたクライアントを Windows 10 にアップグレードしたり、新規の Windows 10 にこのレジストリを構成しても、共有には接続できません。これは、上記の参考情報に書かれているように、このレジストリは Windows 10 では利用できず無視されるからです。

SMBv1 以前のファイル共有プロトコルはすでに非推奨となって久しく、将来的に利用できなくなると考えられるので、Windows 10 で SMB によるファイル共有を行う場合は、TCP 445 番ポートをブロックしないようにネットワークを構成しましょう。

ファイル共有で利用されている SMB のバージョンを確認する方法

Filed under: Windows Tips — hebikuzure @ 6:42 午後

先日の「MS16-110 適用後 NAS などの共有フォルダーに接続できない問題」の記事の調べ物をしている際に見つけた Tips についてメモ代わりに投稿しておきます。

Windows でのファイル共有には SMB プロトコルが利用されていることは良く知られていますが、SMB は Windows 製品で長く使われ機能とセキュリティが強化されてきたため、SMBv1、SMBv2、SMBv3 といったバージョンやさらに細かなダイアレクト が存在しています。通常はサーバー – クライアント間で自動的にネゴシエーションが行われ適切なバージョン・ダイアレクトが利用されるため、こうした違いを意識する必要はないのですが、Windows 製品以外 (Linux 上の Samba や OS Ⅹ、NAS など) と接続する場合や、Windows 間でもトラブルシュートをする場合など、どのようなバージョン・ダイアレクトが利用されているのか確認したい場合があります。

そのような場合、クライアントで次のような方法で利用している SMB のバージョン・ダイアレクトを確認することができます。

クライアントで利用可能な SMB のバージョンを確認する

  1. コマンド プロンプトで以下を実行します
    sc.exe qc lanmanworkstation
  2. 結果がC:\>sc.exe qc lanmanworkstation
    [SC] QueryServiceConfig SUCCESS

    SERVICE_NAME: lanmanworkstation
    TYPE                              : 20  WIN32_SHARE_PROCESS
    START_TYPE                  : 2   AUTO_START
    ERROR_CONTROL          : 1   NORMAL
    BINARY_PATH_NAME     : C:\WINDOWS\System32\svchost.exe -k NetworkService
    LOAD_ORDER_GROUP   : NetworkProvider
    TAG                              : 0
    DISPLAY_NAME             : Workstation
    DEPENDENCIES             : Bowser
    : MRxSmb20
    : NSI
    SERVICE_START_NAME : NT AUTHORITY\NetworkService

    のように表示されます。

  3. DEPENDENCIES 欄を確認します。
    mrxsmb20 がある場合は SMBv2 (Windows 8/Windows Server 2012 以降は SMBv3 も) が有効です。
    mrxsmb10 がある場合は SMBv1 が有効です。

参考 : Windows Vista、Windows Server 2008、Windows 7 、Windows Server 2008 R2、Windows 8、Windows Server 2012 で 、SMBv1、SMBv2、SMBv3 を有効、または無効にする方法

SMB セッションで利用されている SMB のダイアレクトを確認する

実際に開いている SMB セッションでどのような SMB ダイアレクトが利用されているか確認するには、管理者として実行した PowerShell で以下を実行します。
Get-SmbConnection
開いている SMB セッションの利用しているダイアレクトや資格情報などの詳細情報が表示されます。

SMB セッションがないと何も表示されないので、利用ダイアレクトを調べたい相手 (サーバー) 上の共有を開いた状態で実行してください。簡単にはエクスプローラーで共有フォルダーを開いておけば OK です。

2015年8月22日

Windows 10 の 1394 OHCI ホスト ドライバー

Filed under: Windows トラブル, Windows Tips — タグ: , , — hebikuzure @ 4:14 午後

Windows 8 がリリースされた際に、古めの 1394 接続 (FireWire 接続) のデバイス、例えばデジタル ビデオ カメラなどが正常に認識されなくなったり、機能が制限されてしまったりするという現象が起きました。これは Windows 8 での 1394 OHCI 対応ホスト コントローラー 用のドライバーが、新しいWindows Driver Framework (WDF) モデルの物だけになり、古い (Legacy) ドライバーが削除されたためです。一部の古い 1394 接続周辺デバイスは WDF ドライバーで動作する 1394 ホスト コントローラーと互換性がないため、Windows 8 ではそれらのデバイスが正しく動作しなくなってしまったのです。

古いドライバーから新しいドライバーへの置き換えは、実は Windows 7 で行われていたのですが、Windows 7 には古いモデルの 1394 OHCI Compliant Host Controller (Legacy) ドライバーも含まれており、手動でこちらのドライバーに切り替える事で古いデバイスも利用可能でした。しかし Windows 8 では古いモデルのドライバーは削除され、この方法は利用できなくなっていました。

この非互換についてユーザーから多くの要望が寄せられたため、Microsoft では Windows 8/8.1 用の 1394 OHCI Compliant Host Controller (Legacy) ドライバーを別途に用意することにし、技術情報「FireWire port-based device does not work correctly in Windows 8.1 or Windows 8」を公開してダウンロード提供を開始しました。

Windows 8 で削除された古いモデルの OHCI ホスト ドライバーは Windows 10 にも含まれていません。そのため Windows 7 などから Windows 10 にアップグレードした場合や、Windows 10 の新規インストールを行った場合、Windows 8 の時と同様に一部の 1394 デバイスが正常に利用できなくなるという問題が発生します。

Windows 8/8.1 へのレガシーな OHCI ホスト ドライバーの提供開始を案内する「Announcing the availability of a standalone legacy 1394 OHCI (FireWire) package」に『•Customers who upgrade to a newer OS version in the future will be required to reinstall this standalone driver package.』と書かれているように、この Windows 8/8.1 用に提供されたドライバーは Windows 10 にも適用可能です。Windows 8/8.1 の場合と同様に、32ビット版または 64ビット版のドライバー パッケージをダウンロード/インストールした後、デバイス マネージャーで OHCI ホスト コントローラーのドライバーを手動で “Generic1394 OHCI compliant host controller (Legacy)” に変更すれば、Windows 10 でも古い 1394 デバイスを利用することができるようになります (下図参照)。

参考情報

Older Posts »

WordPress.com Blog.

%d人のブロガーが「いいね」をつけました。