Active Directory アカウント
Windows Server オペレーティング システムは、既定のローカル アカウントでインストールされます。 さらに、組織の要件を満たすユーザー アカウントを作成できます。
このリファレンス記事では、ドメイン コントローラーにローカルに格納され、Active Directory で使用される Windows Server の既定のローカル アカウントについて説明します。 メンバー、スタンドアロン サーバー、または Windows クライアントの既定のローカル ユーザー アカウントについては説明しません。 詳細については、「ローカル アカウント」を参照してください。
Active Directory の既定のローカル アカウント
既定のローカル アカウントは、Windows Server ドメイン コントローラーがインストールされ、ドメインが作成されるときに自動的に作成される組み込みアカウントです。 これらの既定のローカル アカウントには、Active Directory に対応するアカウントがあります。 ドメイン全体に対するアクセス権もあり、メンバーまたはスタンドアロン サーバーの既定のローカル ユーザー アカウントとは完全に分離されています。
権限とアクセス許可を、特定のドメイン コントローラーの既定のローカル アカウントに、そのドメイン コントローラー専用で割り当てることができます。 これらのアカウントは、ドメインに対してローカルです。 既定のローカル アカウントがインストールされると、Active Directory ユーザーとコンピューターの Users コンテナーに格納されます。 既定のローカル アカウントを Users コンテナーに維持し、これらのアカウントを別の組織単位 (OU) などに移動しないようにすることをお勧めします。
Users コンテナーの既定のローカル アカウントには、Administrator、Guest、KRBTGT が含まれます。 リモート アシスタンス セッションが確立されると、HelpAssistant アカウントがインストールされます。 以降のセクションでは、Active Directory の既定のローカル アカウントとその用途について説明します。
既定のローカル アカウントは、次のアクションを実行します。
ドメインが、一意の資格情報 (ユーザー名とパスワード) を使用して、アカウントに割り当てられているユーザーの ID を表し、識別し、認証できるようにします。 セキュリティを最大限に高めるために、各ユーザーを 1 つのアカウントに割り当てることをお勧めします。 複数のユーザーが 1 つのアカウントを共有することはできません。 ユーザー アカウントにより、ユーザーはコンピューター、ネットワーク、またはドメインで認証できる一意の ID を使用してコンピューター、ネットワーク、ドメインにサインインできます。
リソースへのアクセスを承認 (許可または拒否) します。 ユーザーの資格情報が認証されると、リソースに対してユーザーに明示的に割り当てられた権限に基づいて、ネットワークとドメイン リソースへのアクセスがユーザーに許可されます。
ユーザー アカウントで実行されるアクションを監査します。
Active Directory で、管理者は既定のローカル アカウントを使用して、ドメインとメンバー サーバーを直接、専用の管理ワークステーションから管理します。 Active Directory アカウントは、ネットワーク リソースへのアクセスを提供します。 Active Directory ユーザー アカウントとコンピューター アカウントは、コンピューターや個人などの物理エンティティを表したり、一部のアプリケーションの専用サービス アカウントとして機能したりできます。
既定の各ローカル アカウントは、特定のタスクを実行するための適切な権限とアクセス許可で事前構成されているセキュリティ グループに自動的に割り当てられます。 Active Directory セキュリティ グループは、ユーザー アカウント、コンピューター アカウント、およびその他のグループを管理可能な単位に収集します。 詳細については、「Active Directory セキュリティ グループ」を参照してください。
Active Directory ドメイン コントローラーでは、既定の各ローカル アカウントはセキュリティ プリンシパルと呼ばれます。 セキュリティ プリンシパルは、ドメイン コントローラー リソースへのアクセスを提供する Active Directory サービスをセキュリティで保護および管理するために使用されるディレクトリ オブジェクトです。 セキュリティ プリンシパルには、ユーザー アカウント、コンピューター アカウント、セキュリティ グループ、またはユーザーやコンピューター アカウントのセキュリティ コンテキストで実行されるスレッドあるいはプロセスなどのオブジェクトが含まれます。 詳細については、「セキュリティ プリンシパル」を参照してください。
セキュリティ プリンシパルは、一意のセキュリティ ID (SID) で表されます。 Active Directory の既定のローカル アカウントそれぞれに関連する SID については、次のセクションで説明します。
既定のローカル アカウントの一部は、特定のセキュリティ記述子を定期的にチェックして適用するバックグラウンド プロセスによって保護されています。 セキュリティ記述子は、保護されたオブジェクトに関連付けられているセキュリティ情報を含むデータ構造です。 このプロセスにより、既定のローカル アカウントまたはグループのいずれかのセキュリティ記述子を変更しようとする未承認の試行が成功した場合、保護された設定で上書きされます。
このセキュリティ記述子は AdminSDHolder オブジェクトに存在します。 いずれかのサービス管理者グループまたはそのメンバー アカウントのアクセス許可を変更する場合は、AdminSDHolder オブジェクトのセキュリティ記述子を変更して、一貫して適用されるようにする必要があります。 これらの変更は、保護されているすべてのアカウントに適用される既定の設定も変更するため、注意深く行ってください。
[Administrator account] (管理者アカウント)
Administrator アカウントは、すべてのコンピューターとデバイス上のすべてのバージョンの Windows オペレーティング システムで使用される既定のアカウントです。 Administrator アカウントは、システム管理者によって管理者資格情報を必要とするタスクに使用されます。 このアカウントは削除またはロックアウトできませんが、アカウントの名前を変更したり無効にしたりすることはできます。
Administrator アカウントは、ユーザーに、そのローカル サーバー上にあるファイル、ディレクトリ、サービス、およびその他のリソースの完全なアクセス権 (フル コントロール アクセス許可) を付与します。 Administrator アカウントを使用して、ローカル ユーザーを作成し、ユーザー権限とアクセス制御のアクセス許可を割り当てることができます。 このアカウントを使用して、任意の時点でローカル リソースを制御することもできます。それを行うにはユーザーの権限とアクセス許可を変更するのみです。 ファイルとディレクトリは Administrator アカウントから一時的に保護できますが、このアカウントはアクセス許可を変更することで任意の時点でこれらのリソースを制御できます。
アカウント グループのメンバーシップ
Administrator アカウントは、この記事の Administrator アカウント属性の表で後述するように、既定のセキュリティ グループのメンバーです。
セキュリティ グループを使用すると、各 Administrator アカウントを変更しなくても管理者権限を制御できます。 ほとんどの場合、このアカウントの基本設定を変更する必要はありません。 ただし、特定のグループのメンバーシップなどの詳細設定を変更することが必要な場合があります。
セキュリティに関する考慮事項
サーバー オペレーティング システムをインストールした後、最初のタスクは Administrator アカウントのプロパティを安全に設定することです。 これには、特に長くて強力なパスワードの設定と、リモート コントロールとリモート デスクトップ サービスのプロファイル設定のセキュリティ保護が含まれます。
Administrator アカウントは、不要なときには無効にすることもできます。 Administrator アカウントの名前を変更するか、無効にすると、悪意のあるユーザーがアカウントへのアクセスを試みることがより困難になります。 ただし、Administrator アカウントは、無効になっているときでも、セーフ モードを使用することでドメイン コントローラーへのアクセスに使用できます。
ドメイン コントローラーでは、Administrator アカウントがドメイン管理者アカウントになります。 ドメイン管理者アカウントは、ドメイン コントローラーへのサインインに使用されます。このアカウントには強力なパスワードが必要です。 ドメイン管理者アカウントは、ドメイン リソースへのアクセス権をユーザーに付与します。
注意
ドメイン コントローラーが最初にインストールされたら、サインインし、サーバー マネージャーを使用して、割り当てる権限とアクセス許可を持つローカルの Administrator アカウントを設定できます。 たとえば、オペレーティング システムを最初にインストールするときに、ローカルの Administrator アカウントを使用して管理できます。 この方法を使用すると、ロックアウトされることなくオペレーティング システムを設定できます。一般に、インストール後にこのアカウントを使用する必要はありません。 ドメイン コントローラーでローカル ユーザー アカウントを作成できるのは、Active Directory Domain Services がインストールされる前のみで、その後はできません。
Active Directory がドメインの最初のドメイン コントローラーにインストールされると、Active Directory の Administrator アカウントが作成されます。 Administrator アカウントは、ドメイン内で最も強力なアカウントです。 コンピューターとドメインを管理するためのドメイン全体のアクセス権と管理者権限が付与され、ドメインに対する最も広範な権限とアクセス許可を持ちます。 コンピューターに Active Directory Domain Services をインストールするユーザーは、インストール中にこのアカウントのパスワードを作成します。
Administrator アカウント属性
| 属性 | 値 |
|---|---|
| 既知の SID/RID | S-1-5-<domain>-500 |
| 型 | User |
| 既定のコンテナー | CN=Users、DC=<domain>、DC= |
| 既定メンバー | 該当なし |
| ～の既定のメンバー | Administrators、Domain Admins、Enterprise Administrators、Domain Users (すべてのユーザー アカウントのプライマリ グループ ID は Domain Users) Active Directory ドメインの Users グループの Group Policy Creator Owners、および Schema Admins |
| ADMINSDHOLDER で保護されているか | はい |
| 既定のコンテナーから移動することができるか | はい |
| このグループの管理をサービス管理者以外に委任することができるか | いいえ |
Guest アカウント
Guest アカウントは、コンピューターへのアクセスが制限付きで、既定では無効になっている既定のローカル アカウントです。 既定では、Guest アカウントのパスワードは空白のままです。 空白のパスワードを使用すると、ユーザーがパスワードを入力しなくても Guest アカウントにアクセスできます。
Guest アカウントを使用すると、コンピューター上に個人のアカウントを持たない不定期や 1 回限りのユーザーが、制限付きの権限とアクセス許可でローカル サーバーまたはドメインにサインインできます。 Guest アカウントは有効にでき、必要に応じてパスワードを設定できますが、実行者はドメインの Administrator グループのメンバーのみです。
Guest アカウント グループのメンバーシップ
Guest アカウントは、次の Guest アカウント属性の表で説明されている既定のセキュリティ グループのメンバーです。 既定では Guest アカウントは、ユーザーがサーバーにサインインできるようにする既定の Guests グループと、ユーザーがドメインにサインインできるようにする Domain Guests グローバル グループの唯一のメンバーです。
Administrators グループまたは Domain Admins グループのメンバーは、1 台以上のコンピューターに Guest アカウントを持つユーザーを設定できます。
Guest アカウントのセキュリティに関する考慮事項
Guest アカウントは匿名アクセスを提供できるため、セキュリティ リスクがあります。 SID がよく知られてもいます。 このため、Guest アカウントは、使用が必要な場合を除き、無効なままにしておき、必要な場合は期間を非常に限定して、制限付きの権限とアクセス許可のみにすることをお勧めします。
Guest アカウントが必要なときは、ドメイン コントローラーの Administrator が Guest アカウントを有効にする必要があります。 Guest アカウントは、パスワードを必要とせずに有効にすることも、強力なパスワードで有効にすることもできます。 Guest アカウントへの制限付きの権限とアクセス許可の付与も Administrator が行います。 不正アクセスを防止するには:
ゲスト アカウントにシステムのシャットダウンユーザー権限を付与 "しないで" ください。 コンピューターがシャットダウンまたは起動すると、Guest ユーザーまたは悪意のあるユーザーなどのローカル アクセス権を持つすべてのユーザーが、コンピューターに不正にアクセスする可能性があります。
イベント ログを表示する機能を Guest アカウントに提供 "しないで" ください。 Guest アカウントが有効になった後は、このアカウントを頻繁に監視して、他のユーザーがサービスやその他のリソース (前のユーザーが意図せずに使用できるままにしたリソースなど) を使用できないようにすることをお勧めします。
サーバーに外部ネットワークへのアクセス権または他のコンピューターへのアクセス権があるときは、Guest アカウントを使用 "しないで" ください。
Guest アカウントを有効にすると決定した場合は、使用を制限し、パスワードを定期的に変更するようにしてください。 Administrator アカウントと同様に、追加のセキュリティ上の予防措置としてアカウントの名前を変更することも考えられます。
さらに、管理者が Guest アカウントの管理を担当します。 管理者は Guest アカウントを監視し、Guest アカウントが使用されなくなったときに無効にし、必要に応じてパスワードを変更または削除します。
Guest アカウント属性の詳細については、次の表を参照してください。
Guest アカウント属性
| 属性 | 値 |
|---|---|
| 既知の SID/RID | S-1-5-<domain>-501 |
| 型 | User |
| 既定のコンテナー | CN=Users、DC=<domain>、DC= |
| 既定メンバー | なし |
| ～の既定のメンバー | Guests、Domain Guests |
| ADMINSDHOLDER で保護されているか | No |
| 既定のコンテナーから移動することができるか | 外に移動できますが、お勧めしません。 |
| このグループの管理をサービス管理者以外に委任することができるか | いいえ |
HelpAssistant アカウント (リモート アシスタンス セッションでインストール)
HelpAssistant アカウントは、リモート アシスタンス セッションの実行時に有効になる既定のローカル アカウントです。 保留になっているリモート アシスタンス要求がないとき、このアカウントは自動的に無効になります。
HelpAssistant は、リモート アシスタンス セッションを確立するために使用されるプライマリ アカウントです。 リモート アシスタンス セッションは、Windows オペレーティング システムを実行している別のコンピューターに接続するために使用され、招待によって開始されます。 リモート アシスタンスを要請するために、ユーザーはコンピューターから、メールを経由するかファイルとして、サポートを提供できるユーザーに招待状を送信します。 リモート アシスタンス セッションへのユーザーの招待が受け入れられると、既定の HelpAssistant アカウントが自動的に作成され、サポートを提供するユーザーにコンピューターへの制限付きのアクセス権が付与されます。 HelpAssistant アカウントは、Remote Desktop Help Session Manager サービスが管理します。
HelpAssistant のセキュリティに関する考慮事項
既定の HelpAssistant アカウントに関連する SID は次のとおりです。
SID: S-1-5--
<domain>13、表示名は Terminal Server User。 このグループには、リモート デスクトップ サービスが有効になっているサーバーにサインインするすべてのユーザーが含まれます。 Windows Server 2008 では、リモート デスクトップ サービスはターミナル サービスと呼ばれています。SID: S-1-5--
<domain>14、表示名は Remote Interactive Logon。 このグループには、リモート デスクトップ接続を使用してコンピューターに接続するすべてのユーザーが含まれます。 このグループは、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) |
| 型 | User |
| 既定のコンテナー | CN=Users、DC=<domain>、DC= |
| 既定メンバー | なし |
| ～の既定のメンバー | Domain Guests ゲスト |
| ADMINSDHOLDER で保護されているか | No |
| 既定のコンテナーから移動することができるか | 外に移動できますが、お勧めしません。 |
| このグループの管理をサービス管理者以外に委任することができるか | いいえ |
KRBTGT アカウント
KRBTGT アカウントは、キー配布センター (KDC) サービスのサービス アカウントとして機能するローカルの既定のアカウントです。 このアカウントは削除できず、アカウント名を変更できません。 Active Directory で KRBTGT アカウントを有効にすることはできません。
KRBTGT は、RFC 4120 で指定されている Windows Server ドメインの KDC によって使用されるセキュリティ プリンシパル名でもあります。 KRBTGT アカウントは KRBTGT セキュリティ プリンシパルのエンティティであり、新しいドメインが作成されると自動的に作成されます。
Windows Server Kerberos 認証は、対称キーで暗号化された特別な Kerberos チケット保証チケット (TGT) を使用することによって実現されます。 このキーは、アクセスの要求先のサーバーまたはサービスのパスワードから派生します。 KRBTGT アカウントの TGT パスワードがわかるのは、Kerberos サービスのみです。 セッション チケットを要求するには、TGT を KDC に提示する必要があります。 TGT は KDC から Kerberos クライアントに発行されます。
KRBTGT アカウントのメンテナンスに関する考慮事項
KRBTGT と信頼アカウントには強力なパスワードが自動的に割り当てられます。 特権サービス アカウントと同様、組織はこれらのパスワードを定期的に変更する必要があります。 KDC アカウントのパスワードは、発行される TGT 要求を暗号化および復号化するための秘密鍵を派生させるために使用されます。 ドメイン信頼アカウントのパスワードは、紹介チケットを暗号化するための領域間キーを派生させるために使用されます。
パスワードをリセットするには、Domain Admins グループのメンバーであるか、適切な権限を委任されている必要があります。 また、ローカルの Administrators グループのメンバーであるか、適切な権限が委任されている必要があります。
KRBTGT パスワードをリセットしたら、(Kerberos) キー配布センター イベント ソースのイベント ID 9 がシステム イベント ログに書き込まれていることを確認します。
KRBTGT アカウントのセキュリティに関する考慮事項
新しく復元されるドメイン コントローラーが侵害されたドメイン コントローラーをレプリケートしないように、KRBTGT アカウントのパスワードをリセットすることもお勧めします。 複数の場所に分散する大規模なフォレストの回復の場合、すべてのドメイン コントローラーがシャットダウンされていることと、シャットダウンされている場合に、すべての適切な回復手順が実行される前に再度再起動できないことを保証できません。 KRBTGT アカウントをリセットした後に、別のドメイン コントローラーが古いパスワードを使用してこのアカウント のパスワードをレプリケートすることはできません。
KRBTGT アカウントのドメイン侵害が疑われる組織では、専門的なインシデント レスポンス サービスの使用を検討する必要があります。 アカウントの所有権を復元する影響は、ドメイン全体にわたり、作業負荷が高いため、より大規模な回復作業の一環として実行する必要があります。
KRBTGT パスワードは、Kerberos のすべての信頼のチェーン元のキーです。 KRBTGT パスワードのリセットは、ルート CA 証明書を新しいキーで更新し、すぐに古いキーを信頼しないことに似ています。その結果、その後の Kerberos 操作のほとんどすべてが影響を受けます。
すべてのアカウントの種類 (ユーザー、コンピューター、サービス) について、次のようになります。
既に発行および配布されているすべての TGT は、DC によって拒否されるため無効になります。 これらのチケットは KRBTGT で暗号化されるため、どの DC でも検証できます。 パスワードが変更されると、チケットは無効になります。
サインインしているユーザーがリソース (ファイル共有、SharePoint サイト、Exchange サーバーなど) に対して (サービス チケットに基づいて) 確立した現在認証済みのすべてのセッションは、サービス チケットの再認証が必要になるまで有効です。
NTLM で認証された接続は影響を受けません。
運用稼働環境のいずれのユーザーについても発生する特定のエラーを予測することは不可能であるため、すべてのコンピューターとユーザーが影響を受けるものと想定する必要があります。
重要
コンピューターを再起動は、機能を回復する唯一の信頼性の高い方法です。それにより、コンピューター アカウントとユーザー アカウントの両方が再度サインインするためです。 再度サインインすると、新しい KRBTGT で有効な新しい TGT が要求されます。これにより、そのコンピューターの KRBTGT 関連の運用上の問題が修正されます。
読み取り専用ドメイン コントローラーと KRBTGT アカウント
Windows Server 2008 では、読み取り専用ドメイン コントローラー (RODC) が導入されました。 RODC は、ブランチ オフィスに対するキー配布センター (KDC) としてアドバタイズされます。 RODC は、チケット保証チケット (TGT) 要求に対して署名または暗号化を行うときに、書き込み可能なドメイン コントローラー上の KDC とは異なる KRBTGT アカウントおよびパスワードを使用します。 アカウントが正常に認証されると、RODC は、パスワード レプリケーション ポリシーを使用して、ユーザーの資格情報またはコンピューターの資格情報を書き込み可能なドメイン コントローラーから RODC にレプリケートできるかどうかを判断します。
資格情報が RODC にキャッシュされると、RODC は資格情報が変更されるまで、そのユーザーのサインイン要求を受け付けることができるようになります。 TGT が RODC の KRBTGT アカウントで署名されると、RODC はそれに資格情報のキャッシュされたコピーがあることを認識します。 別のドメイン コントローラーが TGT に署名すると、RODC は書き込み可能なドメイン コントローラーに要求を転送します。
KRBTGT アカウント属性
KRBTGT アカウント属性の詳細については、次の表を参照してください。
| 属性 | 値 |
|---|---|
| 既知の SID/RID | S-1-5-<domain>-502 |
| 型 | User |
| 既定のコンテナー | CN=Users、DC=<domain>、DC= |
| 既定メンバー | なし |
| ～の既定のメンバー | Domain Users グループ (すべてのユーザー アカウントのプライマリ グループ ID は Domain Users) |
| ADMINSDHOLDER で保護されているか | はい |
| 既定のコンテナーから移動することができるか | 外に移動できますが、お勧めしません。 |
| このグループの管理をサービス管理者以外に委任することができるか | いいえ |
Active Directory の既定のローカル アカウントの設定
Active Directory の既定の各ローカル アカウントには、次の表に示すように、パスワード設定とセキュリティ固有の情報を構成するために使用できるいくつかのアカウント設定があります。
| アカウント設定 | 説明 |
|---|---|
| ユーザーは次回ログオン時にパスワード変更が必要 | ユーザーが次回ネットワークにサインインするときに、パスワードの変更を強制します。 そのユーザーのみがパスワードを知るようにするには、このオプションを使用します。 |
| ユーザーがパスワードを変更できない | ユーザーがパスワードを変更できないようにします。 Guest や一時的なアカウントなどのユーザー アカウントに対する制御を維持するには、このオプションを使用します。 |
| パスワードを無期限にする | ユーザー パスワードの有効期限が切れないようにします。 サービス アカウントに対してこのオプションを有効にし、強力なパスワードを使用することをお勧めします。 |
| 暗号化を元に戻せる状態でパスワードを保存する | 認証目的でユーザーのパスワードのプレーンテキスト形式での認識を必要とするプロトコルを使用するアプリケーションへのサポートを提供します。 このオプションは、インターネット認証サービス (IAS) でチャレンジ ハンドシェイク認証プロトコル (CHAP) を使用しているとき、およびインターネット インフォメーション サービス (IIS) でダイジェスト認証を使用しているときに必要です。 |
| アカウントを無効にする | 選択したアカウントでユーザーがサインインできないようにします。 管理者は、無効化したアカウントを一般的なユーザー アカウントのテンプレートとして使用できます。 |
| 対話型ログオンにはスマート カードが必要 | ユーザーがネットワークに対話的にサインオンするには、スマート カードの所有を必要とするようにします。 ユーザーは、コンピューターにスマート カード リーダーを取り付け、そのスマート カード用の有効な暗証番号 (PIN) を入力する必要もあります。 この属性をアカウントに適用すると、次のような影響があります。 |
| アカウントは委任に対して信頼されている | このアカウントで実行されているサービスがネットワーク上の他のユーザー アカウントに代わって操作を実行できるようにします。 委任に対して信頼され、ユーザー アカウント (サービス アカウントとも呼ばれます) で実行されているサービスは、クライアントを借用して、サービスが実行されているコンピューターや、他のコンピューター上のリソースにアクセスできます。 たとえば、Windows Server 2003 の機能レベルに設定されているフォレストでは、この設定は [委任] タブにあります。これは、Windows サポート ツールの setspn コマンドを使用して設定されたサービス プリンシパル名 (SPN) が割り当てられているアカウントでのみ使用できます。 この設定はセキュリティに影響するため、慎重に割り当てる必要があります。 |
| アカウントは重要なので委任できない | Guest アカウントや一時的なアカウントなどのユーザー アカウントを制御できるようにします。 このオプションは、このアカウントを別のアカウントによる委任に割り当てることができない場合に使用できます。 |
| このアカウントに DES 暗号化を使う | データ暗号化標準 (DES) のサポートを提供します。 DES は、Microsoft Point-to-Point Encryption (MPPE) Standard (40 ビットおよび 56 ビット)、MPPE Standard (56 ビット)、MPPE Strong (128 ビット)、インターネット プロトコル セキュリティ (IPsec) DES (40 ビット)、IPsec 56 ビット DES、IPsec Triple DES (3DES) などの複数の暗号化レベルに対応しています。 |
| Kerberos 事前認証を必要としない | Kerberos プロトコルの代替実装に対するサポートを提供します。 事前認証によりセキュリティが強化されるため、このオプションを有効にするときは注意深く行ってください。 Windows 2000 または Windows Server 2003 を実行しているドメイン コントローラーでは、他のメカニズムを使用して時刻を同期できます。 |
注意
DES は、Windows Server オペレーティング システム (Windows Server 2008 R2 以降) や Windows クライアント オペレーティング システム (Windows 7 以降) では、既定で有効になっていません。 これらのオペレーティング システムでは、コンピューターは DES-CBC-MD5 または DES-CBC-CRC 暗号スイートを既定で使用しません。 環境で DES が必要な場合、この設定は環境内のクライアント コンピューターやサービスおよびアプリケーションとの互換性に影響を与える可能性があります。
詳細については、DES を見つけて Kerberos を安全にデプロイする方法に関する記事を参照してください。
Active Directory の既定のローカル アカウントを管理する
既定のローカル アカウントがインストールされると、これらのアカウントは Active Directory ユーザーとコンピューターの Users コンテナーに格納されます。 Active Directory ユーザーとコンピューターの Microsoft 管理コンソール (MMC) の使用と、コマンドライン ツールの使用によって、既定のローカル アカウントを作成、無効化、リセット、および削除できます。
Active Directory ユーザーとコンピューターを使用して、指定したローカル ドメイン コントローラーにのみ権限とアクセス許可を割り当てることで、ローカル ユーザーとグループが特定のアクションを実行する機能を制限できます。 ユーザーがコンピューターで特定の操作 (ファイルとフォルダーのバックアップやコンピューターのシャットダウンなど) を行うときは、権利によって承認されます。 一方、アクセス許可とは、オブジェクト (通常はファイル、フォルダー、またはプリンター) に関連付けられたルールであり、そのオブジェクトにアクセスできるユーザーとそのアクセス方法を制御します。
Active Directory でのローカル ユーザー アカウントの作成と管理の詳細については、「ローカル ユーザーを管理する」を参照してください。
ネットワーク上のドメイン コントローラーではないリモート コンピューターを対象に、ドメイン コントローラーで Active Directory ユーザーとコンピューターを使用することもできます。
Security Compliance Manager (SCM) ツールを使用して配布できるドメイン コントローラー構成に関する推奨事項を Microsoft から取得できます。 詳細については、「Microsoft Security Compliance Manager」を参照してください。
既定のローカル ユーザー アカウントの一部は、特定のセキュリティ記述子を定期的にチェックして適用するバックグラウンド プロセスによって保護されます。これは、保護されたオブジェクトに関連付けられているセキュリティ情報を含むデータ構造です。 このセキュリティ記述子は AdminSDHolder オブジェクトに存在します。
つまり、サービス管理者グループまたはそのメンバー アカウントに対するアクセス許可を変更するときは、AdminSDHolder オブジェクトのセキュリティ記述子も変更する必要があります。 この方法により、アクセス許可が一貫して適用されます。 これらの変更は注意深く行ってください。このアクションは、保護されているすべての管理アカウントに適用される既定の設定にも影響する可能性があるためです。
機密性の高いドメイン アカウントを制限および保護する
ドメイン環境でドメイン アカウントを制限および保護するには、次のベスト プラクティス アプローチを採用して実装する必要があります。
メンバーシップを、Administrators、Domain Admins、および Enterprise Admins グループに厳密に制限します。
ドメイン アカウントの使用場所と方法を厳重に制御します。
ドメインまたはフォレスト内の Administrators、Domain Admins、Enterprise Admins グループのメンバー アカウントは、悪意のあるユーザーにとって価値の高いターゲットです。 公開を制限するには、これらの管理者グループのメンバーシップを最小数のアカウントに厳密に制限することをお勧めします。 これらのグループのメンバーシップを制限すると、管理者が意図せずにこれらの資格情報を誤用して、悪意のあるユーザーが悪用できる脆弱性が生成される確率が低くなります。
さらに、機密性の高いドメイン アカウントを使用する場所と方法を厳重に制御することをお勧めします。 Domain Admins アカウントとその他の Administrator アカウントの使用を制限して、マネージド システムと同じレベルでセキュリティで保護されている管理システムやワークステーションへのサインインに使用されないようにします。 Administrator アカウントがこの方法で制限されていないと、ドメイン管理者がサインインする各ワークステーションは、悪意のあるユーザーが悪用できる場所がさらに 1 つ増えることになります。
これらのベスト プラクティスの実装は、次のタスクに分かれています。
- Administrator アカウントとユーザー アカウントを分離する
- 管理者のサインイン アクセスをサーバーとワークステーションに制限する
- 機密性の高い Administrator アカウントのアカウント委任権限を無効にする
ドメイン環境との統合が困難であると予想される例を示すために、各タスクは、最小、適度、理想の実装の要件に従って記述されています。 運用環境に対するすべての重要な変更と同様、これらの変更を実装してデプロイする前に、徹底的にテストしてください。 次に、技術的な問題が発生した場合に変更をロールバックできる方法でデプロイをステージングします。
Administrator アカウントとユーザー アカウントを分離する
Domain Admins アカウントとその他の機密性の高いアカウントを制限して、信頼の低いサーバーとワークステーションへのサインインに使用されないようにします。 Administrator アカウントを標準ユーザー アカウントから分離し、管理業務を他のタスクから分離し、これらのアカウントの使用を制限することで、Administrator アカウントを制限および保護します。 次のガイドラインに従って、特定の管理タスクを実行するために管理者の資格情報を必要とする管理者用に専用アカウントを作成し、他の標準ユーザー タスク用に別個のアカウントを作成します。
特権アカウント: Administrator アカウントを割り当てて、次の管理業務のみを実行します。
最小: ドメイン管理者とエンタープライズ管理者に別個のアカウントを、またはドメインまたはフォレスト内で適切な管理者権限を持つ同等のものを作成します。 機密性の高い管理者権限が付与されているアカウントは、ドメイン データとドメイン コントローラーの管理にのみ使用します。
適度: ワークステーション管理者のアカウントや、指定された Active Directory 組織単位 (OU) に対するユーザー権限を持つアカウントなどの、縮小した管理者権限を持つ管理者用に別個のアカウントを作成します。
理想: 異なる信頼レベルを必要とする複数の職務を持つ管理者用に複数の別個のアカウントを作成します。 ワークステーション管理、サーバー管理、ドメイン管理などの、異なるユーザー権限を持つ各 Administrator アカウントを設定して、管理者が職務に厳密に基づいて指定のワークステーション、サーバー、ドメイン コントローラーにサインインできるようにします。
標準ユーザー アカウント: メール、Web 閲覧、基幹業務 (LOB) アプリケーションの使用などの、標準ユーザー タスク用の標準ユーザー権限を付与します。 これらのアカウントには管理者権限を付与しないでください。
重要
次のセクションで説明するように、機密性の高い管理者アカウントがメールにアクセスしたり、インターネットを閲覧したりできないようにします。
特権アクセスの詳細については、特権アクセス デバイスに関する記事を参照してください。
管理者のサインイン アクセスをサーバーとワークステーションに制限する
管理者が機密性の高い Administrator アカウントを使用して、信頼の低いサーバーとワークステーションにサインインすることを制限することをお勧めします。 この制限により、管理者が信頼度の低いコンピューターにサインインしたために、資格情報を不注意で盗難されるリスクが増大しないようにできます。
重要
ドメイン コントローラーへのローカル アクセス権を持っているか、少なくとも 1 台の専用管理ワークステーションを構築していることを確認してください。
次のガイドラインを使用して、低信頼サーバーとワークステーションへのサインイン アクセス権を制限します。
最小: ドメイン管理者がサーバーとワークステーションへのサインイン アクセス権を持たないように制限します。 この手順を開始する前に、ワークステーションとサーバーを含むドメイン内のすべての OU を特定してください。 特定されていない OU 内のコンピューターは、機密性の高いアカウントを持つ管理者のサインインを制限しません。
適度: ドメイン管理者をドメイン コントローラー以外のサーバーとワークステーションから制限します。
理想: ドメイン管理者に加えて、サーバー管理者がワークステーションにサインインすることを制限します。
注意
この手順では、管理業務のみを実行する管理者用のワークステーションを含む OU にアカウントをリンク "せず"、インターネットやメールへのアクセス権を提供 "しないで" ください。
ワークステーションからドメイン管理者を制限するには (最小)
ドメイン管理者として、グループ ポリシー管理コンソール (GPMC) を開きます。
[グループ ポリシーの管理] を開き、<forest>\Domains\
<domain>を展開します。[グループ ポリシー オブジェクト] を右クリックし、[新規] を選択します。
![グループ ポリシー 管理コンソール ウィンドウのスクリーンショット。[グループ ポリシー オブジェクト] コマンドとショートカット メニューが表示されています。](media/default-user-account-restrict1.png)
[新しい GPO] ウィンドウで、管理者のワークステーションへのサインインを制限する GPO に名前を付け、[OK] を選択します。
![グループ名とソース スターター GPO を入力するための [新しい GPO] ウィンドウのスクリーンショット。](media/default-user-account-restrict2.png)
[新しい GPO] を右クリックし、[編集] を選択します。
ドメイン管理者のローカルでのサインインを拒否するようにユーザー権限を構成します。
[コンピューターの構成]>[ポリシー]>[Windows の設定]>[ローカル ポリシー] の順に選択し、[ユーザー権利の割り当て] を選択し、次の操作を行います。
a. [ローカルでログオンを拒否する] をダブルクリックし、[これらのポリシーの設定を定義する] を選択します。 b. [ユーザーまたはグループの追加] を選択し、[参照] を選択し、「Enterprise Admins」と入力して、[OK] を選択します。 c. [ユーザーまたはグループの追加] を選択し、[参照] を選択し、「Domain Admins」と入力して、[OK] を選択します。
![[ユーザー権利の割り当て] ウィンドウのスクリーンショット。[これらのポリシー設定を定義する] チェック ボックスがオンで、2 つのドメイン アカウントがローカル サインインを拒否されることを示しています。](media/default-user-account-restrict3.png)
ヒント
必要に応じて、ワークステーションへのサインインを制限するサーバー管理者を含む任意のグループを追加できます。
注意
この手順を完了すると、スケジュールされたタスクとして実行される管理者タスク、または Domain Admins グループのアカウントを使用するサービスに関する問題が発生する可能性があります。 ドメインの Administrator アカウントを使用してワークステーションでサービスとタスクを実行する方法は、資格情報の盗難攻撃のリスクがかなり高いため、スケジュールされたタスクまたはサービスを実行する別の手段に置き換える必要があります。
d. 構成を終了するには、OK をクリックします。
GPO を最初のワークステーション OU にリンクします。 <forest>\Domains\
<domain>\OU パスに移動し、次の操作を行います。a. ワークステーション OU を右クリックし、[既存の GPO のリンク] を選択します。
![ワークステーション項目を右クリックし、[既存の GPO のリンク] を選択するグループ ポリシー管理コンソール ウィンドウのスクリーンショット。](media/default-user-account-restrict4.png)
b. 直前に作成した GPO を選択し、[OK] をクリックします。
![ドメインとグループ ポリシー オブジェクトを選択する [GPO の選択] ウィンドウのスクリーンショット。](media/default-user-account-restrict5.png)
最初の OU 内のワークステーションでエンタープライズ アプリケーションの機能をテストし、新しいポリシーによって発生した問題を解決します。
ワークステーションが含まれている他のすべての OU をリンクします。
ただし、管理作業専用で、インターネットやメールへのアクセス権がない管理ワークステーション用に作成された管理ワークステーション OU には、リンクを作成 "しないで" ください。
重要
後でこのソリューションを拡張する場合、Domain Users グループのサインイン権限を拒否 "しないで" ください。 Domain Users グループには、Users、Domain Administrators、Enterprise Administrators などの、ドメイン内のすべてのユーザー アカウントが含まれます。
機密性の高い Administrator アカウントのアカウント委任権限を無効にする
ユーザー アカウントには既定では委任用のマークが付けられていませんが、Active Directory ドメイン内のアカウントは委任に対して信頼できます。 つまり、委任に対して信頼されているサービスまたはコンピューターは、ネットワーク経由で他のリソースにアクセスすることが認証されるアカウントを借用できます。
機密性の高いアカウント (Active Directory の Administrators、Domain Admins、Enterprise Admins グループのメンバーに属するものなど) の場合、委任によって権限エスカレーションの大きなリスクが生じることがあります。 たとえば、Domain Admins グループ内のアカウントを使用して、委任に対して信頼されている侵害されたメンバー サーバーにサインインすると、そのサーバーが Domain Admins アカウントのコンテキストでリソースへのアクセスを要求して、そのメンバー サーバーの侵害をドメイン侵害にエスカレートする可能性があります。
Active Directory のすべての機密性の高いアカウントのユーザー オブジェクトは、[アカウント オプション] の下の [アカウントは重要なので委任できない] チェック ボックスをオンにして構成して、アカウントが委任されないようにすることをすることをお勧めします。 詳細については、「Active Directory の既定のローカル アカウントの設定」を参照してください。
構成の変更と同様、この有効にした設定を実装する前に、完全にテストして正しく実行されることを確認してください。
![Active Directory アカウントのプロパティ ウィンドウのスクリーンショット。[アカウントは重要なので委任できない] チェック ボックスがオンになっています。](media/active-directory-account-properties.png)
ドメイン コントローラーをセキュリティ保護および管理する
環境内のドメイン コントローラーに厳密に制限を適用することをお勧めします。 これにより、ドメイン コントローラーが次のようになります。
- 必要なソフトウェアのみを実行します。
- ソフトウェアを定期的に更新することを要求します。
- 適切なセキュリティ設定で構成されます。
ドメイン コントローラーのセキュリティ保護と管理の 1 つの側面は、既定のローカル ユーザー アカウントが完全に保護されるようにすることです。 これまでのセクションで説明したように、すべての機密性の高いドメイン アカウントを制限してセキュリティで保護することが最も重要です。
ドメイン コントローラーは、ドメイン内のすべてのアカウントの資格情報パスワード ハッシュを格納するため、悪意のあるユーザーにとって価値の高いターゲットです。 ドメイン コントローラーが厳密に適用される制限を使用して適切に管理およびセキュリティ保護されていないと、悪意のあるユーザーによって侵害される可能性があります。 たとえば、悪意のあるユーザーがあるドメイン コントローラーから機密性の高いドメイン管理者の資格情報を盗み、これらの資格情報を使用してドメインとフォレストを攻撃する可能性があります。
さらに、ドメイン コントローラーにインストールされているアプリケーションと管理エージェントが、管理サービスやそのサービスの管理者を侵害するために悪意のあるユーザーが使用できる権限のエスカレート パスを提供する可能性があります。 組織がドメイン コントローラーとその管理者を管理するために使用する管理ツールとサービスは、ドメイン コントローラーとドメインの Administrator アカウントのセキュリティと同等に重要です。 これらのサービスと管理者が同等の労力で完全にセキュリティ保護されるようにしてください。