Azure AD パスワード保護のトラブルシューティングAzure AD Password Protection troubleshooting

Azure AD パスワード保護をデプロイした後、トラブルシューティングを必要とする場合があります。After the deployment of Azure AD Password Protection, troubleshooting may be required. この記事では、いくつかの一般的なトラブルシューティング手順を理解しやすいように詳しく説明しています。This article goes into detail to help you understand some common troubleshooting steps.

DC エージェントがディレクトリ内でプロキシを見つけることができないThe DC agent cannot locate a proxy in the directory

この問題の主な症状は、DC エージェント管理イベント ログ内の 30017 イベントに相当します。The main symptom of this problem is 30017 events in the DC agent Admin event log.

この問題の一般的な原因は、プロキシがまだ登録されていないことです。The usual cause of this issue is that a proxy has not yet been registered. プロキシが登録されている場合は、特定の DC エージェントでそのプロキシを表示できるようになるまでの AD レプリケーションの待機時間が原因の遅延がある可能性があります。If a proxy has been registered, there may be some delay due to AD replication latency until a particular DC agent is able to see that proxy.

DC エージェントがプロキシ サーバーと通信できないThe DC agent is not able to communicate with a proxy

この問題の主な症状は、DC エージェント管理イベント ログ内の 30018 イベントに相当します。The main symptom of this problem is 30018 events in the DC agent Admin event log. この問題には、次に示すいくつかの原因が考えられます。This problem may have several possible causes:

  1. DC エージェントが、登録されているプロキシへのネットワーク接続を許可しない、ネットワークの分離された部分にあります。The DC agent is located in an isolated portion of the network that does not allow network connectivity to the registered proxy(s). この問題は、Azure からパスワード ポリシーをダウンロードするために他の DC エージェントがプロキシと通信できる限りは、問題にならない可能性があります。This problem may be benign as long as other DC agents can communicate with the proxy(s) in order to download password policies from Azure. ダウンロードが完了すると、これらのポリシーは、sysvol 共有内のポリシー ファイルのレプリケーションを介して、分離された DC によって取得されます。Once downloaded, those policies will then be obtained by the isolated DC via replication of the policy files in the sysvol share.

  2. プロキシ ホスト コンピューターが RPC エンドポイント マッパー エンドポイント (ポート 135) へのアクセスをブロックしているThe proxy host machine is blocking access to the RPC endpoint mapper endpoint (port 135)

    Azure AD パスワード保護プロキシのインストーラーでは、ポート 135 へのアクセスを許可する Windows ファイアウォールの受信規則が自動的に作成されます。The Azure AD Password Protection Proxy installer automatically creates a Windows Firewall inbound rule that allows access to port 135. このルールを後で削除したり無効にしたりすると、DC エージェントはプロキシ サービスと通信できなくなります。If this rule is later deleted or disabled, DC agents will be unable to communicate with the Proxy service. 別のファイアウォール製品ではなく組み込みの Windows ファイアウォールを無効にしている場合は、そのファイアウォールを、ポート 135 へのアクセスを許可するように構成する必要があります。If the builtin Windows Firewall has been disabled in lieu of another firewall product, you must configure that firewall to allow access to port 135.

  3. プロキシ ホスト コンピューターがプロキシ サービスによってリッスンされる RPC エンドポイント (動的または静的) へのアクセスをブロックしているThe proxy host machine is blocking access to the RPC endpoint (dynamic or static) listened on by the Proxy service

    Azure AD パスワード保護プロキシのインストーラーでは、Azure AD パスワード保護プロキシ サービスによってリッスンされる受信ポートへのアクセスを許可する Windows ファイアウォールの受信規則が、自動的に作成されます。The Azure AD Password Protection Proxy installer automatically creates a Windows Firewall inbound rule that allows access to any inbound ports listened to by the Azure AD Password Protection Proxy service. このルールを後で削除したり無効にしたりすると、DC エージェントはプロキシ サービスと通信できなくなります。If this rule is later deleted or disabled, DC agents will be unable to communicate with the Proxy service. 別のファイアウォール製品ではなく組み込みの Windows ファイアウォールを無効にしている場合は、そのファイアウォールを、Azure AD パスワード保護プロキシ サービスによってリッスンされる受信ポートへのアクセスを許可するように構成する必要があります。If the builtin Windows Firewall has been disabled in lieu of another firewall product, you must configure that firewall to allow access to any inbound ports listened to by the Azure AD Password Protection Proxy service. この構成は、より具体的には、(Set-AzureADPasswordProtectionProxyConfiguration コマンドレットを使用して) プロキシ サービスが特定の静的な RPC ポートをリッスンするように構成されている場合に行われることがあります。This configuration may be made more specific if the Proxy service has been configured to listen on a specific static RPC port (using the Set-AzureADPasswordProtectionProxyConfiguration cmdlet).

  4. プロキシ ホスト コンピューターは、ドメイン コントローラーがコンピューターにログオンする機能を許可するようには構成されていません。The proxy host machine is not configured to allow domain controllers the ability to log on to the machine. この動作は、"ネットワーク経由でコンピューターへアクセス" ユーザー特権の割り当てによって制御されます。This behavior is controlled via the "Access this computer from the network" user privilege assignment. フォレスト内のすべてのドメインのすべてのドメイン コントローラーに、この特権を付与する必要があります。All domain controllers in all domains in the forest must be granted this privilege. 多くの場合、この設定は、より大きなネットワーク強化作業の一部として制約されます。This setting is often constrained as part of a larger network hardening effort.

プロキシ サービスが Azure と通信できないProxy service is unable to communicate with Azure

  1. プロキシ コンピューターが「デプロイ要件」に示されているエンドポイントに接続できることを確認してください。Ensure the proxy machine has connectivity to the endpoints listed in the deployment requirements.

  2. フォレストとすべてのプロキシ サーバーが同じ Azure テナントに対して登録されていることを確認します。Ensure that the forest and all proxy servers are registered against the same Azure tenant.

    この要件は、PowerShell コマンドレット Get-AzureADPasswordProtectionProxyGet-AzureADPasswordProtectionDCAgent を実行し、返された各項目の AzureTenant プロパティを比較することで確認できます。You can check this requirement by running the Get-AzureADPasswordProtectionProxy and Get-AzureADPasswordProtectionDCAgent PowerShell cmdlets, then compare the AzureTenant property of each returned item. 正しく動作するためには、報告されたテナント名がすべての DC エージェントとプロキシ サーバーにおいて同じである必要があります。For correct operation, the reported tenant name must be the same across all DC agents and proxy servers.

    Azure テナントの登録に矛盾した状態が存在する場合、Register-AzureADPasswordProtectionProxyRegister-AzureADPasswordProtectionForest のいずれかまたは両方の PowerShell コマンドレットを必要に応じて実行し、すべての登録について確実に同じ Azure テナントの資格情報を使用することで、この問題を解決できます。If an Azure tenant registration mismatch condition does exist, this problem can be fixed by running the Register-AzureADPasswordProtectionProxy and/or Register-AzureADPasswordProtectionForest PowerShell cmdlets as needed, making sure to use credentials from the same Azure tenant for all registrations.

DC エージェントがパスワード ポリシー ファイルを暗号化または暗号化解除できないDC agent is unable to encrypt or decrypt password policy files

Azure AD パスワード保護には、Microsoft キー配布サービスによって提供される暗号化と復号化の機能に対する重要な依存関係があります。Azure AD Password Protection has a critical dependency on the encryption and decryption functionality supplied by the Microsoft Key Distribution Service. 暗号化または暗号化解除の失敗は、さまざまな症状で示され、複数の原因が存在する可能性があります。Encryption or decryption failures can manifest with a variety of symptoms and have several potential causes.

  1. KDS サービスが有効になっていて、ドメイン内の Windows Server 2012 以降のすべてのドメイン コントローラーで機能することを確認します。Ensure that the KDS service is enabled and functional on all Windows Server 2012 and later domain controllers in a domain.

    既定では、KDS サービスのサービス開始モードは、手動 (トリガーで開始) として構成されます。By default the KDS service's service start mode is configured as Manual (Trigger Start). この構成は、クライアントが初めてサービスを使用しようとすると、サービスオンデマンドで開始されることを意味します。This configuration means that the first time a client tries to use the service, it is started on-demand. この既定のサービス開始モードは、Azure AD パスワード保護で使用してもかまいません。This default service start mode is acceptable for Azure AD Password Protection to work.

    KDS サービス開始モードが [無効] に構成されている場合、Azure AD パスワード保護を正常に機能させるためには、この構成を修正する必要があります。If the KDS service start mode has been configured to Disabled, this configuration must be fixed before Azure AD Password Protection will work properly.

    この問題の簡単なテストは、サービス管理 MMC コンソールを使用するか、他の管理ツールを使用して (たとえば、コマンド プロンプト コンソールから "net start kdssvc" を実行して)、KDS サービスを手動で開始することです。A simple test for this issue is to manually start the KDS service, either via the Service management MMC console, or using other management tools (for example, run "net start kdssvc" from a command prompt console). KDS サービスは、正常に開始して実行を維持することが期待されます。The KDS service is expected to start successfully and stay running.

    KDS サービスを開始できない最も一般的な根本原因は、Active Directory ドメイン コントローラーのオブジェクトが既定のドメイン コントローラー OU の外部にあることです。The most common root cause for the KDS service being unable to start is that the Active Directory domain controller object is located outside of the default Domain Controllers OU. この構成は KDS サービスではサポートされておらず、Azure AD パスワード保護によって課せられた制限ではありません。This configuration is not supported by the KDS service and is not a limitation imposed by Azure AD Password Protection. この状態の修正は、ドメイン コントローラーのオブジェクトを既定のドメイン コントローラー OU の下の場所に移動することです。The fix for this condition is to move the domain controller object to a location under the default Domain Controllers OU.

  2. Windows Server 2012 R2 から Windows Server 2016 での、互換性のない KDS 暗号化バッファー形式の変更Incompatible KDS encrypted buffer format change from Windows Server 2012 R2 to Windows Server 2016

    Windows Server 2016 で導入された KDS セキュリティ修正プログラムでは、KDS 暗号化バッファーの形式が変更されており、これらのバッファーは、Windows Server 2012 および Windows Server 2012 R2 での暗号化解除に失敗することがあります。A KDS security fix was introduced in Windows Server 2016 that modifies the format of KDS encrypted buffers; these buffers will sometimes fail to decrypt on Windows Server 2012 and Windows Server 2012 R2. 逆方向は問題ありません。Windows Server 2012 および Windows Server 2012 R2 で KDS 暗号化されたバッファーは常に、Windows Server 2016 以降で正常に暗号化解除されます。The reverse direction is okay - buffers that are KDS-encrypted on Windows Server 2012 and Windows Server 2012 R2 will always successfully decrypt on Windows Server 2016 and later. Active Directory ドメイン内のドメイン コントローラーでこれらのオペレーティング システムが混在して実行されている場合は、Azure AD パスワード保護の暗号化解除エラーがときどき報告されることがあります。If the domain controllers in your Active Directory domains are running a mix of these operating systems, occasional Azure AD Password Protection decryption failures may be reported. セキュリティ修正プログラムの性質上、また特定の時点でどの Azure AD パスワード保護 DC エージェント上のドメイン コントローラーによってデータが暗号化されるかわからないため、これらの障害のタイミングや症状を正確に予測することはできません。It is not possible to accurately predict the timing or symptoms of these failures given the nature of the security fix, and given that it is non-deterministic which Azure AD Password Protection DC Agent on which domain controller will encrypt data at a given time.

    Microsoft はこの問題の修正を調査していますが、まだ ETA は利用できません。Microsoft is investigating a fix for this issue but no ETA is available yet. それまでの間は、このような互換性のないオペレーティング システムを Active Directory ドメインに混在させないようにする以外に、この問題を回避することはできません。In the meantime, there is no workaround for this issue other than to not run a mix of these incompatible operating systems in your Active Directory domain(s). つまり、Windows Server 2012 と Windows Server 2012 R2 のドメイン コントローラーのみを実行するか、Windows Server 2016 以降のドメイン コントローラーのみを実行する必要があります。In other words, you should run only Windows Server 2012 and Windows Server 2012 R2 domain controllers, OR you should only run Windows Server 2016 and above domain controllers.

脆弱なパスワードが受け入れられているが、受け入れるべきではないWeak passwords are being accepted but should not be

この問題にはいくつかの原因が考えられます。This problem may have several causes.

  1. DC エージェントで実行されているパブリック プレビュー版ソフトウェアの有効期限が切れています。Your DC agent(s) are running a public preview software version that has expired. パブリック プレビュー DC エージェント ソフトウェアの有効期限切れ」を参照してください。See Public preview DC agent software has expired.

  2. DC エージェントがポリシーをダウンロードできないか、既存のポリシーの暗号化を解除できません。Your DC agent(s) cannot download a policy or is unable to decrypt existing policies. 上記のトピックで考えられる原因を確認してください。Check for possible causes in the above topics.

  3. パスワード ポリシーの適用モードがまだ [監査] に設定されています。The password policy Enforce mode is still set to Audit. この構成が有効な場合は、Azure AD パスワード保護ポータルを使用してそのモードを [強制] に再構成します。If this configuration is in effect, reconfigure it to Enforce using the Azure AD Password Protection portal. パスワード保護を有効にする」を参照してください。See Enable Password protection.

  4. パスワード ポリシーが無効にされています。The password policy has been disabled. この構成が有効な場合は、Azure AD パスワード保護ポータルを使用してそのモードを [有効] に再構成します。If this configuration is in effect, reconfigure it to enabled using the Azure AD Password Protection portal. パスワード保護を有効にする」を参照してください。See Enable Password protection.

  5. DC エージェント ソフトウェアがドメイン内のすべてのドメイン コントローラーにはインストールされていません。You have not installed the DC agent software on all domain controllers in the domain. このような状況では、パスワードの変更操作中にリモートの Windows クライアントが特定のドメイン コントローラーを確実にターゲットにするようにすることは困難です。In this situation, it is difficult to ensure that remote Windows clients target a particular domain controller during a password change operation. DC エージェント ソフトウェアがインストールされている特定の DC を正常にターゲットにしていたと思われる場合は、DC エージェント管理イベント ログを再度確認することで確認できます。結果に関係なく、パスワードの検証結果を文書化するイベントが少なくとも 1 つあります。If you think you have successfully targeted a particular DC where the DC agent software is installed, you can verify by double-checking the DC agent admin event log: regardless of outcome, there will be at least one event to document the outcome of the password validation. パスワードが変更されたユーザーのイベントがない場合、パスワード変更は別のドメイン コントローラーで処理された可能性があります。If there is no event present for the user whose password is changed, then the password change was likely processed by a different domain controller.

    別のテストとして、DC エージェント ソフトウェアがインストールされている DC に直接ログインした状態で、パスワードを設定したり変更したりしてみてください。As an alternative test, try setting\changing passwords while logged in directly to a DC where the DC agent software is installed. この手法は運用環境の Active Directory ドメインでは推奨されません。This technique is not recommended for production Active Directory domains.

    DC エージェント ソフトウェアの増分デプロイはこれらの制限の下でサポートされていますが、Microsoft では、DC エージェント ソフトウェアを、できるだけ早くドメイン内のすべてのドメイン コントローラーにインストールすることを強くお勧めします。While incremental deployment of the DC agent software is supported subject to these limitations, Microsoft strongly recommends that the DC agent software is installed on all domain controllers in a domain as soon as possible.

  6. パスワード検証アルゴリズムが実際に期待どおりに動作している可能性があります。The password validation algorithm may actually be working as expected. パスワードの評価方法」を参照してください。See How are passwords evaluated.

Ntdsutil.exe が弱い DSRM パスワードを設定できないNtdsutil.exe fails to set a weak DSRM password

Active Directory では、常に新しいディレクトリ サービス修復モード パスワードが検証されて、ドメインのパスワードの複雑さ要件が満たされているかどうかが確認されています。この検証では、Azure AD パスワード保護などのパスワード フィルター DLL も呼び出されます。Active Directory will always validate a new Directory Services Repair Mode password to make sure it meets the domain's password complexity requirements; this validation also calls into password filter dlls like Azure AD Password Protection. 新しい DSRM パスワードが拒否された場合、次のエラー メッセージが表示されます。If the new DSRM password is rejected, the following error message results:

C:\>ntdsutil.exe
ntdsutil: set dsrm password
Reset DSRM Administrator Password: reset password on server null
Please type password for DS Restore Mode Administrator Account: ********
Please confirm new password: ********
Setting password failed.
        WIN32 Error Code: 0xa91
        Error Message: Password doesn't meet the requirements of the filter dll's

Azure AD パスワード保護で Active Directory DSRM パスワードのパスワード検証イベント ログ イベントがログに記録されるとき、イベント ログ メッセージにユーザー名が含まれないことが予想されます。When Azure AD Password Protection logs the password validation event log event(s) for an Active Directory DSRM password, it is expected that the event log messages will not include a user name. この動作は、DSRM アカウントが実際の Active Directory ドメインの一部ではないローカル アカウントであるために発生します。This behavior occurs because the DSRM account is a local account that is not part of the actual Active Directory domain.

弱い DSRM パスワードが原因でドメイン コントローラー レプリカの昇格が失敗するDomain controller replica promotion fails because of a weak DSRM password

DC 昇格プロセス中に、新しいディレクトリ サービス修復モード パスワードが、検証のためにドメイン内の既存の DC に送信されます。During the DC promotion process, the new Directory Services Repair Mode password will be submitted to an existing DC in the domain for validation. 新しい DSRM パスワードが拒否された場合、次のエラー メッセージが表示されます。If the new DSRM password is rejected, the following error message results:

Install-ADDSDomainController : Verification of prerequisites for Domain Controller promotion failed. The Directory Services Restore Mode password does not meet a requirement of the password filter(s). Supply a suitable password.

上記の問題と同様に、このシナリオでは Azure AD パスワード保護パスワード検証の結果イベントでユーザー名が空になります。Just like in the above issue, any Azure AD Password Protection password validation outcome event will have empty user names for this scenario.

弱いローカル管理者パスワードのためにドメイン コントローラーの降格が失敗するDomain controller demotion fails due to a weak local Administrator password

DC エージェント ソフトウェアを実行中でもドメイン コントローラーを降格させることができます。It is supported to demote a domain controller that is still running the DC agent software. ただし、降格手続き中も DC エージェント ソフトウェアによって現在のパスワード ポリシーが継続的に適用されることに管理者は注意する必要があります。Administrators should be aware however that the DC agent software continues to enforce the current password policy during the demotion procedure. 新しいローカル管理者アカウントのパスワード (降格操作の一環で指定されます) は、他のパスワードと同様に検証されます。The new local Administrator account password (specified as part of the demotion operation) is validated like any other password. DC 降格手順の一部として、ローカル管理者アカウントに対してセキュリティで保護されたパスワードを選択することをお勧めします。Microsoft recommends that secure passwords be chosen for local Administrator accounts as part of a DC demotion procedure.

降格が成功し、ドメイン コントローラーが再起動され、通常のメンバー サーバーとして改めて実行されると、DC エージェント ソフトウェアはパッシブ モードで動作するようになります。Once the demotion has succeeded, and the domain controller has been rebooted and is again running as a normal member server, the DC agent software reverts to running in a passive mode. このソフトウェアはいつでもアンインストールできます。It may then be uninstalled at any time.

ディレクトリ サービス修復モードでの起動Booting into Directory Services Repair Mode

ドメイン コントローラーがディレクトリ サービスの修復モードで起動された場合、DC エージェントのパスワード フィルター DLL でこの条件が検出され、現在アクティブなポリシー構成に関係なく、すべてのパスワード検証または適用アクティビティが無効にされます。If the domain controller is booted into Directory Services Repair Mode, the DC agent password filter dll detects this condition and will cause all password validation or enforcement activities to be disabled, regardless of the currently active policy configuration. DC エージェントのパスワード フィルター DLL は、管理者のイベント ログに 10023 警告イベントを記録します。次に例を示します。The DC agent password filter dll will log a 10023 warning event to the Admin event log, for example:

The password filter dll is loaded but the machine appears to be a domain controller that has been booted into Directory Services Repair Mode. All password change and set requests will be automatically approved. No further messages will be logged until after the next reboot.

パブリック プレビュー DC エージェント ソフトウェアの有効期限切れPublic preview DC agent software has expired

Azure AD パスワード保護のパブリック プレビュー期間中、次の日付になったらパスワード検証要求の処理を停止するよう、DC エージェント ソフトウェアがハードコードされています。During the Azure AD Password Protection public preview period, the DC agent software was hard-coded to stop processing password validation requests on the following dates:

  • バージョン 1.2.65.0 は、2019 年 9 月 1 日にパスワード検証要求の処理を停止します。Version 1.2.65.0 will stop processing password validation requests on September 1 2019.
  • バージョン 1.2.25.0 およびそれ以前は、2019 年 7 月 1 日にパスワード検証要求の処理を停止しました。Version 1.2.25.0 and prior stopped processing password validation requests on July 1 2019.

期限が近づくと、時間制限のあるすべての DC エージェント バージョンは、起動時に DC エージェント管理イベント ログに 10021 イベントを出力します。これは次のようになります。As the deadline approaches, all time-limited DC agent versions will emit a 10021 event in the DC agent Admin event log at boot time that looks like this:

The password filter dll has successfully loaded and initialized.

The allowable trial period is nearing expiration. Once the trial period has expired, the password filter dll will no longer process passwords. Please contact Microsoft for an newer supported version of the software.

Expiration date:  9/01/2019 0:00:00 AM

This message will not be repeated until the next reboot.

期限が過ぎると、時間制限のあるすべての DC エージェント バージョンは、起動時に DC エージェント管理イベント ログに 10022 イベントを出力します。これは次のようになります。Once the deadline has passed, all time-limited DC agent versions will emit a 10022 event in the DC agent Admin event log at boot time that looks like this:

The password filter dll is loaded but the allowable trial period has expired. All password change and set requests will be automatically approved. Please contact Microsoft for a newer supported version of the software.

No further messages will be logged until after the next reboot.

期限は初回起動時にしかチェックされないため、カレンダーの期限が過ぎてからも長期間、これらのイベントが記録されない場合があります。Since the deadline is only checked on initial boot, you may not see these events until long after the calendar deadline has passed. 期限が認識された後、ドメイン コントローラーまたはより大規模な環境への悪影響は、すべてのパスワードが自動的に承認されることを除いては発生しません。Once the deadline has been recognized, no negative effects on either the domain controller or the larger environment will occur other than all passwords will be automatically approved.

重要

Microsoft では、有効期限が切れたパブリック プレビュー DC エージェントを、すぐに最新バージョンにアップグレードすることをお勧めします。Microsoft recommends that expired public preview DC agents be immediately upgraded to the latest version.

アップグレードが必要な環境内の DC エージェントを検出する簡単な方法は、Get-AzureADPasswordProtectionDCAgent コマンドレットを実行することです。次に例を示します。An easy way to discover DC agents in your environment that need to be upgrade is by running the Get-AzureADPasswordProtectionDCAgent cmdlet, for example:

PS C:\> Get-AzureADPasswordProtectionDCAgent

ServerFQDN            : bpl1.bpl.com
SoftwareVersion       : 1.2.125.0
Domain                : bpl.com
Forest                : bpl.com
PasswordPolicyDateUTC : 8/1/2019 9:18:05 PM
HeartbeatUTC          : 8/1/2019 10:00:00 PM
AzureTenant           : bpltest.onmicrosoft.com

このトピックに関して、SoftwareVersion フィールドは明らかに、注目すべき重要なプロパティです。For this topic, the SoftwareVersion field is obviously the key property to look at. PowerShell のフィルターを使用して、既に必要なベースライン バージョン以上である DC エージェントを除外することもできます。次に例を示します。You can also use PowerShell filtering to filter out DC agents that are already at or above the required baseline version, for example:

PS C:\> $LatestAzureADPasswordProtectionVersion = "1.2.125.0"
PS C:\> Get-AzureADPasswordProtectionDCAgent | Where-Object {$_.SoftwareVersion -lt $LatestAzureADPasswordProtectionVersion}

Azure AD パスワード保護プロキシ ソフトウェアでは、どのバージョンでも期間が制限されません。The Azure AD Password Protection Proxy software is not time-limited in any version. Microsoft では、DC エージェントとプロキシ エージェントのどちらも、最新バージョンがリリースされたらすぐ、そのバージョンにアップグレードすることもお勧めします。Microsoft still recommends that both DC and proxy agents be upgraded to the latest versions as they are released. 上記の DC エージェントの例と同様に、Get-AzureADPasswordProtectionProxy コマンドレットを使用して、アップグレードが必要なプロキシ エージェントを見つけることができます。The Get-AzureADPasswordProtectionProxy cmdlet may be used to find Proxy agents that require upgrades, similar to the example above for DC agents.

具体的なアップグレード手順の詳細については、DC エージェントのアップグレードおよびプロキシ エージェントのアップグレードに関する項目を参照してください。Refer to Upgrading the DC agent and Upgrading the Proxy agent for more details on specific upgrade procedures.

緊急時の修復Emergency remediation

DC エージェント サービスが問題の原因である状況が発生した場合、DC エージェント サービスは直ちにシャットダウンされる可能性があります。If a situation occurs where the DC agent service is causing problems, the DC agent service may be immediately shut down. DC エージェントのパスワード フィルター dll が実行中ではないサービスをまだ呼び出そうとすると、警告イベント (10012、10013) がログに記録されますが、その間にすべての受信パスワードが承認されます。The DC agent password filter dll still attempts to call the non-running service and will log warning events (10012, 10013), but all incoming passwords are accepted during that time. DC エージェント サービスは、必要に応じて Windows サービス コントロール マネージャーを使用してスタートアップの種類を "無効" に構成することもできます。The DC agent service may then also be configured via the Windows Service Control Manager with a startup type of “Disabled” as needed.

また、Azure AD パスワード保護ポータルで有効モードを [いいえ] に設定することで修復する方法もあります。Another remediation measure would be to set the Enable mode to No in the Azure AD Password Protection portal. 更新されたポリシーがダウンロードされたら、各 DC エージェント サービスが休止モードに入り、すべてパスワードが現状のままで受け入れられます。Once the updated policy has been downloaded, each DC agent service will go into a quiescent mode where all passwords are accepted as-is. 詳細については、「強制モード」を参照してください。For more information, see Enforce mode.

削除Removal

Azure AD パスワード保護ソフトウェアをアンインストールし、関連するすべての状態をドメインとフォレストからクリーンアップする場合、次の手順で実行できます。If it is decided to uninstall the Azure AD password protection software and cleanup all related state from the domain(s) and forest, this task can be accomplished using the following steps:

重要

これらの手順は、順番に実行することが重要です。It is important to perform these steps in order. プロキシ サービスのインスタンスを実行中のままにすると、定期的に serviceConnectionPoint オブジェクトが再作成されます。If any instance of the Proxy service is left running it will periodically re-create its serviceConnectionPoint object. DC エージェント サービスのインスタンスを実行中のままにすると、定期的に serviceConnectionPoint オブジェクトと sysvol 状態が再作成されます。If any instance of the DC agent service is left running it will periodically re-create its serviceConnectionPoint object and the sysvol state.

  1. すべてのマシンからプロキシ ソフトウェアをアンインストールします。Uninstall the Proxy software from all machines. この手順では、再起動する必要はありませんThis step does not require a reboot.

  2. すべてのドメイン コントローラーから DC エージェント ソフトウェアをアンインストールします。Uninstall the DC Agent software from all domain controllers. この手順では、再起動する必要がありますThis step requires a reboot.

  3. 各ドメイン名前付けコンテキストのすべてのプロキシ サービス接続ポイントを手動で削除します。Manually remove all Proxy service connection points in each domain naming context. これらのオブジェクトの場所は、次の Active Directory PowerShell コマンドを使用して検出できます。The location of these objects may be discovered with the following Active Directory PowerShell command:

    $scp = "serviceConnectionPoint"
    $keywords = "{ebefb703-6113-413d-9167-9f8dd4d24468}*"
    Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
    

    $keywords 変数値の末尾のアスタリスク ("*") は省略しないでください。Do not omit the asterisk (“*”) at the end of the $keywords variable value.

    Get-ADObject コマンドで見つかった結果のオブジェクトは、Remove-ADObject にパイプ出力するか、手動で削除することができます。The resulting object(s) found via the Get-ADObject command can then be piped to Remove-ADObject, or deleted manually.

  4. 各ドメイン名前付けコンテキストに含まれるすべての DC エージェント接続ポイントを手動で削除します。Manually remove all DC agent connection points in each domain naming context. ソフトウェアの展開の規模によっては、フォレスト内のドメイン コントローラーごとにこのようなオブジェクトが 1 つ存在することがあります。There may be one these objects per domain controller in the forest, depending on how widely the software was deployed. そのオブジェクトの場所は、次の Active Directory PowerShell コマンドを使用して検出できます。The location of that object may be discovered with the following Active Directory PowerShell command:

    $scp = "serviceConnectionPoint"
    $keywords = "{2bac71e6-a293-4d5b-ba3b-50b995237946}*"
    Get-ADObject -SearchScope Subtree -Filter { objectClass -eq $scp -and keywords -like $keywords }
    

    Get-ADObject コマンドで見つかった結果のオブジェクトは、Remove-ADObject にパイプ出力するか、手動で削除することができます。The resulting object(s) found via the Get-ADObject command can then be piped to Remove-ADObject, or deleted manually.

    $keywords 変数値の末尾のアスタリスク ("*") は省略しないでください。Do not omit the asterisk (“*”) at the end of the $keywords variable value.

  5. フォレストレベルの構成状態を手動で削除します。Manually remove the forest-level configuration state. フォレストの構成状態は、Active Directory 構成の名前付けコンテキストのコンテナーに保持されます。The forest configuration state is maintained in a container in the Active Directory configuration naming context. 次のように検出および削除できます。It can be discovered and deleted as follows:

    $passwordProtectionConfigContainer = "CN=Azure AD Password Protection,CN=Services," + (Get-ADRootDSE).configurationNamingContext
    Remove-ADObject -Recursive $passwordProtectionConfigContainer
    
  6. 次のフォルダーとそのすべての内容を手動で削除して、すべての sysvol 関連の状態を手動で削除します。Manually remove all sysvol related state by manually deleting the following folder and all of its contents:

    \\<domain>\sysvol\<domain fqdn>\AzureADPasswordProtection

    必要に応じて、特定のドメイン コントローラーのローカルでこのパスにアクセスすることもできます。既定の場所は次のようなパスになります。If necessary, this path may also be accessed locally on a given domain controller; the default location would be something like the following path:

    %windir%\sysvol\domain\Policies\AzureADPasswordProtection

    sysvol 共有が既定以外の場所に設定されている場合は、別のパスになります。This path is different if the sysvol share has been configured in a non-default location.

次の手順Next steps

Azure AD パスワード保護についてよく寄せられる質問Frequently asked questions for Azure AD Password Protection

グローバルおよびカスタムの禁止パスワード リストの詳細については、不適切なパスワードの禁止に関する記事を参照してください。For more information on the global and custom banned password lists, see the article Ban bad passwords