メイン コンテンツへスキップ
サポート
Microsoft アカウントでサインイン
サインインまたはアカウントを作成してください。
こんにちは、
別のアカウントを選択してください。
複数のアカウントがあります
サインインに使用するアカウントを選択してください。

要約

セキュリティ設定とユーザー権限の割り当ては、ドメイン コントローラーとメンバー コンピューターのセキュリティを強化するために、ローカル ポリシーとグループ ポリシーで変更できます。 ただし、セキュリティ強化の欠点は、クライアント、サービス、およびプログラムとの非互換性の導入です。

この記事では、Windows Server 2003 ドメインまたは以前の Windows Server ドメインで特定のセキュリティ設定とユーザー権限の割り当てを変更する場合に、Windows XP または以前のバージョンの Windows を実行しているクライアント コンピューターで発生する可能性がある非互換性について説明します。

Windows 7、Windows Server 2008 R2、Windows Server 2008 のグループ ポリシーの詳細については、次の記事を参照してください。

注: この記事の残りのコンテンツは、Windows XP、Windows Server 2003、および以前のバージョンの Windows に固有です。

Windows XP

正しく構成されていないセキュリティ設定の認識を高めるには、グループ ポリシー オブジェクト エディター ツールを使用してセキュリティ設定を変更します。 グループ ポリシー オブジェクト エディターを使用すると、次のオペレーティング システムでユーザー権限の割り当てが強化されます。

  • Windows XP Professional Service Pack 2 (SP2)

  • Windows Server 2003 Service Pack 1 (SP1)

強化された機能は、この記事へのリンクを含むダイアログ ボックスです。 このダイアログ ボックスは、セキュリティ設定またはユーザー権限の割り当てを、互換性が低く制限の厳しい設定に変更すると表示されます。 レジストリを使用するか、セキュリティ テンプレートを使用して同じセキュリティ設定またはユーザー権限の割り当てを直接変更する場合、その効果は、グループ ポリシー オブジェクト エディターの設定を変更した場合と同じです。 ただし、この記事へのリンクを含むダイアログ ボックスは表示されません。

この記事には、特定のセキュリティ設定またはユーザー権限の割り当ての影響を受けるクライアント、プログラム、操作の例が含まれています。 ただし、この例は、すべての Microsoft オペレーティング システム、すべてのサード パーティのオペレーティング システム、または影響を受けるすべてのプログラム バージョンに対して権限を持つものではありません。 この記事には、すべてのセキュリティ設定とユーザー権限の割り当てが含まれているわけではありません。

運用環境で導入する前に、テスト フォレスト内のすべてのセキュリティ関連の構成変更の互換性を検証することをお勧めします。 テスト フォレストは、次の方法で運用フォレストをミラー化する必要があります。

  • クライアントとサーバーのオペレーティング システムのバージョン、クライアントとサーバーのプログラム、Service Pack のバージョン、修正プログラム、スキーマ変更、セキュリティ グループ、グループ メンバーシップ、ファイル システム内のオブジェクトに対するアクセス許可、共有フォルダー、レジストリ、Active Directory ディレクトリ サービス、ローカルとグループ ポリシーの設定、オブジェクト数の種類と場所

  • 実行される管理タスク、使用される管理ツール、および管理タスクの実行に使用されるオペレーティング システム

  • 次のような操作が実行されます。

    • コンピューターとユーザーのログオン認証

    • ユーザー、コンピューター、管理者によるパスワード のリセット

    • 閲覧

    • すべてのアカウントまたはリソース ドメインのすべてのクライアント オペレーティング システムのすべてのアカウントまたはリソース ドメインで ACL エディターを使用して、ファイル システム、共有フォルダー、レジストリ、Active Directory リソースのアクセス許可を設定する

    • 管理アカウントと非管理者アカウントからの印刷

Windows Server 2003 SP1

Gpedit.msc の警告

ネットワークに悪影響を与える可能性のあるユーザーの権利またはセキュリティ オプションを編集していることを顧客に知らせるため、gpedit.msc に 2 つの警告メカニズムが追加されました。 管理者が企業全体に悪影響を与える可能性のあるユーザー権利を編集すると、利回り記号のような新しいアイコンが表示されます。 また、Microsoft サポート技術情報の記事823659へのリンクを含む警告メッセージも表示されます。 このメッセージのテキストは次のとおりです。

この設定を変更すると、クライアント、サービス、およびアプリケーションとの互換性に影響する可能性があります。 詳細については、「<ユーザー権利またはセキュリティ オプションの変更> (Q823659) Gpedit.msc のリンクからこのナレッジ ベースの記事に移動した場合は、提供されている説明と、この設定を変更した場合の影響を確認してください。 警告テキストを含むユーザー権限の一覧を次に示します。

  • ネットワークからこのコンピューターにアクセスする

  • ローカルでログオンする

  • バイパス トラバース チェック

  • 信頼された委任のためにコンピューターとユーザーを有効にする

警告とポップアップ メッセージを含むセキュリティ オプションを次に示します。

  • ドメイン メンバー: セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (常に)

  • ドメイン メンバー: 強力な (Windows 2000 以降のバージョン) セッション キーが必要

  • ドメイン コントローラー: LDAP サーバー署名の要件

  • Microsoft ネットワーク サーバー: 通信にデジタル署名する (常に)

  • ネットワーク アクセス: 匿名 Sid/名前の変換を許可する

  • ネットワーク アクセス: SAM アカウントと共有の匿名列挙を許可しない

  • ネットワーク セキュリティ: LAN Manager 認証レベル

  • 監査: セキュリティ監査をログに記録できない場合は、すぐにシステムをシャットダウンする

  • ネットワーク アクセス: LDAP クライアント署名の要件

その他の情報

以降のセクションでは、Windows NT 4.0 ドメイン、Windows 2000 ドメイン、および Windows Server 2003 ドメインの特定の設定を変更するときに発生する可能性のある非互換性について説明します。

ユーザー権限

次の一覧では、ユーザー権利の説明、問題の原因となる可能性がある構成設定の識別、ユーザー権利を適用する理由と、ユーザー権利を削除する理由、およびユーザー権利の構成時に発生する可能性がある互換性の問題の例を示します。

  1. ネットワークからこのコンピューターにアクセスする

    1. 背景

      リモート Windows ベースのコンピューターと対話するには、ネットワーク ユーザー権利からこのコンピューターにアクセスする必要があります。 このようなネットワーク操作の例を次に示します。

      • 共通ドメインまたはフォレスト内のドメイン コントローラー間での Active Directory のレプリケーション

      • ユーザーとコンピューターからのドメイン コントローラーへの認証要求

      • ネットワーク上のリモート コンピューター上にある共有フォルダー、プリンター、およびその他のシステム サービスへのアクセス



      ユーザー、コンピューター、およびサービス アカウントは、このユーザー権利が付与されているセキュリティ グループから明示的または暗黙的に追加または削除されることによって、ネットワーク ユーザーからこのコンピューターにアクセスする権利を取得または失います。 たとえば、ユーザー アカウントまたはコンピューター アカウントは、管理者によってカスタム セキュリティ グループまたは組み込みのセキュリティ グループに明示的に追加される場合や、オペレーティング システムによってドメイン ユーザー、認証されたユーザー、エンタープライズ ドメイン コントローラーなどの計算済みセキュリティ グループに暗黙的に追加される場合があります。

      既定では、ユーザー アカウントとコンピューター アカウントには、すべてのユーザーなどのコンピューティング グループ(できれば認証されたユーザー)、およびドメイン コントローラーの場合、Enterprise Domain Controllers グループが既定のドメイン コントローラー グループ ポリシー オブジェクト (GPO) で定義されている場合、ネットワーク ユーザーからこのコンピューターにアクセス権が付与されます。

    2. 危険な構成

      有害な構成設定を次に示します。

      • このユーザー権利から Enterprise Domain Controllers セキュリティ グループを削除する

      • 認証されたユーザー グループまたはユーザー、コンピューター、およびサービスアカウントを許可する明示的なグループを削除すると、ユーザーはネットワーク経由でコンピューターに接続できます

      • このユーザー権利からすべてのユーザーとコンピューターを削除する

    3. このユーザーに権利を付与する理由

      • ネットワーク ユーザーからエンタープライズ ドメイン コントローラー グループへのアクセス権をこのコンピューターに付与すると、同じフォレスト内のドメイン コントローラー間でレプリケーションを行うために Active Directory レプリケーションに必要な認証要件が満たされます。

      • このユーザー権利により、ユーザーとコンピューターは、Active Directory を含む共有ファイル、プリンター、およびシステム サービスにアクセスできます。

      • このユーザー権利は、ユーザーが Microsoft Outlook Web Access (OWA) の初期バージョンを使用してメールにアクセスするために必要です。

    4. このユーザー権利を削除する理由

      • コンピューターをネットワークに接続できるユーザーは、アクセス許可を持つリモート コンピューター上のリソースにアクセスできます。 たとえば、ユーザーが共有プリンターやフォルダーに接続するには、このユーザー権利が必要です。 このユーザー権利が Everyone グループに付与され、一部の共有フォルダーに、同じグループが読み取りアクセス権を持つように構成された共有フォルダーと NTFS ファイル システムの両方のアクセス許可がある場合、誰でもそれらの共有フォルダー内のファイルを表示できます。 ただし、既定の共有と Windows Server 2003 の NTFS アクセス許可に [すべてのユーザー] グループが含まれていないため、Windows Server 2003 の新規インストールでは、これはありそうもない状況です。 Microsoft Windows NT 4.0 または Windows 2000 からアップグレードされたシステムの場合、これらのオペレーティング システムの既定の共有とファイル システムのアクセス許可が Windows Server 2003 の既定のアクセス許可ほど制限されていないため、この脆弱性のリスクレベルが高くなる可能性があります。

      • このユーザー権利から Enterprise Domain Controllers グループを削除する正当な理由はありません。

      • Everyone グループは、通常、認証されたユーザー グループを優先して削除されます。 Everyone グループが削除された場合は、認証されたユーザー グループにこのユーザー権利を付与する必要があります。

      • Windows 2000 にアップグレードされた Windows NT 4.0 ドメインでは、ネットワーク ユーザーからこのコンピューターへのアクセス権が、Everyone グループ、認証済みユーザー グループ、またはエンタープライズ ドメイン コントローラー グループに明示的に付与されません。 そのため、Windows NT 4.0 ドメイン ポリシーから Everyone グループを削除すると、Windows 2000 にアップグレードした後、Active Directory のレプリケーションが "アクセス拒否" というエラー メッセージで失敗します。 Windows Server 2003 のWinnt32.exeでは、Windows NT 4.0 プライマリ ドメイン コントローラー (PDC) をアップグレードするときに、エンタープライズ ドメイン コントローラー グループにこのユーザー権利を付与することで、この構成ミスを回避できます。 グループ ポリシー オブジェクト エディターに存在しない場合は、エンタープライズ ドメイン コントローラー グループにこのユーザー権利を付与します。

    5. 互換性の問題の例

      • Windows 2000 および Windows Server 2003: 次のパーティションのレプリケーションは、REPLMON や REPADMIN などの監視ツールまたはイベント ログのレプリケーション イベントによって報告される "アクセス拒否" エラーで失敗します。

        • Active Directory スキーマ パーティション

        • 構成パーティション

        • ドメイン パーティション

        • グローバル カタログ パーティション

        • アプリケーション パーティション

      • すべての Microsoft ネットワーク オペレーティング システム: リモート ネットワーク クライアント コンピューターからのユーザー アカウント認証は、ユーザーまたはユーザーがメンバーであるセキュリティ グループにこのユーザー権利が付与されていない限り失敗します。

      • すべての Microsoft ネットワーク オペレーティング システム: リモート ネットワーク クライアントからのアカウント認証は、アカウントまたはアカウントがメンバーであるセキュリティ グループにこのユーザー権利が付与されていない限り失敗します。 このシナリオは、ユーザー アカウント、コンピューター アカウント、およびサービス アカウントに適用されます。

      • すべての Microsoft ネットワーク オペレーティング システム: このユーザー権利からすべてのアカウントを削除すると、アカウントがドメインにログオンしたり、ネットワーク リソースにアクセスしたりできなくなります。 Enterprise Domain Controllers、Everyone、Authenticated Users などのコンピューティング グループが削除された場合は、アカウントまたはアカウントがネットワーク経由でリモート コンピューターにアクセスするメンバーであるセキュリティ グループに対して、このユーザーに明示的に権限を付与する必要があります。 このシナリオは、すべてのユーザー アカウント、すべてのコンピューター アカウント、およびすべてのサービス アカウントに適用されます。

      • すべての Microsoft ネットワーク オペレーティング システム: ローカル管理者アカウントは、"空白" のパスワードを使用します。 ドメイン環境の管理者アカウントでは、空白のパスワードを使用したネットワーク接続は許可されません。 この構成では、"アクセス拒否" エラー メッセージが表示される可能性があります。

  2. ローカルでのログオンを許可する

    1. 背景

      Windows ベースのコンピューターのコンソールで (Ctrl + ALT + DELETE キーボード ショートカットを使用して) ログオンしようとしているユーザーと、サービスを開始しようとしているアカウントには、ホスティング コンピューターに対するローカル ログオン特権が必要です。 ローカル ログオン操作の例には、メンバー コンピューターのコンソールにログオンしている管理者や、特権のないアカウントを使用してデスクトップにアクセスするためにメンバー コンピューターにログオンしているエンタープライズ ユーザーやドメイン ユーザー全体のドメイン コントローラーなどがあります。 リモート デスクトップ接続またはターミナル サービスを使用するユーザーは、ホスト コンピューターに対してローカルと見なされるため、Windows 2000 または Windows XP を実行している移行先コンピューターでローカルでログオンを許可するユーザー権限を持っている必要があります。 ターミナル サーバーが有効になっていて、このユーザー権限を持たないサーバーにログオンしているユーザーは、ターミナル サービスを介したログオンを許可する権限を持っている場合でも、Windows Server 2003 ドメインでリモート対話型セッションを開始できます。

    2. 危険な構成

      有害な構成設定を次に示します。

      • アカウントオペレーター、バックアップオペレーター、印刷オペレーター、サーバーオペレーターなどの管理セキュリティ グループと、組み込みの Administrators グループを既定のドメイン コントローラーのポリシーから削除します。

      • 既定のドメイン コントローラーのポリシーから、コンポーネントおよびメンバー コンピューター上およびドメイン内のドメイン コントローラー上のプログラムによって使用されるサービス アカウントを削除します。

      • ドメイン内のメンバー コンピューターのコンソールにログオンするユーザーまたはセキュリティ グループを削除します。

      • メンバー コンピューターまたはワークグループ コンピューターのローカル Security Accounts Manager (SAM) データベースで定義されているサービス アカウントを削除します。

      • ドメイン コントローラーで実行されているターミナル サービスを介して認証している、組み込みでない管理アカウントを削除します。

      • ドメイン内のすべてのユーザー アカウントを、Everyone グループを介して明示的または暗黙的に 、ローカルログオンを拒否する権限に追加します。 この構成により、ユーザーはドメイン内の任意のメンバー コンピューターまたは任意のドメイン コントローラーにログオンできなくなります。

    3. このユーザーに権利を付与する理由

      • ユーザーは、コンソールまたはワークグループ コンピューター、メンバー コンピューター、またはドメイン コントローラーのデスクトップにアクセスする権限をローカルで許可するユーザー権限を持っている必要があります。

      • ユーザーは、Windows 2000 ベースのメンバー コンピューターまたはドメイン コントローラーで実行されているターミナル サービス セッションでログオンする権限を持っている必要があります。

    4. このユーザー権利を削除する理由

      • 正当なユーザー アカウントへのコンソール アクセスを制限しないと、承認されていないユーザーが悪意のあるコードをダウンロードして実行してユーザー権限を変更する可能性があります。

      • ローカルユーザーのログオンを許可する権限を削除すると、ドメイン コントローラーやアプリケーション サーバーなどのコンピューターのコンソールでの承認されていないログオンが防止されます。

      • このログオン権限を削除すると、ドメイン以外のアカウントがドメイン内のメンバー コンピューターのコンソールでログオンできなくなります。

    5. 互換性の問題の例

      • Windows 2000 ターミナル サーバー: ユーザーが Windows 2000 ターミナル サーバーにログオンするには、ローカルでのログオンを許可するユーザー権限が必要です。

      • Windows NT 4.0、Windows 2000、Windows XP、または Windows Server 2003: ユーザー アカウントには、Windows NT 4.0、Windows 2000、Windows XP、または Windows Server 2003 を実行しているコンピューターのコンソールでログオンする権限をこのユーザーに付与する必要があります。

      • Windows NT 4.0 以降: Windows NT 4.0 以降を実行しているコンピューターで、ローカルログオンを許可するユーザー権限を追加しても、ローカルログオンを拒否する権限も暗黙的または明示的に付与すると、アカウントはドメイン コントローラーのコンソールにログオンできなくなります。

  3. バイパス トラバース チェック

    1. 背景

      [バイパス トラバースチェック] ユーザー権利を使用すると、ユーザーは、NTFS ファイル システムまたはレジストリ内のフォルダーを参照できます。また、フォルダーのスキャンの特別なアクセス許可をチェックする必要はありません。 バイパス 走査チェック ユーザー権利では、ユーザーがフォルダーの内容を一覧表示することはできません。 これにより、ユーザーはフォルダーのみを走査できます。

    2. 危険な構成

      有害な構成設定を次に示します。

      • Windows 2000 ベースのターミナル サービス コンピューターまたは Windows Server 2003 ベースのターミナル サービス コンピューターにログオンする管理アカウント以外のアカウントを削除します。ファイル システム内のファイルとフォルダーにアクセスするアクセス許可がありません。

      • 既定で、このユーザーを持つセキュリティ プリンシパルの一覧から Everyone グループを削除します。 Windows オペレーティング システムおよび多くのプログラムは、コンピューターに正当にアクセスできるすべてのユーザーが、バイパス トラバースチェックユーザー権利を持つという期待を持って設計されています。 そのため、既定でこのユーザー権利を持つセキュリティ プリンシパルの一覧から Everyone グループを削除すると、オペレーティング システムが不安定になったり、プログラムのエラーが発生したりする可能性があります。 この設定は既定のままにすることをお勧めします。

    3. このユーザーに権利

      を付与する理由 [走査チェックのバイパス] ユーザー権利の既定の設定は、すべてのユーザーがトラバース チェックをバイパスできるようにすることです。 経験豊富な Windows システム管理者の場合、これは想定される動作であり、それに応じてファイル システム アクセス制御リスト (SACL) を構成します。 既定の構成で問題が発生する可能性がある唯一のシナリオは、アクセス許可を構成する管理者が動作を理解せず、親フォルダーにアクセスできないユーザーが子フォルダーのコンテンツにアクセスできないことを想定している場合です。

    4. このユーザー権利

      を削除する理由 ファイル またはファイル システム内のフォルダーへのアクセスを防ぐために、セキュリティを非常に懸念している組織は、ユーザーのバイパスチェック権限を持つグループの一覧から Everyone グループ 、またはユーザー グループを削除するように誘惑される可能性があります。

    5. 互換性の問題の例

      • Windows 2000、Windows Server 2003: Windows 2000 または Windows Server 2003 を実行しているコンピューターで[バイパス トラバースチェック] ユーザー権利が削除された場合、または正しく構成されていない場合、SYVOL フォルダーのグループ ポリシー設定はドメイン内のドメイン コントローラー間でレプリケートされません。

      • Windows 2000、Windows XP Professional、Windows Server 2003: Windows 2000、Windows XP Professional、または Windows Server 2003 を実行しているコンピューターは、イベント 1000 と 1202 をログに記録し、必要なファイル システムのアクセス許可が SYSVOL ツリーから削除されたときに、コンピューター ポリシーとユーザー ポリシーを適用できません。これは、バイパス走査チェックユーザー権利が削除または不適切な構成の場合に SYSVOL ツリーから削除されます。

         

      • Windows 2000、Windows Server 2003: Windows 2000 または Windows Server 2003 を実行しているコンピューターでは、ボリュームのプロパティを表示すると、Windows エクスプローラーの [クォータ ] タブが表示されなくなります。

      • Windows 2000: Windows 2000 ターミナル サーバーにログオンする管理者以外のユーザーには、次のエラー メッセージが表示される場合があります。

        アプリケーション エラーUserinit.exe。 アプリケーションを正しく初期化できませんでした0xc0000142[OK] をクリックしてアプリを終了します。

      • Windows NT 4.0、Windows 2000、Windows XP、Windows Server 2003: コンピューターが Windows NT 4.0、Windows 2000、Windows XP、または Windows Server 2003 を実行しているユーザーは、共有フォルダー上の共有フォルダーまたはファイルにアクセスできない場合があり、バイパス トラバース チェック 権限が付与されていない場合は、"アクセス拒否" エラー メッセージが表示される場合があります。


         

      • Windows NT 4.0: Windows NT 4.0 ベースのコンピューターでは、バイパス 走査チェック ユーザー権限を削除すると、ファイル コピーによってファイル ストリームが削除されます。 このユーザー権利を削除すると、Windows クライアントまたは Macintosh クライアントから、Services for Macintosh を実行している Windows NT 4.0 ドメイン コントローラーにファイルがコピーされると、コピー先のファイル ストリームが失われ、ファイルはテキスト専用ファイルとして表示されます。

      • Microsoft Windows 95、Microsoft Windows 98: Windows 95 または Windows 98 を実行しているクライアント コンピューターでは、認証されたユーザー グループにバイパス トラバースチェック ユーザー権限が付与されていない場合、net use * /home コマンドは "アクセス拒否" エラー メッセージで失敗します。

      • Outlook Web Access: 管理者以外のユーザーは Microsoft Outlook Web Access にログオンできず、バイパス トラバース チェック ユーザー権利が付与されていない場合は、"アクセス拒否" というエラー メッセージが表示されます。

セキュリティ設定

次の一覧はセキュリティ設定を識別し、入れ子になった一覧にはセキュリティ設定に関する説明、問題の原因となる構成設定の識別、セキュリティ設定の適用理由、およびセキュリティ設定を削除する理由について説明します。 入れ子になったリストには、セキュリティ設定のシンボリック名と、セキュリティ設定のレジストリ パスが提供されます。 最後に、セキュリティ設定の構成時に発生する可能性がある互換性の問題の例を示します。

  1. 監査: セキュリティ監査をログに記録できない場合は、すぐにシステムをシャットダウンする

    1. 背景

      • [監査: セキュリティ監査をログに記録できない場合はシステムをすぐにシャットダウンする] 設定は、セキュリティ イベントをログに記録できない場合にシステムがシャットダウンするかどうかを決定します。 この設定は、信頼されたコンピューター セキュリティ評価基準 (TCSEC) プログラムの C2 評価と、監査システムがそれらのイベントをログに記録できない場合に監査可能なイベントを防ぐための情報技術セキュリティ評価の共通基準に必要です。 監査システムが失敗した場合、システムはシャットダウンされ、Stop エラー メッセージが表示されます。

      • コンピューターがセキュリティ ログにイベントを記録できない場合、重大な証拠や重要なトラブルシューティング情報は、セキュリティ インシデント後に確認できない可能性があります。

    2. 危険な構成

      有害な構成設定を次に示します。[監査: セキュリティ監査をログに記録できない場合はシステムを直ちにシャットダウンする] 設定がオンになっており、セキュリティ イベント ログのサイズは、[イベントを上書きしない (ログを手動でクリア)] オプション、必要に応じてイベントを上書きするオプション、またはイベント ビューアーの [日数より前のイベントの上書き] オプションによって制約されます。 Windows 2000、Windows 2000 Service Pack 1 (SP1)、Windows 2000 SP2、または Windows 2000 SP3 の元のリリース バージョンを実行しているコンピューターの特定のリスクについては、「互換性の問題の例」セクションを参照してください。

    3. この設定

      を有効にする理由 コンピューターがセキュリティ ログにイベントを記録できない場合、重大な証拠や重要なトラブルシューティング情報は、セキュリティ インシデント後に確認できない可能性があります。

    4. この設定を無効にする理由

      • 監査を有効にする: セキュリティ監査をログに記録できない場合にシステムをすぐにシャットダウンする設定は、何らかの理由でセキュリティ監査をログに記録できない場合にシステムを停止します。 通常、セキュリティ監査ログがいっぱいの場合、および指定された保持方法が [イベントを上書きしない (ログを手動でクリア)] オプションまたは [ 日数 より前のイベントの上書き] オプションの場合、イベントをログに記録できません。

      • 監査を有効にすることの管理上の負担: セキュリティ監査をログに記録できない場合、システムをすぐにシャットダウンする設定は非常に高くなる可能性があります。特に、セキュリティ ログの [イベントを上書きしない (ログを手動でクリアする)] オプションをオンにした場合です。 この設定は、オペレーターアクションに対する個々の説明責任を提供します。 たとえば、管理者は、組み込みの管理者アカウントまたは他の共有アカウントを使用して監査が有効になっている組織単位 (OU) 内のすべてのユーザー、コンピューター、およびグループに対するアクセス許可をリセットし、そのようなアクセス許可をリセットすることを拒否できます。 ただし、この設定を有効にすると、ログオン イベントやセキュリティ ログに書き込まれるその他のセキュリティ イベントでサーバーが強制的にシャットダウンされる可能性があるため、システムの堅牢性が低下します。 さらに、シャットダウンが正常ではないため、オペレーティング システム、プログラム、またはデータに対する回復不可能な損害が発生する可能性があります。 NTFS は、不名誉なシステムシャットダウン中にファイル システムの整合性が維持されることを保証しますが、システムの再起動時にすべてのプログラムのすべてのデータ ファイルが引き続き使用可能な形式であることを保証することはできません。

    5. シンボリック名:

      CrashOnAuditFail

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)

    7. 互換性の問題の例

      • Windows 2000: バグにより、Windows 2000、Windows 2000 SP1、Windows 2000 SP2、または Windows Server SP3 の元のリリース バージョンを実行しているコンピューターは、セキュリティ イベント ログの [最大ログ サイズ] オプションで指定されたサイズに達する前に、イベントのログ記録を停止することがあります。 このバグは、Windows 2000 Service Pack 4 (SP4) で修正されています。 この設定を有効にすることを検討する前に、Windows 2000 ドメイン コントローラーに Windows 2000 Service Pack 4 がインストールされていることを確認してください。

         

      • Windows 2000、Windows Server 2003: Windows 2000 または Windows Server 2003 を実行しているコンピューターが応答を停止し、監査: セキュリティ監査設定をログに記録できない場合はシステムを直ちにシャットダウンし、セキュリティ ログがいっぱいになり、既存のイベント ログ エントリを上書きできない場合は、自然に再起動することがあります。 コンピューターが再起動すると、次の Stop エラー メッセージが表示されます。

        STOP: C0000244 {Audit Failed}
        セキュリティ監査を生成できませんでした。

        回復するには、管理者がログオンし、セキュリティ ログをアーカイブし (省略可能)、セキュリティ ログをクリアしてから、このオプション (オプションと必要に応じて) をリセットする必要があります。

      • Microsoft Network Client for MS-DOS、Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP、Windows Server 2003: ドメインにログオンしようとする管理者以外のユーザーには、次のエラー メッセージが表示されます。

        このコンピューターを使用できないようにアカウントが構成されています。 別のコンピューターを試してください。

      • Windows 2000: Windows 2000 ベースのコンピューターでは、管理者以外のユーザーはリモート アクセス サーバーにログオンできず、次のようなエラー メッセージが表示されます。

        不明なユーザーまたは不適切なパスワード

      • Windows 2000: Windows 2000 ドメイン コントローラーでは、サイト間メッセージング サービス (Ismserv.exe) が停止し、再起動できません。 DCDIAG はエラーを "失敗したテスト サービス ISMserv" として報告し、イベント ID 1083 はイベント ログに登録されます。

      • Windows 2000: Windows 2000 ドメイン コントローラーでは、Active Directory レプリケーションが失敗し、セキュリティ イベント ログがいっぱいの場合は "アクセス拒否" メッセージが表示されます。

      • Microsoft Exchange 2000: Exchange 2000 を実行しているサーバーはインフォメーション ストア データベースをマウントできず、イベント ログにイベント 2102 が登録されます。

      • Outlook、Outlook Web Access: 管理者以外のユーザーは、Microsoft Outlook または Microsoft Outlook Web Access を介して自分のメールにアクセスできず、503 エラーが表示されます。

  2. ドメイン コントローラー: LDAP サーバー署名の要件

    1. 背景

      ドメイン コントローラー: LDAP サーバー署名要件のセキュリティ設定により、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーでデータ署名のネゴシエートに LDAP クライアントが必要かどうかが決まります。 このポリシー設定で使用できる値は次のとおりです。

      • なし: サーバーとバインドするためにデータ署名は必要ありません。 クライアントがデータ署名を要求した場合、サーバーはそれをサポートします。

      • 署名が必要: トランスポート層セキュリティ/Secure Socket Layer (TLS/SSL) が使用されている場合を除き、LDAP データ署名オプションをネゴシエートする必要があります。

      • 定義されていません: この設定は有効または無効ではありません。

    2. 危険な構成

      有害な構成設定を次に示します。

      • クライアントが LDAP 署名をサポートしていない環境、またはクライアント側の LDAP 署名が有効になっていない環境でサインインを要求するを有効にする

      • クライアントが LDAP 署名をサポートしていない環境、またはクライアント側の LDAP 署名が有効になっていない環境で Windows 2000 または Windows Server 2003 Hisecdc.inf セキュリティ テンプレートを適用する

      • クライアントが LDAP 署名をサポートしていない環境、またはクライアント側の LDAP 署名が有効になっていない環境で Windows 2000 または Windows Server 2003 Hisecws.inf セキュリティ テンプレートを適用する

    3. この設定

      を有効にする理由 署名されていないネットワーク トラフィックは、侵入者がクライアントとサーバーの間のパケットをキャプチャし、パケットを変更してからサーバーに転送する中間者攻撃の影響を受けやすくなります。 この動作が LDAP サーバーで発生した場合、攻撃者はサーバーに LDAP クライアントからの誤ったクエリに基づいて決定を下す可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークのこのリスクを減らすことができます。 インターネット プロトコル セキュリティ (IPSec) 認証ヘッダー モードは、中間者攻撃を防ぐのに役立ちます。 認証ヘッダー モードでは、IP トラフィックに対して相互認証とパケット整合性が実行されます。

    4. この設定を無効にする理由

      • LDAP 署名をサポートしていないクライアントは、NTLM 認証がネゴシエートされ、正しいサービス パックが Windows 2000 ドメイン コントローラーにインストールされていない場合、ドメイン コントローラーとグローバル カタログに対して LDAP クエリを実行できません。

      • クライアントとサーバー間の LDAP トラフィックのネットワーク トレースは暗号化されます。 これにより、LDAP 会話を調べるのが困難になります。

      • Windows 2000 ベースのサーバーは、Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行するクライアント コンピューターから実行される LDAP 署名をサポートするプログラムで管理されている場合は、Windows 2000 Service Pack 3 (SP3) がインストールされている必要があります。  

    5. シンボリック名:

      LDAPServerIntegrity

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)

    7. 互換性の問題の例

      • 単純バインドは失敗し、次のエラー メッセージが表示されます。

        Ldap_simple_bind_s() に失敗しました: 強力な認証が必要です。

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003: Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行しているクライアントでは、NTLM 認証がネゴシエートされたときに SP3 より前のバージョンの Windows 2000 を実行しているドメイン コントローラーに対して、一部の Active Directory 管理ツールが正しく動作しません。

         

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003: Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行しているクライアントでは、SP3 より前のバージョンの Windows 2000 を実行しているドメイン コントローラーを対象とする一部の Active Directory 管理ツールは、IP アドレスを使用している場合は正しく動作しません (たとえば、 "dsa.msc /server=x.x.x.x.x.x" (
        x.x.x.x は IP アドレスです)。


         

      • Windows 2000 Service Pack 4、Windows XP、Windows Server 2003: Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行しているクライアントでは、SP3 より前のバージョンの Windows 2000 を実行しているドメイン コントローラーを対象とする一部の Active Directory 管理ツールは正しく動作しません。

         

  3. ドメイン メンバー: 強力な (Windows 2000 以降) セッション キーが必要

    1. 背景

      • ドメイン メンバー: 強力な (Windows 2000 以降の) セッション キー設定を必要とすると、セキュリティで保護されたチャネル トラフィックを強力な 128 ビット セッション キーで暗号化できないドメイン コントローラーでセキュリティで保護されたチャネルを確立できるかどうかを決定します。 この設定を有効にすると、セキュリティで保護されたチャネル データを強力なキーで暗号化できないドメイン コントローラーでセキュリティで保護されたチャネルを確立できなくなります。 この設定を無効にすると、64 ビット セッション キーが許可されます。

      • メンバー ワークステーションまたはサーバーでこの設定を有効にするには、メンバーが属するドメイン内のすべてのドメイン コントローラーが、強力な 128 ビット キーを使用してセキュリティで保護されたチャネル データを暗号化できる必要があります。 つまり、このようなすべてのドメイン コントローラーが Windows 2000 以降を実行している必要があります。

    2. 危険な構成

      ドメイン メンバーを有効にする: 強力な (Windows 2000 以降の) セッション キー設定を必要とするのは有害な構成設定です。

    3. この設定を有効にする理由

      • メンバー コンピューターとドメイン コントローラー間のセキュリティで保護されたチャネル通信を確立するために使用されるセッション キーは、Windows 2000 では、以前のバージョンの Microsoft オペレーティング システムよりもはるかに強力です。

      • 可能な場合は、これらの強力なセッション キーを利用して、盗聴やネットワーク攻撃のセッション乗っ取りからセキュリティで保護されたチャネル通信を保護することをお勧めします。 盗聴は、ネットワーク データが読み取られるか、転送中に変更される悪意のある攻撃の一種です。 データは、送信者を非表示にしたり変更したり、リダイレクトしたりするように変更できます。

      重要: Windows Server 2008 R2 または Windows 7 を実行しているコンピューターでは、セキュリティで保護されたチャネルが使用されている場合にのみ強力なキーがサポートされます。 この制限により、Windows NT 4.0 ベースのドメインと Windows Server 2008 R2 ベースのドメイン間の信頼が回避されます。 さらに、この制限により、Windows 7 または Windows Server 2008 R2 を実行しているコンピューターの Windows NT 4.0 ベースのドメイン メンバーシップがブロックされ、その逆もブロックされます。

    4. この設定

      を無効にする理由 ドメインには、Windows 2000、Windows XP、または Windows Server 2003 以外のオペレーティング システムを実行しているメンバー コンピューターが含まれています。

    5. シンボリック名:

      StrongKey

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)

    7. 互換性の問題

      の例Windows NT 4.0: Windows NT 4.0 ベースのコンピューターでは、NLTEST を使用してWindows NT 4.0 ドメインと Windows 2000 ドメイン間のセキュリティで保護された信頼関係チャネルをリセットできません。 "アクセス拒否" というエラー メッセージが表示されます。

      プライマリ ドメインと信頼されたドメインの間の信頼関係が失敗しました。

      Windows 7 および Server 2008 R2: Windows 7 以降のバージョンおよび Windows Server 2008 R2 以降のバージョンの場合、この設定は今後適用されず、強力なキーは常に使用されます。 そのため、Windows NT 4.0 ドメインの信頼は機能しなくなります。

  4. ドメイン メンバー: セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (常に)

    1. 背景

      • ドメイン メンバーを有効にする: セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (常に) すべてのセキュリティで保護されたチャネル データに署名または暗号化できないドメイン コントローラーを使用してセキュリティで保護されたチャネルを確立することはできません。 中間者攻撃、リプレイ攻撃、その他の種類のネットワーク攻撃から認証トラフィックを保護するために、Windows ベースのコンピューターは、Net Logon サービスを介してコンピューター アカウントを認証するセキュリティで保護されたチャネルと呼ばれる通信チャネルを作成します。 セキュリティで保護されたチャネルは、1 つのドメインのユーザーがリモート ドメイン内のネットワーク リソースに接続するときにも使用されます。 このマルチドメイン認証 (パススルー認証) を使用すると、ドメインに参加している Windows ベースのコンピューターは、そのドメイン内および信頼されたドメイン内のユーザー アカウント データベースにアクセスできます。

      • ドメイン メンバーを有効にするには、メンバー コンピューター上のセキュリティで保護されたチャネル データ (常に) 設定をデジタルで暗号化または署名します。メンバーが属するドメイン内のすべてのドメイン コントローラーは、すべてのセキュリティで保護されたチャネル データに署名または暗号化できる必要があります。 つまり、このようなドメイン コントローラーはすべて、Service Pack 6a (SP6a) 以降で Windows NT 4.0 を実行している必要があります。

      • ドメイン メンバーを有効にする: セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (常に) 設定すると、[ドメイン メンバー: デジタル暗号化またはセキュリティで保護されたチャネル データの署名 (可能な場合)] 設定が自動的に有効になります。

    2. 危険な構成

      ドメイン メンバーを有効にする: すべてのドメイン コントローラーがセキュリティで保護されたチャネル データに署名または暗号化できるわけではないドメインで、セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (常に) 設定が有害な構成設定です。

    3. この設定

      を有効にする理由 署名されていないネットワーク トラフィックは、侵入者がサーバーとクライアントの間のパケットをキャプチャし、クライアントに転送する前に変更する中間者攻撃の影響を受けやすくなります。 この動作が Lightweight Directory Access Protocol (LDAP) サーバーで発生すると、侵入者が LDAP ディレクトリからの偽レコードに基づいてクライアントに決定を下す可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークに対するこのような攻撃のリスクを低くすることができます。 さらに、インターネット プロトコル セキュリティ (IPSec) 認証ヘッダー モードを実装すると、中間者攻撃を防ぐのに役立ちます。 このモードでは、IP トラフィックに対して相互認証とパケット整合性が実行されます。

    4. この設定を無効にする理由

      • ローカルドメインまたは外部ドメイン内のコンピューターでは、暗号化されたセキュリティで保護されたチャネルがサポートされます。

      • ドメイン内のすべてのドメイン コントローラーに、暗号化されたセキュリティで保護されたチャネルをサポートするための適切なサービス パックリビジョン レベルがあるわけではありません。

    5. シンボリック名:

      StrongKey

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)

    7. 互換性の問題の例

      • Windows NT 4.0: Windows 2000 ベースのメンバー コンピューターは、4.0 ドメインWindows NT参加できず、次のエラー メッセージが表示されます。

        このアカウントは、このステーションからログインする権限がありません。

        詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。

        281648 エラー メッセージ: このアカウントは、このステーションからログインする権限がありません
         

      • Windows NT 4.0: Windows NT 4.0 ドメインでは、Windows 2000 ドメインとの下位レベルの信頼を確立できず、次のエラー メッセージが表示されます。

        このアカウントは、このステーションからログインする権限がありません。

        既存の下位レベルの信頼では、信頼されたドメインからユーザーを認証できない場合もあります。 一部のユーザーは、ドメインへのログオンに問題があり、クライアントがドメインを見つけられないことを示すエラー メッセージが表示される場合があります。

      • Windows XP: Windows NT 4.0 ドメインに参加している Windows XP クライアントでは、ログオン試行を認証できず、次のエラー メッセージが表示されたり、次のイベントがイベント ログに登録されたりすることがあります。

        ドメイン コントローラーがダウンしているか、それ以外の場合は使用できないか、コンピューター アカウントが見つからなかったため、Windows はドメインに接続できません

      • Microsoft Network: Microsoft Network クライアントには、次のいずれかのエラー メッセージが表示されます。

        ログオンエラー: 不明なユーザー名または不適切なパスワード。

        指定したログオン セッションのユーザー セッション キーはありません。

  5. Microsoft ネットワーク クライアント: 通信にデジタル署名する (常に)

    1. 背景

      サーバー メッセージ ブロック (SMB) は、多くの Microsoft オペレーティング システムでサポートされているリソース共有プロトコルです。 これは、ネットワーク基本入出力システム (NetBIOS) とその他の多くのプロトコルの基礎です。 SMB 署名は、データをホストするユーザーとサーバーの両方を認証します。 どちらかの側で認証プロセスが失敗した場合、データ転送は行われません。

      SMB 署名の有効化は、SMB プロトコル ネゴシエーション中に開始されます。 SMB 署名ポリシーは、コンピューターが常にクライアント通信にデジタル署名するかどうかを決定します。

      Windows 2000 SMB 認証プロトコルでは、相互認証がサポートされます。 相互認証は、"中間者" 攻撃を閉じます。 Windows 2000 SMB 認証プロトコルでは、メッセージ認証もサポートされています。 メッセージ認証は、アクティブなメッセージ攻撃を防ぐのに役立ちます。 この認証を行うために、SMB 署名は各 SMB にデジタル署名を配置します。 クライアントとサーバーは、それぞれデジタル署名を検証します。

      SMB 署名を使用するには、SMB 署名を有効にするか、SMB クライアントと SMB サーバーの両方で SMB 署名を要求する必要があります。 サーバーで SMB 署名が有効になっている場合、SMB 署名も有効になっているクライアントは、後続のすべてのセッションでパケット署名プロトコルを使用します。 サーバーで SMB 署名が必要な場合、クライアントが SMB 署名に有効または必須でない限り、クライアントはセッションを確立できません。


      セキュリティの高いネットワークでデジタル署名を有効にすると、クライアントとサーバーの偽装を防ぐことができます。 この種の偽装は、セッションハイジャックと呼ばれます。 クライアントまたはサーバーと同じネットワークにアクセスできる攻撃者は、セッションハイジャック ツールを使用して、進行中のセッションを中断、終了、または盗みます。 攻撃者は、署名されていない SMB パケットを傍受して変更し、トラフィックを変更し、サーバーが望ましくないアクションを実行できるように転送する可能性があります。 または、攻撃者は正当な認証の後にサーバーまたはクライアントとして攻撃を受け、データへの不正アクセスを取得する可能性があります。

      Windows 2000 Server、Windows 2000 Professional、Windows XP Professional、または Windows Server 2003 を実行しているコンピューターでのファイル共有と印刷共有に使用される SMB プロトコルは、相互認証をサポートします。 相互認証では、セッション乗っ取り攻撃が終了し、メッセージ認証がサポートされます。 そのため、中間者攻撃を防ぎます。 SMB 署名では、各 SMB にデジタル署名を配置することで、この認証が提供されます。 次に、クライアントとサーバーが署名を確認します。

      ノート

      • 別の対策として、IPSec を使用してデジタル署名を有効にして、すべてのネットワーク トラフィックを保護することができます。 IPSec 暗号化と署名のためのハードウェア ベースのアクセラレータがあり、サーバーの CPU からのパフォーマンスへの影響を最小限に抑えるために使用できます。 SMB 署名に使用できるアクセラレータはありません。

        詳細については、Microsoft MSDN Web サイトの 「サーバー通信にデジタル署名 する」の章を参照してください。

        グループ ポリシー オブジェクト エディターを使用して SMB 署名を構成します。これは、オーバーライドするドメイン ポリシーがある場合、ローカル レジストリ値の変更は影響を受けないためです。

      • Windows 95、Windows 98、および Windows 98 Second Edition では、ディレクトリ サービス クライアントは NTLM 認証を使用して Windows Server 2003 サーバーで認証するときに SMB 署名を使用します。 ただし、これらのクライアントは、NTLMv2 認証を使用してこれらのサーバーで認証するときに SMB 署名を使用しません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。 詳細については、項目 10: "ネットワーク セキュリティ: Lan Manager 認証レベル" を参照してください。

    2. 危険な構成

      有害な構成設定を次に示します。Microsoft ネットワーク クライアントの両方を残します:通信のデジタル署名 (常に) 設定と Microsoft ネットワーク クライアント: 通信にデジタル署名する (サーバーが同意した場合) 設定を "定義なし" または無効にします。 これらの設定により、リダイレクターは、認証時にパスワード暗号化をサポートしていない Microsoft 以外の SMB サーバーにプレーンテキスト パスワードを送信できます。

    3. この設定

      を有効にする理由 Microsoft ネットワーク クライアントを有効にする: デジタル署名通信 (常に) では、SMB 署名を必要としないサーバーに接続するときに、クライアントが SMB トラフィックに署名する必要があります。 これにより、クライアントはセッションハイジャック攻撃に対して脆弱になります。

    4. この設定を無効にする理由

      • Microsoft ネットワーク クライアントを有効にする: 通信にデジタル署名 (常に) すると、クライアントが SMB 署名をサポートしていないターゲット サーバーと通信できなくなります。

      • すべての署名されていない SMB 通信を無視するようにコンピューターを構成すると、以前のプログラムとオペレーティング システムが接続できなくなります。

    5. シンボリック名:

      RequireSMBSignRdr

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature

    7. 互換性の問題の例

      • Windows NT 4.0: NLTEST または NETDOM を使用して、Windows Server 2003 ドメインと Windows NT 4.0 ドメイン間の信頼のセキュリティで保護されたチャネルをリセットできず、"アクセス拒否" というエラー メッセージが表示されます。

      • Windows XP: Windows XP クライアントから Windows 2000 ベースのサーバーにファイルをコピーし、Windows Server 2003 ベースのサーバーにコピーすると、時間がかかる場合があります。

      • この設定を有効にしたクライアントからネットワーク ドライブをマップすることはできません。次のエラー メッセージが表示されます。

        このアカウントは、このステーションからログインする権限がありません。

    8. 再起動の要件

      コンピューターを再起動するか、ワークステーション サービスを再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力します。 各コマンドを入力した後、Enter キーを押します。

      net stop ワークステーション
      net start ワークステーション

  6. Microsoft ネットワーク サーバー: 通信にデジタル署名する (常に)

    1. 背景

      • Server Messenger Block (SMB) は、多くの Microsoft オペレーティング システムでサポートされているリソース共有プロトコルです。 これは、ネットワーク基本入出力システム (NetBIOS) とその他の多くのプロトコルの基礎です。 SMB 署名は、データをホストするユーザーとサーバーの両方を認証します。 どちらかの側で認証プロセスが失敗した場合、データ転送は行われません。

        SMB 署名の有効化は、SMB プロトコル ネゴシエーション中に開始されます。 SMB 署名ポリシーは、コンピューターが常にクライアント通信にデジタル署名するかどうかを決定します。

        Windows 2000 SMB 認証プロトコルでは、相互認証がサポートされます。 相互認証は、"中間者" 攻撃を閉じます。 Windows 2000 SMB 認証プロトコルでは、メッセージ認証もサポートされています。 メッセージ認証は、アクティブなメッセージ攻撃を防ぐのに役立ちます。 この認証を行うために、SMB 署名は各 SMB にデジタル署名を配置します。 クライアントとサーバーは、それぞれデジタル署名を検証します。

        SMB 署名を使用するには、SMB 署名を有効にするか、SMB クライアントと SMB サーバーの両方で SMB 署名を要求する必要があります。 サーバーで SMB 署名が有効になっている場合、SMB 署名も有効になっているクライアントは、後続のすべてのセッションでパケット署名プロトコルを使用します。 サーバーで SMB 署名が必要な場合、クライアントが SMB 署名に有効または必須でない限り、クライアントはセッションを確立できません。


        セキュリティの高いネットワークでデジタル署名を有効にすると、クライアントとサーバーの偽装を防ぐことができます。 この種の偽装は、セッションハイジャックと呼ばれます。 クライアントまたはサーバーと同じネットワークにアクセスできる攻撃者は、セッションハイジャック ツールを使用して、進行中のセッションを中断、終了、または盗みます。 攻撃者は、署名されていないサブネット帯域幅マネージャー (SBM) パケットを傍受して変更し、トラフィックを変更し、サーバーが望ましくないアクションを実行できるように転送する可能性があります。 または、攻撃者は正当な認証の後にサーバーまたはクライアントとして攻撃を受け、データへの不正アクセスを取得する可能性があります。

        Windows 2000 Server、Windows 2000 Professional、Windows XP Professional、または Windows Server 2003 を実行しているコンピューターでのファイル共有と印刷共有に使用される SMB プロトコルは、相互認証をサポートします。 相互認証では、セッション乗っ取り攻撃が終了し、メッセージ認証がサポートされます。 そのため、中間者攻撃を防ぎます。 SMB 署名では、各 SMB にデジタル署名を配置することで、この認証が提供されます。 次に、クライアントとサーバーが署名を確認します。

      • 別の対策として、IPSec を使用してデジタル署名を有効にして、すべてのネットワーク トラフィックを保護することができます。 IPSec 暗号化と署名のためのハードウェア ベースのアクセラレータがあり、サーバーの CPU からのパフォーマンスへの影響を最小限に抑えるために使用できます。 SMB 署名に使用できるアクセラレータはありません。

      • Windows 95、Windows 98、および Windows 98 Second Edition では、ディレクトリ サービス クライアントは NTLM 認証を使用して Windows Server 2003 サーバーで認証するときに SMB 署名を使用します。 ただし、これらのクライアントは、NTLMv2 認証を使用してこれらのサーバーで認証するときに SMB 署名を使用しません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。 詳細については、項目 10: "ネットワーク セキュリティ: Lan Manager 認証レベル" を参照してください。

    2. 危険な構成

      有害な構成設定を次に示します。Microsoft ネットワーク サーバーを有効にします。互換性のない Windows ベースのコンピューターと、ローカルドメインまたは外部ドメイン内のサードパーティのオペレーティング システム ベースのクライアント コンピューターからアクセスされるサーバーとドメイン コントローラーの通信 (常に) 設定にデジタル署名します。

    3. この設定を有効にする理由

      • レジストリまたはグループ ポリシー設定を使用して直接この設定を有効にするすべてのクライアント コンピューターでは、SMB 署名がサポートされます。 つまり、この設定が有効になっているすべてのクライアント コンピューターは、DS クライアントがインストールされた Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP Professional、または Windows Server 2003 のいずれかを実行します。

      • Microsoft ネットワーク サーバー: デジタル署名通信 (常に) が無効になっている場合、SMB 署名は完全に無効になります。 すべての SMB 署名を完全に無効にすると、コンピューターはセッションハイジャック攻撃に対して脆弱になります。

    4. この設定を無効にする理由

      • この設定を有効にすると、クライアント コンピューターでのファイル コピーとネットワーク パフォーマンスが低下する可能性があります。

      • この設定を有効にすると、SMB 署名をネゴシエートできないクライアントがサーバーやドメイン コントローラーと通信できなくなります。 これにより、ドメインへの参加、ユーザーとコンピューターの認証、プログラムによるネットワーク アクセスなどの操作が失敗します。

    5. シンボリック名:

      RequireSMBSignServer

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)

    7. 互換性の問題の例

      • Windows 95: Directory Services (DS) クライアントがインストールされていない Windows 95 クライアントは、ログオン認証に失敗し、次のエラー メッセージが表示されます。

        指定したドメイン パスワードが正しくないか、ログオン サーバーへのアクセスが拒否されました。

      • Windows NT 4.0: Service Pack 3 (SP3) より前のバージョンの Windows NT 4.0 を実行しているクライアント コンピューターは、ログオン認証に失敗し、次のエラー メッセージが表示されます。

        システムがログオンできませんでした。 ユーザー名とドメインが正しいことを確認し、もう一度パスワードを入力します。

        Microsoft 以外の一部の SMB サーバーでは、認証中に暗号化されていないパスワード交換のみがサポートされます。 (これらの交換は、"プレーンテキスト" エクスチェンジとも呼ばれます。 Windows NT 4.0 SP3 以降のバージョンでは、特定のレジストリ エントリを追加しない限り、SMB リダイレクターは認証中に暗号化されていないパスワードを SMB サーバーに送信しません。
        Windows NT 4.0 SP 3 以降のシステムで SMB クライアントの暗号化されていないパスワードを有効にするには、レジストリを次のように変更します:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Rdr\Parameters

        値の名前: EnablePlainTextPassword

        データ型: REG_DWORD

        データ: 1

         

      • Windows Server 2003: 既定では、Windows Server 2003 を実行するドメイン コントローラーのセキュリティ設定は、悪意のあるユーザーによるドメイン コントローラー通信の傍受や改ざんを防ぐために構成されています。 ユーザーが Windows Server 2003 を実行するドメイン コントローラーと正常に通信するには、クライアント コンピューターで SMB 署名と暗号化、またはセキュリティで保護されたチャネル トラフィック署名の両方を使用する必要があります。 既定では、Service Pack 2 (SP2) 以前のインストール済みWindows NT 4.0 を実行するクライアントと、Windows 95 を実行するクライアントでは SMB パケット署名が有効になっていません。 そのため、これらのクライアントは Windows Server 2003 ベースのドメイン コントローラーに対して認証できない可能性があります。

      • Windows 2000 と Windows Server 2003 のポリシー設定: 特定のインストールのニーズと構成に応じて、Microsoft Management Console グループ ポリシー エディター スナップイン階層で、必要なスコープの最も低いエンティティに次のポリシー設定を設定することをお勧めします。

        • コンピューターの構成\Windows セキュリティ設定\セキュリティ オプション

        • 暗号化されていないパスワードを送信してサード パーティの SMB サーバーに接続する (この設定は Windows 2000 用)

        • Microsoft ネットワーク クライアント: 暗号化されていないパスワードをサード パーティの SMB サーバーに送信します (この設定は Windows Server 2003 用です)


        注: 古い Samba バージョンなど、一部のサードパーティの CIFS サーバーでは、暗号化されたパスワードを使用できません。

      • 次のクライアントは、Microsoft ネットワーク サーバーと互換性がありません。通信にデジタル署名 (常に) 設定します。

        • Apple Computer, Inc., Mac OS X クライアント

        • Microsoft MS-DOS ネットワーク クライアント (Microsoft LAN Manager など)

        • Microsoft Windows for ワークグループ クライアント

        • DS クライアントがインストールされていない Microsoft Windows 95 クライアント

        • MICROSOFT Windows NT SP3 以降がインストールされていない 4.0 ベースのコンピューター

        • Novell Netware 6 CIFS クライアント

        • SMB 署名をサポートしていない SAMBA SMB クライアント

    8. 再起動の要件

      コンピューターを再起動するか、サーバー サービスを再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力します。 各コマンドを入力した後、Enter キーを押します。

      net stop サーバー
      net start サーバー

  7. ネットワーク アクセス: 匿名 SID/名前変換を許可する

    1. 背景

      [ネットワーク アクセス: 匿名 SID/名前変換を許可する] セキュリティ設定は、匿名ユーザーが別のユーザーのセキュリティ識別番号 (SID) 属性を要求できるかどうかを決定します。

    2. 危険な構成

      ネットワーク アクセスを有効にする: 匿名 SID/名前変換を許可する設定は有害な構成設定です。

    3. この設定

      を有効にする理由 [ネットワーク アクセス: 匿名 SID/名前変換を許可する] 設定が無効になっている場合、以前のオペレーティング システムまたはアプリケーションが Windows Server 2003 ドメインと通信できない可能性があります。 たとえば、次のオペレーティング システム、サービス、またはアプリケーションが動作しない可能性があります。

      • Windows NT 4.0 ベースのリモート アクセス サービス サーバー

      • Windows NT 3.x ベースのコンピューターまたは Windows NT 4.0 ベースのコンピューターで実行されている Microsoft SQL Server

      • Windows NT 3.x ドメインまたは Windows NT 4.0 ドメインにある Windows 2000 ベースのコンピューターで実行されているリモート アクセス サービス

      • Windows NT 3.x ドメインまたは Windows NT 4.0 ドメインにある Windows 2000 ベースのコンピューターで実行されているSQL Server

      • Windows NT 4.0 リソース ドメインのユーザーで、Windows Server 2003 ドメイン コントローラーを含むアカウント ドメインからユーザー アカウントにファイル、共有フォルダー、レジストリ オブジェクトにアクセスするアクセス許可を付与する必要がある

    4. この設定

      を無効にする理由 この設定が有効になっている場合、悪意のあるユーザーは、アカウントの名前が変更された場合でも、既知の Administrators SID を使用して組み込みの管理者アカウントの実名を取得できます。 そのユーザーは、アカウント名を使用してパスワード推測攻撃を開始できます。

    5. シンボリック名: N/A

    6. レジストリ パス: なし。 パスは UI コードで指定されます。

    7. 互換性の問題

      の例Windows NT 4.0: Windows NT 4.0 リソース ドメイン内のコンピューターでは、共有フォルダー、共有ファイル、レジストリ オブジェクトを含むリソースが、Windows Server 2003 ドメイン コントローラーを含むアカウント ドメインに存在するセキュリティ プリンシパルでセキュリティで保護されている場合、ACL エディターに "アカウント不明" エラー メッセージが表示されます。

  8. ネットワーク アクセス: SAM アカウントの匿名列挙を許可しない

    1. 背景

      • [ネットワーク アクセス]: SAM アカウントの匿名列挙を許可しない] 設定は、コンピューターへの匿名接続に対して付与される追加のアクセス許可を決定します。 Windows を使用すると、匿名ユーザーは、ワークステーションとサーバーの Security Accounts Manager (SAM) アカウントの名前やネットワーク共有の名前を列挙するなど、特定のアクティビティを実行できます。 たとえば、管理者はこれを使用して、相互信頼を維持しない信頼されたドメイン内のユーザーにアクセス権を付与できます。 セッションが行われると、匿名ユーザーは、[ネットワーク アクセス] の設定に基づいて [Everyone] グループに付与されるのと同じアクセス権を持つ場合があります。[すべてのユーザーのアクセス許可を匿名ユーザー設定またはオブジェクトの随意アクセス制御リスト (DACL)] に適用できます。

        通常、匿名接続は、SMB セッションのセットアップ中に以前のバージョンのクライアント (下位レベルのクライアント) によって要求されます。 このような場合、ネットワーク トレースは、SMB プロセス ID (PID) が Windows 2000 の0xFEFFやWindows NTの0xCAFEなどのクライアント リダイレクターであることを示します。 RPC は匿名接続を試みる場合もあります。

      • 重要: この設定は、ドメイン コントローラーには影響しません。 ドメイン コントローラーでは、"Windows 2000 以前の互換性のあるアクセス" に "NT AUTHORITY\ANONYMOUS LOGON" が存在することで、この動作が制御されます。

      • Windows 2000 では、匿名接続の追加制限と呼ばれる同様の設定が RestrictAnonymous レジストリ値を管理します。 この値の場所は次のとおりです。

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA  

    2. 危険な構成

      ネットワーク アクセスを有効にする: SAM アカウントの匿名列挙を許可しない設定は、互換性の観点から有害な構成設定です。 無効にすると、セキュリティの観点から有害な構成設定になります。

    3. この設定

      を有効にする理由 承認されていないユーザーは、匿名でアカウント名を一覧表示し、その情報を使用してパスワードを推測したり、ソーシャル エンジニアリング攻撃を実行したりできます。 ソーシャル エンジニアリングは専門用語であり、ユーザーが自分のパスワードや何らかの形式のセキュリティ情報を明らかにすることを意味します。

    4. この設定

      を無効にする理由 この設定が有効になっている場合、Windows NT 4.0 ドメインで信頼を確立することはできません。 この設定では、サーバー上のリソースを使用しようとしている下位レベルのクライアント (Windows NT 3.51 クライアントや Windows 95 クライアントなど) にも問題が発生します。

    5. シンボリック名:


      RestrictAnonymousSAM

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)

    7. 互換性の問題の例

    • SMS ネットワーク探索では、オペレーティング システム情報を取得できず、OperatingSystemNameandVersion プロパティに "不明" と書き込まれます。

    • Windows 95、Windows 98: Windows 95 クライアントと Windows 98 クライアントは、パスワードを変更できません。

    • Windows NT 4.0: Windows NT 4.0 ベースのメンバー コンピューターは認証できません。

    • Windows 95、Windows 98: Windows 95 ベースのコンピューターと Windows 98 ベースのコンピューターは、Microsoft ドメイン コントローラーで認証できません。

    • Windows 95、Windows 98: Windows 95 ベースおよび Windows 98 ベースのコンピューターのユーザーは、ユーザー アカウントのパスワードを変更できません。

  9. ネットワーク アクセス: SAM アカウントと共有の匿名列挙を許可しない

    1. 背景

      • ネットワーク アクセス: SAM アカウントと共有の匿名列挙を許可しない設定 (RestrictAnonymous とも呼ばれます) は、Security Accounts Manager (SAM) アカウントと共有の匿名列挙を許可するかどうかを決定します。 Windows を使用すると、匿名ユーザーは、ドメイン アカウント (ユーザー、コンピューター、グループ) の名前やネットワーク共有の名前の列挙など、特定のアクティビティを実行できます。 これは、たとえば、管理者が相互信頼を維持しない信頼されたドメイン内のユーザーにアクセス権を付与する場合などに便利です。 SAM アカウントと共有の匿名列挙を許可しない場合は、この設定を有効にします。

      • Windows 2000 では、匿名接続の追加制限と呼ばれる同様の設定が RestrictAnonymous レジストリ値を管理します。 この値の場所は次のとおりです。

        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

    2. 危険な構成

      ネットワーク アクセスを有効にする: SAM アカウントの匿名列挙を許可しないし、共有設定は有害な構成設定です。

    3. この設定を有効にする理由

      • ネットワーク アクセスを有効にする: SAM アカウントと共有の匿名列挙を許可しない設定では、匿名アカウントを使用しているユーザーとコンピューターによる SAM アカウントと共有の列挙が禁止されます。

    4. この設定を無効にする理由

      • この設定が有効になっている場合、承認されていないユーザーは匿名でアカウント名を一覧表示し、その情報を使用してパスワードを推測したり、ソーシャル エンジニアリング攻撃を実行したりできます。 ソーシャル エンジニアリングは専門用語であり、ユーザーが自分のパスワードや何らかの形式のセキュリティ情報を明らかにすることをだまし取ります。

      • この設定が有効になっている場合、Windows NT 4.0 ドメインで信頼を確立することはできません。 この設定では、サーバー上のリソースを使用しようとしているWindows NT 3.51 クライアントや Windows 95 クライアントなどの下位レベルのクライアントでも問題が発生します。

      • 信頼しているドメインの管理者は他のドメインのアカウントのリストを列挙できないため、リソース ドメインのユーザーにアクセス権を付与することは不可能です。 ファイル サーバーと印刷サーバーに匿名でアクセスするユーザーは、それらのサーバー上の共有ネットワーク リソースを一覧表示できません。 ユーザーは、共有フォルダーとプリンターの一覧を表示する前に認証する必要があります。

    5. シンボリック名:

      RestrictAnonymous

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous

    7. 互換性の問題の例

      • Windows NT 4.0: ユーザーのドメイン コントローラーで RestrictAnonymous が有効になっている場合、ユーザーはパスワードを Windows NT 4.0 ワークステーションから変更できません。

      • Windows NT 4.0: 信頼された Windows 2000 ドメインのユーザーまたはグローバル グループを User Manager の Windows NT 4.0 ローカル グループに追加すると失敗し、次のエラー メッセージが表示されます。

        現在、ログオン要求を処理できるログオン サーバーはありません。

      • Windows NT 4.0: Windows NT 4.0 ベースのコンピューターは、セットアップ中またはドメイン参加ユーザー インターフェイスを使用してドメインに参加できません。

      • Windows NT 4.0: Windows NT 4.0 リソース ドメインで下位レベルの信頼を確立すると失敗します。 信頼されたドメインで RestrictAnonymous が有効になっている場合、次のエラー メッセージが表示されます。

        このドメインのドメイン コントローラーが見つかりませんでした。

      • Windows NT 4.0: Windows NT 4.0 ベースのターミナル サーバー コンピューターにログオンするユーザーは、ドメインの User Manager で定義されているホーム ディレクトリではなく、既定のホーム ディレクトリにマップされます。

      • Windows NT 4.0: Windows NT 4.0 バックアップ ドメイン コントローラー (BDC) では、Net Logon サービスを開始したり、バックアップ ブラウザーの一覧を取得したり、Windows 2000 または同じドメイン内の Windows Server 2003 ドメイン コントローラーから SAM データベースを同期したりすることはできません。

      • Windows 2000: Windows NT 4.0 ドメインの Windows 2000 ベースのメンバー コンピューターは、クライアント コンピューターのローカル セキュリティ ポリシーで [明示的に匿名アクセス許可のないアクセス許可なし] 設定が有効になっている場合、外部ドメイン内のプリンターを表示できません。

      • Windows 2000: Windows 2000 ドメイン ユーザーは Active Directory からネットワーク プリンターを追加できません。ただし、ツリー ビューからプリンターを選択すると、プリンターを追加できます。

      • Windows 2000: Windows 2000 ベースのコンピューターでは、ACL エディターでは、信頼できる Windows NT 4.0 ドメインのユーザーまたはグローバル グループを追加できません。

      • ADMT バージョン 2: Active Directory 移行ツール (ADMT) バージョン 2 を使用してフォレスト間で移行されたユーザー アカウントのパスワード移行は失敗します。

        詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示してください。

        322981 ADMTv2 を使用してフォレスト間のパスワード移行をトラブルシューティングする方法

      • Outlook クライアント: グローバル アドレス一覧は、Microsoft Exchange Outlook クライアントには空で表示されます。

      • SMS: Microsoft Systems Management Server (SMS) ネットワーク検出では、オペレーティング システム情報を取得できません。 そのため、探索データ レコード (DDR) の SMS DDR プロパティの OperatingSystemNameandVersion プロパティに "Unknown" が書き込まれます。

      • SMS: SMS 管理者ユーザー ウィザードを使用してユーザーとグループを参照すると、ユーザーやグループは表示されません。 さらに、高度なクライアントは管理ポイントと通信できません。 管理ポイントには匿名アクセスが必要です。

      • SMS: SMS 2.0 のネットワーク検出機能と、トポロジ、クライアント、およびクライアント オペレーティング システムのネットワーク検出オプションがオンになっているリモート クライアント インストールでネットワーク検出機能を使用している場合、コンピューターは検出される可能性がありますが、インストールされていない可能性があります。

  10. ネットワーク セキュリティ: Lan Manager 認証レベル

    1. 背景

      LAN Manager (LM) 認証は、ドメインへの参加、ネットワーク リソースへのアクセス、ユーザーまたはコンピューターの認証など、ネットワーク操作のために Windows クライアントを認証するために使用されるプロトコルです。 LM 認証レベルは、クライアントコンピューターとサーバー コンピューターの間でネゴシエートされるチャレンジ/応答認証プロトコルを決定します。 具体的には、LM 認証レベルによって、クライアントがネゴシエートしようとする認証プロトコル、またはサーバーが受け入れる認証プロトコルが決まります。 LmCompatibilityLevel に設定された値によって、ネットワーク ログオンに使用されるチャレンジ/応答認証プロトコルが決まります。 この値は、クライアントが使用する認証プロトコルのレベル、ネゴシエートされたセッション セキュリティのレベル、およびサーバーが受け入れる認証のレベルに影響します。

      使用可能な設定は次のとおりです。

      設定

      説明

      0

      LM & NTLM 応答を送信する

      クライアントでは LM 認証と NTLM 認証が使用され、NTLMv2 セッション セキュリティは使用されません。 ドメイン コントローラーは、LM、NTLM、および NTLMv2 認証を受け入れます。

      1

      LM & NTLM を送信する - ネゴシエートされた場合は NTLMv2 セッション セキュリティを使用する

      クライアントは LM 認証と NTLM 認証を使用し、サーバーでサポートされている場合は NTLMv2 セッション セキュリティを使用します。 ドメイン コントローラーは、LM、NTLM、および NTLMv2 認証を受け入れます。

      2

      NTLM 応答のみを送信する

      クライアントは NTLM 認証のみを使用し、サーバーでサポートされている場合は NTLMv2 セッション セキュリティを使用します。 ドメイン コントローラーは、LM、NTLM、および NTLMv2 認証を受け入れます。

      3

      NTLMv2 応答のみを送信する

      クライアントは NTLMv2 認証のみを使用し、サーバーでサポートされている場合は NTLMv2 セッション セキュリティを使用します。 ドメイン コントローラーは、LM、NTLM、および NTLMv2 認証を受け入れます。

      4

      NTLMv2 応答のみを送信する/LM を拒否する

      クライアントは NTLMv2 認証のみを使用し、サーバーでサポートされている場合は NTLMv2 セッション セキュリティを使用します。 ドメイン コントローラーは LM を拒否し、NTLM 認証と NTLMv2 認証のみを受け入れます。

      5

      NTLMv2 応答のみを送信する/LM & NTLM を拒否する

      クライアントは NTLMv2 認証のみを使用し、サーバーでサポートされている場合は NTLMv2 セッション セキュリティを使用します。 ドメイン コントローラーは LM と NTLM を拒否し、NTLMv2 認証のみを受け入れます。

      注: Windows 95、Windows 98、および Windows 98 Second Edition では、ディレクトリ サービス クライアントは NTLM 認証を使用して Windows Server 2003 サーバーで認証するときに SMB 署名を使用します。 ただし、これらのクライアントは、NTLMv2 認証を使用してこれらのサーバーで認証するときに SMB 署名を使用しません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。

      LM 認証レベルを確認します。NTLM を許可するようにサーバーのポリシーを変更するか、NTLMv2 をサポートするようにクライアント コンピューターを構成する必要があります。

      ポリシーが (5) NTLMv2 応答の送信のみ\接続先のコンピューターで LM & NTLM を拒否する] に設定されている場合は、そのコンピューターの設定を下げるか、接続元のコンピューターにあるのと同じ設定にセキュリティを設定する必要があります。

      LAN マネージャー認証レベルを変更して、クライアントとサーバーを同じレベルに設定できる正しい場所を見つけます。 LAN マネージャー認証レベルを設定しているポリシーを見つけたら、以前のバージョンの Windows を実行しているコンピューターとの間で接続する場合は、少なくとも (1) [LM & NTLM の送信] に値を下げます。ネゴシエートされた場合は NTLM バージョン 2 セッション セキュリティを使用します。 互換性のない設定の影響の 1 つは、サーバーで NTLMv2 (値 5) が必要な場合に、クライアントが LM と NTLMv1 のみを使用するように構成されている場合 (値 0) です。認証を試みるユーザーは、不正なパスワードを持ち、不正なパスワード数をインクリメントするログオン エラーが発生します。 アカウントのロックアウトが構成されている場合、ユーザーは最終的にロックアウトされる可能性があります。

      たとえば、ドメイン コントローラーを調べる必要がある場合や、ドメイン コントローラーのポリシーを調べる必要がある場合があります。

      ドメイン コントローラー

      を確認する 注: すべてのドメイン コントローラーで次の手順を繰り返す必要がある場合があります。

      1. [ スタート] ボタンをクリックし、[ プログラム] をポイントして、[ 管理ツール] をクリックします。

      2. [ ローカル セキュリティ設定] で、[ ローカル ポリシー] を展開します。

      3. [ セキュリティ オプション] をクリックします。

      4. [ネットワーク セキュリティ: LAN マネージャー認証レベル] をダブルクリックし、一覧の値をクリックします。


      有効な設定とローカル設定が同じ場合、ポリシーはこのレベルで変更されています。 設定が異なる場合は、ドメイン コントローラーのポリシーを確認して、ネットワーク セキュリティ: LAN マネージャーの認証レベル設定が定義されているかどうかを確認する必要があります。 定義されていない場合は、ドメイン コントローラーのポリシーを調べます。

      ドメイン コントローラーのポリシーを調べる

      1. [ スタート] ボタンをクリックし、[ プログラム] をポイントして、[ 管理ツール] をクリックします。

      2. ドメイン コントローラー のセキュリティ ポリシーで、[セキュリティ設定] を展開し、[ローカル ポリシー] を展開します。

      3. [ セキュリティ オプション] をクリックします。

      4. [ネットワーク セキュリティ: LAN マネージャー認証レベル] をダブルクリックし、一覧の値をクリックします。


      メモ

      • また、LAN マネージャー認証レベルを構成する必要がある場所を決定するために、サイト レベル、ドメイン レベル、または組織単位 (OU) レベルでリンクされているポリシーを確認する必要がある場合もあります。

      • 既定のドメイン ポリシーとしてグループ ポリシー設定を実装する場合、ポリシーはドメイン内のすべてのコンピューターに適用されます。

      • 既定のドメイン コントローラーのポリシーとしてグループ ポリシー設定を実装する場合、ポリシーはドメイン コントローラーの OU 内のサーバーにのみ適用されます。

      • ポリシー アプリケーション階層で必要なスコープの最も低いエンティティに LAN マネージャー認証レベルを設定することをお勧めします。

      Windows Server 2003 には、NTLMv2 のみを使用する新しい既定の設定があります。 既定では、Windows Server 2003 および Windows 2000 Server SP3 ベースのドメイン コントローラーでは、"Microsoft ネットワーク サーバー: 通信にデジタル署名 (常に)" ポリシーが有効になっています。 この設定では、SMB サーバーが SMB パケット署名を実行する必要があります。 Windows Server 2003 の変更が行われた理由は、どの組織のドメイン コントローラー、ファイル サーバー、ネットワーク インフラストラクチャ サーバー、Web サーバーでも、セキュリティを最大化するために異なる設定が必要であるためです。

      ネットワークに NTLMv2 認証を実装する場合は、ドメイン内のすべてのコンピューターがこの認証レベルを使用するように設定されていることを確認する必要があります。 Windows 95 または Windows 98 および Windows NT 4.0 用の Active Directory クライアント拡張機能を適用する場合、クライアント拡張機能は NTLMv2 で使用できる強化された認証機能を使用します。 次のいずれかのオペレーティング システムを実行しているクライアント コンピューターは Windows 2000 グループ ポリシー オブジェクトの影響を受けないため、これらのクライアントを手動で構成する必要があります。

      • Microsoft Windows NT 4.0

      • Microsoft Windows Millennium Edition

      • Microsoft Windows 98

      • Microsoft Windows 95

      注: ネットワーク セキュリティを有効にした場合 : 次のパスワード変更ポリシーに LAN マネージャー ハッシュ値を格納しない か、 NoLMHash レジストリ キーを設定します。ディレクトリ サービス クライアントがインストールされていない Windows 95 ベースおよび Windows 98 ベースのクライアントは、パスワード変更後にドメインにログオンできません。

      Novell Netware 6 などの多くのサード パーティの CIFS サーバーは、NTLMv2 を認識せず、NTLM のみを使用しています。 そのため、2 より大きいレベルでは接続は許可されません。 また、拡張セッション セキュリティを使用しないサード パーティの SMB クライアントもあります。 このような場合、リソース サーバーの LmCompatiblityLevel は考慮されません。 その後、サーバーはこのレガシ要求をパックし、ユーザー ドメイン コントローラーに送信します。 次に、ドメイン コントローラーの設定によって、要求の検証に使用されるハッシュと、それらがドメイン コントローラーのセキュリティ要件を満たしているかどうかを決定します。

       

      299656 Windows が Active Directory データベースとローカル SAM データベースにパスワードの LAN マネージャー ハッシュを格納できないようにする方法
       

      2701704監査イベントは、NTLMv2 の代わりに NTLMv1 として認証パッケージを示します LM 認証レベルの詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示します。

      239869 NTLM 2 認証を有効にする方法
       

    2. 危険な構成

      有害な構成設定を次に示します。

      • クリアテキストでパスワードを送信し、NTLMv2 ネゴシエーションを拒否する非回帰設定

      • 互換性のないクライアントまたはドメイン コントローラーが共通の認証プロトコルをネゴシエートできないようにする制限付き設定

      • Service Pack 4 (SP4) より前のバージョンの Windows NT 4.0 を実行しているメンバー コンピューターとドメイン コントローラーで NTLMv2 認証を要求する

      • Windows 95 クライアントまたは Windows Directory Services クライアントがインストールされていない Windows 98 クライアントで NTLMv2 認証を要求する。

      • Windows Server 2003 または Windows 2000 Service Pack 3 ベースのコンピューターの Microsoft Management Console グループ ポリシー エディター スナップインで [NTLMv2 セッション セキュリティが必要] チェック ボックスをオンにし、LAN マネージャー認証レベルを 0 に下げると、2 つの設定が競合し、Secpol.msc ファイルまたは GPEdit.msc ファイルに次のエラー メッセージが表示される場合があります。

        Windows では、ローカル ポリシー データベースを開くことができません。 データベースを開こうとしたときに、不明なエラーが発生しました。

        セキュリティ構成と分析ツールの詳細については、Windows 2000 または Windows Server 2003 のヘルプ ファイルを参照してください。

    3. この設定を変更する理由

      • 組織内のクライアントとドメイン コントローラーでサポートされている最も低い一般的な認証プロトコルを増やす必要があります。

      • セキュリティで保護された認証がビジネス要件である場合は、LM と NTLM プロトコルのネゴシエーションを禁止する必要があります。

    4. この設定

      を無効にする理由 クライアントまたはサーバーの認証要件 (またはその両方) は、共通プロトコルでの認証が行えない時点まで増加しています。

    5. シンボリック名:

      LmCompatibilityLevel

    6. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel

    7. 互換性の問題の例

      • Windows Server 2003: 既定では、Windows Server 2003 NTLMv2 [NTLM 応答の送信] 設定が有効になっています。 そのため、Windows Server 2003 は、最初のインストール後に、Windows NT 4.0 ベースのクラスターまたは OS/2 Lanserver などの LanManager V2.1 ベースのサーバーに接続しようとすると、"アクセス拒否" エラー メッセージを受け取ります。 この問題は、以前のバージョンのクライアントから Windows Server 2003 ベースのサーバーに接続しようとした場合にも発生します。

      • Windows 2000 セキュリティ ロールアップ パッケージ 1 (SRP1) をインストールします。SRP1 では NTLM バージョン 2 (NTLMv2) が強制されます。 このロールアップ パッケージは、Windows 2000 Service Pack 2 (SP2) のリリース後にリリースされました。
         

      • Windows 7 および Windows Server 2008 R2: Novell Netware 6 や Linux ベースの Samba サーバーなど、多くのサード パーティ製 CIFS サーバーは NTLMv2 を認識せず、NTLM のみを使用します。 したがって、"2" より大きいレベルでは接続は許可されません。 このバージョンのオペレーティング システムでは、LmCompatibilityLevel の既定値が "3" に変更されました。 そのため、Windows をアップグレードすると、これらのサード パーティ製のファイルが動作しなくなる可能性があります。

      • Microsoft Outlook クライアントは、既にドメインにログオンしている場合でも、資格情報の入力を求められる場合があります。 ユーザーが資格情報を指定すると、Windows 7 と Windows Server 2008 R2 というエラー メッセージが表示されます。

        指定されたログオン資格情報が正しくありませんでした。 ユーザー名とドメインが正しいことを確認し、もう一度パスワードを入力します。

        Outlook を起動すると、ログオン ネットワーク セキュリティ設定がパススルーまたはパスワード認証に設定されている場合でも、資格情報の入力を求められる場合があります。 正しい資格情報を入力すると、次のエラー メッセージが表示される場合があります。

        指定されたログイン資格情報が正しくありませんでした。

        ネットワーク モニター トレースでは、グローバル カタログによってリモート プロシージャコール (RPC) エラーが発行され、状態が0x5示される場合があります。 0x5の状態は"アクセス拒否" を意味します。

      • Windows 2000: ネットワーク モニター キャプチャでは、NETBIOS over TCP/IP (NetBT) サーバー メッセージ ブロック (SMB) セッションで次のエラーが表示される場合があります。

        SMB R Search Directory Dos エラー、 (5) ACCESS_DENIED (109) STATUS_LOGON_FAILURE (91) 無効なユーザー識別子

      • Windows 2000: NTLMv2 レベル 2 以降の Windows 2000 ドメインが Windows NT 4.0 ドメインによって信頼されている場合、リソース ドメイン内の Windows 2000 ベースのメンバー コンピューターで認証エラーが発生する可能性があります。

      • Windows 2000 と Windows XP: 既定では、Windows 2000 と Windows XP は LAN Manager 認証レベルのローカル セキュリティ ポリシー オプションを 0 に設定します。 0 の設定は、"LM 応答と NTLM 応答の送信" を意味します。

        4.0 ベースのクラスター Windows NT管理には LM を使用する必要があることに注意してください。

      • Windows 2000: Windows 2000 クラスタリングは、両方のノードが Windows NT 4.0 Service Pack 6a (SP6a) ドメインの一部である場合、参加ノードを認証しません。

      • IIS ロックダウン ツール (HiSecWeb) は LMCompatibilityLevel 値を 5 に設定し、RestrictAnonymous 値を 2 に設定します。

      • Macintosh

        用サービス ユーザー認証モジュール (UAM): Microsoft UAM (ユーザー認証モジュール) は、Windows AFP (AppleTalk ファイリング プロトコル) サーバーへのログオンに使用するパスワードを暗号化する方法を提供します。 Apple ユーザー認証モジュール (UAM) は、最小限またはまったく暗号化を提供しません。 そのため、パスワードは LAN またはインターネットで簡単に傍受できます。 UAM は必須ではありませんが、Services For Macintosh を実行する Windows 2000 サーバーに暗号化された認証を提供します。 このバージョンには、NTLMv2 128 ビット暗号化認証と MacOS X 10.1 互換リリースのサポートが含まれています。

        既定では、Windows Server 2003 Services for Macintosh サーバーでは Microsoft 認証のみが許可されます。
         

      • Windows Server 2008、Windows Server 2003、Windows XP、Windows 2000: LMCompatibilityLevel 値を 0 または 1 に構成し、NoLMHash 値を 1 に構成した場合、アプリケーションとコンポーネントは NTLM 経由でアクセスを拒否される可能性があります。 この問題は、コンピューターが LM を有効にするように構成されているが、LM で保存されたパスワードを使用しないように構成されているために発生します。

        NoLMHash 値を 1 に構成する場合は、LMCompatibilityLevel 値を 2 以上に構成する必要があります。

  11. ネットワーク セキュリティ: LDAP クライアント署名の要件

    1. 背景

      ネットワーク セキュリティ: LDAP クライアント署名要件の設定は、Lightweight Directory Access Protocol (LDAP) BIND 要求を発行するクライアントに代わって要求されるデータ署名のレベルを次のように決定します。

      • なし: LDAP BIND 要求は、呼び出し元が指定したオプションで発行されます。

      • 署名のネゴシエート: Secure Sockets Layer/Transport Layer Security (SSL/TLS) が開始されていない場合、LDAP BIND 要求は、呼び出し元が指定したオプションに加えて LDAP データ署名オプションを設定して開始されます。 SSL/TLS が開始されている場合、LDAP BIND 要求は呼び出し元が指定したオプションを使用して開始されます。

      • 署名が必要: これは、ネゴシエート署名と同じです。 ただし、LDAP サーバーの中間 saslBindInProgress 応答が LDAP トラフィック署名が必要であることを示していない場合、呼び出し元は LDAP BIND コマンド要求が失敗したことを通知します。

    2. 危険な構成

      ネットワーク セキュリティを有効にする: LDAP クライアント署名要件設定は有害な構成設定です。 サーバーに LDAP 署名が必要な場合は、クライアントで LDAP 署名も構成する必要があります。 LDAP 署名を使用するようにクライアントを構成しないと、サーバーとの通信が妨されます。 これにより、ユーザー認証、グループ ポリシー設定、ログオン スクリプト、およびその他の機能が失敗します。

    3. この設定

      を変更する理由 署名されていないネットワーク トラフィックは、侵入者がクライアントとサーバーの間のパケットをキャプチャし、それらを変更してサーバーに転送する中間者攻撃の影響を受けやすくなります。 これが LDAP サーバーで発生した場合、攻撃者は LDAP クライアントからの誤ったクエリに基づいてサーバーが応答する可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークのこのリスクを減らすことができます。 さらに、IPSec 認証ヘッダーを使用して、すべてのネットワーク パケットにデジタル署名を要求することで、あらゆる種類の中間者攻撃を防ぐのに役立ちます。

    4. シンボリック名:

      LDAPClientIntegrity

    5. レジストリ パス:

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity

  12. イベント ログ: セキュリティ ログの最大サイズ

    1. 背景

      [イベント ログ: 最大セキュリティ ログ サイズ] セキュリティ設定では、セキュリティ イベント ログの最大サイズを指定します。 このログの最大サイズは 4 GB です。 この設定を見つけるには、[Windows 設定] を展開
      し、[セキュリティ設定] を展開します。

    2. 危険な構成

      有害な構成設定を次に示します。

      • [監査: セキュリティ監査をログに記録できない場合はシステムをすぐにシャットダウンする] 設定が有効になっている場合に、セキュリティ ログ サイズとセキュリティ ログ保持方法を制限します。 詳細については、この記事の「監査: セキュリティ監査をログに記録できない場合はシステムをすぐにシャットダウンする」セクションを参照してください。

      • 目的のセキュリティ イベントが上書きされるようにセキュリティ ログ サイズを制限する。

    3. この設定

      を増やす理由 ビジネスとセキュリティの要件により、セキュリティ ログのサイズを増やして、追加のセキュリティ ログの詳細を処理したり、セキュリティ ログを長期間保持したりする必要があります。

    4. この設定

      を減らす理由イベント ビューアーログはメモリ マップ ファイルです。 イベント ログの最大サイズは、ローカル コンピューター内の物理メモリの量と、イベント ログ プロセスで使用できる仮想メモリによって制約されます。 イベント ビューアーで使用できる仮想メモリの量を超えてログ サイズを大きくしても、保持されるログ エントリの数は増えません。

    5. 互換性の問題

      の例 Windows 2000: Service Pack 4 (SP4) より前のバージョンの Windows 2000 を実行しているコンピューターは、[イベントを上書きしない (手動でログをクリアする)] オプションがオンになっている場合、イベント ビューアーの [最大ログ サイズ] 設定で指定されたサイズに達する前に、イベント ログ内のイベントのログ記録を停止することがあります。


       

  13. イベント ログ: セキュリティ ログを保持する

    1. 背景

      [イベント ログ: セキュリティ ログの保持] セキュリティ設定によって、セキュリティ ログの "折り返し" メソッドが決まります。 この設定を見つけるには、[ Windows 設定] を展開し、[ セキュリティ設定] を展開します。

    2. 危険な構成

      有害な構成設定を次に示します。

      • ログに記録されたすべてのセキュリティ イベントが上書きされる前に保持できない

      • [最大セキュリティ ログ サイズ] 設定が小さすぎるため、セキュリティ イベントが上書きされるように構成する

      • 監査中にセキュリティ ログのサイズと保持方法を制限する: セキュリティ監査のセキュリティ設定をログに記録できない場合はシステムをすぐにシャットダウンする

    3. この設定

      を有効にする理由 この設定を有効にできるのは、[日単位の イベントの上書き ] 保持方法を選択した場合のみです。 イベントをポーリングするイベント関連付けシステムを使用する場合は、日数がポーリング頻度の少なくとも 3 倍であることを確認します。 失敗したポーリング サイクルを許可するには、これを行います。

  14. ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用できるようにする

    1. 背景

      既定では、[ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用できるようにする] 設定は、Windows Server 2003 で [定義されていません] に設定されています。 既定では、Windows Server 2003 には、Everyone グループに匿名アクセス トークンは含まれません。

    2. 互換性の問題

      の例 次の値

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous [REG_DWORD]=0x0 は、Windows Server 2003 ドメインがアカウント ドメインであり、Windows NT 4.0 ドメインがリソース ドメインである場合に、Windows Server 2003 と Windows NT 4.0 の間で信頼の作成を中断します。 つまり、アカウント ドメインは Windows NT 4.0 で信頼され、リソース ドメインは Windows Server 2003 側で信頼されています。 この動作は、最初の匿名接続後に信頼を開始するプロセスが、Windows NT 4.0 の匿名 SID を含む Everyone トークンを使用して ACL であるために発生します。

    3. この設定

      を変更する理由 この値は、ドメイン コントローラーの OU の GPO を使用して0x1または設定する必要があります。ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用できます。信頼の作成を可能にするために有効にします。

      他のほとんどのセキュリティ設定は、最もセキュリティで保護された状態で0x0に下がらず、値が上がります。 より安全な方法は、すべてのドメイン コントローラーではなく、プライマリ ドメイン コントローラー エミュレーターのレジストリを変更することです。 何らかの理由でプライマリ ドメイン コントローラー エミュレーターロールを移動する場合は、レジストリを新しいサーバーで更新する必要があります。

      この値が設定された後は、再起動が必要です。

    4. レジストリ パス

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous

  15. NTLMv2 認証

    1. セッション セキュリティ

      セッション セキュリティは、クライアント セッションとサーバー セッションの最小セキュリティ標準を決定します。 Microsoft 管理コンソール グループ ポリシー エディター スナップインで、次のセキュリティ ポリシー設定を確認することをお勧めします。

      • コンピューターの設定\Windows 設定\セキュリティ設定\ローカル ポリシー\セキュリティ オプション

      • ネットワーク セキュリティ: NTLM SSP ベース (セキュリティで保護された RPC を含む) サーバーの最小セッション セキュリティ

      • ネットワーク セキュリティ: NTLM SSP ベース (セキュリティで保護された RPC を含む) クライアントの最小セッション セキュリティ

      これらの設定のオプションは次のとおりです。

      • メッセージの整合性を要求する

      • メッセージの機密性を要求する

      • NTLM バージョン 2 のセッション セキュリティを必要とする

      • 128 ビット暗号化が必要

      Windows 7 より前の既定の設定は [要件なし] です。 Windows 7 以降では、セキュリティを強化するために、既定値が 128 ビット暗号化を必要とするように変更されました。 この既定値では、128 ビット暗号化をサポートしていないレガシ デバイスは接続できません。

      これらのポリシーは、クライアントのサーバー上のアプリケーション間通信セッションの最小セキュリティ標準を決定します。

      有効な設定として説明されていますが、NTLM セッション のセキュリティが決定されたときに、メッセージの整合性と機密性を必要とするフラグは使用されないことに注意してください。

      これまで、Windows NTでは、ネットワーク ログオンに対して次の 2 つのチャレンジ/応答認証がサポートされています。

      • LM チャレンジ/応答

      • NTLM バージョン 1 のチャレンジ/応答

      LM を使用すると、インストールされているクライアントとサーバーのベースとの相互運用性が可能になります。 NTLM により、クライアントとサーバー間の接続のセキュリティが強化されます。

      対応するレジストリ キーは次のとおりです。

      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinServerSec"
      HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\"NtlmMinClientSec"

    2. 危険な構成

      この設定は、NTLM を使用してセキュリティで保護されたネットワーク セッションを処理する方法を制御します。 これは、たとえば NTLM で認証された RPC ベースのセッションに影響します。 次のリスクがあります。

      • NTLMv2 よりも古い認証方法を使用すると、使用されるハッシュ方法が単純であるため、通信の攻撃が容易になります。

      • 128 ビット未満の暗号化キーを使用すると、攻撃者はブルートフォース攻撃を使用して通信を中断できます。

時刻同期

時刻同期に失敗しました。 影響を受けるコンピューターでは、時間が 30 分以上オフになります。 クライアント コンピューターのクロックがドメイン コントローラーのクロックと同期されていることを確認します。

SMB 署名の回避策

Windows Server 2003 ベースのドメインで相互運用する Windows NT 4.0 クライアントに Service Pack 6a (SP6a) をインストールすることをお勧めします。 Windows 98 Second Edition ベースのクライアント、Windows 98 ベースのクライアント、Windows 95 ベースのクライアントは、NTLMv2 を実行するためにディレクトリ サービス クライアントを実行する必要があります。 Windows NT 4.0 ベースのクライアントに Windows NT 4.0 SP6 がインストールされていない場合、または Windows 95 ベースのクライアント、Windows 98 ベースのクライアント、および Windows 98SE ベースのクライアントにディレクトリ サービス クライアントがインストールされていない場合は、ドメイン コントローラーの OU で既定のドメイン コントローラーのポリシー設定で SMB 署名を無効にし、このポリシーをホスト ドメイン コントローラーのすべての OU にリンクします。

Windows 98 Second Edition、Windows 98、Windows 95 用の Directory Services クライアントは、NTLM 認証では Windows 2003 サーバーで SMB 署名を実行しますが、NTLMv2 認証では実行されません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。

お勧めしませんが、ドメインで Windows Server 2003 を実行するすべてのドメイン コントローラーで SMB 署名が必要にならないようにすることができます。 このセキュリティ設定を構成するには、次の手順に従います。

  1. 既定のドメイン コントローラーのポリシーを開きます。

  2. コンピューター構成\Windows 設定\セキュリティ設定\ローカル ポリシー\セキュリティ オプション フォルダーを開きます。

  3. [Microsoft ネットワーク サーバー: 通信にデジタル署名する (常に) ポリシー設定] を見つけてクリックし、[無効] をクリックします。

重要: このセクション、メソッド、またはタスクには、レジストリを変更する方法を示す手順が含まれています。 ただし、レジストリを正しく変更しないと、重大な問題が発生する可能性があります。 そのため、次の手順に注意してください。 保護を強化するには、レジストリを変更する前にレジストリをバックアップします。 次に、問題が発生した場合にレジストリを復元できます。 レジストリをバックアップおよび復元する方法の詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を参照してください。

322756 Windows でレジストリをバックアップして復元する方法または、レジストリを変更してサーバーでの SMB 署名を無効にする方法。 これを行うには、次の手順を実行します。

  1. [ スタート] ボタンをクリックし、[ 実行] をクリックし、「regedit」と入力して、[OK] をクリック します

  2. 次のサブキーを見つけてクリックします:HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters

  3. enablesecuritysignature エントリをクリックします。

  4. [ 編集] メニューの [ 変更] をクリックします。

  5. [ 値データ ] ボックスに「0」と入力し、[ OK] をクリックします。

  6. レジストリ エディターを終了します。

  7. コンピューターを再起動するか、サーバー サービスを停止して再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力し、各コマンドを入力した後に Enter キーを押します
    。 net stop サーバー
    net start サーバー

クライアント コンピューターの対応するキーは、次のレジストリ サブキーにあります。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Lanmanworkstation\Parameters 次に、変換されたエラー コード番号を状態コードと、前述の逐語的なエラー メッセージに一覧表示します。

エラー 5


ERROR_ACCESS_DENIED アクセスが拒否されました。

エラー 1326



ERROR_LOGON_FAILURE ログオンエラー: 不明なユーザー名または不適切なパスワード。

エラー 1788



ERROR_TRUSTED_DOMAIN_FAILURE プライマリ ドメインと信頼されたドメインの間の信頼関係が失敗しました。

エラー 1789



ERROR_TRUSTED_RELATIONSHIP_FAILURE このワークステーションとプライマリ ドメインの間の信頼関係が失敗しました。

詳細については、次の記事番号をクリックして、Microsoft サポート技術情報の記事を表示します。

324802 Windows Server 2003 でシステム サービスのセキュリティを設定するようにグループ ポリシーを構成する方法

816585 Windows Server 2003 で定義済みのセキュリティ テンプレートを適用する方法

ヘルプを表示

その他のオプションが必要ですか?

サブスクリプションの特典の参照、トレーニング コースの閲覧、デバイスのセキュリティ保護方法などについて説明します。

コミュニティは、質問をしたり質問の答えを得たり、フィードバックを提供したり、豊富な知識を持つ専門家の意見を聞いたりするのに役立ちます。

この情報は役に立ちましたか?

言語の品質にどの程度満足していますか?
どのような要因がお客様の操作性に影響しましたか?
[送信] を押すと、Microsoft の製品とサービスの改善にフィードバックが使用されます。 IT 管理者はこのデータを収集できます。 プライバシーに関する声明。

フィードバックをいただき、ありがとうございます。

×