オンプレミス アプリケーションのプロビジョニングのトラブルシューティング
テスト接続の問題をトラブルシューティングする
プロビジョニング エージェントと Extensible Connectivity (ECMA) ホストを構成したら、Microsoft Entra プロビジョニング サービスからプロビジョニング エージェント、ECMA ホスト、アプリケーションへの接続をテストします。 このエンド ツー エンド テストを実行するには、Azure portal でアプリケーションの [テスト接続] を選択します。 最初のエージェントを割り当てた後、またはエージェントを変更してから接続をテストする前に、必ず 10 分から 20 分待ってください。 この時間が過ぎた後にテスト接続に失敗した場合は、次のトラブルシューティング手順を試してください。
エージェントと ECMA ホストが実行中であることを確認します。
エージェントがインストールされているサーバーのスタート ボタンをクリックし、 [ファイル名を指定して実行] で「Services.msc」と入力して、 [サービス] を開きます。
[サービス] に Microsoft Entra Connect プロビジョニング エージェントと Microsoft ECMA2Host サービスが存在し、それらの状態が [実行中] になっていることを確認します。
ECMA コネクタ ホスト サービスが要求に応答していることを確認します。
- エージェントがインストールされているサーバーで、PowerShell を起動します。
- ECMA ホストがインストールされたフォルダー (
C:\Program Files\Microsoft ECMA2Hostなど) に変更します。 - サブディレクトリ
Troubleshootingに変更します。 - そのディレクトリでスクリプト
TestECMA2HostConnection.ps1を実行します。 プロンプトが表示されたら、コネクタ名とシークレット トークンを引数として指定します。PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1 Supply values for the following parameters: ConnectorName: CORPDB1 SecretToken: ************ - このスクリプトでは、SCIM GET または POST 要求を送信して、ECMA Connector Host が動作していて、要求に応答することを確認します。 出力に HTTP 接続が成功したことが示されない場合は、サービスが実行されていること、および正しいシークレット トークンが指定されていることを確認します。
Azure portal でアプリケーションに移動し、 [admin connectivity](管理者接続) を選択し、エージェントのドロップダウン リストを選択して、お使いのエージェントをアクティブにすることにより、エージェントを確実にアクティブにします。
指定したシークレット トークンがオンプレミスのシークレット トークンと同じであるかどうかを確認します。 オンプレミスに移動し、シークレット トークンを再度指定し、Azure portal にそれをコピーします。
Azure portal で、必ず 1 つ以上のエージェントをアプリケーションに割り当てます。
エージェントを割り当てた後、登録が完了するまで 10 分から 20 分待つ必要があります。 登録が完了するまで、接続テストは機能しません。
有効期限が切れていない有効な証明書を使用していることを確認します。 ECMA ホストの [設定] タブに移動して、証明書の有効期限を表示します。 証明書の有効期限が切れている場合は、
Generate certificateをクリックして新しい証明書を生成します。VM 上のタスク バーに移動し、Microsoft Entra Connect プロビジョニング エージェントを検索して、プロビジョニング エージェントを再起動します。 [停止] を右クリックして、 [開始] を選択します。
ECMA コネクタ ホストとプロビジョニング エージェントを再起動し、初期インポートが完了するまで待機した後も引き続き
The ECMA host is currently importing data from the target applicationが表示される場合は、Azure portal でアプリケーションへのプロビジョニングの構成をいったん取り消してからもう一度やり直す必要が生じる場合があります。Azure portal でテナントの URL を指定する場合は、必ず次のパターンに従ってください。
localhostを、お使いのホスト名に置き換えることができますが、必須ではありません。connectorNameを、ECMA ホストで指定したコネクタの名前に置き換えます。 エラー メッセージ 'invalid resource' (無効なリソース) は、一般に、URL が想定される形式に従っていないことを示しています。https://localhost:8585/ecma2host_connectorName/scimフォルダー C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace に移動して、プロビジョニング エージェントのログを確認します。
- 次のエラーが表示される場合は、サービス アカウント "NT SERVICE\AADConnectProvisioningAgent" を "Performance Log Users" というローカル グループに追加してください。 これにより、アカウントが目的のレジストリ キー HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Perflib にアクセスできるようにすることで、"Unable to initialize metrics collector" という例外エラーが発生しなくなります。
Unable to initialize metrics collector, exception: 'System.UnauthorizedAccessException: Access to the registry key 'Global' is denied.
- ECMA ホストを構成するときは、Windows サーバーのホスト名と一致するサブジェクトを証明書に指定してください。 ECMA ホストによって生成された証明書は自動的にこれを行いますが、テスト目的でのみ使用する必要があります。
Error code: SystemForCrossDomainIdentityManagementCredentialValidationUnavailable
Details: We received this unexpected response from your application: Received response from Web resource. Resource: https://localhost/Users?filter=PLACEHOLDER+eq+"8646d011-1693-4cd3-9ee6-0d7482ca2219" Operation: GET Response Status Code: InternalServerError Response Headers: Response Content: An error occurred while sending the request. Please check the service and try again.
ECMA ホストの構成、イベント ビューアーでのログの表示、または ECMA ホスト サービスの起動ができない
次の問題を解決するには、管理者として ECMA ホスト設定ウィザードを実行します。
ECMA ホスト ウィザードを開くとエラーが発生する。
ECMA ホスト ウィザードは構成できたが、ECMA ホスト ログを表示できない: このケースでは、ECMA ホスト構成ウィザードを管理者としてオープンし、コネクタの端から端までを設定する必要があります。 この手順は、既存のコネクタをエクスポートし、再度インポートすることで簡単に行うことができます。
ECMA ホスト ウィザードは構成できたが、ECMA ホスト サービスを開始できない:
詳細ログ記録を有効にする
既定では、ECMA Connector Host の switchValue は Verbose に設定されます。 この設定では、トラブルシューティングの問題に役立つ詳細ログが出力されます。 出力されるログの数をエラーのみに制限する場合は、詳細レベルを Error に変更できます。 Windows 統合認証を使用せずに SQL コネクタを使用する場合、接続文字列がログに出力されないように、 switchValue を Error に設定することをお勧めします。 詳細レベルをエラーに変更するには、次に示すように、 両方の場所で switchValue を "error" に更新してください。
サービスの詳細ログ ファイルは、C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.config にあります。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" />
</startup>
<appSettings>
<add key="Debug" value="true" />
</appSettings>
<system.diagnostics>
<sources>
<source name="ConnectorsLog" switchValue="Error">
<listeners>
<add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack">
<filter type=""/>
</add>
</listeners>
</source>
<!-- Choose one of the following switchTrace: Off, Error, Warning, Information, Verbose -->
<source name="ECMA2Host" switchValue="Error">
<listeners>
<add initializeData="ECMA2Host" type="System.Diagnos
ウィザードのログ ファイルは、C:\Program Files\Microsoft ECMA2Host\Wizard\Microsoft.ECMA2Host.ConfigWizard.exe.config にあります。
<source name="ConnectorsLog" switchValue="Error">
<listeners>
<add initializeData="ConnectorsLog" type="System.Diagnostics.EventLogTraceListener, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ConnectorsLog" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack">
<filter type=""/>
</add>
</listeners>
</source>
<!-- Choose one of the following switchTrace: Off, Error, Warning, Information, Verbose -->
<source name="ECMA2Host" switchValue="Error">
<listeners>
<add initializeData="ECMA2Host" type="System.Diagnostics.EventLogTraceListener, System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" name="ECMA2HostListener" traceOutputOptions="LogicalOperationStack, DateTime, Timestamp, Callstack" />
ECMA ホスト キャッシュのクエリを実行する
ECMA ホストには、アプリケーション内のユーザーのキャッシュがあります。このキャッシュは、ECMA ホスト ウィザードのプロパティ ページで指定したスケジュールに従って更新されます。 キャッシュのクエリを実行するには、次の手順を実行します。
[デバッグ] フラグを
trueに設定します。デバッグ フラグを
trueに設定すると、ECMA ホストでの認証が無効になることに注意してください。 キャッシュのクエリの実行が完了したら、設定をfalseに戻して、ECMA ホスト サービスを再起動する必要があります。詳細サービス ログのファイル ロケーションは
C:\Program Files\Microsoft ECMA2Host\Service\Microsoft.ECMA2Host.Service.exe.configです。<?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6" /> </startup> <appSettings> <add key="Debug" value="true" /> </appSettings>Microsoft ECMA2Hostサービスを再開します。ECMA ホストがターゲット システムに接続し、接続されている各システムからキャッシュを読み取り直すのを待ちます。 接続されているシステムに多数のユーザーがいる場合、このインポート プロセスには数分かかる場合があります。
ECMA ホストがインストールされているサーバーからこのエンドポイントのクエリを実行し、
{connector name}を ECMA ホストのプロパティ ページで指定したコネクタの名前https://localhost:8585/ecma2host_{connectorName}/scim/cacheに置き換えます。- エージェントがインストールされているサーバーで、PowerShell を起動します。
- ECMA ホストがインストールされたフォルダー (
C:\Program Files\Microsoft ECMA2Hostなど) に変更します。 - サブディレクトリ
Troubleshootingに変更します。 - そのディレクトリでスクリプト
TestECMA2HostConnection.ps1を実行し、コネクタ名とObjectTypePath値cacheを引数として指定します。 ダイアログが表示されたら、そのコネクタ用に構成されたシークレット トークンを入力します。PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> .\TestECMA2HostConnection.ps1 -ConnectorName CORPDB1 -ObjectTypePath cache Supply values for the following parameters: SecretToken: ************ - このスクリプトでは、SCIM GET 要求を送信して、ECMA Connector Host が動作していて、要求に応答することを確認します。 出力に HTTP 接続が成功したことが示されない場合は、サービスが実行されていること、および正しいシークレット トークンが指定されていることを確認します。
キャッシュのクエリが完了したら、デバッグ フラグを
falseに戻すか、設定を削除します。Microsoft ECMA2Hostサービスを再開します。
ターゲット属性がない
ターゲット アプリケーションの属性は、プロビジョニング サービスによって自動的に検出されます。 Azure portal のターゲット属性リストにターゲット属性が存在しないことがわかったら、次のトラブルシューティング手順を実行してください。
- ECMA ホスト構成の [属性の選択] ページを確認し、Azure portal に公開する属性が選択されていることを確認します。
- ECMA ホスト サービスが実行されていることを確認します。
- エージェントをエンタープライズ アプリケーションに割り当て、テスト接続手順を完了し、管理者資格情報を保存したら、ブラウザーを更新します。 これにより、プロビジョニング サービスは /schemas 要求を行い、ターゲット属性が検出されます。
- ECMA ホストのログを確認して、/schemas 要求が行われたことを確認し、その応答で属性を確認します。 これは、問題のトラブルシューティングをサポートするうえで有益な情報です。
イベント ビューアーから ZIP ファイルとしてログを収集する
付属のスクリプトを使用して、イベント ログを ZIP ファイルにキャプチャしてエクスポートすることができます。
- エージェントがインストールされているサーバーで、[スタート] メニューの [PowerShell] を右クリックし、
Run as administratorを選択します。 - ECMA ホストがインストールされたフォルダー (
C:\Program Files\Microsoft ECMA2Hostなど) に変更します。 - サブディレクトリ
Troubleshootingに変更します。 - そのディレクトリでスクリプト
CollectTroubleshootingInfo.ps1を実行します。 - スクリプトは、イベント ログを含む ZIP ファイルをそのディレクトリに作成します。
イベント ビューアーでイベントを確認する
ECMA Connector Host のスキーマ マッピングが構成されたら、サービスを開始して受信接続をリッスンします。 そのうえで、受信要求を監視します。
- スタート メニューを選択し、「イベント ビューアー」と入力して、 [イベント ビューアー] を選択します。
- イベント ビューアーで、 [アプリケーションとサービス ログ] を展開し、 [Microsoft ECMA2Host ログ] を選択します。
- コネクタ ホストで変更が受信されると、イベントがアプリケーション ログに書き込まれます。
一般的なエラー
| エラー | 解像度 |
|---|---|
| ファイルまたはアセンブリ 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\Cache\8b514472-c18a-4641-9a44-732c296534e8\Microsoft.IAM.Connector.GenericSql.dll' またはその依存関係の 1 つを読み込めませんでした。 アクセスが拒否されました。 | ネットワーク サービス アカウントに、キャッシュ フォルダーに対する 'フル コントロール' のアクセス許可があることを確認します。 アカウントにアクセス許可があるが、.NET がコネクタ DLL のコピーを作成しようとしている場合は、DLL をグローバル アセンブリ キャッシュに追加することが必要な場合があります。 |
オブジェクトの DN の LDAP スタイルが無効です。 DN: username@domain.com" または Target Site: ValidByLdapStyle |
ECMA ホストの [connectivity](接続) ページで [DN is Anchor](DN はアンカー) チェックボックスがオフになっていることを確認します。 ECMA ホストの [object types](オブジェクトの種類) ページで [autogenerated](自動生成) チェックボックスがオンになっていることを確認します。 詳細については、「アンカー属性と識別名について」を参照してください。 |
| ExportErrorCustomContinueRun。 objectClass: 構文につき値番号が無効 | objectClass 属性へのプロビジョニング属性マッピングには、ディレクトリ サーバーによって認識されるオブジェクト クラスの名前のみが含まれていることを確認します。 |
受信 SCIM 要求について
Microsoft Entra ID からプロビジョニング エージェントやコネクタ ホストに対して行われる要求には、SCIM プロトコルが使用されます。 ホストからアプリに対して行われる要求には、アプリでサポートされるプロトコルが使用されます。 ホストからエージェントへ、さらに Microsoft Entra ID に対して行われる要求には、SCIM が使用されます。 SCIM の実装の詳細については、「チュートリアル: Microsoft Entra ID の SCIM エンドポイントのプロビジョニングを開発および計画する」を参照してください。
一般に、Microsoft Entra プロビジョニング サービスは get-user 呼び出しを行い、各プロビジョニング サイクルの開始時、オンデマンド プロビジョニングを実行する前、およびテスト接続が選択されている場合の 3 つの状況でダミー ユーザーを確認します。 このチェックにより、ターゲット エンドポイントが使用でき、SCIM 準拠の応答が Microsoft Entra プロビジョニング サービスに返されることが保証されます。
プロビジョニング エージェントをトラブルシューティングする方法
次のエラー シナリオが発生する場合があります。
エージェントが起動しない
次の内容のエラー メッセージが表示されることがあります。
"サービス 'Microsoft Azure AD Connect Provisioning Agent' を開始できませんでした。 Check that you have sufficient privileges to start the system services. (システム サービスを起動するために十分な特権を持っていることを確認してください。)"
この問題は、通常、インストーラー (NT SERVICE\AADConnectProvisioningAgent) によって作成されたローカル NT サービスのサインイン アカウントにアクセス許可が適用されないようにするグループ ポリシーが原因で発生します。 サービスを開始するには、これらのアクセス許可が必要です。
これを解決するには、次の手順に従います。
- 管理者アカウントでサーバーにサインインします。
- [サービス] を開きます。これには、そこに直接移動するか、スタート ボタンをクリックし、 [ファイル名を指定して実行] で「Services.msc」と入力します。
- [サービス] で [Microsoft Entra Connect プロビジョニング エージェント] をダブルクリックします。
- [ログオン] タブで、 [このアカウント] をドメイン管理者に変更します。その後、サービスを再起動します。
このテストでは、エージェントがポート 443 を介して Azure と通信できることを確認します。 ブラウザーを開き、エージェントがインストールされているサーバーから前の URL に移動します。
エージェントがタイムアウトになるか証明書が無効である
エージェントを登録しようとしたときに、次のエラー メッセージが表示されることがあります。
この問題は、通常、エージェントがハイブリッド ID サービスに接続できないことが原因で発生し、HTTP プロキシを構成する必要があります。 この問題を解決するには、送信プロキシを構成します。
プロビジョニング エージェントでは、送信プロキシの使用がサポートされます。 構成するには、エージェントの構成ファイル C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config を編集します。ファイルの末尾近くにある </configuration> の終了タグの直前に次の行を追加します。
[proxy-server] 変数と [proxy-port] 変数をお使いのプロキシ サーバー名とポート値に置き換えてください。
<system.net>
<defaultProxy enabled="true" useDefaultCredentials="true">
<proxy
usesystemdefault="true"
proxyaddress="http://[proxy-server]:[proxy-port]"
bypassonlocal="true"
/>
</defaultProxy>
</system.net>
セキュリティ エラーが発生してエージェントの登録が失敗する
クラウド プロビジョニング エージェントのインストール時にエラー メッセージが表示されることがあります。
この問題は、通常、ローカルの PowerShell 実行ポリシーのせいで、エージェントで PowerShell 登録スクリプトを実行できないことが原因で発生します。
この問題を解決するには、サーバー上の PowerShell 実行ポリシーを変更します。 マシンとユーザーのポリシーを Undefined または RemoteSigned に設定する必要があります。 Unrestricted として設定されている場合、このエラーが表示されます。 詳細については、PowerShell 実行ポリシーに関する記事を参照してください。
ログ ファイル
既定では、エージェントによって発行されるエラー メッセージとスタック トレース情報は最小限に抑えられています。 トレース ログは、C:\ProgramData\Microsoft\Azure AD Connect Provisioning Agent\Trace フォルダーにあります。
エージェント関連の問題をトラブルシューティングするための詳細な情報を入手するには、次の手順に従います。
「Microsoft Entra Connect クラウド同期用
AADCloudSyncToolsPowerShell モジュール」の説明に従って、AADCloudSyncToolsPowerShell モジュールをインストールします。Export-AADCloudSyncToolsLogsPowerShell コマンドレットを使用して情報をキャプチャします。 次のスイッチを使用してデータ収集を微調整します。 次のコマンドを使用します。- SkipVerboseTrace: 詳細ログをキャプチャせずに現在のログのみをエクスポートします (既定値 = false)。
- TracingDurationMins: 別のキャプチャ期間を指定します (既定値 = 3 分)。
- OutputPath: 別の出力パスを指定します (既定値 = ユーザーのドキュメント)。
Microsoft Entra ID を使用することにより、クラウドでプロビジョニング サービスを監視し、オンプレミスでログを収集できます。 プロビジョニング サービスは、同期プロセスの一環として評価された各ユーザーのログを出力します。 それらのログは、Azure portal の UI、API、Log Analytics を通じて利用することができます。 ECMA ホストでも、オンプレミスでログが生成されます。 これは、受信された各プロビジョニング要求および Microsoft Entra ID に送信された応答を示します。
エージェントのインストールの失敗
エラー "
System.ComponentModel.Win32Exception: The specified service already exists" は、以前の ECMA ホストが正しくアンインストールされなかったことを示します。 ホスト アプリケーションをアンインストールします。 Program Files に移動し、ECMA ホストのフォルダーを削除します。 バックアップ用に構成ファイルを保存することもできます。次のエラーは、前提条件が満たされていないことを示します。 .NET 4.7.1 がインストールされていることを確認してください。
Method Name : <>c__DisplayClass0_1 : RegisterNotLoadedAssemblies Error during load assembly: System.Management.Automation.resources.dll --------- Outer Exception Data --------- Message: Could not load file or assembly 'file:///C:\Program Files\Microsoft ECMA2Host\Service\ECMA\System.Management.Automation.resources.dll' or one of its dependencies. The system cannot find the file specified.
SQL で ECMA Connector Host を構成しようとすると、無効な LDAP スタイルの DN エラーが発生する
既定では、汎用 SQL コネクタでは、LDAP スタイルを使用して DN が設定されていると想定されています (最初の接続ページで [DN is anchor] (DN はアンカー) 属性がオフの場合)。 エラー メッセージ Invalid LDAP style DN または Target Site: ValidByLdapStyle では、DN フィールドにコネクタで想定されている LDAP スタイルの DN ではなく、ユーザー プリンシパル名 (UPN) が入っていることがあります。
このエラー メッセージを解決するには、コネクタを構成する際に [object types](オブジェクトの種類) ページで [Autogenerated](自動生成) が選択されていることを確認してください。
詳細については、「アンカー属性と識別名について」を参照してください。