概要
ドメイン コントローラーとメンバー コンピューターのセキュリティを強化するために、ローカル ポリシーとグループ ポリシーでセキュリティ設定とユーザー権限の割り当てを変更できます。 ただし、セキュリティ強化の欠点は、クライアント、サービス、プログラムとの非互換性の導入です。
この記事では、Windows Server 2003 ドメインまたは以前のWindows Server ドメインで特定のセキュリティ設定とユーザー権利の割り当てを変更すると、Windows XP または以前のバージョンの Windows を実行しているクライアント コンピューターで発生する可能性がある非互換性について説明します。
Windows 7、Windows Server 2008 R2、Windows Server 2008 のグループ ポリシーについては、次の記事を参照してください。
- Windows 7 については、「IT 担当者向けのグループ ポリシー管理」を参照してください
- Windows 7 および Windows Server 2008 R2 については、「グループ ポリシーの新機能」を参照してください。
注: この記事の残りのコンテンツは、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 ドメインの特定の設定を変更するときに発生する可能性がある非互換性について説明します。
ユーザー権限
次の一覧では、ユーザー権利について説明し、問題の原因となる可能性のある構成設定を特定し、ユーザー権利を適用する理由と、ユーザー権利を削除する理由について説明し、ユーザー権利の構成時に発生する可能性がある互換性の問題の例を示します。
ネットワークからこのコンピューターにアクセスする
背景
リモート Windows ベースのコンピューターと対話するには、ネットワーク ユーザー権限からこのコンピューターにアクセスする必要があります。 このようなネットワーク操作の例を次に示します。
- 共通ドメインまたはフォレスト内のドメイン コントローラー間の Active Directory のレプリケーション
- ユーザーとコンピューターからのドメイン コントローラーへの認証要求
- ネットワーク上のリモート コンピューターにある共有フォルダー、プリンター、およびその他のシステム サービスへのアクセス
ユーザー、コンピューター、およびサービス アカウントは、このユーザー権限が付与されているセキュリティ グループから明示的または暗黙的に追加または削除されることによって、ネットワーク ユーザー権利からこのコンピューターにアクセスする権利を取得または失います。 たとえば、ユーザー アカウントまたはコンピューター アカウントは、管理者によってカスタム セキュリティ グループまたは組み込みのセキュリティ グループに明示的に追加されたり、オペレーティング システムによってドメイン ユーザー、認証済みユーザー、エンタープライズ ドメイン コントローラーなどの計算されたセキュリティ グループに暗黙的に追加されたりします。
既定では、ユーザー アカウントとコンピューター アカウントには、すべてのユーザーなどの計算済みグループ、できれば認証済みユーザー、ドメイン コントローラーの場合は Enterprise Domain Controllers グループが、既定のドメイン コントローラー グループ ポリシー オブジェクト (GPO) で定義されている場合、ネットワーク ユーザー権利からこのコンピューターにアクセスする権限が付与されます。
危険な構成
有害な構成設定を次に示します。
- このユーザー権利から Enterprise Domain Controllers セキュリティ グループを削除する
- ユーザー、コンピューター、およびサービス アカウントをネットワーク経由でコンピューターに接続する権限を付与する認証されたユーザー グループまたは明示的なグループを削除する
- このユーザー権利からすべてのユーザーとコンピューターを削除する
このユーザーに権限を付与する理由
- ネットワーク ユーザーから Enterprise Domain Controllers グループへのアクセス権をこのコンピューターに付与すると、同じフォレスト内のドメイン コントローラー間でレプリケーションを実行するために Active Directory レプリケーションに必要な認証要件が満たされます。
- このユーザー権利を使用すると、ユーザーとコンピューターは、Active Directory を含む共有ファイル、プリンター、およびシステム サービスにアクセスできます。
- このユーザー権利は、ユーザーが初期バージョンの Microsoft Outlook Web Access (OWA) を使用してメールにアクセスするために必要です。
このユーザー権利を削除する理由
- コンピューターをネットワークに接続できるユーザーは、アクセス許可を持つリモート コンピューター上のリソースにアクセスできます。 たとえば、ユーザーが共有プリンターとフォルダーに接続するには、このユーザー権限が必要です。 このユーザー権限が Everyone グループに付与され、同じグループに読み取りアクセス権が付与されるように共有フォルダーと NTFS ファイル システムの両方のアクセス許可が構成されている共有フォルダーがある場合、誰でもそれらの共有フォルダー内のファイルを表示できます。 ただし、Windows Server 2003 の既定の共有と NTFS アクセス許可には Everyone グループが含まれていないため、これは、Windows Server 2003 の新規インストールではありそうもない状況です。 Microsoft Windows NT 4.0 または Windows 2000 からアップグレードされたシステムの場合、これらのオペレーティング システムの既定の共有とファイル システムのアクセス許可が、Windows Server 2003 の既定のアクセス許可ほど制限されていないため、この脆弱性のリスクが高くなる可能性があります。
- このユーザー権利から Enterprise Domain Controllers グループを削除する正当な理由はありません。
- すべてのユーザー グループは、通常、認証されたユーザー グループを優先して削除されます。 Everyone グループが削除された場合は、認証されたユーザー グループにこのユーザー権限を付与する必要があります。
- Windows 2000 にアップグレードされた Windows NT 4.0 ドメインは、ネットワーク ユーザーから [このコンピューターにアクセスする] 権限を Everyone グループ、Authenticated Users グループ、または Enterprise Domain Controllers グループに明示的に付与しません。 そのため、4.0 ドメイン ポリシー Windows NTから Everyone グループを削除すると、Windows 2000 にアップグレードした後、Active Directory レプリケーションが "アクセス拒否" というエラー メッセージで失敗します。 Windows Server 2003 の Winnt32.exe では、4.0 プライマリ ドメイン コントローラー (PDC) をアップグレードするときに、エンタープライズ ドメイン コントローラー グループにこのユーザー権利Windows NT付与することで、この構成の誤りを回避します。 グループ ポリシー オブジェクト エディターに存在しない場合は、エンタープライズ ドメイン コントローラー グループにこのユーザー権限を付与します。
互換性の問題の例
Windows 2000 および Windows Server 2003: 次のパーティションのレプリケーションは、REPLMON や REPADMIN などの監視ツールやイベント ログ内のレプリケーション イベントによって報告される "アクセス拒否" エラーで失敗します。
- Active Directory スキーマ パーティション
- 構成パーティション
- ドメイン パーティション
- グローバル カタログ パーティション
- アプリケーション パーティション
すべての Microsoft ネットワーク オペレーティング システム: リモート ネットワーク クライアント コンピューターからのユーザー アカウント認証は、ユーザーまたはユーザーがメンバーであるセキュリティ グループにこのユーザー権限が付与されていない限り失敗します。
すべての Microsoft ネットワーク オペレーティング システム: リモート ネットワーク クライアントからのアカウント認証は、アカウントまたはアカウントがメンバーであるセキュリティ グループにこのユーザー権限が付与されていない限り失敗します。 このシナリオは、ユーザー アカウント、コンピューター アカウント、およびサービス アカウントに適用されます。
すべての Microsoft ネットワーク オペレーティング システム: このユーザー権利からすべてのアカウントを削除すると、アカウントがドメインにログオンしたり、ネットワーク リソースにアクセスしたりできなくなります。 エンタープライズ ドメイン コントローラー、Everyone、Authenticated Users などの計算されたグループが削除された場合は、アカウントまたはアカウントがメンバーであるセキュリティ グループに対して、ネットワーク経由でリモート コンピューターにアクセスする権限を明示的に付与する必要があります。 このシナリオは、すべてのユーザー アカウント、すべてのコンピューター アカウント、およびすべてのサービス アカウントに適用されます。
すべての Microsoft ネットワーク オペレーティング システム: ローカル管理者アカウントでは、"空白" のパスワードが使用されます。 空白のパスワードを使用したネットワーク接続は、ドメイン環境の管理者アカウントでは許可されません。 この構成では、"アクセスが拒否されました" というエラー メッセージが表示されます。
ローカルでのログオンを許可
背景
Windows ベースのコンピューターのコンソールで (Ctrl + Alt + DELETE キーボード ショートカットを使用して) ログオンしようとしているユーザーと、サービスを開始しようとしているアカウントには、ホスティング コンピューターに対するローカル ログオン権限が必要です。 ローカル ログオン操作の例としては、メンバー コンピューターのコンソールにログオンしている管理者、またはエンタープライズ全体のドメイン コントローラー、および特権のないアカウントを使用してデスクトップにアクセスするためにメンバー コンピューターにログオンしているドメイン ユーザーなどがあります。 リモート デスクトップ接続またはターミナル サービスを使用するユーザーは、Windows 2000 または Windows XP を実行している対象のコンピューターで[ローカルログオンを許可する] ユーザー権限を持っている必要があります。これらのログオン モードはホスティング コンピューターに対してローカルと見なされるためです。 ターミナル サーバーが有効になっていて、このユーザー権限を持たないサーバーにログオンしているユーザーは、ターミナル サービスによるログオンを許可する権限がある場合でも、Windows Server 2003 ドメインでリモート 対話型セッションを開始できます。
危険な構成
有害な構成設定を次に示します。
- 既定のドメイン コントローラーのポリシーから、Account Operators、Backup Operators、Print Operators、Server Operators、組み込みの Administrators グループなどの管理セキュリティ グループを削除します。
- 既定のドメイン コントローラーのポリシーから、メンバー コンピューターおよびドメイン内のドメイン コントローラー上のコンポーネントとプログラムによって使用されるサービス アカウントを削除します。
- ドメイン内のメンバー コンピューターのコンソールにログオンするユーザーまたはセキュリティ グループを削除する。
- メンバー コンピューターまたはワークグループ コンピューターのローカル セキュリティ アカウント マネージャー (SAM) データベースで定義されているサービス アカウントを削除します。
- ドメイン コントローラーで実行されているターミナル サービスを介して認証する組み込み以外の管理アカウントを削除する。
- ドメイン内のすべてのユーザー アカウントを、Everyone グループを介して明示的または暗黙的に [ログオンの拒否] ローカル ログオン権限に追加します。 この構成により、ユーザーが任意のメンバー コンピューターまたはドメイン内の任意のドメイン コントローラーにログオンできなくなります。
このユーザーに権限を付与する理由
- ユーザーは、ワークグループ コンピューター、メンバー コンピューター、またはドメイン コントローラーのコンソールまたはデスクトップにアクセスするには、ローカルでのログオンを許可する権限が必要です。
- ユーザーは、Windows 2000 ベースのメンバー コンピューターまたはドメイン コントローラーで実行されているターミナル サービス セッションでログオンする権限を持っている必要があります。
このユーザー権利を削除する理由
- 正当なユーザー アカウントへのコンソール アクセスを制限しないと、承認されていないユーザーが悪意のあるコードをダウンロードして実行してユーザー権限を変更する可能性があります。
- ローカルユーザー権限の [ログの許可] を削除すると、ドメイン コントローラーやアプリケーション サーバーなどのコンピューターのコンソールで未承認のログオンが防止されます。
- このログオン権限を削除すると、ドメイン内のメンバー コンピューターのコンソールでドメイン以外のアカウントがログオンできなくなります。
互換性の問題の例
- Windows 2000 ターミナル サーバー: ユーザーが Windows 2000 ターミナル サーバーにログオンするには、[ローカルでのログオンを許可する] ユーザー権限が必要です。
- Windows NT 4.0、Windows 2000、Windows XP、または Windows Server 2003: ユーザー アカウントには、4.0、Windows 2000、Windows XP、または Windows Server 2003 Windows NT実行されているコンピューターのコンソールでログオンする権限が付与されている必要があります。
- Windows NT 4.0 以降: Windows NT 4.0 以降を実行しているコンピューターで、[ローカルでのログオンを許可する] ユーザー権利を追加しても、暗黙的または明示的に [ログオンの拒否] 権限もローカルに付与した場合、アカウントはドメイン コントローラーのコンソールにログオンできません。
スキャン検査のバイパス
背景
[走査チェックをバイパスする] ユーザー権限を使用すると、NTFS ファイル システムまたはレジストリ内のフォルダーを、走査フォルダーの特別なアクセス許可をチェックせずに参照できます。 [走査チェックのバイパス] ユーザー権限では、ユーザーはフォルダーの内容を一覧表示できません。 これにより、ユーザーはフォルダーのみを走査できます。
危険な構成
有害な構成設定を次に示します。
- Windows 2000 ベースのターミナル サービス コンピューターまたはファイル システム内のファイルとフォルダーにアクセスするためのアクセス許可を持たない 2003 ベースのターミナル サービス コンピューター Windows Serverにログオンする管理以外のアカウントを削除します。
- 既定でこのユーザー権限を持つセキュリティ プリンシパルの一覧から Everyone グループを削除します。 Windows オペレーティング システムと多くのプログラムは、コンピューターに正当にアクセスできるすべてのユーザーがバイパス 走査チェック ユーザー権利を持っていることを期待して設計されています。 そのため、既定でこのユーザー権限を持つセキュリティ プリンシパルの一覧から Everyone グループを削除すると、オペレーティング システムが不安定になったり、プログラムが失敗したりする可能性があります。 この設定は既定値のままにすることをお勧めします。
このユーザーに権限を付与する理由
[走査チェックをバイパスする] ユーザー権利の既定の設定は、すべてのユーザーが走査チェックをバイパスできるようにすることです。 経験豊富な Windows システム管理者の場合、これは想定される動作であり、それに応じてファイル システム アクセス制御リスト (SACL) を構成します。 既定の構成で問題が発生する可能性がある唯一のシナリオは、アクセス許可を構成する管理者が動作を理解せず、親フォルダーにアクセスできないユーザーが子フォルダーの内容にアクセスできないことを想定している場合です。
このユーザー権利を削除する理由
ファイル システム内のファイルまたはフォルダーへのアクセスを防ぐために、セキュリティが非常に懸念されている組織は、[走査チェックをバイパスする] ユーザー権限を持つグループの一覧から Everyone グループ、または Users グループを削除したくなる可能性があります。
互換性の問題の例
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 ツリーから削除されると、コンピューター ポリシーとユーザー ポリシーを適用できません。バイパス走査チェック のユーザー権限が削除された場合、または正しく構成されていない場合。
Windows 2000、Windows Server 2003: Windows 2000 または Windows Server 2003 を実行しているコンピューターでは、ボリュームのプロパティを表示すると、Windows エクスプローラーの [クォータ] タブが表示されなくなります。
Windows 2000: Windows 2000 ターミナル サーバーにログオンする管理者以外のユーザーは、次のエラー メッセージを受け取ることがあります。
注
アプリケーション エラー Userinit.exe。 [OK] をクリックしてアプリを終了0xc0000142、アプリケーションを適切に初期化できませんでした。
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 クライアントから 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 にログオンできず、バイパス走査チェック ユーザー権限が付与されていない場合、"アクセス拒否" というエラー メッセージが表示されます。
セキュリティ設定
次の一覧では、セキュリティ設定を識別し、入れ子になった一覧には、セキュリティ設定に関する説明、問題が発生する可能性がある構成設定の識別、セキュリティ設定を適用する必要がある理由、セキュリティ設定を削除する理由について説明します。 入れ子になったリストは、セキュリティ設定とセキュリティ設定のレジストリ パスのシンボリック名を提供します。 最後に、セキュリティ設定の構成時に発生する可能性がある互換性の問題の例を示します。
監査: セキュリティ監査をログに記録できない場合は、システムを直ちにシャットダウンします
背景
- [監査: セキュリティ監査をログに記録できない場合は直ちにシステムをシャットダウンする] 設定は、セキュリティ イベントをログに記録できない場合にシステムがシャットダウンするかどうかを決定します。 この設定は、信頼されたコンピューター セキュリティ評価基準 (TCSEC) プログラムの C2 評価と、監査システムがそれらのイベントをログに記録できない場合に監査可能なイベントを防ぐための情報技術セキュリティ評価の共通基準に必要です。 監査システムが失敗した場合、システムはシャットダウンされ、Stop エラー メッセージが表示されます。
- コンピューターがセキュリティ ログにイベントを記録できない場合は、セキュリティ インシデントの後に重要な証拠や重要なトラブルシューティング情報を確認できない可能性があります。
危険な構成
有害な構成設定を次に示します。[監査: セキュリティ監査をログに記録できない場合はシステムを直ちにシャットダウンする] 設定がオンになり、セキュリティ イベント ログのサイズは、[イベントを上書きしない (手動でログをクリアする)] オプション、必要に応じて [イベントを上書きする] オプション、またはイベント ビューアーの [日数より古いイベントを上書きする] オプションによって制限されます。 Windows 2000、Windows 2000 Service Pack 1 (SP1)、Windows 2000 SP2、または Windows 2000 SP3 の元のリリースバージョンを実行しているコンピューターの特定のリスクについては、「互換性の問題の例」セクションを参照してください。
この設定を有効にする理由
コンピューターがセキュリティ ログにイベントを記録できない場合は、セキュリティ インシデントの後に重要な証拠や重要なトラブルシューティング情報を確認できない可能性があります。
この設定を無効にする理由
- [監査: セキュリティ監査をログに記録できない場合は直ちにシステムをシャットダウンする] 設定を有効にすると、何らかの理由でセキュリティ監査をログに記録できない場合にシステムが停止します。 通常、セキュリティ監査ログがいっぱいで、指定された保持方法が [イベントを上書きしない (手動でログをクリアする)] オプションまたは [ 日数より前 のイベントを上書きする] オプションである場合は、イベントをログに記録できません。
- [監査: セキュリティ監査をログに記録できない場合は直ちにシステムをシャットダウンする] 設定を有効にした場合の管理上の負担が非常に大きい場合があります。特に、セキュリティ ログの [イベントを上書きしない ( ログを手動でクリアする)] オプションもオンにした場合。 この設定は、オペレーター アクションの個々の説明責任を提供します。 たとえば、管理者は、組み込みの管理者アカウントまたはその他の共有アカウントを使用して監査が有効になっている組織単位 (OU) 内のすべてのユーザー、コンピューター、およびグループに対するアクセス許可をリセットし、そのようなアクセス許可をリセットすることを拒否できます。 ただし、この設定を有効にすると、ログオン イベントやセキュリティ ログに書き込まれるその他のセキュリティ イベントでサーバーが強制的にシャットダウンされる可能性があるため、システムの堅牢性が低下します。 さらに、シャットダウンが正常ではないため、オペレーティング システム、プログラム、またはデータに回復不能な損傷が発生する可能性があります。 NTFS では、不明確なシステム シャットダウン中にファイル システムの整合性が維持されることを保証しますが、システムの再起動時にすべてのプログラムのすべてのデータ ファイルが使用可能な形式であることを保証することはできません。
シンボリック名:
CrashOnAuditFail
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\CrashOnAuditFail (Reg_DWORD)互換性の問題の例
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 エラーが発生します。
ドメイン コントローラー: LDAP サーバー署名の要件
背景
[ドメイン コントローラー: LDAP サーバー署名要件] セキュリティ設定は、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーで LDAP クライアントがデータ署名をネゴシエートする必要があるかどうかを決定します。 このポリシー設定で使用できる値は次のとおりです。
- なし: サーバーとのバインドにデータ署名は必要ありません。 クライアントがデータ署名を要求した場合、サーバーはデータ署名をサポートします。
- 署名が必要: トランスポート層のセキュリティ/セキュリティ ソケット層 (TLS/SSL) が使用されていない限り、LDAP データ署名オプションをネゴシエートする必要があります。
- 定義されていません: この設定は有効または無効ではありません。
危険な構成
有害な構成設定を次に示します。
- クライアントが LDAP 署名をサポートしていない環境、またはクライアント側の LDAP 署名がクライアントで有効になっていない環境で [サインインが必要] を有効にする
- クライアントが LDAP 署名をサポートしていない環境、またはクライアント側 LDAP 署名が有効になっていない環境で Windows 2000 または Windows Server 2003 Hisecdc.inf セキュリティ テンプレートを適用する
- クライアントが LDAP 署名をサポートしていない環境、またはクライアント側 LDAP 署名が有効になっていない環境で Windows 2000 または Windows Server 2003 Hisecws.inf セキュリティ テンプレートを適用する
この設定を有効にする理由
署名されていないネットワーク トラフィックは、侵入者がクライアントとサーバーの間でパケットをキャプチャし、パケットを変更し、それらをサーバーに転送する中間者攻撃の影響を受けやすくなります。 この動作が LDAP サーバーで発生すると、攻撃者は、LDAP クライアントからの誤ったクエリに基づいてサーバーが決定を下す可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークでこのリスクを軽減できます。 インターネット プロトコル セキュリティ (IPSec) 認証ヘッダー モードは、中間者攻撃を防ぐのに役立ちます。 認証ヘッダー モードでは、IP トラフィックに対して相互認証とパケット整合性が実行されます。
この設定を無効にする理由
- NTLM 認証がネゴシエートされ、正しいサービス パックが Windows 2000 ドメイン コントローラーにインストールされていない場合、LDAP 署名をサポートしていないクライアントは、ドメイン コントローラーとグローバル カタログに対して LDAP クエリを実行できません。
- クライアントとサーバー間の LDAP トラフィックのネットワーク トレースが暗号化されます。 これにより、LDAP の会話を調べるのが困難になります。
- Windows 2000 ベースのサーバーは、Windows 2000 SP4、Windows XP、Windows Server または 2003 を実行するクライアント コンピューターから実行される LDAP 署名をサポートするプログラムで管理されている場合は、Windows 2000 Service Pack 3 (SP3) がインストールされている必要があります。
シンボリック名:
LDAPServerIntegrity
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity (Reg_DWORD)互換性の問題の例
単純バインドは失敗し、次のエラー メッセージが表示されます。
注
Ldap_simple_bind_s() に失敗しました: 強力な認証が必要です。
Windows 2000 Service Pack 4、Windows XP、Windows Server 2003: Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行しているクライアントでは、一部の Active Directory 管理ツールは、NTLM 認証のネゴシエート時に SP3 より前のバージョンの Windows 2000 を実行しているドメイン コントローラーに対して正しく動作しません。
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 は IP アドレスです)。Windows 2000 Service Pack 4、Windows XP、Windows Server 2003: Windows 2000 SP4、Windows XP、または Windows Server 2003 を実行しているクライアントでは、SP3 より前のバージョンの Windows 2000 を実行しているドメイン コントローラーを対象とする一部の Active Directory 管理ツールが正しく動作しません。
ドメイン メンバー: 強力な (Windows 2000 以降) セッション キーが必要
背景
- [ドメイン メンバー: Require strong (Windows 2000 以降)] セッション キー設定は、セキュリティで保護されたチャネル トラフィックを強力な 128 ビット セッション キーで暗号化できないドメイン コントローラーで確立できるかどうかを決定します。 この設定を有効にすると、セキュリティで保護されたチャネル データを強力なキーで暗号化できないドメイン コントローラーでセキュリティで保護されたチャネルを確立できなくなります。 この設定を無効にすると、64 ビット セッション キーが許可されます。
- メンバー ワークステーションまたはサーバーでこの設定を有効にする前に、メンバーが属するドメイン内のすべてのドメイン コントローラーで、強力な 128 ビット キーを使用してセキュリティで保護されたチャネル データを暗号化できる必要があります。 つまり、このようなドメイン コントローラーはすべて Windows 2000 以降を実行している必要があります。
危険な構成
ドメイン メンバーを有効にする: 強力な (Windows 2000 以降) セッション キー設定を必要とすることは、有害な構成設定です。
この設定を有効にする理由
- メンバー コンピューターとドメイン コントローラー間のセキュリティで保護されたチャネル通信を確立するために使用されるセッション キーは、Windows 2000 では、以前のバージョンの Microsoft オペレーティング システムよりもはるかに強力です。
- 可能な場合は、これらの強力なセッション キーを利用して、セキュリティで保護されたチャネル通信を盗聴やセッション乗っ取りネットワーク攻撃から保護することをお勧めします。 盗聴は、ネットワーク データが読み取られたり、転送中に変更されたりする悪意のある攻撃の一種です。 データを変更して、送信者を非表示にしたり、送信者を変更したり、リダイレクトしたりできます。
重要 2008 R2 または Windows 7 Windows Server実行されているコンピューターでは、セキュリティで保護されたチャネルを使用する場合にのみ強力なキーがサポートされます。 この制限により、Windows NT 4.0 ベースのドメインと 2008 R2 ベースのドメインWindows Server間の信頼が禁止されます。 さらに、この制限により、Windows 7 または Windows Server 2008 R2 を実行しているコンピューターのWindows NT 4.0 ベースのドメイン メンバーシップがブロックされます。その逆も同様です。
この設定を無効にする理由
ドメインには、Windows 2000、Windows XP、または Windows Server 2003 以外のオペレーティング システムを実行しているメンバー コンピューターが含まれています。
シンボリック名:
StrongKey
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireStrongKey (Reg_DWORD)互換性の問題の例
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 ドメインでの信頼は機能しなくなります。
ドメイン メンバー: セキュリティで保護されたチャネル データをデジタル暗号化または署名する (常に)
背景
- ドメイン メンバーの有効化: セキュリティで保護されたチャネル データ (常に) をデジタル暗号化または署名すると、すべてのセキュリティで保護されたチャネル データに署名または暗号化できないドメイン コントローラーでセキュリティで保護されたチャネルを確立できなくなります。 中間者攻撃、再生攻撃、その他の種類のネットワーク攻撃から認証トラフィックを保護するために、Windows ベースのコンピューターは、Net Logon サービスを介してセキュリティで保護されたチャネルと呼ばれる通信チャネルを作成して、コンピューター アカウントを認証します。 セキュリティで保護されたチャネルは、1 つのドメインのユーザーがリモート ドメインのネットワーク リソースに接続するときにも使用されます。 このマルチドメイン認証 (パススルー認証) を使用すると、ドメインに参加している Windows ベースのコンピューターは、そのドメイン内のユーザー アカウント データベースと信頼されたドメイン内のユーザー アカウント データベースにアクセスできます。
- ドメイン メンバーを有効にするには、メンバー コンピューターのセキュリティで保護されたチャネル データ (常に) 設定をデジタル暗号化または署名します。メンバーが属するドメイン内のすべてのドメイン コントローラーは、すべてのセキュリティで保護されたチャネル データに署名または暗号化できる必要があります。 つまり、このようなドメイン コントローラーはすべて、Service Pack 6a (SP6a) 以降Windows NT 4.0 で実行されている必要があります。
- ドメイン メンバーの有効化: セキュリティで保護されたチャネル データ (常に) をデジタル暗号化または署名する設定では、[ドメイン メンバー: セキュリティで保護されたチャネル データをデジタルで暗号化または署名する (可能な場合)] 設定が自動的に有効になります。
危険な構成
ドメイン メンバーの有効化: すべてのドメイン コントローラーがセキュリティで保護されたチャネル データに署名または暗号化できるわけではないドメインで、セキュリティで保護されたチャネル データ (常に) 設定をデジタル暗号化または署名します。
この設定を有効にする理由
署名されていないネットワーク トラフィックは、中間者攻撃の影響を受けやすくなります。侵入者は、サーバーとクライアントの間でパケットをキャプチャし、クライアントに転送する前にそれらを変更します。 この動作がライトウェイト ディレクトリ アクセス プロトコル (LDAP) サーバーで発生すると、侵入者によって、LDAP ディレクトリからの false レコードに基づいてクライアントが決定を下す可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークに対するこのような攻撃のリスクを軽減できます。 さらに、インターネット プロトコル セキュリティ (IPSec) 認証ヘッダー モードを実装すると、中間者攻撃を防ぐのに役立ちます。 このモードでは、IP トラフィックに対して相互認証とパケット整合性が実行されます。
この設定を無効にする理由
- ローカル ドメインまたは外部ドメイン内のコンピューターでは、暗号化されたセキュリティで保護されたチャネルがサポートされます。
- ドメイン内のすべてのドメイン コントローラーに、暗号化されたセキュリティで保護されたチャネルをサポートするための適切な Service Pack リビジョン レベルがあるわけではありません。
シンボリック名:
StrongKey
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters\RequireSignOrSeal (REG_DWORD)互換性の問題の例
Windows NT 4.0: Windows 2000 ベースのメンバー コンピューターは、Windows NT 4.0 ドメインに参加できず、次のエラー メッセージが表示されます。
注
アカウントは、このステーションからのログインを許可されていません。
詳細については、次のマイクロソフト サポート技術情報番号をクリックしてください。
281648 エラー メッセージ: アカウントがこのステーションからログインする権限がありません
Windows NT 4.0: Windows NT 4.0 ドメインでは、Windows 2000 ドメインとの下位レベルの信頼を確立できず、次のエラー メッセージが表示されます。
注
アカウントは、このステーションからのログインを許可されていません。
既存の下位レベルの信頼は、信頼されたドメインからのユーザーを認証しない場合もあります。 一部のユーザーは、ドメインへのログオンに問題があり、クライアントがドメインを見つけることができないことを示すエラー メッセージが表示される場合があります。
Windows XP: Windows NT 4.0 ドメインに参加している Windows XP クライアントは、ログオン試行を認証できず、次のエラー メッセージが表示されたり、次のイベントがイベント ログに登録されたりすることがあります。
注
ドメイン コントローラーがダウンしているか、使用できないか、コンピューター アカウントが見つからなかったため、Windows はドメインに接続できません
Microsoft Network: Microsoft Network クライアントは、次のいずれかのエラー メッセージを受け取ります。
注
ログオンエラー: 不明なユーザー名または不適切なパスワード。
注
指定されたログオン セッションのユーザー セッション キーはありません。
Microsoft ネットワーク クライアント: 通信にデジタル署名する (常に)
背景
サーバー メッセージ ブロック (SMB) は、多くの Microsoft オペレーティング システムでサポートされているリソース共有プロトコルです。 これは、ネットワーク基本入出力システム (NetBIOS) とその他の多くのプロトコルの基礎です。 SMB 署名は、データをホストするユーザーとサーバーの両方を認証します。 どちらの側でも認証プロセスに失敗した場合、データ転送は行われません。
SMB 署名の有効化は、SMB プロトコル ネゴシエーション中に開始されます。 SMB 署名ポリシーは、コンピューターが常にクライアント通信にデジタル署名するかどうかを決定します。
Windows 2000 SMB 認証プロトコルでは、相互認証がサポートされています。 相互認証は、"man-in-the-middle" 攻撃を閉じます。 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 では、Directory Services クライアントは NTLM 認証を使用してWindows Server 2003 サーバーで認証するときに SMB 署名を使用します。 ただし、これらのクライアントは、NTLMv2 認証を使用してこれらのサーバーで認証するときに SMB 署名を使用しません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。 詳細については、「項目 10: ネットワーク セキュリティ: Lan Manager 認証レベル」を参照してください。
危険な構成
有害な構成設定を次に示します。Microsoft ネットワーク クライアントのままにします。デジタル署名通信 (常に) 設定と Microsoft ネットワーク クライアント: デジタル署名通信 (サーバーが同意する場合) 設定を "定義されていません" または無効に設定します。 これらの設定により、リダイレクターは、認証中にパスワード暗号化をサポートしていない Microsoft 以外の SMB サーバーにプレーン テキスト パスワードを送信できます。
この設定を有効にする理由
Microsoft ネットワーク クライアントの有効化: デジタル署名通信 (常に) では、SMB 署名を必要としないサーバーに接続するときに、クライアントが SMB トラフィックに署名する必要があります。 これにより、クライアントはセッション乗っ取り攻撃に対して脆弱になります。
この設定を無効にする理由
- Microsoft ネットワーク クライアントの有効化: デジタル署名通信 (常に) では、クライアントが SMB 署名をサポートしていないターゲット サーバーと通信できなくなります。
- 署名されていない SMB 通信をすべて無視するようにコンピューターを構成すると、以前のプログラムとオペレーティング システムが接続できなくなります。
シンボリック名:
RequireSMBSignRdr
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters\RequireSecuritySignature互換性の問題の例
Windows NT 4.0: NLTEST または NETDOM を使用して、Windows Server 2003 ドメインと Windows NT 4.0 ドメイン間の信頼のセキュリティで保護されたチャネルをリセットすることはできません。"アクセス拒否" エラー メッセージが表示されます。
Windows XP: Windows XP クライアントから Windows 2000 ベースのサーバー、および 2003 ベースのサーバー Windows Serverファイルをコピーする場合、時間がかかる場合があります。
この設定が有効になっているクライアントからネットワーク ドライブをマップすることはできず、次のエラー メッセージが表示されます。
注
アカウントは、このステーションからのログインを許可されていません。
再起動の必要性
コンピューターを再起動するか、ワークステーション サービスを再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力します。 1 つのコマンドを入力するたびに Enter キーを押します。
net stop workstation
net start workstation
Microsoft ネットワーク サーバー: 通信にデジタル署名する (常に)
背景
Server Messenger Block (SMB) は、多くの Microsoft オペレーティング システムでサポートされているリソース共有プロトコルです。 これは、ネットワーク基本入出力システム (NetBIOS) とその他の多くのプロトコルの基礎です。 SMB 署名は、データをホストするユーザーとサーバーの両方を認証します。 どちらの側でも認証プロセスに失敗した場合、データ転送は行われません。
SMB 署名の有効化は、SMB プロトコル ネゴシエーション中に開始されます。 SMB 署名ポリシーは、コンピューターが常にクライアント通信にデジタル署名するかどうかを決定します。
Windows 2000 SMB 認証プロトコルでは、相互認証がサポートされています。 相互認証は、"man-in-the-middle" 攻撃を閉じます。 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 では、Directory Services クライアントは NTLM 認証を使用してWindows Server 2003 サーバーで認証するときに SMB 署名を使用します。 ただし、これらのクライアントは、NTLMv2 認証を使用してこれらのサーバーで認証するときに SMB 署名を使用しません。 さらに、Windows 2000 サーバーは、これらのクライアントからの SMB 署名要求に応答しません。 詳細については、「項目 10: ネットワーク セキュリティ: Lan Manager 認証レベル」を参照してください。
危険な構成
有害な構成設定を次に示します。Microsoft ネットワーク サーバーを有効にする: ローカルまたは外部ドメインの互換性のない Windows ベースのコンピューターとサード パーティのオペレーティング システム ベースのクライアント コンピューターからアクセスされるサーバーとドメイン コントローラーで、通信にデジタル署名 (常に) 設定します。
この設定を有効にする理由
- レジストリまたはグループ ポリシー設定を介してこの設定を直接有効にするすべてのクライアント コンピューターは、SMB 署名をサポートします。 つまり、この設定が有効になっているすべてのクライアント コンピューターは、DS クライアントがインストールされている Windows 95、Windows 98、Windows NT 4.0、Windows 2000、Windows XP Professional、または Windows Server 2003 のいずれかを実行します。
- Microsoft ネットワーク サーバー: デジタル署名通信 (常に) が無効になっている場合、SMB 署名は完全に無効になります。 すべての SMB 署名を完全に無効にすると、コンピューターはセッション乗っ取り攻撃に対して脆弱になります。
この設定を無効にする理由
- この設定を有効にすると、クライアント コンピューターでのファイルのコピーとネットワークのパフォーマンスが低下する可能性があります。
- この設定を有効にすると、SMB 署名をネゴシエートできないクライアントがサーバーやドメイン コントローラーと通信できなくなります。 これにより、ドメイン参加、ユーザーとコンピューターの認証、プログラムによるネットワーク アクセスなどの操作が失敗します。
シンボリック名:
RequireSMBSignServer
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanManServer\Parameters\RequireSecuritySignature (REG_DWORD)互換性の問題の例
Windows 95: ディレクトリ サービス (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 を実行するドメイン コントローラーのセキュリティ設定は、ドメイン コントローラーの通信が悪意のあるユーザーによって傍受または改ざんされるのを防ぐのに役立ちます。 ユーザーが 2003 Windows Server実行されているドメイン コントローラーと正常に通信するには、クライアント コンピューターで SMB 署名と暗号化の両方またはセキュリティで保護されたチャネル トラフィック署名を使用する必要があります。 既定では、Service Pack 2 (SP2) 以前のインストール済みWindows NT 4.0 を実行するクライアントと、Windows 95 を実行するクライアントでは SMB パケット署名が有効になっていません。 そのため、これらのクライアントは、Windows Server 2003 ベースのドメイン コントローラーに対して認証できない場合があります。
Windows 2000 および Windows Server 2003 ポリシー設定: 特定のインストールのニーズと構成に応じて、Microsoft 管理コンソール グループ ポリシー Editor スナップイン階層で必要なスコープの最小エンティティで次のポリシー設定を設定することをお勧めします。
- コンピューターの構成\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
- DS クライアントがインストールされていない Microsoft Windows 95 クライアント
- SP3 以降がインストールされていない Microsoft Windows NT 4.0 ベースのコンピューター
- Novell Netware 6 CIFS クライアント
- SMB 署名をサポートしていない SAMBA SMB クライアント
再起動の必要性
コンピューターを再起動するか、サーバー サービスを再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力します。 1 つのコマンドを入力するたびに Enter キーを押します。
net stop server
net start server
ネットワーク アクセス: 匿名 SID/名前変換を許可する
背景
[ネットワーク アクセス: 匿名 SID/名前変換セキュリティを許可する] 設定は、匿名ユーザーが別のユーザーのセキュリティ ID 番号 (SID) 属性を要求できるかどうかを決定します。
危険な構成
ネットワーク アクセスの有効化: 匿名 SID/名前変換を許可する設定は有害な構成設定です。
この設定を有効にする理由
[ネットワーク アクセス: 匿名 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 ドメイン コントローラーを含むアカウント ドメインからユーザー アカウントにファイル、共有フォルダー、レジストリ オブジェクトにアクセスするアクセス許可を付与する必要があるユーザー
この設定を無効にする理由
この設定が有効になっている場合、悪意のあるユーザーは、既知の管理者 SID を使用して、アカウントの名前が変更された場合でも、組み込みの管理者アカウントの実際の名前を取得できます。 そのユーザーは、アカウント名を使用してパスワード推測攻撃を開始できます。
シンボリック名: N/A
レジストリ パス: なし。 パスは UI コードで指定されます。
互換性の問題の例
Windows NT 4.0: Windows NT 4.0 リソース ドメイン内のコンピューターは、共有フォルダー、共有ファイル、レジストリ オブジェクトを含むリソースが、Windows Server 2003 ドメイン コントローラーを含むアカウント ドメインに存在するセキュリティ プリンシパルで保護されている場合、ACL エディターで "アカウント不明" エラー メッセージを表示します。
ネットワーク アクセス: SAM アカウントの匿名列挙を許可しない
背景
[ネットワーク アクセス: SAM アカウントの匿名列挙を許可しない] 設定は、コンピューターへの匿名接続に対して付与される追加のアクセス許可を決定します。 Windows を使用すると、匿名ユーザーは、ワークステーションとサーバーセキュリティ アカウント マネージャー (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
危険な構成
ネットワーク アクセスを有効にする: SAM アカウントの匿名列挙を許可しない設定は、互換性の観点から有害な構成設定です。 無効にすることは、セキュリティの観点から見た有害な構成設定です。
この設定を有効にする理由
未承認のユーザーは、アカウント名を匿名で一覧表示し、その情報を使用してパスワードの推測やソーシャル エンジニアリング攻撃の実行を試みることができます。 ソーシャル エンジニアリングとは、人々をだましてパスワードや何らかの形式のセキュリティ情報を明らかにすることを意味する専門用語です。
この設定を無効にする理由
この設定を有効にすると、Windows NT 4.0 ドメインで信頼を確立することはできません。 この設定により、サーバー上のリソースを使用しようとしているダウンレベルのクライアント (Windows NT 3.51 クライアントや Windows 95 クライアントなど) にも問題が発生します。
シンボリック名:
RestrictAnonymousSAM
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymousSAM (Reg_DWORD)互換性の問題の例
- SMS ネットワーク検出はオペレーティング システム情報を取得できず、OperatingSystemNameandVersion プロパティに "Unknown" と書き込まれます。
- 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 ベースのコンピューターのユーザーは、ユーザー アカウントのパスワードを変更できません。
ネットワーク アクセス: SAM アカウントと共有の匿名列挙を許可しない
背景
- ネットワーク アクセス: SAM アカウントと共有の匿名列挙を許可しない設定 (RestrictAnonymous とも呼ばれます) は、セキュリティ アカウント マネージャー (SAM) アカウントと共有の匿名列挙を許可するかどうかを決定します。 Windows を使用すると、匿名ユーザーは、ドメイン アカウント (ユーザー、コンピューター、グループ) の名前やネットワーク共有の名前の列挙など、特定のアクティビティを実行できます。 これは、たとえば、管理者が相互信頼を維持しない信頼されたドメイン内のユーザーにアクセス権を付与する場合に便利です。 SAM アカウントと共有の匿名列挙を許可しない場合は、この設定を有効にします。
- Windows 2000 では、匿名接続の追加制限と呼ばれる同様の設定によって RestrictAnonymous レジストリ値が管理されます。 この値の場所は次のとおりです。
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA
危険な構成
[ネットワーク アクセスの有効化]: SAM アカウントの匿名列挙を許可せず、共有設定は有害な構成設定です。
この設定を有効にする理由
- ネットワーク アクセスを有効にする: SAM アカウントと共有の匿名列挙を許可しない設定では、匿名アカウントを使用しているユーザーとコンピューターによる SAM アカウントと共有の列挙が禁止されます。
この設定を無効にする理由
- この設定が有効になっている場合、未承認のユーザーは匿名でアカウント名を一覧表示し、その情報を使用してパスワードを推測したり、ソーシャル エンジニアリング攻撃を実行したりすることができます。 ソーシャル エンジニアリングとは、ユーザーをだまして自分のパスワードや何らかの形式のセキュリティ情報を明らかにすることを意味する専門用語です。
- この設定が有効になっている場合、Windows NT 4.0 ドメインで信頼を確立することはできません。 この設定により、サーバー上のリソースを使用しようとしているWindows NT 3.51 クライアントや Windows 95 クライアントなど、ダウンレベルのクライアントでも問題が発生します。
- 信頼ドメインの管理者は他のドメインのアカウントのリストを列挙できないため、リソース ドメインのユーザーにアクセス権を付与することは不可能です。 ファイル サーバーとプリント サーバーに匿名でアクセスするユーザーは、それらのサーバー上の共有ネットワーク リソースを一覧表示できません。 ユーザーは、共有フォルダーとプリンターの一覧を表示する前に認証する必要があります。
シンボリック名:
RestrictAnonymous
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\RestrictAnonymous互換性の問題の例
Windows NT 4.0: ユーザーのドメイン内のドメイン コントローラーで RestrictAnonymous が有効になっている場合、ユーザーは Windows NT 4.0 ワークステーションからパスワードを変更できません。
Windows NT 4.0: ユーザー マネージャーで信頼された Windows 2000 ドメインから 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 ベースのターミナル サーバー コンピューターにログオンするユーザーは、ドメインのユーザー マネージャーで定義されているホーム ディレクトリではなく、既定のホーム ディレクトリにマップされます。
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 を使用してフォレスト間で移行されたユーザー アカウントのパスワード移行は失敗します。
詳細については、次のマイクロソフト サポート技術情報番号をクリックしてください。
322981 ADMTv2 を使用したフォレスト間パスワード移行のトラブルシューティング方法Outlook クライアント: グローバル アドレス一覧は、Microsoft Exchange Outlook クライアントには空で表示されます。
SMS: Microsoft Systems Management Server (SMS) ネットワーク検出では、オペレーティング システム情報を取得できません。 そのため、検出データ レコード (DDR) の SMS DDR プロパティの OperatingSystemNameandVersion プロパティに "Unknown" と書き込まれます。
SMS: SMS 管理者ユーザー ウィザードを使用してユーザーとグループを参照すると、ユーザーまたはグループは一覧表示されません。 さらに、高度なクライアントは管理ポイントと通信できません。 管理ポイントでは匿名アクセスが必要です。
SMS: SMS 2.0 のネットワーク検出機能と、トポロジ、クライアント、およびクライアント オペレーティング システムのネットワーク検出オプションをオンにしてリモート クライアント インストールで使用している場合、コンピューターは検出される可能性がありますが、インストールされていない可能性があります。
ネットワーク セキュリティ: Lan Manager 認証レベル
背景
LAN Manager (LM) 認証は、ドメイン参加、ネットワーク リソースへのアクセス、ユーザーまたはコンピューターの認証など、ネットワーク操作に対する Windows クライアントの認証に使用されるプロトコルです。 LM 認証レベルは、クライアントとサーバー コンピューターの間でネゴシエートされるチャレンジ/応答認証プロトコルを決定します。 具体的には、LM 認証レベルによって、クライアントがネゴシエートしようとする認証プロトコル、またはサーバーが受け入れる認証プロトコルが決まります。 LmCompatibilityLevel に設定されている値は、ネットワーク ログオンに使用されるチャレンジ/応答認証プロトコルを決定します。 この値は、クライアントが使用する認証プロトコルのレベル、ネゴシエートされたセッション セキュリティのレベル、およびサーバーによって受け入れられる認証のレベルに影響します。
使用できる設定は次のとおりです。
Value 設定 説明 0 LM & NTLM 応答を送信する クライアントは LM 認証と NTLM 認証を使用し、NTLMv2 セッション セキュリティを使用しません。 ドメイン コントローラーは、LM、NTLM、NTLMv2 認証を受け入れます。 1 NTLM & LM を送信する - ネゴシエートされた場合は 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 応答のみ\refuse LM & NTLM を送信します。そのコンピューターの設定を下げるか、接続元のコンピューターと同じ設定にセキュリティを設定する必要があります。
LAN マネージャー認証レベルを変更して、クライアントとサーバーを同じレベルに設定できる正しい場所を見つけます。 LAN マネージャー認証レベルを設定しているポリシーを見つけたら、以前のバージョンの Windows を実行しているコンピューターとの間で接続する場合は、値を少なくとも (1) [LM & NTLM & 送信] に下げます。ネゴシエートされている場合は NTLM バージョン 2 のセッション セキュリティを使用します。 互換性のない設定の 1 つの効果は、サーバーが NTLMv2 (値 5) を必要とするが、クライアントが LM と NTLMv1 のみを使用するように構成されている (値 0) 場合、認証を試みるユーザーが、パスワードが正しくないログオン エラーが発生し、不正なパスワード数が増えるということです。 アカウントのロックアウトが構成されている場合、ユーザーは最終的にロックアウトされる可能性があります。
たとえば、ドメイン コントローラーを調べる必要がある場合や、ドメイン コントローラーのポリシーを調べる必要がある場合があります。
ドメイン コントローラーを確認する
注: すべてのドメイン コントローラーで次の手順を繰り返す必要がある場合があります。
- [ スタート] をクリックし、[ プログラム] をポイントし、[ 管理ツール] をクリックします。
- [ローカル セキュリティ設定] で、[ローカル ポリシー] を展開します。
- [ セキュリティ オプション] をクリックします。
- [ネットワーク セキュリティ: LAN マネージャー認証レベル] をダブルクリックし、一覧の値をクリックします。
[有効な設定] と [ローカル設定] が同じ場合、ポリシーはこのレベルで変更されています。 設定が異なる場合は、ドメイン コントローラーのポリシーをチェックして、ネットワーク セキュリティ: LAN マネージャー認証レベルの設定が定義されているかどうかを判断する必要があります。 そこで定義されていない場合は、ドメイン コントローラーのポリシーを調べます。
ドメイン コントローラーのポリシーを調べる
- [ スタート] をクリックし、[ プログラム] をポイントし、[ 管理ツール] をクリックします。
- ドメイン コントローラーのセキュリティ ポリシーで、[セキュリティ設定] を展開し、[ローカル ポリシー] を展開します。
- [ セキュリティ オプション] をクリックします。
- [ネットワーク セキュリティ: LAN マネージャー認証レベル] をダブルクリックし、一覧の値をクリックします。
注
- また、LAN マネージャー認証レベルを構成する必要がある場所を決定するには、サイト レベル、ドメイン レベル、または組織単位 (OU) レベルでリンクされているポリシーをチェックする必要があります。
- 既定のドメイン ポリシーとしてグループ ポリシー設定を実装した場合、ポリシーはドメイン内のすべてのコンピューターに適用されます。
- 既定のドメイン コントローラーのポリシーとしてグループ ポリシー設定を実装する場合、ポリシーはドメイン コントローラーの OU 内のサーバーにのみ適用されます。
- ポリシー アプリケーション階層で必要なスコープの最小エンティティで LAN マネージャー認証レベルを設定することをお勧めします。
Windows Server 2003 には、NTLMv2 のみを使用する新しい既定の設定があります。 既定では、Windows Server 2003 および Windows 2000 Server SP3 ベースのドメイン コントローラーでは、"Microsoft ネットワーク サーバー: デジタル署名通信 (always)" ポリシーが有効になっています。 この設定では、SMB サーバーが SMB パケット署名を実行する必要があります。 Windows Server 2003 の変更は、ドメイン コントローラー、ファイル サーバー、ネットワーク インフラストラクチャ サーバー、および任意のorganizationの Web サーバーで、セキュリティを最大化するために異なる設定が必要であるためです。
ネットワークに NTLMv2 認証を実装する場合は、ドメイン内のすべてのコンピューターがこの認証レベルを使用するように設定されていることを確認する必要があります。 Windows 95 または Windows 98 および Windows NT 4.0 用の Active Directory クライアント拡張機能を適用する場合、クライアント拡張機能は NTLMv2 で利用できる強化された認証機能を使用します。 次のいずれかのオペレーティング システムを実行しているクライアント コンピューターは Windows 2000 グループ ポリシー オブジェクトの影響を受けないため、これらのクライアントを手動で構成する必要がある場合があります。
- Microsoft Windows NT 4.0
- Microsoft Windows ミレニアム エディション
- 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 認証を有効にする方法
危険な構成
有害な構成設定を次に示します。
クリア テキストでパスワードを送信し、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 管理コンソール グループ ポリシー Editor スナップインで [NTLMv2 セッション セキュリティ チェックを要求する] ボックスをクリックして選択し、LAN マネージャー認証レベルを 0 に下げると、2 つの設定が競合し、Secpol.msc ファイルまたは GPEdit.msc ファイルに次のエラー メッセージが表示される場合があります。
注
Windows では、ローカル ポリシー データベースを開くことができません。 データベースを開こうとしたときに不明なエラーが発生しました。
セキュリティ構成および分析ツールの詳細については、Windows 2000 または Windows Server 2003 ヘルプ ファイルを参照してください。
この設定を変更する理由
- organizationのクライアントとドメイン コントローラーでサポートされている最も低い一般的な認証プロトコルを増やす必要があります。
- セキュリティで保護された認証がビジネス要件である場合は、LM と NTLM プロトコルのネゴシエーションを禁止する必要があります。
この設定を無効にする理由
クライアントまたはサーバーの認証要件、またはその両方が、共通プロトコルを介した認証が行えないまで増加しました。
シンボリック名:
LmCompatibilityLevel
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\LmCompatibilityLevel互換性の問題の例
Windows Server 2003: 既定では、Windows Server 2003 NTLMv2 の NTLM 応答の送信設定が有効になっています。 そのため、Windows Server 2003 では、Windows NT 4.0 ベースのクラスターまたは LANManager V2.1 ベースのサーバー (OS/2 Lanserver など) に接続しようとすると、初期インストール後に "アクセスが拒否されました" というエラー メッセージが表示されます。 この問題は、以前のバージョンのクライアントから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 User Authentication Module (UAM) では、最小限の暗号化または暗号化は提供されません。 そのため、パスワードは LAN またはインターネット上で簡単に傍受される可能性があります。 UAM は必要ありませんが、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 以上に構成する必要があります。
ネットワーク セキュリティ: LDAP クライアント署名の要件
背景
[ネットワーク セキュリティ: LDAP クライアント署名要件] 設定は、ライトウェイト ディレクトリ アクセス プロトコル (LDAP) BIND 要求を発行するクライアントに代わって要求されるデータ署名のレベルを次のように決定します。
- なし: LDAP BIND 要求は、呼び出し元が指定したオプションで発行されます。
- ネゴシエート署名: Secure Sockets Layer/Transport Layer Security (SSL/TLS) が開始されていない場合、LDAP BIND 要求は、呼び出し元が指定したオプションに加えて、LDAP データ署名オプションを設定して開始されます。 SSL/TLS が開始されている場合、LDAP BIND 要求は呼び出し元が指定したオプションで開始されます。
- 署名が必要: これはネゴシエート署名と同じです。 ただし、LDAP サーバーの中間 saslBindInProgress 応答が LDAP トラフィック署名が必要であることを示していない場合、呼び出し元は LDAP BIND コマンド要求が失敗したと通知されます。
危険な構成
[ネットワーク セキュリティ: LDAP クライアント署名要件] 設定を有効にすると、有害な構成設定になります。 LDAP 署名を要求するようにサーバーを設定する場合は、クライアントで LDAP 署名も構成する必要があります。 LDAP 署名を使用するようにクライアントを構成しないと、サーバーとの通信が妨けられます。 これにより、ユーザー認証、グループ ポリシー設定、ログオン スクリプト、およびその他の機能が失敗します。
この設定を変更する理由
署名されていないネットワーク トラフィックは、侵入者がクライアントとサーバーの間のパケットをキャプチャし、それらを変更し、それらをサーバーに転送する中間者攻撃の影響を受けやすくなります。 これが LDAP サーバーで発生すると、攻撃者は LDAP クライアントからの誤ったクエリに基づいてサーバーが応答する可能性があります。 ネットワーク インフラストラクチャの保護に役立つ強力な物理的なセキュリティ対策を実装することで、企業ネットワークでこのリスクを軽減できます。 さらに、IPSec 認証ヘッダーを使用して、すべてのネットワーク パケットにデジタル署名を要求することで、あらゆる種類の中間者攻撃を防ぐことができます。
シンボリック名:
LDAPClientIntegrity
レジストリ パス :
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LDAP\LDAPClientIntegrity
イベント ログ: セキュリティ ログの最大サイズ
背景
[イベント ログ: セキュリティ ログの最大サイズ] セキュリティ設定では、セキュリティ イベント ログの最大サイズを指定します。 このログの最大サイズは 4 GB です。 この設定を見つけるには、
[Windows 設定]、[ セキュリティ設定] の順に展開します。危険な構成
有害な構成設定を次に示します。
- [監査: セキュリティ監査をログに記録できない場合は直ちにシステムをシャットダウンする] 設定が有効になっている場合に、セキュリティ ログのサイズとセキュリティ ログ保持方法を制限します。 詳細については、この記事の「監査: セキュリティ監査をログに記録できない場合は、システムを直ちにシャットダウンする」セクションを参照してください。
- 対象のセキュリティ イベントが上書きされるようにセキュリティ ログのサイズを制限する。
この設定を増やす理由
ビジネスとセキュリティの要件では、セキュリティ ログのサイズを増やして追加のセキュリティ ログの詳細を処理するか、セキュリティ ログを長期間保持することが決まる場合があります。
この設定を減らす理由
イベント ビューアーログはメモリ マップファイルです。 イベント ログの最大サイズは、ローカル コンピューター内の物理メモリの量と、イベント ログ プロセスで使用できる仮想メモリによって制限されます。 イベント ビューアーで使用できる仮想メモリの量を超えてログ サイズを大きくしても、保持されるログ エントリの数は増えません。
互換性の問題の例
Windows 2000: Service Pack 4 (SP4) より前のバージョンの Windows 2000 を実行しているコンピューターは、[イベントを上書きしない (手動でログをクリアする)] オプションがオンになっている場合、イベント ビューアーの [最大ログ サイズ] 設定で指定されているサイズに達する前に、イベント ログのイベントのログ記録を停止することがあります。
イベント ログ: セキュリティ ログを保持する
背景
[イベント ログ: セキュリティ ログを保持する] セキュリティ設定は、セキュリティ ログの "ラッピング" メソッドを決定します。 この設定を見つけるには、[ Windows 設定] を展開し、[ セキュリティ設定] を展開します。
危険な構成
有害な構成設定を次に示します。
- 上書きされる前にログに記録されたすべてのセキュリティ イベントを保持できない
- セキュリティ イベントが上書きされるように、[最大セキュリティ ログ サイズ] 設定の構成が小さすぎます
- [監査: セキュリティ監査をログに記録できない場合は直ちにシステムをシャットダウンする] 設定が有効になっている間に、セキュリティ ログのサイズと保持方法を制限する
この設定を有効にする理由
[ イベントを日単位で上書き する] 保持方法を選択した場合にのみ、この設定を有効にします。 イベントをポーリングするイベント相関システムを使用する場合は、日数がポーリング頻度の少なくとも 3 倍であることを確認します。 失敗したポーリング サイクルを許可するには、これを行います。
ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用させる
背景
既定では、[ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用する] 設定は、Windows Server 2003 で [定義されていません] に設定されています。 既定では、Windows Server 2003 には、Everyone グループに匿名アクセス トークンは含まれません。
互換性の問題の例
の次の値
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 であるために発生します。この設定を変更する理由
値は、ドメイン コントローラーの OU で GPO を使用して0x1に設定するか、設定する必要があります。ネットワーク アクセス: すべてのユーザーのアクセス許可を匿名ユーザーに適用できるようにする - 信頼の作成を可能にするために有効にします。
注 他のほとんどのセキュリティ設定は、最もセキュリティで保護された状態で0x0に下がる代わりに値が上がります。 より安全な方法は、すべてのドメイン コントローラーではなく、プライマリ ドメイン コントローラー エミュレーターのレジストリを変更することです。 何らかの理由でプライマリ ドメイン コントローラー エミュレーターロールを移動する場合は、新しいサーバーでレジストリを更新する必要があります。
この値を設定した後は、再起動が必要です。
レジストリ パス
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\everyoneincludesanonymous
NTLMv2 認証
セッション セキュリティ
セッション セキュリティは、クライアント セッションとサーバー セッションの最小セキュリティ標準を決定します。 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"危険な構成
この設定は、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 を実行するために Directory Services クライアントを実行する必要があります。 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 署名要求に応答しません。
お勧めしませんが、ドメインで 2003 Windows Server実行されるすべてのドメイン コントローラーで SMB 署名が必要になるのを防ぐことができます。 このセキュリティ設定を構成するには、次の手順に従います。
- 既定のドメイン コントローラーのポリシーを開きます。
- コンピューターの構成\Windows 設定\セキュリティ設定\ローカル ポリシー\セキュリティ オプション フォルダーを開きます。
- [Microsoft ネットワーク サーバー: デジタル署名通信 (常に) ポリシー設定] を見つけてクリックし、[無効] をクリックします。
重要: このセクション、メソッド、またはタスクには、レジストリの変更方法が記載されています。 ただし、レジストリを誤って変更すると、深刻な問題が発生する可能性があります。 そのため、この手順は必ず慎重に行ってください。 さらなる保護のため、レジストリは変更する前にバックアップしてください。 こうしておけば、問題が発生した場合にレジストリを復元できます。 レジストリのバックアップ方法および復元方法の詳細を参照するには、以下のサポート技術情報番号をクリックしてください。
322756 Windows でレジストリをバックアップおよび復元する方法または、レジストリを変更してサーバーでの SMB 署名をオフにします。 手順は次のとおりです。
- [スタート] ボタンをクリックし、[ファイル名を指定して実行] をクリックします。次に、「Regedit」と入力し、[OK] をクリックします。
- 次のサブキーを見つけてクリックします。
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Lanmanserver\Parameters - enablesecuritysignature エントリをクリックします。
- [編集] メニューの [変更] をクリックします。
- [ 値データ ] ボックスに「0」と入力し、[ OK] をクリックします。
- レジストリ エディターを終了します。
- コンピューターを再起動するか、サーバー サービスを停止して再起動します。 これを行うには、コマンド プロンプトで次のコマンドを入力し、各コマンドを入力した後に Enter キーを押します。
net stop server
net start server
注 クライアント コンピューターの対応するキーは、次のレジストリ サブキーにあります。
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
このワークステーションとプライマリ ドメインの間の信頼関係が失敗しました。
関連情報を参照するには、以下のサポート技術情報番号をクリックしてください。
324802 Windows Server 2003 でシステム サービスのセキュリティを設定するようにグループ ポリシーを構成する方法
816585 Windows Server 2003 で定義済みのセキュリティ テンプレートを適用する方法