Azure AD Connect 同期: 宣言型のプロビジョニングについてAzure AD Connect sync: Understanding Declarative Provisioning

このトピックでは、Azure AD Connect の構成モデルについて説明します。This topic explains the configuration model in Azure AD Connect. このモデルは宣言型のプロビジョニングと呼ばれ、構成の変更を簡単に実行することができます。The model is called Declarative Provisioning and it allows you to make a configuration change with ease. このトピックで説明する多くの内容は高度であるため、ほとんどの顧客シナリオで必要ありません。Many things described in this topic are advanced and not required for most customer scenarios.


宣言型のプロビジョニングでは、ソースの接続されたディレクトリからのオブジェクトを処理します。また、オブジェクトと属性をソースからターゲットに変換する方法を決定します。Declarative provisioning is processing objects coming in from a source connected directory and determines how the object and attributes should be transformed from a source to a target. オブジェクトは同期パイプラインで処理されます。このパイプラインは受信規則と送信規則とで同じです。An object is processed in a sync pipeline and the pipeline is the same for inbound and outbound rules. 受信規則はコネクタ スペースからメタバースに対する規則であり、送信規則はメタバースからコネクタ スペースに対する規則です。An inbound rule is from a connector space to the metaverse and an outbound rule is from the metaverse to a connector space.


パイプラインには何種類かのモジュールがあります。The pipeline has several different modules. 各モジュールは、オブジェクトの同期における各概念に対応しています。Each one is responsible for one concept in object synchronization.


  • Source (ソース): ソース オブジェクトSource, The source object
  • Scope (スコープ): スコープ内のすべての同期規則を特定Scope, Finds all sync rules that are in scope
  • Join (結合): コネクタ スペースとメタバースの間の関係を決定Join, Determines relationship between connector space and metaverse
  • Transform (変換): 属性の変換とフローの方法を計算Transform, Calculates how attributes should be transformed and flow
  • Precedence (優先順位): 属性のコントリビューションの競合を解決Precedence, Resolves conflicting attribute contributions
  • Target (ターゲット): ターゲット オブジェクトTarget, The target object


スコープ モジュールはオブジェクトを評価し、スコープ内にあり、処理に含める必要のある規則を決定します。The scope module is evaluating an object and determines the rules that are in scope and should be included in the processing. オブジェクトの属性値に応じて、各種同期規則がスコープ内にあるかどうか評価されます。Depending on the attributes values on the object, different sync rules are evaluated to be in scope. たとえば、Exchange のメールボックスを持たない無効なユーザーには、メールボックスを持つ有効なユーザーとは異なる規則が適用されます。For example, a disabled user with no Exchange mailbox does have different rules than an enabled user with a mailbox.
オブジェクトのスコープ モジュールを示す図。

スコープはグループおよび句として定義されます。The scope is defined as groups and clauses. 句はグループ内にあります。The clauses are inside a group. グループ内のすべての句の間で論理 AND が使用されます。A logical AND is used between all clauses in a group. たとえば、(department = IT AND country = Denmark) などです。For example, (department =IT AND country = Denmark). グループ間では 論理 OR が使用されます。A logical OR is used between groups.

この図のスコープは、(department = IT AND country = Denmark) OR (country=Sweden) となっています。The scope in this picture should be read as (department = IT AND country = Denmark) OR (country=Sweden). グループ 1 とグループ 2 のいずれかが true に評価される場合、規則はスコープに含まれています。If either group 1 or group 2 is evaluated to true, then the rule is in scope.

スコープ モジュールでは、次の演算がサポートされています。The scope module supports the following operations.

操作Operation 説明Description
EQUAL、NOTEQUALEQUAL, NOTEQUAL 値が属性内の値と等しいかどうかを評価する文字列の比較。A string compare that evaluates if value is equal to the value in the attribute. 複数値の属性については、ISIN と ISNOTIN を参照してください。For multi-valued attributes, see ISIN and ISNOTIN.
LESSTHAN、LESSTHAN_OR_EQUALLESSTHAN, LESSTHAN_OR_EQUAL 値が属性内の値未満であるかどうかを評価する文字列の比較。A string compare that evaluates if value is less than of the value in the attribute.
CONTAINS、NOTCONTAINSCONTAINS, NOTCONTAINS 値が属性内の値の中で見つかるかどうかを評価する文字列の比較。A string compare that evaluates if value can be found somewhere inside value in the attribute.
STARTSWITH、NOTSTARTSWITHSTARTSWITH, NOTSTARTSWITH 値が属性内の値の先頭にあるかどうかを評価する文字列の比較。A string compare that evaluates if value is in the beginning of the value in the attribute.
ENDSWITH、NOTENDSWITHENDSWITH, NOTENDSWITH 値が属性内の値の末尾にあるかどうかを評価する文字列の比較。A string compare that evaluates if value is in the end of the value in the attribute.
GREATERTHAN、GREATERTHAN_OR_EQUALGREATERTHAN, GREATERTHAN_OR_EQUAL 値が属性内の値より大きいかどうかを評価する文字列の比較。A string compare that evaluates if value is greater than of the value in the attribute.
ISNULL、ISNOTNULLISNULL, ISNOTNULL オブジェクトに属性が存在しないかどうかを評価します。Evaluates if the attribute is absent from the object. 属性が存在しない場合は null となり、規則はスコープに含まれます。If the attribute is not present and therefore null, then the rule is in scope.
ISIN、ISNOTINISIN, ISNOTIN 定義されている属性に値が存在するかどうかを評価します。Evaluates if the value is present in the defined attribute. この演算は EQUAL と NOTEQUAL の複数値バージョンです。This operation is the multi-valued variation of EQUAL and NOTEQUAL. 属性は複数値の属性であることが想定され、値がいずれかの属性値内に見つかる場合、規則はスコープに含まれます。The attribute is supposed to be a multi-valued attribute and if the value can be found in any of the attribute values, then the rule is in scope.
ISBITSET、ISNOTBITSETISBITSET, ISNOTBITSET 特定のビットが設定されているかどうかを評価します。Evaluates if a particular bit is set. たとえば、userAccountControl 内のビットを評価して、ユーザーが有効であるか無効であるかを確認するために使用できます。For example, can be used to evaluate the bits in userAccountControl to see if a user is enabled or disabled.
ISMEMBEROF、ISNOTMEMBEROFISMEMBEROF, ISNOTMEMBEROF この値には、コネクタ スペース内のグループに対する DN が含まれている必要があります。The value should contain a DN to a group in the connector space. オブジェクトが指定されたグループのメンバーである場合、規則はスコープに含まれます。If the object is a member of the group specified, the rule is in scope.


同期パイプライン内の結合モジュールは、ソース内のオブジェクトとターゲット内のオブジェクトの関係を特定するためのものです。The join module in the sync pipeline is responsible for finding the relationship between the object in the source and an object in the target. 受信規則では、この関係は、メタバース内のオブジェクトに対する関係を見つけるためのコネクタ スペース内のオブジェクトです。On an inbound rule, this relationship would be an object in a connector space finding a relationship to an object in the metaverse.
Join between cs and mv
その目的は、関連付ける必要のある、別のコネクタによって作成されたオブジェクトが既にメタバースに存在するかどうかを確認することです。The goal is to see if there is an object already in the metaverse, created by another Connector, it should be associated with. たとえば、account-resource フォレストでは、account フォレストのユーザーを resource フォレストのユーザーと結合する必要があります。For example, in an account-resource forest the user from the account forest should be joined with the user from the resource forest.

結合は、コネクタ スペース オブジェクトを同じメタバース オブジェクトに結合するために、主に受信規則で使用されます。Joins are used mostly on inbound rules to join connector space objects together to the same metaverse object.

結合は 1 つ以上のグループとして定義されます。The joins are defined as one or more groups. グループの中には句があります。Inside a group, you have clauses. グループ内のすべての句の間で論理 AND が使用されます。A logical AND is used between all clauses in a group. グループ間では 論理 OR が使用されます。A logical OR is used between groups. グループは上から下へ順番に処理されます。The groups are processed in order from top to bottom. 1 つのグループに対してターゲット内に 1 つだけ一致するオブジェクトがあった場合、他の結合規則は評価されません。When one group has found exactly one match with an object in the target, then no other join rules are evaluated. オブジェクトが 1 つも見つからないか、複数のオブジェクトが見つかった場合は、次の規則のグループが処理されます。If zero or more than one object is found, processing continues to the next group of rules. そのため、規則を作成するときは、最もはっきりしたものを最初に作成し、最もあいまいなものを最後に作成してください。For this reason, the rules should be created in the order of most explicit first and more fuzzy at the end.
Join definition
この図の結合は、上から下へ処理されます。The joins in this picture are processed from top to bottom. 最初に同期パイプラインが employeeID で一致するものがあるかどうかを確認します。First the sync pipeline sees if there is a match on employeeID. 一致するものがない場合は、2 番目の規則によってアカウント名をオブジェクトの結合に使用できるかどうかが確認されます。If not, the second rule sees if the account name can be used to join the objects together. それでも一致するものがない場合は、最後の 3 番目の規則により、ユーザー名を使ってよりあいまいな照合が行われます。If that is not a match either, the third and final rule is a more fuzzy match by using the name of user.

すべての結合規則が評価されても一致するものが 1 つでない場合は、 [説明] ページの [リンクの種類] が使用されます。If all join rules have been evaluated and there is not exactly one match, the Link Type on the Description page is used. このオプションが [プロビジョニング] に設定されている場合は、ターゲットの新しいオブジェクトが作成されます。If this option is set to Provision, then a new object in the target is created.
開いた [リンクの種類] ドロップダウン メニューを示すスクリーンショット。Screenshot that shows the "Link Type" drop-down menu open.

オブジェクトには、スコープ内の結合規則を持つ同期規則が 1 つだけ必要です。An object should only have one single sync rule with join rules in scope. 結合が定義されている複数の同期規則がある場合、エラーが発生します。If there are multiple sync rules where join is defined, an error occurs. 優先順位は、結合の競合の解決には使用されません。Precedence is not used to resolve join conflicts. 同じ受信/送信方向で属性をフローさせるためには、オブジェクトにスコープ内の結合規則が必要です。An object must have a join rule in scope for attributes to flow with the same inbound/outbound direction. 同じオブジェクトに送受信双方向で属性をフローさせる必要がある場合は、結合が設定された受信と送信両方の同期規則が必要です。If you need to flow attributes both inbound and outbound to the same object, you must have both an inbound and an outbound sync rule with join.

ターゲット コネクタ スペースへのオブジェクトのプロビジョニングを試みる際、送信結合では特殊な処理を行います。Outbound join has a special behavior when it tries to provision an object to a target connector space. 最初に、DN 属性を使って逆結合が試されます。The DN attribute is used to first try a reverse-join. 同じ DN のオブジェクトがターゲット コネクタ スペースに既に存在する場合、オブジェクトは結合されます。If there is already an object in the target connector space with the same DN, the objects are joined.

結合モジュールは、新しい同期規則がスコープに入ってきた場合にのみ評価されます。The join module is only evaluated once when a new sync rule comes into scope. いったんオブジェクトが結合されると、結合条件が満たされなくなっても、切断されることはありません。When an object has joined, it is not disjoining even if the join criteria is no longer satisfied. オブジェクトを切断するには、そのオブジェクトを結合した同期規則がスコープから出て行く必要があります。If you want to disjoin an object, the sync rule that joined the objects must go out of scope.

メタバースの削除Metaverse delete

[リンクの種類][プロビジョニング] または [StickyJoin] に設定された同期規則がスコープに 1 つ存在している限り、メタバース オブジェクトはそのままとなります。A metaverse object remains as long as there is one sync rule in scope with Link Type set to Provision or StickyJoin. StickyJoin は、コネクタによるメタバースへの新しいオブジェクトのプロビジョニングが許可されていない場合に使用されますが、オブジェクトが結合されている場合、ソースの側で先に削除しておかないと、メタバース オブジェクトを削除できません。A StickyJoin is used when a Connector is not allowed to provision a new object to the metaverse, but when it has joined, it must be deleted in the source before the metaverse object is deleted.

メタバース オブジェクトが削除されると、出力同期規則に関連付けられているすべてのオブジェクト ( プロビジョニング とマークされているもの) が削除とマークされます。When a metaverse object is deleted, all objects associated with an outbound sync rule marked for provision are marked for a delete.


変換は、ソースからターゲットへの属性のフローの方法を定義するために使用されます。The transformations are used to define how attributes should flow from the source to the target. フローには、直接、定数、式のいずれかの フローの種類を設定できます。The flows can have one of the following flow types: Direct, Constant, or Expression. 直接フローの場合、属性値は変換が行われることなく、そのままフローされます。A direct flow, flows an attribute value as-is with no additional transformations. 定数値の場合、指定の値を設定します。A constant value sets the specified value. 式の場合、宣言型のプロビジョニングの式言語を使用して変換の方法を指定します。An expression uses the declarative provisioning expression language to express how the transformation should be. 式言語の詳細については、 宣言型のプロビジョニングの式言語 に関するトピックを参照してください。The details for the expression language can be found in the understanding declarative provisioning expression language topic.

Provision or join

[Apply once (1 度だけ適用する)] チェック ボックスをオンにすると、オブジェクトの作成当初にのみ属性が設定されるように定義できます。The Apply once checkbox defines that the attribute should only be set when the object is initially created. たとえば、この構成を使用すると、新しいユーザー オブジェクトの初期パスワードを設定できます。For example, this configuration can be used to set an initial password for a new user object.

属性値の結合Merging attribute values

属性フローには、複数値の属性をいくつかの異なるコネクタから結合する必要があるかどうかを判断する設定があります。In the attribute flows there is a setting to determine if multi-valued attributes should be merged from several different Connectors. 既定値は Update です。これは、優先順位の最も高い同期規則が優先的に実行されることを示します。The default value is Update, which indicates that the sync rule with highest precedence should win.

[マージの種類] ドロップダウン メニューが開いた [変換の追加] セクションを示すスクリーンショット。

MergeMergeCaseInsensitive もあります。There is also Merge and MergeCaseInsensitive. これらのオプションを使用すると、異なるソースの値を結合できます。These options allow you to merge values from different sources. たとえば、それを使用して、いくつかの異なるフォレストのメンバー属性や proxyAddresses 属性を結合できます。For example, it can be used to merge the member or proxyAddresses attribute from several different forests. このオプションを使用する場合、オブジェクトのスコープ内にあるすべての同期規則では、同じ結合の種類を使用する必要があります。When you use this option, all sync rules in scope for an object must use the same merge type. あるコネクタから Update を定義し、別のコネクタから Merge を定義することはできません。You cannot define Update from one Connector and Merge from another. 試した場合は、エラーが発生します。If you try, you receive an error.

MergeMergeCaseInsensitive では、重複する属性値の処理方法が異なります。The difference between Merge and MergeCaseInsensitive is how to process duplicate attribute values. 同期エンジンは、重複する値がターゲット属性に挿入されていないことを確認します。The sync engine makes sure duplicate values are not inserted into the target attribute. MergeCaseInsensitiveを使用すると、大文字小文字のみが異なる重複する値は表示されなくなります。With MergeCaseInsensitive, duplicate values with only a difference in case are not going to be present. たとえば、"" と "" は両方ともターゲット属性に表示されなくなります。For example, you should not see both "" and "" in the target attribute. Merge は、正確な値だけを調べるため、大文字小文字のみが異なる複数の値は表示される可能性があります。Merge is only looking at the exact values and multiple values where there only is a difference in case might be present.

オプション ReplaceUpdate と同じですが、使用されていません。The option Replace is the same as Update, but it is not used.

属性フローの処理の制御Control the attribute flow process

複数の受信同期規則が同じメタバース属性に提供されるよう構成されると、その後、優先順位は、優先される規則を決定するために使用されます。When multiple inbound sync rules are configured to contribute to the same metaverse attribute, then precedence is used to determine the winner. 優先順位の最も高い (数値が最も小さい) 同期規則は値を提供します。The sync rule with highest precedence (lowest numeric value) is going to contribute the value. 送信規則についても同じことになります。The same happens for outbound rules. 優先順位の最も高い同期規則が優先され、接続されたディレクトリに値を提供します。The sync rule with highest precedence wins and contribute the value to the connected directory.

場合によっては、同期規則は、値を提供するのではなく、他の規則の動作を決定する必要があります。In some cases, rather than contribute a value, the sync rule should determine how other rules should behave. この例では、いくつかの特殊なリテラルが使用されています。There are some special literals used for this case.

受信同期規則の場合、リテラルの NULL を使用すると、提供する値がフローにないことを示すことができます。For inbound Synchronization Rules, the literal NULL can be used to indicate that the flow has no value to contribute. 優先順位の低い別の規則は値を提供できます。Another rule with lower precedence can contribute a value. 値を提供するルールがない場合、メタバース属性は削除されます。If no rule contributed a value, then the metaverse attribute is removed. 送信規則では、すべての同期規則が処理された後の最終的な値が NULL が場合、接続されたディレクトリからこの値が削除されます。For an outbound rule, if NULL is the final value after all sync rules have been processed, then the value is removed in the connected directory.

リテラル AuthoritativeNullNULL に似ていますが、優先順位の低い規則は値を提供できないという点が異なります。The literal AuthoritativeNull is similar to NULL but with the difference that no lower precedence rules can contribute a value.

また、属性フローでは IgnoreThisFlowも使用できます。An attribute flow can also use IgnoreThisFlow. これは、提供するものがないことを示す意味では NULL に似ています。It is similar to NULL in the sense that it indicates there is nothing to contribute. 違いは、ターゲットに既に存在する値を削除しないことです。The difference is that it does not remove an already existing value in the target. 属性フローがそこにあったことがないようなものです。It is like the attribute flow has never been there.

たとえば次のようになります。Here is an example:

Out to AD - User Exchange hybrid では、次のフローが見つかります。In Out to AD - User Exchange hybrid the following flow can be found:
IIF([cloudSOAExchMailbox] = True,[cloudMSExchSafeSendersHash],IgnoreThisFlow)
この式は、ユーザーのメールボックスが Azure AD にある場合に属性を Azure AD から AD へフローするという意味になります。This expression should be read as: if the user mailbox is located in Azure AD, then flow the attribute from Azure AD to AD. Azure AD にない場合は、Active Directory に何もフローされません。If not, do not flow anything back to Active Directory. この場合、既存の値が AD で保持されます。In this case, it would keep the existing value in AD.


ImportedValue 関数は、属性名を角かっこではなく引用符で囲む必要がある点で、他のすべての関数とは異なっています。次に例を示します。The function ImportedValue is different than all other functions since the attribute name must be enclosed in quotes rather than square brackets:

通常、同期する際は、まだエクスポートされていない場合であっても、エクスポート中にエラーが発生した場合であっても、属性では予想される値を使用します ("top of the tower")。Usually during synchronization an attribute uses the expected value, even if it hasn’t been exported yet or an error was received during export (“top of the tower”). 受信同期では、接続されたディレクトリにまだ届いていない属性も最終的には届くと見なされます。An inbound synchronization assumes that an attribute that hasn’t yet reached a connected directory eventually reaches it. また、接続されたディレクトリで確認された値のみを同期することが重要です ("hologram and delta import tower")。In some cases, it is important to only synchronize a value that has been confirmed by the connected directory (“hologram and delta import tower”).

この関数の例は、標準の同期規則 In from AD – User Common from Exchange にあります。An example of this function can be found in the out-of-box Synchronization Rule In from AD – User Common from Exchange. ハイブリッド Exchange の場合、Exchange Online によって追加された値を同期する必要があるのは、その値が正常エクスポートされたことが確認されたときのみです。In Hybrid Exchange, the value added by Exchange online should only be synchronized when it has been confirmed that the value was exported successfully:
proxyAddresses <- RemoveDuplicates(Trim(ImportedValue("proxyAddresses")))


複数の同期規則が同じ属性値をターゲットに渡そうとしたときに、優先順位の値によってどれが選ばれるかが決まります。When several sync rules try to contribute the same attribute value to the target, the precedence value is used to determine the winner. 優先順位の最も高い (数値が最も小さい) 同期規則が、競合している属性を渡すことになります。The rule with highest precedence, lowest numeric value, is going to contribute the attribute in a conflict.

Merge Types

この順序の指定方法を利用すると、オブジェクトの小さいサブセットについて、より正確な属性フローを定義することができます。This ordering can be used to define more precise attribute flows for a small subset of objects. たとえば、そのまま使用できる規則により、有効なアカウント (User AccountEnabled) の属性は、他のアカウントの属性より優先されます。For example, the out-of-box-rules make sure that attributes from an enabled account (User AccountEnabled) have precedence from other accounts.

優先順位はコネクタ間で定義できます。Precedence can be defined between Connectors. そのため、より適切なデータを持つコネクタが値を先に渡せます。That allows Connectors with better data to contribute values first.

同じコネクタ スペースからの複数のオブジェクトMultiple objects from the same connector space

同じコネクタ スペース内の複数のオブジェクトを同じメタバース オブジェクトに結合する場合、優先順位を調整する必要があります。If you have several objects in the same connector space joined to the same metaverse object, precedence must be adjusted. 複数のオブジェクトが同じ同期規則のスコープに含まれる場合、同期エンジンは優先順位を決めることができません。If several objects are in scope of the same sync rule, then the sync engine is not able to determine precedence. どのソース オブジェクトからメタバースに値を渡すかが明確ではないのです。It is ambiguous which source object should contribute the value to the metaverse. この構成は、ソース内の属性の値が同じであっても、あいまいとしてレポートされます。This configuration is reported as ambiguous even if the attributes in the source have the same value.
透明な赤の X オーバーレイを持つ同じ mv オブジェクトに結合された複数のオブジェクトを示す図。Diagram that shows multiple objects joined to the same mv object with a transparent red X overlay.

このシナリオでは、同期規則のスコープを変更して、ソース オブジェクトがスコープ内に異なる同期規則を持つようにする必要があります。For this scenario, you need to change the scope of the sync rules so the source objects have different sync rules in scope. そうすれば、異なる優先順位を定義できます。That allows you to define different precedence.
Multiple objects joined to the same mv object

次のステップNext steps

概要トピックOverview topics

参照トピックReference topics