Azure Active Directory 同期でのユーザーと連絡先について
更新日: 2015 年 7 月 22 日
重要
このトピックは近日中にアーカイブされます。
AADSyncと DirSync を置き換える "Azure Active Directory Connect" という新しい製品があります。
Azure AD Connect には、以前 Dirsync と AAD Sync としてリリースされたコンポーネントと機能が組み込まれています。
将来のある時点で、Dirsync とAAD Syncのサポートは終了します。
これらのツールは機能改善によって個別に更新されなくなり、今後のすべての機能強化は Azure AD Connectの更新プログラムに含まれる予定です。
複数の Active Directory フォレストを使用することになる理由はさまざまあり、複数の異なるデプロイ トポロジがあります。 一般的なモデルとしては、アカウント リソース デプロイ、合併や買収の後で GAL 同期が行われたフォレストなどがあります。 ただし、純粋なモデルがある一方で、ハイブリッド モデルも一般的です。 AADSync の既定の構成では特殊なモデルを想定しませんが、インストール ガイドにおけるユーザーの一致の選択方法によっては、異なる動作が見られることもあります。
このドキュメントでは、既定の構成が特定のトポロジでどのように動作するかを説明します。 構成の概要についてと、構成を確認するために使用できる同期ルール エディターについて取り上げます。
構成の前提となるいくつかの一般的なルールがあります。
ソースの Active Directory を読み取る順序に関係なく、最終的な結果は常に同じになる必要があります。
アクティブなアカウントは、userPrincipalName と sourceAnchor を含むログイン情報を常に提供します。
無効なアカウントは、リンクされたメールボックスでない限り、userPrincipalName と sourceAnchor を提供します。
リンクされたメールボックスを使用するアカウントは、userPrincipalName と sourceAnchor に使用されることはありません。 アクティブなアカウントは後で見つかることが前提です。
連絡先オブジェクトは、Azure AD に対して連絡先またはユーザーとしてプロビジョニングされます。 すべてのソースの Active Directory フォレストが処理されるまでは、実際にはわかりません。
連絡先
異なるフォレスト内のユーザーを表す連絡先は、GALSync ソリューションが複数のExchange フォレストをブリッジしている合併&買収後に一般的です。 連絡先オブジェクトは、メール属性を使用してコネクタ スペースからメタバースを常に結合しています。 同じメール アドレスの連絡先オブジェクトまたはユーザー オブジェクトが既にある場合、これらのオブジェクトは一緒に結合されます。 これは、In from AD – Contact Join というルールで構成されます。 また、定数が Contact であるメタバース属性 sourceObjectType への属性フローを使用する In from AD – Contact Common というルールもあります。 このルールの優先順位は低いので、ユーザー オブジェクトが同じメタバース オブジェクトに結合された場合は、In from AD – User Common というルールによって User という値がこの属性に提供されます。 このルールでは、この属性は、ユーザーが 1 人も結合されていない場合に Contact という値を使用し、ユーザーが 1 人でも見つかった場合に User という値を使用します。
AAD に対するオブジェクトのプロビジョニングでは、メタバース属性 sourceObjectType が Contact に設定された場合、Out to AAD – Contact Join というアウトバウンド ルールによって連絡先オブジェクトが作成されます。 この属性が User に設定された場合は、代わりに Out to AAD – User Join というルールによってユーザー オブジェクトが作成されます。 より多くのソースの Active Directory がインポートされ、同期されるときに、オブジェクトは Contact から User に昇格できます。
たとえば、GALSync トポロジでは、最初のフォレストをインポートするときに、2 番目のフォレストですべてのユーザーの連絡先オブジェクトを見つけます。 これにより、AAD コネクタの新しい連絡先オブジェクトがステージングされます。 後で 2 番目のフォレストをインポートして同期するときに、実際のユーザーを見つけ、既存のメタバース オブジェクトに結合します。 次に、AAD の連絡先オブジェクトを削除し、代わりに新しいユーザー オブジェクトを作成します。
ユーザーが連絡先として表されるトポロジを使用する場合は、インストール ガイドでメール属性のユーザーに一致するように選択する必要があります。 別のオプションを選択した場合は、順序に依存する構成を使用します。 連絡先オブジェクトは、常にメール属性で結合されますが、ユーザー オブジェクトは、このオプションがインストール ガイドで選択された場合にのみメール属性で結合されます。 そうすると、ユーザー オブジェクトより前に連絡先オブジェクトがインポートされた場合、メタバース内の 2 つの異なるオブジェクトが同じメール属性を使用することになる可能性があります。 Azure AD へのエクスポート中に、エラーがスローされます。 この動作は仕様によるもので、不適切なデータが示されるか、インストール時にトポロジが正常に特定されなかったことが示されます。
無効なアカウント
無効なアカウントは、Azure AD にも同期されます。 無効なアカウントは、会議室などの Exchange のリソースを表すことが一般的です。 リンクされたメールボックスを使用するユーザーは例外で、すでに説明したように、これらのユーザーは Azure AD に対してアカウントをプロビジョニングしません。
前提では、無効なユーザー アカウントが見つかった場合、後で別のアクティブなアカウントを見つけることはなく、オブジェクトは、見つかった userPrincipalName および sourceAnchor を使用して Azure AD にプロビジョニングされます。 別のアクティブなアカウントが同じメタバース オブジェクトに結合される場合は、その userPrincipalName と sourceAnchor が使用されます。
sourceAnchor の変更
オブジェクトが Azure AD にエクスポートされると、sourceAnchor は変更できなくなります。 オブジェクトがエクスポートされると、Azure AD が受け取った sourceAnchor 値を使用してメタバース属性 cloudSourceAnchor が設定されます。 sourceAnchor が変更され、cloudSourceAnchor と一致しない場合、Out to AAD – User Join というルールによって "sourceAnchor 属性が変更されました" というエラーがスローされます。 この場合、オブジェクトを再度同期できるようにするために、構成またはデータを修正して、同じ sourceAnchor がメタバースに再び存在するようにする必要があります。