このセクションでは、Microsoft Entra パスワード保護に関してよく寄せられる質問の多くへの回答を提供します。
一般的な質問
安全なパスワードを選択する方法に関して、ユーザーにどのようなガイダンスが与えられますか?
このトピックに関する Microsoft の現在のガイダンスについては、次のリンクを参照してください。
オンプレミスの Microsoft Entra パスワード保護はパブリックでないクラウドでサポートされますか?
オンプレミスの Microsoft Entra パスワード保護は、Azure グローバルと Azure Government の両方のクラウドでサポートされています。
Microsoft Entra 管理センターでは、サポートされているクラウド以外の場合でもオンプレミス固有の [Windows Server Active Directory のパスワード保護] 構成を変更できます。このような変更は保存されますが、そうでなければ実行されません。 サポートされていないクラウドでは、オンプレミスのプロキシ エージェントまたはフォレストの登録はサポートされません。そのような登録の試行は常に失敗します。
どのようにして Microsoft Entra パスワード保護の利点を自分のオンプレミスのユーザーのサブセットに適用できますか?
サポートされていません。 デプロイして有効にされると、Microsoft Entra パスワード保護は区別を行わず、すべてのユーザーが同じセキュリティ上の恩恵を受けます。
パスワードの変更とパスワードの設定 (またはリセット) の違いは何ですか?
パスワードの変更は、ユーザーが古いパスワードを知っていることを証明した後に新しいパスワードを選択する場合のアクションです。 パスワードの変更は、たとえば、ユーザーが Windows にログインした後に新しいパスワードを選択するように求められたときに発生します。
パスワードの設定 (パスワードのリセットとも呼ばれます) は、たとえば Active Directory ユーザーとコンピューターの管理ツールを使用して、管理者がアカウントのパスワードを新しいパスワードに置き換える場合のアクションです。 この操作には高いレベルの特権 (通常はドメイン管理者) が必要であり、通常、操作を実行する担当者は古いパスワードを知りません。 ヘルプ デスクのシナリオで、パスワードの設定がよく実行されます。たとえば、パスワードを忘れたユーザーを支援する場合などです。 また、パスワードを指定して新しいユーザー アカウントを初めて作成するときにもパスワードの設定イベントが発生します。
パスワード検証ポリシーは、実行されているのがパスワードの変更か設定かに関係なく同じように動作します。 Microsoft Entra パスワード保護 DC エージェント サービスは、パスワードの変更または設定の操作が行われたかをユーザーに通知するために、さまざまなイベントをログに記録します。 「Microsoft Entra パスワード保護の監視とログ」を参照してください。
Microsoft Entra のパスワード保護では、インストール後に既存のパスワードが検証されますか?
いいえ。Microsoft Entra のパスワード保護では、パスワードの変更または設定操作中に、クリア テキストのパスワードに対してのみパスワード ポリシーを適用できます。 Active Directory によってパスワードが受け入れられると、そのパスワードの認証プロトコル固有のハッシュのみが保持されます。 平文のパスワードは保存されないため、Microsoft Entra パスワード保護は既存のパスワードを検証できません。
Microsoft Entra のパスワード保護を最初にデプロイした後、すべてのユーザーとアカウントでは、時間の経過に伴い通常どおり既存のパスワードの有効期限が切れると、Microsoft Entra のパスワード保護で検証されたパスワードを使用し始めます。 必要に応じて、ユーザー アカウント パスワードを 1 回だけ手動で期限切れにすることによって、このプロセスを高速化できます。
[パスワードを無期限にする] を使用して構成されたアカウントの場合は、手動で期限切れにしない限りパスワードの変更が強制されることはありません。
Active Directory ユーザーとコンピューター管理スナップインを利用して弱いパスワードを設定しようとすると、重複パスワード拒否イベントがログに記録されるのはなぜですか。
Active Directory ユーザーとコンピューター管理スナップインではまず、Kerberos プロトコルを利用して新しいパスワードを設定しようとします。 エラーが発生すると、このスナップインでは次に、レガシ (SAM RPC) プロトコル (使用される特定のプロトコルは重要ではありません) を利用してパスワードを設定しようとします。 新しいパスワードが Microsoft Entra パスワード保護で脆弱であると見なされると、このスナップイン動作の結果、2 セットのパスワード リセット拒否イベントがログに記録されることになります。
Microsoft Entra パスワード保護のパスワード検証イベントが空のユーザー名でログに記録されるのはなぜですか。
Active Directory では、パスワードをテストして、ドメインの現在のパスワード複雑さ要件が満たされているかどうかを確認する機能がサポートされています (たとえば、NetValidatePasswordPolicy API を使用して)。 この方法でパスワードが検証される際、テストには、Microsoft Entra パスワード保護などのパスワード フィルター dll ベースの製品による検証も含まれます。しかし、所定のパスワード フィルター dll に渡されるユーザー名は空になります。 このシナリオにおいても、Microsoft Entra パスワード保護は、現在有効なパスワード ポリシーを使用してパスワードを検証し、結果をキャプチャするためのイベント ログ メッセージを発行しますが、イベント ログ メッセージのユーザー名フィールドは空になります。
Microsoft Entra ID でパスワードの変更を試みたところ、"同じパスワードがこれまでに何度も使われています。 より推測されにくいパスワードをお選びください。" という応答が返されたハイブリッド ユーザーがいます。この場合、オンプレミスの検証の試行が表示されないのはなぜですか?
ハイブリッド ユーザーが Microsoft Entra ID でパスワードを変更すると、Microsoft Entra SSPR、MyAccount、または別の Microsoft Entra パスワード変更メカニズムを使用した場合でも、そのパスワードはクラウド内のグローバルおよびカスタムの禁止パスワード リストに照らして評価されます。 パスワードがパスワード書き戻しにより Active Directory に到達するときには、Microsoft Entra ID での検証が完了しています。
Microsoft Entra ID で開始され、検証に失敗したハイブリッド ユーザーのパスワードのリセットと変更は、Microsoft Entra 監査ログで確認できます。 「Microsoft Entra ID でのセルフサービス パスワード リセットのトラブルシューティング」を参照してください。
その他のパスワードフィルターベースの製品と並行して Microsoft Entra パスワード保護をインストールすることはサポートされていますか?
はい。 複数の登録されたパスワード フィルター dll に対するサポートは、コア Windows 機能であり、Microsoft Entra パスワード保護に固有のものではありません。 登録されたパスワード フィルター DLL はすべて、パスワードを受け入れる前に一致している必要があります。
Azure を使用せずに、Active Directory 環境に Microsoft Entra パスワード保護をデプロイし、構成するにはどうすればよいですか?
サポートされていません。 Microsoft Entra パスワード保護は、オンプレミスの Active Directory 環境への拡張をサポートする Azure の機能です。
Active Directory レベルでポリシーの内容を変更するにはどうすればよいですか?
サポートされていません。 ポリシーは、Microsoft Entra 管理センターを使用してのみ管理できます。 前の質問も参照してください。
sysvol レプリケーションに DFSR が必要なのはなぜですか?
FRS (DFSR に対する先行テクノロジ) には、多くの既知の問題があり、より新しいバージョンの Windows Server Active Directory ではまったくサポートされていません。 FRS で構成されたドメインでは Microsoft Entra パスワード保護のテストは全く行われません。
詳細については、次の記事を参照してください。
sysvol レプリケーションを DFSR に移行するケース
ご利用のドメインでまだ DFSR を使用していない場合、Microsoft Entra パスワード保護をインストールする前に DFSR 使用にドメインを移行する必要があります。 詳細については、次のリンクを参照してください。
SYSVOL レプリケーション移行ガイド: FRS レプリケーションから DFS レプリケーションに移行する
警告
Microsoft Entra パスワード保護 DC エージェント ソフトウェアは、現在、sysvol レプリケーションにまだ FRS を使用しているドメインのドメイン コントローラーにインストールされますが、この環境ではソフトウェアは正しく機能しません。 その他のマイナスの副作用としては、個々のファイルを複製できない、sysvol 復元処理が成功したように見えたが、一部のファイルの複製に失敗しており、何のエラーも表示されない、などがあります。 DFSR に固有のメリットと Microsoft Entra パスワード保護のデプロイのブロック解除の両方のために、できるだけ早く DFSR を使用するようにドメインの移行を行う必要があります。 今後のバージョンでは、ドメインで依然として FRS を使用している場合、このソフトウェアは自動的に無効になります。
この機能では、ドメイン sysvol 共有にどのくらいのディスク領域が必要ですか?
正確な領域の使用量は、Microsoft グローバル禁止リストとテナントごとのカスタム リストで禁止されているトークンの数と長さ、および暗号化オーバーヘッドなどの要素に依存するため、さまざまに異なります。 これらのリストの内容は、将来拡大する可能性があります。 このことを念頭に、妥当な予想として、機能には、ドメイン sysvol 共有に最低 5 メガバイトの領域が必要になります。
DC エージェント ソフトウェアのインストールまたはアップグレードに再起動が必要なのはなぜですか?
これはコア Windows 動作によって必要になります。
特定のプロキシ サーバーを使用するように DC エージェントを構成する方法はありますか?
いいえ。 プロキシ サーバーはステートレスであるため、特定のどのプロキシ サーバーを使用するかは重要ではありません。
Microsoft Entra Connect などの他のサービスと並行して Microsoft Entra パスワード保護プロキシ サービスをデプロイしても大丈夫ですか?
はい。 Microsoft Entra パスワード保護プロキシ サービスと Microsoft Entra Connect は、互いに直接競合することはないはずです。
残念ながら、Microsoft Entra パスワード保護プロキシ ソフトウェアによってインストールされた Microsoft Entra Connect エージェント アップデーター サービスのバージョンと、Microsoft Entra アプリケーション プロキシ ソフトウェアによってインストールされたサービスのバージョンとの間には互換性がありません。 この非互換性が原因で、エージェント アップデーター サービスがソフトウェアの更新のために Azure に接続できなくなっている可能性があります。 Microsoft Entra パスワード保護プロキシとMicrosoft Entra アプリケーション プロキシを同じマシンにインストールすることはお勧めしません。
DC エージェントとプロキシはどのような順序でインストールして登録する必要がありますか?
プロキシ エージェントのインストール、DC エージェントのインストール、フォレストの登録、プロキシの登録は、任意の順序での実行がサポートされています。
この機能のデプロイによるドメイン コントローラーでのパフォーマンスの影響を懸念する必要はありますか?
Microsoft Entra パスワード保護 DC エージェント サービスは、既存の正常な Active Directory デプロイにおいてドメイン コントローラーのパフォーマンスに著しく影響を及ぼすことはないはずです。
ほとんどの Active Directory デプロイで、パスワード変更操作は、特定のどのドメイン コントローラーでもワークロード全体のごく一部になります。 たとえば、10000 ユーザー アカウントと 30 日に設定された MaxPasswordAge ポリシーがある Active Directory ドメインを想像してください。 平均で、このドメインでは毎日 10000/30 = 333 回までのパスワード変更操作が発生しますが、これは 1 つのドメイン コントローラーの場合でも少ない操作数です。 可能性のある最悪のケースのシナリオを考えてみます。1 時間に 1 つの DC でこの 333 回までのパスワードの変更が行われたとします。 たとえば、月曜日の朝に多数の従業員が全員出勤してくる場合に、このシナリオが発生する可能性があります。 この場合でも、333 回まで/60 分 = 1 分あたり 6 回のパスワードの変更が発生することになり、これも同様に重大な負荷ではありません。
ただし現在のドメイン コントローラーが既にパフォーマンス制限付きレベルで実行している (たとえば、CPU、ディスク領域、ディスク I/O に関して最大限に達しているなど) 場合は、この機能をデプロイする前に、ドメイン コン ローラーを追加するか、または使用可能なディスク領域を拡張することをお勧めします。 sysvol ディスク領域の使用量に関する上記の質問も参照してください。
ドメイン内のほんの一部の DC で Microsoft Entra パスワード保護をテストしたいと思います。 ユーザー パスワードの変更で、これらの特定の DC を強制的に使用させることはできますか?
いいえ。 Windows クライアント OS は、ユーザーがパスワードを変更するときに、どのドメイン コントローラーを使用するかを制御します。 ドメイン コントローラーは、Active Directory サイトとサブネット割り当て、環境固有のネットワーク構成などの要素に基づいて選択されます。 Microsoft Entra パスワード保護は、これらの要素を制御せず、ユーザーのパスワードを変更するためにどのドメイン コントローラーが選択されるかに影響を与えることはできません。
この目標に部分的に到達する 1 つの方法は、特定の Active Directory サイト内のすべてのドメイン コントローラーに Microsoft Entra パスワード保護をデプロイすることです。 このアプローチは、そのサイトに割り当てられる Windows クライアントに対し、したがってそれらのクライアントにログインし、パスワードを変更するユーザーに対しても、妥当なカバレッジを提供します。
プライマリ ドメイン コントローラー (PDC) にだけ Microsoft Entra パスワード保護 DC エージェント サービスをインストールした場合、ドメイン内のその他すべてのドメイン コントローラーも保護されますか?
不正解です。 PDC 以外の特定のドメイン コントローラーで、ユーザーのパスワードが変更された場合、クリアテキスト パスワードは PDC に送信されません (この考えは一般的な誤解です)。 特定の DC で、新しいパスワードが受け入れられると、その DC はそのパスワードを使用して、そのパスワードのさまざまな認証プロトコル固有のハッシュを作成し、ディレクトリでそれらのハッシュを保持します。 クリア テキスト パスワードは保持されません。 更新されたハッシュが、PDC にレプリケートされます。 場合により、ユーザー パスワードは、ネットワーク トポロジや Active Directory サイトの設計などのさまざまな要素に応じて、PDC で直接変更されることがあります。 (前の質問を参照してください。)
まとめると、PDC への Microsoft Entra パスワード保護 DC エージェント サービスのデプロイでは、ドメイン全体で 100% の機能のセキュリティ カバレッジに到達する必要があります。 PDC のみに機能をデプロイしても、ドメイン内の他の DC には、Microsoft Entra パスワード保護のセキュリティ上の恩恵はありません。
オンプレミスの Active Directory 環境にエージェントをインストールした後でも、カスタム スマート ロックアウトが機能しないのはなぜですか?
カスタム スマート ロックアウトは Microsoft Entra ID でのみサポートされています。 エージェントがインストールされていても、オンプレミスの Active Directory 環境では、Microsoft Entra 管理センターでカスタム スマート ロックアウトの設定を変更しても環境への影響はありません。
Microsoft Entra パスワード保護で、System Center Operations Manager 管理パックは使用できますか?
不正解です。
ポリシーが監査モードになるよう構成した場合でも Microsoft Entra ID が依然として脆弱なパスワードを拒否しているのはなぜですか?
監査モードがサポートされるのは、オンプレミスの Active Directory 環境でのみです。 Microsoft Entra ID は、パスワードを評価する際、暗黙的に常に "強制" モードになります。
パスワードが Microsoft Entra パスワード保護によって拒否された場合、ユーザーには従来の Windows エラー メッセージが表示されます。 このエラー メッセージをカスタマイズして、実際に発生したことをユーザーに知らせることはできますか?
いいえ。 ドメイン コントローラーによってパスワードが拒否されたときにユーザーに表示されるエラー メッセージは、ドメイン コントローラーではなく、クライアント コンピューターによって制御されています。 この動作は、パスワードが既定の Active Directory パスワード ポリシーによって拒否されたか、Microsoft Entra パスワード保護などのパスワード フィルター ベースのソリューションによって拒否されたかにかかわらず、発生します。
パスワードのテスト手順
ソフトウェアの適切な動作を検証するため、およびパスワード評価アルゴリズムについて理解を深めるために、さまざまなパスワードの基本的なテストを実行することが望ましい場合があります。 このセクションでは、反復可能な結果を生成することを目的とした、このようなテストの方法について概説します。
このような手順に従う必要があるのはなぜでしょうか? オンプレミスの Active Directory 環境には、パスワードの制御された反復可能なテストを行うことが困難になる要因がいくつかあります。
- パスワード ポリシーが Azure で構成および永続化され、ポリシーのコピーが、ポーリング メカニズムを使用して、オンプレミスの DC エージェントによって定期的に同期されます。 このポーリング サイクルに固有の待機時間が原因で混乱が発生する可能性があります。 たとえば、Azure でポリシーを構成しても、それを DC エージェントに同期することを忘れた場合、テストで期待どおりの結果が得られないことがあります。 ポーリング間隔は、1 時間に 1 回になるように現在ハードコーディングされていますが、ポリシーの変更間に 1 時間待機することは、対話型のテスト シナリオでは理想的ではありません。
- 新しいパスワード ポリシーがドメイン コントローラーに同期された後、それが他のドメイン コントローラーにレプリケートされるまで、さらに待機時間が発生します。 最新バージョンのポリシーをまだ受け取っていないドメイン コントローラーに対してパスワードの変更をテストした場合、これらの遅延が原因で、予期しない結果が発生する可能性があります。
- ユーザー インターフェイスを使用してパスワードの変更をテストした場合、結果の信頼性を確保することが難しくなります。 たとえば、ユーザー インターフェイスに無効なパスワードを誤入力することは容易に起こります。これは特に、ほとんどのパスワード ユーザー インターフェイスでユーザー入力が非表示になっているためです (たとえば、Windows の Ctrl + Alt + Delete -> [パスワードの変更] UI など)。
- ドメインに参加しているクライアントからパスワードの変更をテストするときに、どのドメイン コントローラーを使用するかを厳密に制御することはできません。 Windows クライアント OS では、Active Directory サイトとサブネットの割り当て、環境固有のネットワーキング構成などの要因に基づいてドメイン コントローラーが選択されます。
これらの問題を回避するために、下の手順は、ドメイン コントローラーにログインしているときのパスワード リセットのコマンドライン テストに基づいています。
警告
これらの手順はテスト環境でのみ使用する必要があります。これは、DC エージェント サービスが停止している間、受信するすべてのパスワードの変更とリセットが検証されずに受け入れられてしまうため、およびドメイン コントローラーへのログインに固有のリスクが増加するのを避けるためです。
次の手順は、DC エージェントが少なくとも 1 つのドメイン コントローラーにインストールされていること、少なくとも 1 つのプロキシがインストールされていること、およびプロキシとフォレストの両方が登録されていることを前提としています。
DC エージェント ソフトウェアがインストールされ、再起動されたドメイン コントローラーに、ドメイン管理者の資格情報 (または、テスト ユーザー アカウントを作成し、パスワードをリセットするための十分な特権を持つその他の資格情報) を使用してログオンします。
イベント ビューアーを開いて、DC エージェント管理イベント ログに移動します。
昇格した [コマンド プロンプト] ウィンドウを開きます。
パスワード テストを実行するためのテスト アカウントを作成します。
ユーザー アカウントを作成する方法は多数ありますが、反復的なテスト サイクル中にこれを簡単に行う方法として、コマンドライン オプションが提供されています。
net.exe user <testuseraccountname> /add <password>下の説明のために、"ContosoUser" という名前のテスト アカウントを作成したと仮定します。次に例を示します。
net.exe user ContosoUser /add <password>認証管理者以上の権限で Microsoft Entra 管理センターにサインインします。
[保護]、[認証方法]、[パスワード保護] の順に進みます。
実行したいテストの必要に応じて Microsoft Entra パスワード保護ポリシーを変更します。 たとえば、強制または監査のモードを構成する場合や、カスタムの禁止パスワード リストの禁止語句のリストを変更する場合があります。
DC エージェント サービスを停止および再起動して、新しいポリシーを同期します。
この手順は、さまざまな方法で実行できます。 1 つの方法は、[Microsoft Entra パスワード保護 DC エージェント サービス] を右クリックし、"再起動" を選択することで、サービス管理の管理コンソールを使用することです。 もう 1 つの方法では、次のようにコマンド プロンプト ウィンドウから実行できます。
net stop AzureADPasswordProtectionDCAgent && net start AzureADPasswordProtectionDCAgentイベント ビューアーを確認して、新しいポリシーがダウンロードされていることを確認します。
DC エージェント サービスが停止して開始されるたびに、連続して発行された 2 つの 30006 イベントが表示されます。 1 番目の 30006 イベントには、sysvol 共有のディスクにキャッシュされたポリシーが反映されます。 2 番目の 30006 イベント (存在する場合) では、テナント ポリシーの日付が更新されており、その場合、Azure からダウンロードされたポリシーが反映されます。 テナント ポリシーの日付値は、ポリシーが Azure からダウンロードされたおおよそのタイムスタンプを示すように現在コーディングされています。
2 番目の 30006 イベントが表示されない場合は、続行する前に問題をトラブルシューティングする必要があります。
30006 イベントは、この例のようになります。
The service is now enforcing the following Azure password policy. Enabled: 1 AuditOnly: 0 Global policy date: 2018-05-15T00:00:00.000000000Z Tenant policy date: 2018-06-10T20:15:24.432457600Z Enforce tenant policy: 1たとえば、強制と監査のモードを切り替えると、AuditOnly フラグが変更されます (AuditOnly=0 が設定されている上のポリシーは強制モードです)。カスタムの禁止パスワード リストに対する変更は、上の 30006 イベントには直接的には反映されません (また、セキュリティ上の理由から、他のどこにもログされません)。 このような変更の後に Azure からポリシーを正常にダウンロードした場合は、変更されたカスタムの禁止パスワード リストも含まれます。
テスト ユーザー アカウントの新しいパスワードのリセットを試行することで、テストを実行します。
この手順は、コマンド プロンプト ウィンドウから次のように実行できます。
net.exe user ContosoUser <password>コマンドを実行した後、イベント ビューアーを確認することで、コマンドの結果に関する詳細情報を得ることができます。 パスワード検証結果イベントについては、「DC エージェント管理イベント ログ」というトピックを参照してください。net.exe コマンドからの対話型出力に加えて、このようなイベントを使用して、テストの結果を検証します。
例を試してみましょう。Microsoft グローバル リストで禁止されているパスワードを設定しようとしています (このリストはドキュメント化されていませんが、ここでは既知の禁止語句に対してテストすることができます)。 この例では、ポリシーを強制モードに構成し、カスタムの禁止パスワード リストに 0 個の語句を追加したことを前提としています。
net.exe user ContosoUser PassWord The password does not meet the password policy requirements. Check the minimum password length, password complexity and password history requirements. More help is available by typing NET HELPMSG 2245.ドキュメントによると、このテストはパスワード リセット操作であったため、ContosoUser ユーザーに対して 10017 および 30005 イベントが表示されます。
10017 イベントは、この例のようになります。
The reset password for the specified user was rejected because it did not comply with the current Azure password policy. Please see the correlated event log message for more details. UserName: ContosoUser FullName:30005 イベントは、この例のようになります。
The reset password for the specified user was rejected because it matched at least one of the tokens present in the Microsoft global banned password list of the current Azure password policy. UserName: ContosoUser FullName:以上です。別の例を試してみましょう。 今回は、ポリシーが監査モードのときに、カスタムの禁止リストによって禁止されているパスワードを設定してみます。 この例は、次の手順を実行したことを前提としています。ポリシーを監査モードに構成し、カスタムの禁止パスワード リストに "lachrymose" という語句を追加し、上記のように、DC エージェント サービスを停止して開始することで、結果の新しいポリシーをドメイン コントローラーに同期しました。
次に、禁止パスワードのバリエーションを設定します。
net.exe user ContosoUser LaChRymoSE!1 The command completed successfully.今回は、ポリシーが監査モードであるために成功したということを覚えておいてください。 ContosoUser ユーザーに対して 10025 および 30007 イベントが表示されます。
10025 イベントは、この例のようになります。
The reset password for the specified user would normally have been rejected because it did not comply with the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. Please see the correlated event log message for more details. UserName: ContosoUser FullName:30007 イベントは、この例のようになります。
The reset password for the specified user would normally have been rejected because it matches at least one of the tokens present in the per-tenant banned password list of the current Azure password policy. The current Azure password policy is configured for audit-only mode so the password was accepted. UserName: ContosoUser FullName:前のステップで説明した手順を使用して、引き続き任意のさまざまなパスワードをテストし、イベント ビューアーで結果を確認します。 Microsoft Entra 管理センターでポリシーを変更する必要がある場合は、前に説明したように、新しいポリシーを DC エージェントに同期することを忘れないでください。
Microsoft Entra パスワード保護のパスワード検証動作の制御されたテストを実行できるようにする手順について説明しました。 ドメイン コントローラーでコマンド ラインからユーザー パスワードを直接リセットすることは、このようなテストを実行するための特殊な手段のように思われるかもしれませんが、前述のように、この目的は反復可能な結果を生成することです。 さまざまなパスワードをテストする際には、パスワード評価アルゴリズムを念頭に置いてください。これは、予期しない結果を説明するのに役立つ場合があるためです。
警告
すべてのテストが完了したら、テストのために作成したユーザー アカウントを忘れずに削除してください。
その他のコンテンツ
次のリンクは、主要な Microsoft Entra パスワード保護ドキュメントの一部ではありませんが、機能に関する追加情報の有用なソースになるかもしれません。
メールのフィッシング保護ガイド パート 15: Microsoft Entra パスワード保護サービスを実装する (オンプレミスの場合も)
Microsoft Premier\Unified サポート トレーニングの提供開始
Microsoft Entra パスワード保護の詳細と環境へのデプロイについてさらに知りたい場合は、Premier または Unified サポート契約を行っているお客様が利用可能な Microsoft プロアクティブ サービスが利用できます。 サービスの名称は Microsoft Entra ID: パスワード保護です。 詳細については、カスタマー サクセス アカウント マネージャーにお問い合わせください。
次のステップ
ここでは回答されていないオンプレミスの Microsoft Entra パスワード保護に関するご質問がある場合、以下のフィードバック項目を送信してください。