ローカル アカウント
この記事では、Windows オペレーティング システムの既定のローカル ユーザー アカウントと、組み込みアカウントを管理する方法について説明します。
ローカル ユーザー アカウントについて
ローカル ユーザー アカウントは、デバイス上でローカルに定義され、デバイスに対してのみ権限とアクセス許可を割り当てることができます。 ローカル ユーザー アカウントは、サービスまたはユーザーのデバイス上のリソースへのアクセスをセキュリティで保護および管理するために使用されるセキュリティ プリンシパルです。
既定のローカル ユーザー アカウント
既定のローカル ユーザー アカウントは、オペレーティング システムのインストール時に自動的に作成される組み込みアカウントです。 既定のローカル ユーザー アカウントは削除することも削除することも、ネットワーク リソースへのアクセスを提供することもできません。
既定のローカル ユーザー アカウントは、アカウントに割り当てられている権限とアクセス許可に基づいて、ローカル デバイスのリソースへのアクセスを管理するために使用されます。 既定のローカル ユーザー アカウントと作成するローカル ユーザー アカウントは、 Users フォルダーにあります。 Users フォルダーは、ローカル コンピューター管理 Microsoft 管理コンソール (MMC) の [ローカル ユーザーとグループ] フォルダーにあります。 Computer Management は、ローカルまたはリモート デバイスの管理に使用できる管理ツールのコレクションです。
既定のローカル ユーザー アカウントについては、次からの各セクションで説明します。 詳細については、各セクションを展開します。
管理者
既定のローカル管理者アカウントは、システム管理用のユーザー アカウントです。 どのコンピューターにも Administrator アカウントがあります (SID S-1-5-ドメイン-500、表示名「Administrator」)。 Administrator アカウントは、Windows のインストール時に作成される最初のアカウントです。
管理者アカウントは、ローカル デバイス上のファイル、ディレクトリ、サービス、およびその他のリソースを完全に制御できます。 Administrator アカウントでは、別のローカル ユーザーの作成、ユーザー権利の割り当て、およびアクセス許可の割り当てが可能です。 管理者アカウントは、ユーザー権限とアクセス許可を変更することで、ローカル リソースをいつでも制御できます。
既定の Administrator アカウントの削除やロック アウトはできませんが、そのアカウントの名前変更や無効化は可能です。
Windows セットアップでは、組み込みの管理者アカウントが無効になり、Administrators グループのメンバーである別のローカル アカウントが作成されます。
Administrators グループのメンバーは、[管理者として実行] オプションを使用することなく、管理者特権でアプリを実行できます。 高速ユーザー切り替えは、別のユーザー昇格を使用 runas するよりも安全です。
アカウント グループのメンバーシップ
既定では、管理者アカウントは Administrators グループのメンバーです。 Administrators グループのメンバーにはデバイスに対するフル コントロールアクセス許可があるため、Administrators グループのユーザー数を制限することをお勧めします。
管理者アカウントを Administrators グループから削除することはできません。
セキュリティに関する考慮事項
Administrator アカウントは多くのバージョンの Windows オペレーティング システムに存在していることが知られているため、可能な場合は Administrator アカウントを無効化することで、悪意のあるユーザーがサーバーやクライアント コンピューターに簡単にはアクセスできなくなるようにしてください。
Administrator アカウントの名前は変更できます。 ただし、Administrator アカウントは名前を変更しても自動的に割り当てられたセキュリティ識別子 (SID) をそのまま使用します。この識別子は、悪意あるユーザーが探り出すことができます。 ユーザー アカウントの名前変更や無効化の方法の詳細については、「ローカル ユーザー アカウントを無効または有効にする」および「ローカル ユーザー アカウントの名前を変更する」を参照してください。
セキュリティのベスト プラクティスとして、サインインの際にはローカルの (Administrator ではない) アカウントを使用して、標準ユーザー アカウントよりも高度な権利が必要なタスクを実行するときには [管理者として実行] を使用します。 Administrator アカウントは、そのアカウントがどうしても必要な場合を除いて、コンピューターへのサインインには使用しないでください。 詳細については、「管理者資格情報でプログラムを実行する」を参照してください。
グループ ポリシーを使用して、ローカル Administrators グループの使用を自動的に制御できます。 グループ ポリシーの詳細については、「グループ ポリシーの概要」を参照してください。
重要
- 空白のパスワードは許可されません
- 管理者アカウントが無効になっている場合でも、セーフ モードを使用してコンピューターにアクセスするために使用できます。 回復コンソールまたはセーフ モードでは、Administrator アカウントが自動的に有効化されます。 通常の操作が再開されると、無効になります。
ゲスト
Guest アカウントを使用すると、コンピューターに対するアカウントがない臨時ユーザーや 1 回限りのユーザーが、制限付きのユーザー権利でローカルのサーバーまたはクライアント コンピューターに一時的にサインインできるようになります。 既定では、ゲスト アカウントは無効になっており、空白のパスワードが設定されています。 ゲスト アカウントは匿名アクセスを提供できるため、セキュリティ リスクと見なされます。 このため、ゲスト アカウントの使用が必要な場合を除き、ゲスト アカウントを無効のままにしておくことをお勧めします。
ゲスト アカウント グループ メンバーシップ
既定では、ゲスト アカウントは、ユーザーがデバイスにサインインできるようにする既定のゲスト グループ SID S-1-5-32-546の唯一のメンバーです。
ゲスト アカウントのセキュリティに関する考慮事項
Guest アカウントを有効にすると、制限付きの権利とアクセス許可のみが付与されます。 セキュリティ上の理由から、Guest アカウントはネットワーク経由で使用しないでください。また、別のコンピューターからアクセスできるようにしないでください。
さらに、Guest アカウントのゲスト ユーザーは、イベント ログを表示できないようにしておきます。 Guest アカウントを有効化したときには、Guest ユーザーを頻繁に監視して、別のユーザーがサービスなどのリソースを使用できないようにしてください。 これには、以前のユーザーが意図せずに利用可能にしたリソースが含まれます。
HelpAssistant
HelpAssistant アカウントは、リモート アシスタンス セッションの実行時に有効化される既定のローカル アカウントです。 このアカウントは、保留状態のリモート アシスタンス要求がなくなったときに、自動的に無効化されます。
HelpAssistant は、リモート アシスタンス セッションの確立に使用されるプライマリ アカウントです。 リモート アシスタンス セッションは、Windows オペレーティング システムを実行している別のコンピューターに接続するために使用され、招待によって開始されます。 リモート アシスタンスの要請のために、ユーザーは自分のコンピューターからアシスタンスを提供できるユーザーに向けて電子メールまたはファイルとしての招待を送信します。 リモート アシスタンス セッションに対するユーザーの招待が受け入れられた後、既定の HelpAssistant アカウントが自動的に作成され、サポートを提供するユーザーにコンピューターへの制限付きアクセス権が付与されます。 HelpAssistant アカウントは、Remote Desktop Help Session Manager サービスが管理します。
HelpAssistant アカウントのセキュリティに関する考慮事項
既定の HelpAssistant アカウントに関連する SID には、次のものがあります。
- SID:
S-1-5-<domain>-13、表示名 ターミナル サーバー ユーザー。 このグループには、リモート デスクトップ サービスが有効化されたサーバーにサインインするユーザーがすべて含まれます。 - SID:
S-1-5-<domain>-14、表示名 リモート 対話型ログオン。 このグループには、リモート デスクトップ接続を使用してコンピューターに接続するユーザーがすべて含まれます。 このグループは、Interactive グループのサブセットです。 Remote Interactive Logon の SID を格納しているアクセス トークンには、Interactive の SID も格納されています。
Windows Server オペレーティング システムの場合、リモート アシスタンスは、既定ではインストールされないオプションのコンポーネントです。 リモート アシスタンスは、使用前にインストールしておく必要があります。
HelpAssistant アカウントの属性に関する詳細については、次の表を参照してください。
HelpAssistant アカウントの属性
| 属性 | 値 |
|---|---|
| 既知の SID/RID | S-1-5-<domain>-13 (Terminal Server User), S-1-5-<domain>-14 (Remote Interactive Logon) |
| 型 | ユーザー |
| 既定のコンテナー | CN=Users, DC=<domain> |
| 既定のメンバー | なし |
| ～の既定のメンバー | Domain Guests Guests |
| ADMINSDHOLDER で保護されているか | なし |
| 既定のコンテナーから移動することができるか | 移動はできますが、お勧めしません。 |
| このグループの管理をサービス管理者以外に委任できるか | なし |
DefaultAccount
DefaultAccount アカウント (既定のシステムマネージド アカウント (DSMA) とも呼ばれます) は、既知のユーザー アカウントの種類です。 DefaultAccount は、マルチユーザー対応またはユーザーに依存しないプロセスを実行するために使用できます。
DSMA は、デスクトップ エディションとデスクトップ エクスペリエンスを備えたサーバー オペレーティング システムでは、既定で無効になっています。
DSMA には、 の既知の 503RID があります。 したがって、DSMA のセキュリティ識別子 (SID) には、次の形式の既知の SID が含まれます S-1-5-21-\<ComputerIdentifier>-503。
DSMA は、 の既知の SID を持つ、既知のグループ System Managed Accounts グループの S-1-5-32-581メンバーです。
DSMA エイリアスは、アカウント自体が作成される前でも、オフライン ステージング中にリソースへのアクセスを許可できます。 このアカウントとグループは、コンピューターの初回ブート時に、セキュリティ アカウント マネージャー (SAM) に作成されます。
Windows での DefaultAccount の使用方法
アクセス許可の観点では、DefaultAccount は標準ユーザー アカウントになります。 DefaultAccount は、マルチユーザー マニフェスト アプリ (MUMA アプリ) を実行するために必要です。 MUMA アプリは、常時実行されていて、ユーザーによるデバイスへのサインインおよびデバイスからのサインアウトに反応します。 アプリがユーザーのコンテキストで実行され、ユーザーのサインオフ時に終了される Windows デスクトップとは異なり、MUMA アプリは DSMA を使用して実行されます。
MUMA アプリは、Xbox などの共有セッションの SKU で機能します。 たとえば、Xbox シェルは MUMA アプリです。 現在、Xbox は Guest アカウントとして自動的にサインインして、このコンテキストですべてのアプリを実行します。 すべてのアプリがマルチユーザーに対応していて、ユーザー マネージャーによって開始されたイベントに応答します。 アプリは、Guest アカウントとして実行されます。
同様に、電話は DefApps アカウントとして自動ログインします。これは Windows の標準ユーザー アカウントに似ていますが、追加の特権がいくつかあります。 ブローカーや一部のサービスとアプリは、このアカウントとして実行されます。
集約型のユーザー モデルでは、マルチユーザー対応のアプリとマルチユーザー対応のブローカーを別のユーザーのコンテキストで実行する必要があります。 この目的のために、システムによって DSMA が作成されます。
ドメイン コントローラーで DefaultAccount を作成する方法
ドメインがWindows Server 2016実行されているドメイン コントローラーで作成された場合、DefaultAccount はドメイン内のすべてのドメイン コントローラーに存在します。 以前のバージョンの Windows Server を実行しているドメイン コントローラーでドメインが作成された場合、PDC エミュレーターロールがWindows Server 2016を実行するドメイン コントローラーに転送された後に DefaultAccount が作成されます。 DefaultAccount は、ドメイン内の他のすべてのドメイン コントローラーにレプリケートされます。
既定のアカウント (DSMA) を管理する際の推奨事項
Microsoft では、アカウントが無効化されている既定の構成を変更しないことをお勧めしています。 無効化状態のアカウントが、セキュリティ上のリスクになることはありません。 既定の構成を変更すると、このアカウントに依存する将来のシナリオを妨げる可能性があります。
既定のローカル システム アカウント
SYSTEM
SYSTEM アカウントは、オペレーティング システムと Windows で実行されているサービスによって使用されます。 Windows オペレーティング システムには、Windows のインストール時などに、内部的にサインイン機能が必要になるサービスやプロセスが多数あります。 SYSTEM アカウントはその目的のために設計されており、Windows は SYSTEM アカウントのユーザー権限を管理します。 この内部アカウントはユーザー マネージャーには表示されません。また、どのグループにも追加できません。
その一方で、SYSTEM アカウントは、ファイル マネージャーの NTFS ファイル システム ボリュームには表示されます ([セキュリティ] メニューの [アクセス許可] の部分)。 既定では、SYSTEM アカウントには、NTFS ボリュームのすべてのファイルに対するフル コントロールのアクセス許可が付与されています。 この SYSTEM アカウントには、Administrator アカウントと同じ機能性の権利とアクセス許可があります。
備考
アカウントに Administrators グループ ファイルのアクセス許可を付与しても、SYSTEM アカウントに暗黙的にアクセス許可を付与することにはなりません。 SYSTEM アカウントのアクセス許可はファイルから削除できますが、そのアクセス許可の削除はお勧めしません。
NETWORK SERVICE
NETWORK SERVICE アカウントは、サービス コントロール マネージャー (SCM) によって使用される定義済みのローカル アカウントです。 NETWORK SERVICE アカウントのコンテキストで実行されるサービスは、コンピューターの資格情報をリモート サーバーに提示します。 詳細については、「NetworkService アカウント」を参照してください。
LOCAL SERVICE
LOCAL SERVICE アカウントは、サービス コントロール マネージャーによって使用される定義済みのローカル アカウントです。 ローカル コンピューターに対する最小限の権限が付与されていて、ネットワークに匿名の資格情報を提示します。 詳細については、「LocalService アカウント」を参照してください。
ローカル ユーザー アカウントの管理方法
既定のローカル ユーザー アカウントと、ユーザーが作成したローカル ユーザー アカウントは、[ユーザー] フォルダーにあります。 [ユーザー] フォルダーは、[ローカル ユーザーとグループ] フォルダー内にあります。 ローカル ユーザーアカウントの作成および管理の詳細については、「ローカル ユーザーの管理」を参照してください。
"ローカル ユーザーとグループ" は、ローカル サーバーに対する権利とアクセス許可を割り当てて、ローカル ユーザーとグループが特定のアクションを実行する機能を制限するために使用できます。 ユーザーがサーバーで特定の操作 (ファイルとフォルダーのバックアップやサーバーのシャットダウンなど) を実行することは、権利によって許可されます。 アクセス許可とは、オブジェクト (通常はファイル、フォルダ、プリンター) に関連付けられたルールです。 これにより、サーバー上のオブジェクトにアクセスできるユーザーと、アクセスする方法を制御します。
ドメイン コントローラーでは、"ローカル ユーザーとグループ" は使用できません。 ただし、ネットワーク上のドメイン コントローラーではないリモート コンピューターを対象とするドメイン コントローラーでは、"ローカル ユーザーとグループ" を使用できます。
備考
Active Directory ユーザーとコンピューターは、Active Directory のユーザーとグループを管理するために使用します。
また、ローカル ユーザーの管理には NET.EXE USER を使用し、ローカル グループの管理には NET.EXE LOCALGROUP を使用します。それ以外の場合は、各種の PowerShell コマンドレットなどのスクリプト テクノロジを使用します。
管理特権があるローカル アカウントを制限および保護する
悪意のあるユーザーは、あるコンピューターのローカル アカウント用の資格情報 (パスワードやパスワード ハッシュなど) を不正に入手して、管理特権のある別のコンピューターの認証に使用しようとします。管理者は、この行為を防止するために複数の手法を使用できます。 これは 横移動とも呼ばれます。
最も簡単な手法は、Administrator アカウントを使用するのではなく、標準ユーザー アカウントで自分のコンピューターにサインインすることです。 たとえば、標準アカウントを使用してインターネットを参照したり、電子メールを送信したり、ワード プロセッサを使用したりします。 管理タスク (新しいプログラムのインストールや別のユーザーに影響する設定の変更など) の実行が必要なときに、Administrator アカウントに切り替える必要はありません。 ユーザー アカウント制御 (UAC) を使用すると、該当するタスクの実行前にアクセス許可または管理者パスワードの入力を求めるプロンプトを表示できます。これについては、次のセクションで説明します。
管理特権のあるユーザー アカウントの制限および保護には、次の手法も使用できます。
- ローカル アカウントの制限をリモート アクセスに適用する
- すべてのローカル Administrator アカウントに対するネットワーク ログオンを拒否する
- 管理特権があるローカル アカウントに一意のパスワードを作成する
こうした手法のそれぞれについては、次からの各セクションで説明します。
備考
こうした手法は、すべての管理用ローカル アカウントが無効になっている場合には当てはまりません。
ローカル アカウントの制限をリモート アクセスに適用する
ユーザー アカウント制御 (UAC) は、プログラムが管理アクセス許可を必要とする変更を行ったときに通知するセキュリティ機能です。 UAC は、自分のユーザー アカウントのアクセス許可レベルを調整することで機能します。 既定では、UAC は、アプリケーションがコンピューターに変更を加えようとしたときに通知するように設定されていますが、UAC から通知を受け取ったときに変更できます。
UAC を使用すると、管理者権限を持つアカウントは、昇格とも呼ばれる完全な権限が要求され、承認されるまで、標準ユーザーの非管理者アカウントとして扱うことができます。 たとえば、UAC を使用すると、管理者以外のユーザー セッション中に管理者が資格情報を入力して、ユーザーの切り替え、サインアウト、または 実行 コマンドを使用することなく、時折の管理タスクを実行できます。
また、UAC では、システム規模の変更を加えるアプリケーションに実行の権限を付与する前に、管理者のユーザー セッションであったとしても、管理者に対して明確な承認を要求することができます。
たとえば、UAC の既定の機能は、ネットワーク ログオンを使用したリモート コンピューターからのローカル アカウント サインイン (NET.EXE USE などを使用) するときに示されます。 この場合は、管理特権がなく、昇格の要求または受信もできない標準ユーザー トークンが発行されます。 そのため、ネットワーク ログオンを使用してサインインしたローカル アカウントは、管理用の共有 (C$ や ADMIN$ など) にアクセスすることも、リモート管理を実行することもできません。
UAC の詳細については、「ユーザー アカウント制御」を参照してください。
次の表に、ローカル アカウントの制限をリモート アクセスに適用するために使用されるグループ ポリシーとレジストリ設定を示します。
| いいえ、そうではありません。 | 設定 | 詳細説明 |
|---|---|---|
| ポリシーの場所 | コンピューターの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション | |
| 1 | ポリシー名 | ユーザー アカウント制御: ビルトイン Administrator アカウントのための管理者承認モード |
| ポリシー設定 | 有効 | |
| 2 | ポリシーの場所 | コンピューターの構成\Windows の設定\セキュリティの設定\ローカル ポリシー\セキュリティ オプション |
| ポリシー名 | ユーザー アカウント制御: 管理者承認モードですべての管理者を実行する | |
| ポリシー設定 | 有効 | |
| 3 | レジストリ キー | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System |
| レジストリ値の名前 | LocalAccountTokenFilterPolicy | |
| レジストリ値の種類 | DWORD | |
| レジストリ値のデータ | 0 |
注
セキュリティ テンプレートでカスタム ADMX を使用して、LocalAccountTokenFilterPolicy に既定の設定を適用することもできます。
ローカル アカウントの制限をリモート アクセスに適用するには
グループ ポリシー管理コンソール (GPMC) を起動する
コンソール ツリーで [Forest>\Domains\<Domain>] を展開<し、[オブジェクト] をグループ ポリシーします。フォレストはフォレストの名前で、ドメインは グループ ポリシー オブジェクト (GPO) を設定するドメインの名前です。
コンソール ツリーで、[オブジェクト>の新規作成] を右クリックグループ ポリシー
[新しい GPO] ダイアログ ボックスに「gpo_name>」と入力し>、gpo_nameが新しい GPO の名前である場合は [OK] と入力<します。 GPO 名は、GPO が別のコンピューターに引き継がれているローカル管理者権限を制限するために使用されることを示します
詳細ウィンドウで、[gpo_name>] を右クリックし>、[編集] をクリックします<。
次の手順を実行して、UAC が有効になっていることと、UAC の制限が既定の Administrator アカウントに適用されることを確認します。
- [コンピューターの構成]\[Windows 設定]\[セキュリティ設定]\[ローカル ポリシー]\、[セキュリティ オプション] の順>に移動します。
- [ユーザー アカウント制御] をダブルクリックします。すべての管理者を管理承認モード>で実行する[有効] [OK]>
- [ユーザー アカウント制御: 管理承認モード] をダブルクリックして、組み込みの管理者アカウント>の[有効][OK] を選択>します。
次の手順を実行して、ローカル アカウントの制限がネットワーク インターフェイスに適用されていることを確認します。
- [コンピューターの構成]\[基本設定] と [Windows の設定]、[レジストリ] の順>に移動します
- [レジストリ] と [新しい>レジストリ>項目] を右クリックします
- [新しいレジストリのプロパティ] ダイアログ ボックスの [全般] タブで、[アクション] ボックスの設定を [置換] に変更します。
- [Hive] ボックスが [HKEY_LOCAL_MACHINE] に設定されていることを確認します
- (...) を選択し、[キー パス>の選択] で次の場所を参照します。
SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System - [ 値名 ] 領域に「」と入力します。
LocalAccountTokenFilterPolicy - [ 値の種類 ] ボックスのドロップダウン リストから [ REG_DWORD ] を選択して値を変更します
- [値データ] ボックスで、値が 0 に設定されていることを確認します
- この構成を確認し>、[OK]
次の操作を実行して、GPO を最初のワークステーションの組織単位 (OU) にリンクします。
- パスに移動する
*Forest*\<Domains>\*Domain*\*OU* - [ワークステーション] [既存の GPO を>リンクする] を右クリックします
- 作成した GPO を選択し>、[OK] を選択します
- パスに移動する
その最初の OU 内のワークステーションでエンタープライズ アプリケーションの機能をテストし、新しいポリシーによって発生する問題を解決する
ワークステーションを含む他のすべての OU へのリンクを作成する
サーバーを含む他のすべての OU へのリンクを作成する
すべてのローカル Administrator アカウントに対するネットワーク ログオンを拒否する
ローカル アカウントのネットワーク ログオンを実行できないようにすると、悪意のある攻撃でローカル アカウントのパスワード ハッシュが再利用されるのを防ぐことができます。 この手順では、侵害されたオペレーティング システムから盗まれたローカル アカウントの資格情報を使用して、同じ資格情報を使用する別のコンピューターを侵害できないようにすることで、横方向の移動を防ぐことができます。
注
この手順を実行するには、まず、ローカルの既定の Administrator アカウントの名前 (既定のユーザー名 "Administrator" ではない可能性があります)と、ローカルの Administrators グループのメンバーである他のアカウントを識別する必要があります。
次の表に、すべてのローカル Administrator アカウントに対してネットワーク ログオンを拒否するために使用されるグループ ポリシーの設定を示します。
| いいえ、そうではありません。 | 設定 | 詳細説明 |
|---|---|---|
| ポリシーの場所 | [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [ユーザー権利の割り当て] | |
| 1 | ポリシー名 | ネットワークからのこのコンピューターへのアクセスを拒否する |
| ポリシー設定 | ローカル アカウントと Administrators グループのメンバー | |
| 2 | ポリシーの場所 | [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [ユーザー権利の割り当て] |
| ポリシー名 | リモート デスクトップ サービスを使ったログオンを拒否 | |
| ポリシー設定 | ローカル アカウントと Administrators グループのメンバー |
すべてのローカル管理者アカウントに対してネットワーク ログオンを拒否するには
グループ ポリシー管理コンソール (GPMC) を起動する
コンソール ツリーで [Forest>\Domains\<Domain>] を展開<し、[オブジェクト] をグループ ポリシーします。フォレストはフォレストの名前で、ドメインは グループ ポリシー オブジェクト (GPO) を設定するドメインの名前です。
コンソール ツリーで、[オブジェクトのグループ ポリシー] を右クリックし>、[新規] をクリックします。
[新しい GPO] ダイアログ ボックスに「gpo_name>」と入力<し、[OK] を入力します>。ここで、gpo_nameは新しい GPO の名前であり、ローカル管理アカウントがコンピューターに対話形式でサインインするのを制限するために使用されていることを示します
詳細ウィンドウで、[gpo_name>] を右クリックし>、[編集] をクリックします<。
次のように、管理ローカル アカウントのネットワーク ログオンを拒否するように、ユーザー権利を構成します。
[コンピューターの構成]\[Windows 設定]\[セキュリティ設定]\、[ユーザー権利の割り当て] の順>に移動します
[ネットワークからこのコンピューターへのアクセスを拒否する] をダブルクリックします
[ユーザーまたはグループの追加] を選択し、「ローカル アカウントと Administrators グループのメンバー」と入力し>、[OK] を選択します。
次のように、管理ローカル アカウントのリモート デスクトップ (リモート対話) のログオンを拒否するように、ユーザー権利を構成します。
[コンピューターの構成]\[ポリシー]\[Windows の設定とローカル ポリシー] に移動し、[ユーザー権利の割り当て] を選択します。
[リモート デスクトップ サービスを使用してログオンを拒否する] をダブルクリックします
[ユーザーまたはグループの追加] を選択し、「ローカル アカウントと Administrators グループのメンバー」と入力し>、[OK] を選択します。
次に示すように、GPO を最初のワークステーションの OU にリンクします。
- フォレスト>\Domains\Domain>\<OU パスに<移動します
- ワークステーション OU を右クリックし>、既存の GPO をリンクする
- 作成した GPO を選択し>、[OK] を選択します
その最初の OU 内のワークステーションでエンタープライズ アプリケーションの機能をテストし、新しいポリシーによって発生する問題を解決する
ワークステーションを含む他のすべての OU へのリンクを作成する
サーバーを含む他のすべての OU へのリンクを作成する
備考
既定の Administrator アカウントのユーザー名がワークステーションとサーバーで違っていると、別の GPO の作成が必要になる場合があります。
管理特権があるローカル アカウントに一意のパスワードを作成する
パスワードは、それぞれのアカウントごとに一意にする必要があります。 これは、個人のユーザー アカウントには当てはまりますが、多くの企業が共通のローカル アカウント (既定の Administrator アカウントなど) に同一のパスワードを設定しています。 これは、オペレーティング システムの展開時に、ローカル アカウントに同じパスワードが使用されるときにも発生します。
未変更のままにしてあるパスワードや、パスワードが同じになるように同期的に変更すると、組織にとって重大なリスクが増加します。 パスワードをランダム化してローカル アカウントごとに異なるパスワードを使用することで、"pass-the-hash" 攻撃を軽減できます。これにより、悪意のあるユーザーが該当するアカウントのパスワード ハッシュを使用して別のコンピューターを侵害することを困難にします。
パスワードは、次のようにしてランダム化できます。
- このタスクを実現するためのエンタープライズ ツールを購入して実装する。 これらのツールは、一般に"特権パスワード管理" ツールと呼ばれます
- このタスクを実行するための ローカル管理者パスワード ソリューション (LAPS) の構成
- ローカル アカウント パスワードをランダム化するためのカスタム スクリプトまたはソリューションの作成と実装