Microsoft Entra Connect オブジェクトと属性のエンドツーエンドのトラブルシューティング

  • [アーティクル]

この記事は、Microsoft Entra IDでの同期の問題のトラブルシューティング方法に関する一般的なプラクティスを確立することを目的としています。 この方法は、オブジェクトまたは属性が Azure Active AD と同期せず、同期エンジン、アプリケーション ビューアー ログ、またはMicrosoft Entra ログにエラーが表示されない状況に適用されます。 明らかなエラーがない場合は、詳細を見失うのは簡単です。 ただし、ベスト プラクティスを使用すると、問題を分離し、Microsoft サポート エンジニアに分析情報を提供できます。

このトラブルシューティング方法を環境に適用すると、時間が経つにつれて、次の手順を実行できるようになります。

  • 同期エンジン のロジックをエンドツーエンドでトラブルシューティングします。
  • 同期の問題をより効率的に解決します。
  • 発生するステップを予測することで、問題をより迅速に特定します。
  • データを確認するための開始点を特定します。
  • 最適な解像度を決定します。

Microsoft Entra接続フローチャートのスクリーンショット。

ここで説明する手順は、ローカル Active Directory レベルから開始し、Microsoft Entra IDに向けて進みます。 これらの手順は、同期の最も一般的な方向です。 ただし、逆方向 (属性ライトバックなど) にも同じ原則が適用されます。

前提条件

この記事の理解を深めるために、まず、さまざまなソース (AD、AD CS、MV など) でオブジェクトを検索する方法を理解し、オブジェクトのコネクタと系列をチェックする方法を理解するために、次の前提条件の記事を参照してください。

トラブルシューティングに関する不適切なプラクティス

Microsoft Entra IDの DirSyncEnabled フラグは、テナントがオンプレミス AD からのオブジェクトの同期を受け入れる準備ができているかどうかを制御します。 多くのお客様が、オブジェクトまたは属性の同期の問題のトラブルシューティング中にテナントで DirSync を無効にする習慣に陥っています。 次の PowerShell コマンドレットを実行すると、ディレクトリ同期を簡単にオフにすることができます。

Set-MsolDirSyncEnabled -EnableDirSync $false "Please DON'T and keep reading!"

注:

Azure AD および MSOnline PowerShell モジュールは、2024 年 3 月 30 日の時点で非推奨となりました。 詳細については、 非推奨の更新プログラムに関するページを参照してください。 この日付以降、これらのモジュールのサポートは、Microsoft Graph PowerShell SDK への移行支援とセキュリティ修正に限定されます。 非推奨のモジュールは、2025 年 3 月 30 日まで引き続き機能します。

Microsoft Entra ID (旧称 Azure AD) と対話するには、Microsoft Graph PowerShell に移行することをお勧めします。 移行に関する一般的な質問については、移行に関する FAQ を参照してください。 メモ： バージョン 1.0.x の MSOnline では、2024 年 6 月 30 日以降に中断が発生する可能性があります。

ただし、これは、ローカル Active Directory からテナント上のすべての同期オブジェクトに対して SoA をローカル Active Directory からMicrosoft Entra ID/Exchange Onlineに転送する複雑で長いバックエンド操作をトリガーするため、致命的な可能性があります。 この操作は、各オブジェクトを DirSyncEnabled からクラウド専用に変換し、オンプレミス AD (ShadowUserPrincipalName や ShadowProxyAddresses など) から同期されるすべてのシャドウ プロパティをクリーンするために必要です。 テナントのサイズによっては、この操作に 72 時間以上かかることがあります。 また、操作がいつ終了するかを予測することはできません。 この方法を使用して同期の問題をトラブルシューティングしないでください。これは追加の害を引き起こし、問題を解決しないためです。 この無効化操作が完了するまで、DirSync を再度有効にすることはブロックされます。 また、DirSync を再度有効にした後、AADC は、存在する Microsoft Entra オブジェクトを持つすべてのオンプレミス オブジェクトを再び照合する必要があります。 このプロセスは中断する可能性があります。

DirSync を無効にするためにこのコマンドがサポートされているシナリオは次のとおりです。

  • オンプレミス同期サーバーの使用を停止しており、ハイブリッド ID ではなくクラウドから完全に ID を管理し続ける必要があります。
  • テナントには、Microsoft Entra IDでクラウド専用として保持し、オンプレミス AD から完全に削除する同期オブジェクトがいくつかあります。
  • 現在、AADC で SourceAnchor としてカスタム属性 (employeeId など) を使用しており、新しい SourceAnchor 属性 (またはその逆) として ms-Ds-Consistency-Guid/ObjectGuid の使用を開始するために AADC を再インストールしています。
  • 危険なメールボックスとテナントの移行戦略に関連するいくつかのシナリオがあります。

場合によっては、同期を一時的に停止したり、AADC 同期サイクルを手動で制御したりする必要があります。 たとえば、同期を停止して、一度に 1 つの同期ステップを実行できるようにする必要がある場合があります。 ただし、DirSync を無効にする代わりに、次のコマンドレットを実行して同期スケジューラのみを停止できます。

Set-ADSyncScheduler -SyncCycleEnabled $false

準備ができたら、次のコマンドレットを実行して、同期サイクルを手動で開始します。

Start-ADSyncSyncCycle

用語集

頭字語/省略形 名前/説明
AADC Microsoft Entra Connect
AADCA Microsoft Entra コネクタ アカウント
AADCS Microsoft Entra コネクタ スペース
AADCS:AttributeA Microsoft Entra コネクタ 空間の属性 'A'
Acl Access Control Lists (ADDS アクセス許可とも呼ばれます)
ADCA AD コネクタ アカウント
Adc Active Directory コネクタ スペース
ADCS:AttributeA Active Directory コネクタ スペースの属性 'A'
ADDS または AD Active Directory ドメイン サービス
Cs コネクタ スペース
Mv メタバース
MSOL アカウント 自動的に生成された AD コネクタ アカウント (MSOL_########)
MV:AttributeA メタバース オブジェクトの属性 'A'
Soa 機関のソース

手順 1: ADDS と ADCS の間の同期

手順 1 の目的

ADCS にオブジェクトまたは属性が存在し、一貫性があるかどうかを判断します。 ADCS でオブジェクトを見つけることができ、すべての属性に予期される値がある場合は、 手順 2 に進みます。

A D コネクタ スペース A D レプリケーションのスクリーンショット。

手順 1 の説明

ADDS と ADCS の同期はインポート 手順で行われ、AADC がソース ディレクトリから読み取り、データをデータベースに格納する瞬間です。 つまり、データがコネクタ 空間でステージングされる場合です。 AD からの差分インポート中、AADC は、指定されたディレクトリ透かしの後に発生したすべての新しい変更を要求します。 この呼び出しは、Active Directory レプリケーション サービスに対して Directory Services DirSync コントロールを使用して AADC によって開始されます。 この手順では、最後に成功した AD インポートとして最後の透かしを提供し、すべての (デルタ) 変更を取得する必要がある時点からのポイントインタイム参照を AD に提供します。 AADC は AD からすべてのデータ (同期スコープ内) をインポートし、ADCS に残っているが AD からインポートされなかったすべてのオブジェクトを古い (削除) としてマークするため、完全なインポートは異なります。 AD と AADC の間のすべてのデータは LDAP 経由で転送され、既定で暗号化されます。

[A A D C 接続オプション] ダイアログのスクリーンショット。

AD との接続が成功したが、オブジェクトまたは属性が ADCS に存在しない場合 (ドメインまたはオブジェクトが同期スコープにあると仮定)、ほとんどの場合、問題には ADDS アクセス許可が含まれます。 ADCA では、ADCS にデータをインポートするために、AD 内のオブジェクトに対する読み取りアクセス許可が最低限必要です。 既定では、MSOL アカウントには、すべてのユーザー、グループ、およびコンピューターのプロパティに対する明示的な読み取り/書き込みアクセス許可があります。 ただし、次の条件に該当する場合、この状況は引き続き問題になる可能性があります。

  • AADC はカスタム ADCA を使用しますが、AD で十分なアクセス許可が提供されていませんでした。
  • 親 OU で継承がブロックされています。これにより、ドメインのルートからのアクセス許可の伝達が禁止されます。
  • オブジェクトまたは属性自体が継承をブロックしているため、アクセス許可の伝達が妨けられます。
  • オブジェクトまたは属性には、ADCA が読み取りを妨げる明示的な Deny アクセス許可があります。

Active Directory のトラブルシューティング

AD との接続

[同期] Service Managerの [AD からインポート] 手順では、[接続状態] の下で接続されているドメイン コントローラーが表示されます。 AD に影響を与える接続の問題が発生すると、ここでエラーが発生する可能性が最も高くなります。

[A D からのインポート] ステップの [接続状態] 領域を示すスクリーンショット。

AD の接続をさらにトラブルシューティングする必要がある場合(特に、Microsoft Entra Connect サーバーでエラーが発生していない場合、または製品のインストール処理中の場合は、ADConnectivityTool を使用して開始します。

ADDS への接続の問題には、次の原因があります。

  • 無効な AD 資格情報。 たとえば、ADCA の有効期限が切れているか、パスワードが変更されています。
  • "failed-search" エラー。DirSync コントロールが AD レプリケーション サービスと通信しない場合に発生します。通常は、ネットワーク パケットの断片化が高いためです。
  • AD で名前解決の問題 (DNS) が発生した場合に発生する "no-start-ma" エラー。
  • 名前解決の問題、ネットワーク ルーティングの問題、ブロックされたネットワーク ポート、高いネットワーク パケットの断片化、使用可能な書き込み可能な DC がないなどの問題が原因で発生する可能性があるその他の問題。 このような場合は、トラブルシューティングに役立つディレクトリ サービスまたはネットワーク サポート チームが関与する必要があります。

トラブルシューティングの概要

  • 使用されているドメイン コントローラーを特定します。
  • 優先ドメイン コントローラーを使用して、同じドメイン コントローラーをターゲットにします。
  • ADCA を正しく識別します。
  • ADConnectivityTool を使用して問題を特定します。
  • ADCA を使用してドメイン コントローラーにバインドするには、LDP ツールを使用します。
  • トラブルシューティングを行うには、Directory Services またはネットワーク サポート チームにお問い合わせください。

同期トラブルシューティング ツールを実行する

AD 接続のトラブルシューティングを行った後、 オブジェクトの同期のトラブルシューティング ツールを実行します。これは、オブジェクトまたは属性が同期しない最も明白な理由を検出できるためです。

Microsoft Entra接続のトラブルシューティング画面のスクリーンショット。

AD アクセス許可

AD アクセス許可がない場合、同期の両方向に影響する可能性があります。

  • ADDS から ADCS にインポートする場合、アクセス許可が不足すると、AADC がオブジェクトまたは属性をスキップして、AADC がインポート ストリームで ADDS 更新を取得できなくなる可能性があります。 このエラーは、ADCA にオブジェクトを読み取るのに十分なアクセス許可がないために発生します。
  • ADCS から ADDS にエクスポートすると、アクセス許可がない場合、"permission-issue" エクスポート エラーが発生します。

アクセス許可をチェックするには、AD オブジェクトの [プロパティ] ウィンドウを開き、[セキュリティ>の詳細設定] を選択し、[継承の無効化] ボタン (継承が有効になっている場合) を選択して、オブジェクトの許可/拒否 ACL を調べます。 列の内容を 種類 別に並べ替えて、すべての "拒否" アクセス許可を見つけることができます。 AD のアクセス許可は大きく異なる場合があります。 ただし、既定では、"Exchange トラステッド サブシステム" の "拒否 ACL" が 1 つだけ表示される場合があります。ほとんどのアクセス許可は 許可としてマークされます。

次の既定のアクセス許可が最も関連します。

  • Authenticated Users

    認証されたユーザーを示すスクリーンショット。

  • すべてのユーザー

    [許可] オプションが [すべてのユーザー] に設定されていることを示すスクリーンショット。

  • カスタム ADCA または MSOL アカウント

    カスタム ADCA または MSOL アカウントを示すスクリーンショット。

  • Windows 2000 以前の互換性のあるアクセス

    Windows 2000 以前の互換性のあるアクセスを示すスクリーンショット。

  • SELF

    SELF 権限が許可されていることを示すスクリーンショット。

アクセス許可のトラブルシューティングを行う最善の方法は、 AD ユーザーとコンピューター コンソールで "有効なアクセス" 機能を使用することです。 この機能は、トラブルシューティングするターゲット オブジェクトまたは属性に対する特定のアカウント (ADCA) に対する有効なアクセス許可をチェックします。

[セキュリティの詳細設定] ウィンドウの [有効なアクセス] タブの下の情報を示すスクリーンショット。

重要

ACL の変更はすぐには有効にならないため、AD のアクセス許可のトラブルシューティングは難しい場合があります。 このような変更は AD レプリケーションの対象であることを常に考慮してください。

以下に例を示します。

  • 最も近いドメイン コントローラーに必要な変更を直接行っていることを確認します (「AD との接続」セクションを参照してください)。
  • ADDS レプリケーションが発生するまで待ちます。
  • 可能であれば、ADSync サービスを再起動してキャッシュをクリアします。

トラブルシューティングの概要

  • 使用されているドメイン コントローラーを特定します。
  • 優先ドメイン コントローラーを使用して、同じドメイン コントローラーをターゲットにします。
  • ADCA を正しく識別します。
  • AD DS コネクタ アカウントのアクセス許可の構成ツールを使用します。
  • AD ユーザーとコンピューターで "有効なアクセス" 機能を使用します。
  • LDP ツールを使用して、ADCA を持つドメイン コントローラーに対してバインドし、失敗したオブジェクトまたは属性の読み取りを試みます。
  • ADCA をエンタープライズ管理者またはドメイン管理者に一時的に追加し、ADSync サービスを再起動します。

大事な： これをソリューションとして使用しないでください。

  • アクセス許可の問題を確認したら、高い特権を持つグループから ADCA を削除し、必要な AD アクセス許可を ADCA に直接提供します。
  • Engage Directory Services またはネットワーク サポート チームを使用して、状況のトラブルシューティングを支援します。

AD レプリケーション

この問題は、より大きな問題を引き起こすのMicrosoft Entra Connect に影響を与える可能性が低くなります。 ただし、Microsoft Entra Connect が遅延レプリケーションを使用してドメイン コントローラーからデータをインポートする場合、最新の情報は AD からインポートされません。これにより、最近 AD で作成または変更されたオブジェクトまたは属性が、ドメイン コントローラーにレプリケートされていないために同期がMicrosoft Entra IDされない同期の問題が発生します。Microsoft Entra接続中です。 これが問題であることを確認するには、AADC がインポートに使用するドメイン コントローラーをチェックし (「AD への接続」を参照)、AD ユーザーとコンピューター コンソールを使用してこのサーバーに直接接続します (次のイメージの「ドメイン コントローラーの変更」を参照)。 次に、このサーバー上のデータが最新のデータに対応していること、およびそれがそれぞれの ADCS データと一致しているかどうかを確認します。 この段階では、AADC はドメイン コントローラーとネットワーク 層に対してより大きな負荷を生成します。

Active Directory の [ドメイン コントローラーの変更] オプションのスクリーンショット。

もう 1 つの方法は、RepAdmin ツールを使用して、すべてのドメイン コントローラーでオブジェクトのレプリケーション メタデータをチェックし、すべてのドメイン コントローラーから値を取得し、ドメイン コントローラー間のレプリケーション状態をチェックすることです。

  • すべてのドメイン コントローラーの属性値:

    repadmin /showattr * "DC=contoso,DC=com" /subtree /filter:"sAMAccountName=User01" /attrs:pwdLastSet,UserPrincipalName

    showattr を使用した RepAdmin ツールのスクリーンショット。

  • すべての DC からのオブジェクト メタデータ:

    repadmin /showobjmeta * "CN=username,DC=contoso,DC=com" > username-ObjMeta.txt

    showobjmeta コマンドを使用した RepAdmin ツールのスクリーンショット。

  • AD レプリケーションの概要

    repadmin /replsummary

    replsummary コマンドを使用した RepAdmin ツールのスクリーンショット。

トラブルシューティングの概要

  • 使用されているドメイン コントローラーを特定します。
  • ドメイン コントローラー間のデータを比較します。
  • RepAdmin の結果を分析します。
  • 問題のトラブルシューティングを行うには、Directory Services またはネットワーク サポート チームにお問い合わせください。

ドメインと OU の変更、および ADDS コネクタでフィルター処理または除外されたオブジェクトの種類または属性

  • ドメインまたは OU のフィルター処理を変更するには、完全なインポートが必要です

    ドメインまたは OU のフィルター処理が確認された場合でも、ドメインまたは OU フィルター処理に対する変更は、完全なインポート手順を実行した後にのみ有効になります。

  • Microsoft Entra アプリと属性のフィルター処理を使用した属性のフィルター処理

    同期されない属性の見逃しやすいシナリオは、Microsoft Entra Connect がMicrosoft Entra アプリと属性フィルター機能で構成されている場合です。 機能が有効かどうかと属性をチェックするには、一般的な診断レポートを取得します。

  • ADDS コネクタ構成で除外されるオブジェクトの種類

    この状況は、ユーザーとグループに対して一般的には発生しません。 ただし、特定のオブジェクトの種類のすべてのオブジェクトが ADCS に存在しない場合は、ADDS コネクタ構成で有効になっているオブジェクトの種類を調べると便利な場合があります。

    次の図に示すように、 Get-ADSyncConnector コマンドレットを使用して、コネクタで有効になっているオブジェクトの種類を取得できます。 既定で有効にする必要があるオブジェクトの種類を次に示します。

    (Get-ADSyncConnector | where Name -eq "Contoso.com").ObjectInclusionList

    既定で有効にする必要があるオブジェクトの種類を次に示します。

    Get-ADSyncConnector オブジェクトの種類を示すスクリーンショット。

    注:

    publicFolder オブジェクトの種類は、メールが有効なパブリック フォルダー機能が有効になっている場合にのみ存在します。

  • ADCS で除外される属性

    同様に、属性がすべてのオブジェクトに存在しない場合は、AD コネクタで属性が選択されているかどうかをチェックします。

    ADDS コネクタで有効な属性をチェックするには、次の図に示すように同期マネージャーを使用するか、次の PowerShell コマンドレットを実行します。

    (Get-ADSyncConnector | where Name -eq "Contoso.com").AttributeInclusionList

    AD コネクタ同期マネージャーのスクリーンショット。

    注:

    同期Service Managerにオブジェクトの種類または属性を含めたり除外したりすることはできません。

トラブルシューティングの概要

手順 1 のリソース

主なリソース:

  • Get-ADSyncConnectorAccount - AADC で使用される正しいコネクタ アカウントを特定する

  • ADConnectivityTool

  • ADDS での接続の問題を特定する

  • Trace-ADSyncToolsADImport (ADSyncTools) - ADDS からインポートされるトレース データ

  • LDIFDE - ADDS と ADCS の間でデータを比較するために ADDS からオブジェクトをダンプする

  • LDP - AD のセキュリティ コンテキストでオブジェクトを読み取るために AD バインド接続とアクセス許可をテストする

  • DSACLS - ADDS アクセス許可の比較と評価

  • Set-ADSync< 機能 >のアクセス許可 - ADDS で既定の AADC アクセス許可を適用する

  • RepAdmin - AD オブジェクトのメタデータと AD レプリケーションの状態を確認する

手順 2: ADCS と MV の間の同期

A D C S から MetaVerse のフローチャートを示すスクリーンショット。

手順 2 の目的

この手順では、オブジェクトまたは属性が CS から MV に流れるかどうかを確認します (つまり、オブジェクトまたは属性が MV に投影されているかどうか)。 この段階で、オブジェクトが存在するか、ADCS で属性が正しいことを確認し ( 手順 1 で説明します)、オブジェクトの同期規則と系列の確認を開始します。

手順 2 の説明

ADCS と MV の間の同期は、差分/完全同期ステップで行われます。 この時点で、AADC は ADCS でステージングされたデータを読み取り、すべての同期規則を処理し、それぞれの MV オブジェクトを更新します。 この MV オブジェクトには、そのプロパティと同期手順で適用された同期規則の系列に貢献する CS オブジェクトを指す CS リンク (またはコネクタ) が含まれます。 この段階では、AADC は、SQL Server (または LocalDB) とネットワーク レイヤーに対してより多くの負荷を生成します。

オブジェクトの ADCS > MV のトラブルシューティング

  • プロビジョニングの受信同期規則を確認する

    ADCS に存在するが MV に存在しないオブジェクトは、そのオブジェクトに適用されたプロビジョニング同期規則のいずれにもスコープ フィルターがなかったことを示します。 そのため、オブジェクトは MV に投影されませんでした。 この問題は、無効またはカスタマイズされた同期規則がある場合に発生する可能性があります。

    受信プロビジョニング同期規則の一覧を取得するには、次のコマンドを実行します。

    Get-ADSyncRule | where {$_.Name -like "In From AD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

    Get-ADSyncRule コマンドを使用して受信プロビジョニング 規則をチェックするスクリーンショット。

  • ADCS オブジェクトの系列を確認する

    失敗したオブジェクトを ADCS から取得するには、"Search コネクタ スペース" で "DN またはアンカー" を検索します。[系列] タブでは、オブジェクトが切断 (MV へのリンクなし) であり、系列が空であることがわかります。 また、同期エラー タブがある場合に、オブジェクトにエラーがあるかどうかをチェックします。

    A D C S のコネクタ スペース オブジェクトプロパティのスクリーンショット。

  • ADCS オブジェクトでプレビューを実行する

    [プレビューの>生成] [コミット> プレビューの生成] を選択して、オブジェクトが MV に投影されているかどうかを確認します。 その場合は、完全同期サイクルによって、同じ状況にある他のオブジェクトの問題が解決されます。

    A D C S オブジェクトプレビュー画面のスクリーンショット。

    A D C S の [ソース オブジェクトの詳細] 画面のスクリーンショット。

  • オブジェクトを XML にエクスポートする

    より詳細な分析 (またはオフライン分析用) には、 Export-ADSyncObject コマンドレットを使用して、オブジェクトに関連するすべてのデータベース データを収集できます。 このエクスポートされた情報は、どのルールがオブジェクトを除外するかを判断するのに役立ちます。 つまり、プロビジョニング同期規則の受信スコーピング フィルターによって、オブジェクトが MV に投影されなくなります。

    Export-ADsyncObject 構文の例を次に示します。

    • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
    • Export-ADsyncObject -DistinguishedName 'CN=TestUser,OU=Sync,DC=Domain,DC=Contoso,DC=com' -ConnectorName 'Domain.Contoso.com'
    • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose

トラブルシューティングの概要 (オブジェクト)

  • "In From AD" 受信プロビジョニング 規則のスコープ フィルターを確認します。
  • オブジェクトのプレビューを作成します。
  • 完全同期サイクルを実行します。
  • Export-ADSyncObject スクリプトを使用してオブジェクト データをエクスポートします。

属性の ADCS > MV のトラブルシューティング

  1. 属性の受信同期規則と変換規則を特定する

    各属性には、ADCS から MV への値の転送を担当する独自の変換規則のセットがあります。 最初の手順は、トラブルシューティングを行っている属性の変換ルールを含む同期規則を特定することです。

    特定の属性の変換規則を持つ同期規則を特定する最善の方法は、同期規則エディターの組み込みのフィルター機能を使用することです。

    A D C S でエディター同期規則のスクリーンショット。

  2. ADCS オブジェクトの系列を確認する

    CS と MV の間の各コネクタ (またはリンク) には、その CS オブジェクトに適用される同期規則に関する情報を含む系列があります。 前の手順では、ADCS から MV に正しい値を流すために、オブジェクトの系列に存在する必要がある受信同期規則のセット (プロビジョニングまたは結合同期規則) を示します。 ADCS オブジェクトの系列を調べることで、その同期規則がオブジェクトに適用されたかどうかを判断できます。

    コネクタスペースオブジェクトのプロパティ系列画面のスクリーンショット。

    MV オブジェクトにリンクされた複数のコネクタ (複数の AD フォレスト) がある場合は、 メタバース オブジェクトのプロパティ を調べて、トラブルシューティングしようとしている属性に属性値を提供しているコネクタを特定する必要があります。 コネクタを特定したら、その ADCS オブジェクトの系列を調べます。

    メタバース オブジェクトのプロパティ画面のスクリーンショット。

  3. 受信同期規則のスコープ フィルターを確認する

    同期規則が有効になっているが、オブジェクトの系列に存在しない場合、オブジェクトは同期規則のスコープ フィルターによって除外する必要があります。 同期規則のスコープ フィルター、ADCS オブジェクト上のデータ、および同期規則が有効か無効かを確認することで、その同期規則が ADCS オブジェクトに適用されなかった理由を判断できます。

    Exchange プロパティの同期を担当する同期規則からの一般的な面倒なスコープ フィルターの例を次に示します。 オブジェクトに mailNickName の null 値がある場合、変換ルール内の Exchange 属性はMicrosoft Entra IDにフローしません。

    [受信同期規則の表示] 画面のスクリーンショット。

  4. ADCS オブジェクトでプレビューを実行する

    ADCS オブジェクトの系列に同期規則がない理由を特定できない場合は、オブジェクトの完全同期に対して [プレビューの生成 ] と [ コミット プレビュー ] を使用してプレビューを実行します。 MV で属性が更新され、プレビューがある場合は、完全同期サイクルによって、同じ状況にある他のオブジェクトの問題が解決されます。

  5. オブジェクトを XML にエクスポートする

    より詳細な分析またはオフライン分析を行うには、 Export-ADSyncObject スクリプトを使用して、オブジェクトに関連するすべてのデータベース データを収集できます。 このエクスポートされた情報は、MV への属性の投影を妨げているオブジェクトに存在しない同期規則または変換ルールを特定するのに役立ちます (この記事の 「Export-ADSyncObject の例」を参照してください)。

トラブルシューティングの概要 (属性の場合)

  • MV への属性のフローを担当する正しい同期規則と変換ルールを特定します。
  • オブジェクトの系列を確認します。
  • 同期規則が有効になっているかどうかを確認します。
  • オブジェクトの系列に存在しない同期規則のスコープ フィルターを確認します。

同期規則パイプラインの高度なトラブルシューティング

同期規則の処理の観点から ADSync エンジン (MiiServer とも呼ばれます) をさらにデバッグする必要がある場合は、.config ファイル (C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config) で ETW トレースを有効にすることができます。 このメソッドは、同期規則のすべての処理を示す広範な詳細テキスト ファイルを生成します。 ただし、すべての情報を解釈するのは困難な場合があります。 最後の手段として、または Microsoft サポート で示されている場合は、このメソッドを使用します。

手順 2 のリソース

  • 同期Service Manager UI
  • 同期規則のエディター
  • Export-ADsyncObject スクリプト
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW トレース SyncRulesPipeline (miiserver.exe.config)

手順 3: MV と AADCS の間の同期

M V と A A D C S フローチャートのスクリーンショット。

手順 3 の目的

この手順では、オブジェクトまたは属性が MV から AADCS に流れるかどうかを確認します。 この時点で、オブジェクトが存在するか、ADCS と MV で属性が正しいことを確認します (手順 1 と 2 で説明します)。 次に、オブジェクトの同期規則と系列を調べます。 この手順は、ADCS から MV への受信方向を調べた 手順 2 と似ていますが、この段階では、MV から AADCS に流れる送信同期規則と属性に重点を置きます。

手順 3 の説明

MV と AADCS の間の同期は、差分/完全同期ステップで行われます。AADC が MV 内のデータを読み取り、すべての同期規則を処理し、それぞれの AADCS オブジェクトを更新します。 この MV オブジェクトには、そのプロパティに貢献する CS オブジェクトと、同期手順で適用された同期規則の系列を指す CS リンク (コネクタとも呼ばれます) が含まれます。 この時点で、AADC は、SQL Server (または localDB) とネットワーク 層に対してより多くの負荷を生成します。

オブジェクトの MV から AADCS へのトラブルシューティング

  1. プロビジョニングの送信同期規則を確認する

    MV に存在するが AADCS に存在しないオブジェクトは、そのオブジェクトに適用されたプロビジョニング同期規則のいずれにもスコープ フィルターがなかったことを示します。 たとえば、次の図に示す "out to Microsoft Entra ID" 同期規則を参照してください。 そのため、オブジェクトは AADCS でプロビジョニングされませんでした。 このエラーは、無効またはカスタマイズされた同期規則がある場合に発生する可能性があります。

    受信プロビジョニング同期規則の一覧を取得するには、次のコマンドを実行します。

    Get-ADSyncRule | where {$_.Name -like "Out to AAD*" -and $_.LinkType -eq "Provision"} | select Name,Direction,LinkType,Precedence,Disabled | ft

    送信同期規則をチェックするために使用される Get-ADSyncRule のスクリーンショット。

  2. ADCS オブジェクトの系列を確認する

    MV から失敗したオブジェクトを取得するには、Metaverse Searchを使用し、[コネクタ] タブを調べます。このタブでは、MV オブジェクトが AADCS オブジェクトにリンクされているかどうかを確認できます。 また、同期エラー タブが存在する場合に、オブジェクトにエラーがあるかどうかをチェックします。

    メタバース Search画面のスクリーンショット。

    AADCS コネクタが存在しない場合、オブジェクトは cloudFiltered=True に設定される可能性が最も高くなります。 cloudFiltered 値を使用して同期規則が関与している MV 属性を調べることで、オブジェクトが クラウド フィルター 処理されているかどうかを確認できます。

  3. AADCS オブジェクトでプレビューを実行する

    [ プレビューの>生成] [プレビュー>のコミット] を選択して、オブジェクトが AADCS に接続するかどうかを判断します。 その場合は、完全同期サイクルによって、同じ状況にある他のオブジェクトの問題が解決されます。

  4. オブジェクトを XML にエクスポートする

    より詳細な分析またはオフライン分析を行うには、 Export-ADSyncObject スクリプトを使用して、オブジェクトに関連するすべてのデータベース データを収集できます。 このエクスポートされた情報は、(送信) 同期規則の構成と共に、オブジェクトをフィルター処理するルールを決定するのに役立ち、プロビジョニング同期規則のどの送信スコープ フィルターによってオブジェクトが AADCS との接続を妨げているかを判断できます。

    Export-ADsyncObject 構文の例を次に示します。

    • Import-Module "C:\Program Files\Microsoft Azure Active Directory Connect\Tools\AdSyncTools.psm1"
    • Export-ADsyncObject -ObjectId '{46EBDE97-7220-E911-80CB-000D3A3614C0}' -Source Metaverse -Verbose
    • Export-ADsyncObject -DistinguishedName 'CN={2B4B574735713744676B53504C39424D4C72785247513D3D}' -ConnectorName 'Contoso.onmicrosoft.com - AAD'

オブジェクトのトラブルシューティングの概要

  • "Out to Microsoft Entra ID" の送信プロビジョニング規則のスコープ フィルターを確認します。
  • オブジェクトのプレビューを作成します。
  • 完全同期サイクルを実行します。
  • Export-ADSyncObject スクリプトを使用してオブジェクト データをエクスポートします。

属性の MV から AADCS へのトラブルシューティング

  1. 属性の送信同期規則と変換規則を特定する

    各属性には、MV から AADCS への値のフローを担当する独自の変換規則のセットがあります。 まず、トラブルシューティングを行っている属性の変換規則が含まれている同期規則を特定します。

    特定の属性に対して変換規則を持つ同期規則を特定する最善の方法は、同期規則エディターの組み込みフィルター機能を使用することです。

    同期規則のエディターのスクリーンショット。

  2. ADCS オブジェクトの系列を確認する

    CS と MV の間の各コネクタ (またはリンク) には、その CS オブジェクトに適用される同期規則に関する情報を含む系列があります。 前の手順では、MV から AADCS に正しい値を流すために、オブジェクトの系列に存在する必要がある送信同期規則のセット (プロビジョニングまたは結合同期規則) を示します。 AADCS オブジェクトの系列を調べることで、その同期規則がオブジェクトに適用されているかどうかを判断できます。

    A A D C S オブジェクトの [系列] タブの詳細を示すスクリーンショット。

  3. 送信同期規則のスコープ フィルターを確認する

    同期規則が有効になっているが、オブジェクトの系列に存在しない場合は、同期規則のスコープ フィルターによって除外する必要があります。 同期規則のスコープ フィルターの有無と MV オブジェクト上のデータを確認し、同期規則が有効か無効かを確認することで、その同期規則が AADCS オブジェクトに適用されなかった理由を判断できます。

  4. AADCS オブジェクトでプレビューを実行する

    ADCS オブジェクトの系列に同期規則がない理由を決定する場合は、オブジェクトの完全同期に [プレビューの 生成 ] と [コミット プレビュー ] を使用するプレビューを実行します。 プレビューを使用して MV で属性が更新された場合、完全同期サイクルによって、同じ状況にある他のオブジェクトの問題が解決されます。

  5. オブジェクトを XML にエクスポートする

    より詳細な分析またはオフライン分析を行うには、"Export-ADSyncObject" スクリプトを使用して、オブジェクトに関連するすべてのデータベース データを収集できます。 このエクスポートされた情報は、(送信) 同期規則の構成と共に、属性が AADCS に流れるのを妨げているオブジェクトに存在しない同期規則または変換規則を特定するのに役立ちます (前述の「Export-ADSyncObject」の例を参照してください)。

属性のトラブルシューティングの概要

  • 属性を AADCS にフローさせる正しい同期規則と変換規則を特定します。
  • オブジェクトの系列を確認します。
  • 同期規則が有効になっていることを確認します。
  • オブジェクトの系列に存在しない同期規則のスコープ フィルターを確認します。

同期規則パイプラインのトラブルシューティング

同期規則の処理の観点から ADSync エンジン (MiiServer とも呼ばれます) をさらにデバッグする必要がある場合は、.config ファイル (C:\Program Files\Microsoft Azure AD Sync\Bin\miiserver.exe.config) で ETW トレースを有効にすることができます。 このメソッドは、同期規則のすべての処理を示す広範な詳細テキスト ファイルを生成します。 ただし、すべての情報を解釈するのは困難な場合があります。 このメソッドは、最後の手段としてのみ使用するか、Microsoft サポートで示されている場合にのみ使用します。

リソース

  • 同期Service Manager UI
  • 同期規則のエディター
  • Export-ADsyncObject スクリプト
  • Start-ADSyncSyncCycle -PolicyType Initial
  • ETW トレース SyncRulesPipeline (miiserver.exe.config)

手順 4: AADCS と AzureAD の間の同期

A D C S と Microsoft Entra IDの間の同期フローチャートのスクリーンショット。

手順 4 の目的

このステージでは、AADCS オブジェクトと、Microsoft Entra IDでプロビジョニングされたそれぞれのオブジェクトを比較します。

手順 4 の説明

Microsoft Entra IDとの間でデータのインポートとエクスポートに関連する複数のコンポーネントとプロセスによって、次の問題が発生する可能性があります。

  • インターネットへの接続
  • 内部ファイアウォールと ISP 接続 (ブロックされたネットワーク トラフィックなど)
  • DirSync Webservice の前にある Microsoft Entra ゲートウェイ (AdminWebService エンドポイントとも呼ばれます)
  • The DirSync Webservice API
  • Microsoft Entra Core ディレクトリ サービス

幸いなことに、これらのコンポーネントに影響を与える問題は、通常、Microsoft サポートによってトレースできるイベント ログにエラーを生成します。 したがって、これらの問題は、この記事の範囲外です。 それでも、調査できる "サイレント" の問題がまだ存在します。

AADCS のトラブルシューティング

  • Microsoft Entra IDにエクスポートする複数のアクティブな AADC サーバー

    Microsoft Entra IDのオブジェクトが属性値を前後に反転させる一般的なシナリオでは、複数のアクティブな Microsoft Entra Connect サーバーがあり、これらのサーバーの 1 つはローカル AD との接続を失いますが、インターネットに接続されたままであり、データをMicrosoft Entra IDにエクスポートできます。 そのため、この "古い" サーバーが、他のアクティブなサーバーによって行われた同期オブジェクトのMicrosoft Entra IDからの変更をインポートするたびに、同期エンジンは ADCS 内の古い AD データに基づいてその変更を元に戻します。 このシナリオの一般的な症状は、Microsoft Entra IDに同期されている AD に変更を加えたが、変更が数分後 (最大 30 分) に元の値に戻るということです。 この問題を迅速に軽減するには、使用停止になった古いサーバーまたは仮想マシンに戻り、ADSync サービスがまだ実行されているかどうかをチェックします。

  • DirSyncOverrides を使用したモバイル属性

    管理が MSOnline または AzureAD PowerShell モジュールを使用している場合、またはユーザーが Office Portal に移動して Mobile 属性を更新した場合、オブジェクトがオンプレミス AD (DirSyncEnabled とも呼ばれます) から同期されているにもかかわらず、更新された電話番号は AzureAD で上書きされます。

    この更新プログラムと共に、Microsoft Entra IDでは、このユーザーがMicrosoft Entra IDで携帯電話番号が "上書き" されていることを示すフラグをオブジェクトに設定します。 この時点から、この属性はオンプレミスの AD によって管理されなくなったため、オンプレミスから発信されたモバイル属性に対する更新は無視されます。

    BypassDirSyncOverrides 機能の詳細と、Mobile 属性と他のMobile 属性の同期をMicrosoft Entra IDからオンプレミスの Active Directoryに復元する方法については、「Microsoft Entra テナントの BypassDirSyncOverrides 機能を使用する方法」を参照してください。

  • userPrincipalName の変更がMicrosoft Entra IDで更新されない

    Microsoft Entra IDで UserPrincipalName 属性が更新されず、他の属性が想定どおりに同期されている場合は、SynchronizeUpnForManagedUsers という名前の機能がテナントで有効になっていない可能性があります。 このシナリオは頻繁に発生します。

    この機能が追加される前に、ユーザーがMicrosoft Entra IDでプロビジョニングされ、ライセンスが割り当てられた後にオンプレミスから取得された UPN に対する更新はすべて無視されました。 管理者は、MSOnline または Azure AD PowerShell を使用して、Microsoft Entra IDで UPN を直接更新する必要があります。 この機能が更新されると、UPN への更新は、ユーザーがライセンス (管理) されているかどうかに関係なく、Microsoft Entraにフローされます。

    注:

    有効にした後、この機能を無効にすることはできません。

    UserPrincipalName の更新は、ユーザーがライセンスされていない場合に機能します。 ただし、SynchronizeUpnForManagedUsers 機能がないと、ユーザーがプロビジョニングされた後に UserPrincipalName が変更され、Microsoft Entra IDで更新されないライセンスが割り当てられます。 Microsoft では、お客様に代わってこの機能を無効にしていないことに注意してください。

  • 無効な文字と ProxyCalc 内部

    同期エラーが発生しない無効な文字に関連する問題は、 UserPrincipalName 属性と ProxyAddresses 属性の方が面倒です。これは、ProxyCalc 処理のカスケード効果により、オンプレミス AD から同期された値を サイレントに 破棄するためです。 この状況は次のように発生します。

    1. Microsoft Entra IDの結果の UserPrincipalName は、MailNickName または CommonName @ (at) 初期ドメインになります。 たとえば、 ではなくJohn.Smith@Contoso.com、Microsoft Entra IDの UserPrincipalName は、オンプレミス AD の UPN 値に非表示の文字があるためになりますsmithj@Contoso.onmicrosoft.com。

    2. ProxyAddress に空白文字が含まれている場合、ProxyCalc はそれを破棄し、初期ドメインの MailNickName に基づいて電子メール アドレスを自動生成します。 たとえば、"SMTP: John.Smith@Contoso.com" はコロンの後に空白文字が含まれているため、Microsoft Entra IDには表示されません。

    3. スペース文字を含む UserPrincipalName または非表示文字を含む ProxyAddress は、同じ問題を引き起こします。

      UserPrincipalName または ProxyAddress の無効な文字のトラブルシューティングを行うには、ファイルにエクスポートされた LDIFDE または PowerShell からローカル AD に格納されている値を調べます。 見えない文字を検出する簡単なトリックは、エクスポートされたファイルの内容をコピーし、PowerShell ウィンドウに貼り付けることです。 次の例に示すように、非表示の文字は疑問符 (?) に置き換えられます。

      UserPrincipalName または ProxyAddress のトラブルシューティングの例を示すスクリーンショット。

  • ThumbnailPhoto 属性 (KB4518417)

    AD から ThumbnailPhoto を初めて同期した後、更新できなくなるという一般的な誤解があります。これは部分的にしか当てはまりません。

    通常、Microsoft Entra IDの ThumbnailPhoto は継続的に更新されます。 ただし、更新された画像が、それぞれのワークロードまたはパートナー (EXO や SfBO など) によってMicrosoft Entra IDから取得されなくなった場合に問題が発生します。 この問題により、画像がオンプレミス AD からMicrosoft Entra IDに同期されなかったという誤った印象が生じる。

    ThumbnailPhoto のトラブルシューティングに関する基本的な手順

    1. イメージが AD に正しく格納されていて、サイズ制限の 100 KB を超えていないことを確認します。

    2. アカウント ポータルでイメージを確認するか、Get-AzureADUserThumbnailPhoto を使用します。これらのメソッドは、Microsoft Entra IDから ThumbnailPhoto を直接読み取るためです。

    3. AD (または AzureAD) thumbnailPhoto に正しいイメージがあるが、他のオンライン サービスでは正しくない場合は、次の条件が適用される場合があります。

    • ユーザーのメールボックスには HD イメージが含まれており、Microsoft Entra thumbnailPhoto からの低解像度イメージを受け入れていません。 解決策は、ユーザーのメールボックス イメージを直接更新することです。
    • ユーザーのメールボックス イメージは正しく更新されましたが、元のイメージは引き続き表示されます。 解決策は、Office 365 ユーザー ポータルまたはAzure portalで更新されたイメージが表示されるまで少なくとも 6 時間待つ必要があります。

その他のリソース

お問い合わせはこちらから

質問がある場合やヘルプが必要な場合は、サポート要求を作成するか、Azure コミュニティ サポートにお問い合わせください。 Azure フィードバック コミュニティに製品フィードバックを送信することもできます。