次の方法で共有

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

  • [アーティクル]

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

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

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

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

ここで説明する手順は、ローカルの 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!"

Note

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 日以降に使用障害が発生する可能性があります。

ただし、テナント上のすべての同期されたオブジェクトに対して 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 など) を使用しており、AADC を再インストールして、 ms-Ds-Consistency-Guid/ObjectGuid を新しい SourceAnchor 属性 (またはその逆) として使用し始めます。
  • 危険なメールボックスとテナントの移行戦略に関連するいくつかのシナリオがあります。

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

Set-ADSyncScheduler -SyncCycleEnabled $false

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

Start-ADSyncSyncCycle

用語集

頭字語/省略形 名前/説明
AADC Microsoft Entra Connect
AADCA Microsoft Entra Connector アカウント
AADCS Microsoft Entra Connector スペース
AADCS:AttributeA Microsoft Entra コネクタ スペースの属性 'A'
ACL アクセス制御リスト (ADDS アクセス許可とも呼ばれます)
ADCA AD コネクタ アカウント
ADCS 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 レプリケーション サービスに対してディレクトリ サービス DirSync コントロールを使用して AADC によって開始されます。 この手順では、最後に成功した AD インポートとして最後の基準値を提供し、すべての (差分) 変更を取得する必要がある時点からの参照を AD に提供します。 完全なインポートは異なります。AADC は AD からすべてのデータを (同期スコープ内で) インポートし、ADCS に残っているが AD からインポートされなかったすべてのオブジェクトを古い (削除) とマークします。 AD と AADC の間のすべてのデータは LDAP 経由で転送され、既定で暗号化されます。

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

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

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

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

AD との接続

Synchronization Service Manager の [AD からのインポート] ステップで、接続状態 接続されているドメイン コントローラーが表示されます。 ほとんどの場合、AD に影響する接続の問題がある場合は、ここでエラーが表示されます。

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

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

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

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

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

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

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

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

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

AD のアクセス許可

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

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

アクセス許可を確認するには、AD オブジェクトの Properties ウィンドウを開き、 Security>Advanced を選択し、 [継承可能な継承 ] ボタン (継承が有効になっている場合) を選択して、オブジェクトの許可/拒否 ACL を調べます。 列の内容を Type で並べ替えて、すべての "拒否" アクセス許可を見つけることができます。 AD のアクセス許可は大きく異なる場合があります。 ただし、既定では、"Exchange 信頼済みサブシステム" の "拒否 ACL" が 1 つだけ表示される場合があります。ほとんどのアクセス許可は Allow としてマークされます。

最も関連性の高い既定のアクセス許可を次に示します。

  • Authenticated Users

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

  • すべてのユーザー

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

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

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

  • Pre-Windows 2000 Compatible Access

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

  • SELF

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

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

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

重要

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

例えば次が挙げられます。

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

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

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

重要: これをソリューションとして使用しないでください。

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

AD レプリケーション

この問題は、Microsoft Entra Connect により大きな問題が発生するため、影響を受ける可能性が低くなります。 ただし、Microsoft Entra Connect が遅延レプリケーションを使用してドメイン コントローラーからデータをインポートする場合は、AD から最新の情報がインポートされません。これにより、AD で最近作成または変更されたオブジェクトまたは属性が、Microsoft Entra Connect が接続しているドメイン コントローラーにレプリケートされていないために Microsoft Entra ID と同期されない同期の問題が発生します。 これが問題であることを確認するには、AADC がインポートに使用するドメイン コントローラー (「AD への接続」を参照) を確認し、 AD ユーザーとコンピューター コンソールを使用してこのサーバーに直接接続します (次の図の「 Change ドメイン コントローラー 」を参照してください)。 次に、このサーバー上のデータが最新のデータに対応していること、およびそれぞれの 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 アプリと属性フィルター処理 機能で構成されている場合です。 機能が有効かどうか、およびどの属性に対して有効になっているかを確認するには、 General 診断レポートを取得。

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

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

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

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

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

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

    Note

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

  • ADCS で除外される属性

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

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

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

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

    Note

    Synchronization Service Manager にオブジェクトの種類または属性を含めるか除外することはサポートされていません。

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

手順 1 のリソース

主なリソース:

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

  • ADConnectivityTool

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

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

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

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

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

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

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

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

スクリーンショットは、A D C S から MetaVerse へのフロー チャートを示しています。

手順 2 の目的

この手順では、オブジェクトまたは属性が CS から MV に流れるかどうかを確認します (つまり、オブジェクトまたは属性が MV に投影されているかどうか)。 この段階で、オブジェクトが存在するか、または属性が ADCS ( Step 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 オブジェクトの系列を確認する

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

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

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

    Preview>Generate Preview>Commit Preview を選択して、オブジェクトが MV に投影されているかどうかを確認します。 その場合は、完全同期サイクルで、同じ状況の他のオブジェクトの問題を解決する必要があります。

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

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

  • オブジェクトを 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 に値を転送する独自の変換規則のセットがあります。 最初の手順では、トラブルシューティングを行っている属性の変換規則を含む同期規則を特定します。

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

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

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

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

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

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

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

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

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

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

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

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

    ADCS オブジェクトの系列に同期規則がない理由を特定できない場合は、オブジェクトの完全同期のために Generate Preview と Commit Preview を使用してプレビューを実行します。 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 のリソース

  • Synchronization 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 への受信方向を調べた Step 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 オブジェクトにリンクされているかどうかを確認できます。 また、同期エラー タブが存在する場合に備え、オブジェクトにエラーがあるかどうかを確認します。

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

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

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

    Preview>Generate Preview>Commit a Preview を選択して、オブジェクトが 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'

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

  • "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 オブジェクトの系列に同期規則がない理由を特定する場合は、オブジェクトの完全な同期に Generate Preview と Commit Preview を使用するプレビューを実行します。 プレビューを使用して 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 サポートで示されている場合にのみ使用します。

リソース

  • Synchronization 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 Web サービス (AdminWebService エンドポイントとも呼ばれます) の前にある Microsoft Entra Gateway
  • 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 で携帯電話番号を "上書き" したことを示すフラグをオブジェクトに DirSyncOverrides も設定します。 この時点から、オンプレミスから送信されたモバイル属性に対する更新は無視されます。この属性はオンプレミス AD によって管理されなくなります。

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

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

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

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

    Note

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

    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 フィードバック コミュニティに製品フィードバックを送信することもできます。