既定の構成について

更新日: 2015 年 7 月 22 日

重要

このトピックは近日中にアーカイブされます。
AADSyncと DirSync を置き換える "Azure Active Directory Connect" という新しい製品があります。
Azure AD Connect には、以前 Dirsync と AAD Sync としてリリースされたコンポーネントと機能が組み込まれています。
将来のある時点で、Dirsync とAAD Syncのサポートは終了します。
これらのツールは機能改善によって個別に更新されなくなり、今後のすべての機能強化は Azure AD Connectの更新プログラムに含まれる予定です。

Azure Active Directory Connectに関する最新の情報については、「オンプレミス ID とAzure Active Directoryの統合」を参照してください。

このドキュメントでは、Azure Active Directory Sync の既定の構成について説明します。目標は、Azure Active Directory Sync の宣言型プロビジョニングという名前の構成モデルが実際の例でどのように機能しているかを理解することです。 このドキュメントでは、インストール ウィザードを使用して Azure Active Directory Sync を既にインストールして構成していることを前提としています。

シナリオの説明

この例では 1 つのアカウント フォレスト (A)、1 つのリソース フォレスト (R)、1 つの AAD ディレクトリを含むデプロイメントを使用します。

接続されている各ディレクトリには、Azure Active Directory Sync の関連情報のキャッシュされたコピー (コネクタ スペースと呼ばれます) があります。真ん中には、同期されているオブジェクトの統合ビューであるメタバースがあります。

これは、Azure Active Directory同期シナリオの概要で説明されているシナリオ 2 と同じです。

同期規則エディター

この構成は同期規則エディター (SRE) のツールから表示および変更でき、[スタート] メニューにはショートカットもあります。

SRE はリソース キット ツールですが、Azure Active Directory Sync と共にインストールされます。これを開始するには、ADSyncAdmins グループのメンバーである必要があります。 開始すると、次のように表示されます。

このペインには構成に対して作成されたすべての同期規則が表示されます。 表内の各行は 1 つの同期規則です。 左側の [ルールの種類] の下に、受信と送信の 2 つの異なる種類が表示されます。 [着信] および [送信] は、メタバースのビューに基づきます。 この概要の受信規則に主に注目していきます。同期規則の実際の一覧は AD で検出されたスキーマによって異なります。 上の図では、アカウント フォレスト (Azure Active Directory Sync.com) には Exchange や Lync などのサービスがなく、これらのサービスに対して同期規則は作成されていません。 ただし、リソース フォレストではこれらのサービスの同期規則があります。 規則の内容は検出されたバージョンによって異なります。 たとえば Exchange 2013 によるデプロイメントの場合、Exchange 2010 や Exchange 2007 よりも多くの属性フローが構成されます。

同期規則

同期規則は、条件が満たされた場合に、フローする属性のセットを含む構成オブジェクトです。 コネクタ スペースのオブジェクトがメタバースのオブジェクトとどのように (結合や一致など) 関連するかを説明するためにも使用されます。 それぞれの関連性を示す際には同期規則が優先されます。 小さい数値が優先される同期規則の方が優先順位が高くなり、属性フローが競合した場合には高い優先順位の方が競合を解決します。

例として、"AD からの受信 – ユーザー アカウント有効" の同期規則を見てみましょう。 SRE でこの行をマークし、[Edit.A Synchronization Rule]\(同期規則の編集\) を選択します。[説明]、[スコープ フィルター]、[結合ルール]、[変換] の 4 つの構成セクションがあります。

説明

最初のセクションでは、名前や説明などの基本的な情報を提供します。

接続されたシステムのうちこの規則と関連するのはどれか、接続されたシステムのどの種類のオブジェクトに適用されるか、メタバースのオブジェクトの種類に関する情報もあります。 メタバースのオブジェクトの種類は、ソース オブジェクトの種類がユーザーでも、iNetOrgPerson でも連絡先でも、必ず人の名前です。 メタバース オブジェクトの種類は、ジェネリック型として作成されるため、変更しないでください。 リンクの種類は、[結合]、[スティッキー結合]、または [プロビジョニング] に設定できます。 この設定は結合規則のセクションで機能します。これについては後ほど説明します。

スコープ フィルター

[スコープ フィルター] セクションは、同期規則の適用が必要なタイミングを構成するために使用されます。 今見ている同期規則の名前はそれが有効なユーザーにのみ適用されることを示しているため、スコープは AD 属性 userAccountControl がビット 2 のセットを持たないように構成されます。 AD にユーザーがあり、userAccountControl が 10 進数値 512 (有効な標準ユーザー) に設定されている場合はこの規則が適用されますが、見つかったユーザーの userAccountControl が 514 (無効な標準ユーザー) に設定されている場合には適用されません。

スコープ フィルターには入れ子にできるグループおよび句があります。 同期規則を適用するには、グループ内のすべての句が満たされている必要があります。 複数のグループが定義されている場合、ルールを適用するには、少なくとも 1 つのグループを満たす必要があります。 つまり、論理 OR はグループ間で評価され、論理 AND はグループ内で評価されます。 この例は、以下に説明する、送信の同期規則 "AAD への送信 – グループ結合" で確認することができます。 同期フィルターのグループは 2 つあります。1 つはセキュリティ グループ (securityEnabled EQUAL True) 向け、もう 1 つは配布グループ (securityEnabled EQUAL False) 向けです。

この規則は AAD にプロビジョニングするグループを定義するために使用されます。 配布グループを AAD と同期するにはメールを有効にする必要がありますが、セキュリティ グループの場合これは不要です。 おわかりのように、多くの追加属性も同様に評価されます。

結合規則

3 番目のセクションは、コネクタ スペース内のオブジェクトと、メタバース内のオブジェクトの関連付けの構成に使用されます。 これまで見てきた規則には結合規則の構成がなかったので、代わりに "AD からの受信 – ユーザー結合" について見ていきます。

結合規則の内容はインストール ウィザードで選択した一致オプションによって異なります。 受信規則の場合、評価はソースのコネクタ スペースのオブジェクトから開始し、結合規則の各グループが順番に評価されます。 結合規則のうち 1 つを使用してメタバースの 1 つのオブジェクトのみと一致するようにソース オブジェクトを評価する場合、オブジェクトはまとめて結合されます。 すべての規則が評価されて一致が存在しない場合は、説明ページのリンクの種類が使用されます。 この設定が [プロビジョニング] に設定されている場合、新しいオブジェクトがターゲットのメタバースに作成されます。 新しいオブジェクトをメタバースにプロビジョニングすることは、オブジェクトをメタバースに提供することとしても知られています。 結合規則は、1 回のみ評価されます。 コネクタ スペースのオブジェクトとメタバースのオブジェクトがまとめて結合されると、同期規則のスコープが満たされている限り、結合されたままです。 同期規則を評価する際は、結合規則が定義されている同期規則が 1 つだけスコープ内に必要です。 1 つのオブジェクトに対して、結合規則を持つ複数の同期規則がある場合は、エラーがスローされます。 このため、1 つのオブジェクトのスコープに複数の同期規則がある場合は、結合規則が定義された同期規則を 1 つだけにすることをお勧めします。 Azure Active Directory同期の既定の構成では、名前を調べて、名前の末尾に Join という単語を含むルールを見つけることができます。 同期規則に結合規則が定義されておらず、別の同期規則によってオブジェクトが結合されているか、ターゲットに新しいオブジェクトがプロビジョニングされている場合、その同期規則は属性フローを適用します。

変換

変換セクションは、オブジェクトが結合され、スコープ フィルターが満たされている場合にターゲット オブジェクトに適用されるすべての属性フローを定義します。 改めて "AD からの受信 – ユーザー アカウント無効" の同期規則を見ると、次の変換が見つかります。

これを踏まえると、アカウント/リソース フォレストのデプロイメントでは、アカウント フォレストには有効なアカウントが、Exchange および Lync 設定のあるリソース フォレストには無効なアカウントが見つかると予想されます。 今見ている同期規則にはログインに必要な属性が含まれており、これらは有効なアカウントが見つかったフォレストから流用する必要があります。 これらすべての属性フローが 1 つの同期規則にまとめられます。変換には、定数、直接、式の種類があります。 定数フローは常に特定の値を流します。上のケースでは accountEnabled という名前のメタバース属性に値 True が必ず設定されます。 直接フローはソースの属性の値をターゲット属性に流します。 3 番目のフローの種類は式で、より高度な構成が可能です。 式の言語はVBA (Visual Basic for Applications) で、Microsoft Office または VBScript の経験があるユーザーであれば形式がわかります。 属性は、[attributeName] のように角かっこで囲みます。 属性名および関数名は大文字と小文字が区別されます。同期規則エディターが式を評価し、式が無効な場合は警告を出します。すべての式は関数が入れ子になって単一行で表されます。 この構成言語の強力な機能を、次の pwdLastSet のフローで示しています。追加のコメントも挿入されています。

// If-then-else
IIF(
// (The evaluation for IIF) Is the attribute pwdLastSet present in AD? 
IsPresent([pwdLastSet]),
// (The True part of IIF) If it is, then from right to left, convert the AD time format to a .Net datetime, change it to the time format used by AAD, and finally convert it to a string.
CStr(FormatDateTime(DateFromNum([pwdLastSet]),"yyyyMMddHHmmss.0Z")),
// (The False part of IIF) Nothing to contribute
NULL
)

変換のトピックは大きく、Azure Active Directory Sync で可能なカスタム構成の大部分を提供します。カスタム構成については、この概要ドキュメントでは説明しませんが、このドキュメントの後半で追加の属性フローについて説明します。

優先順位

同期規則について個別にいくつか見てきましたが、これらの規則は構成で同時に機能します。 場合によっては、複数の同期規則の属性値が同じターゲット属性に影響します。 この場合、どの属性が使用されるかは属性の優先順位によって決まります。 例として、属性 sourceAnchor を見てみましょう。 この属性は Azure AD にログインするために重要な属性です。 この属性の属性フローは "AD からの受信 - ユーザー アカウント有効" および "AD からの受信 - ユーザー共通" の 2 つの同期規則にあります。 メタバースのオブジェクトに複数のオブジェクトが結合されている場合、属性 sourceAnchor は同期規則の優先順位により、最初に有効にされたアカウントを含むフォレストの影響を受けます。 有効なアカウントがない場合は、包括的な同期規則 "AD からの受信 - ユーザー共通" が使用されます。 これにより、無効なアカウントに対しても sourceAnchor を指定できるようになります。同期規則の優先順位はインストール ウィザードによってグループ単位で設定されます。 規則のグループはすべて同じ名前が付けられますが、接続されるディレクトリは異なります。 インストール ウィザードは "AD からの受信 – ユーザー結合" の規則を最優先し、接続されたすべての AD ディレクトリを繰り返し処理します。 これで、定義済みの順序で次の規則のグループが継続します。 コネクタがウィザードで追加された順序で、グループ内部に規則が追加されます。 別のコネクタがウィザードで追加されると、同期規則の順序が変わり、新しいコネクタの規則が各グループの末尾に挿入されます。

まとめ

ここまでの同期規則に関する説明で、構成がさまざまな同期規則でどのように動作するかを十分理解できるようになりました。 ユーザーおよびメタバースに影響する属性を見ると、規則は次の順序で適用されています。

名前	コメント
AD からの受信 - ユーザー結合	コネクタ スペース オブジェクトをメタバースと結合するための規則。
AD からの受信 - ユーザー アカウント有効	Azure AD とOffice 365へのログインに必要な属性。 これらの属性は有効なアカウントから取得します。
AD からの受信 - Exchange からのユーザー共通	グローバル アドレス一覧で見つかった属性。 ユーザーのメールボックスが見つかったフォレストのデータ品質が最も優れていると想定しています。
AD からの受信 - ユーザー共通	グローバル アドレス一覧で見つかった属性。 メールボックスが見つからなかった場合、それ以外の結合済みオブジェクトが属性値に影響する可能性があります。
AD からの受信 - ユーザー Exchange	Exchange が検出された場合にのみ存在します。 すべてのインフラストラクチャの Exchange 属性が流れます。
AD からの受信 - ユーザー Lync	Lync が検出された場合にのみ存在します。 すべてのインフラストラクチャの Lync 属性が流れます。

その他の注意事項

最後に、ある属性フローを見てドキュメントを終了します。

cloudFiltered

この属性フローは "AD からの受信 – ユーザー結合" にあります。 結合に必要ではありませんが、とても重要なためこの規則に含まれています。 すべての送信の同期規則には cloudFiltered 属性のスコープ フィルターが含まれており、これを使用して追加のフィルター処理をする方法を別のドキュメントで見ていきます。 既定ではこのフローにより多くのオブジェクトがフィルター処理され、クラウドで表示されなくなります。 下の式にある二重の垂直バー || は論理 OR です。

// if-then-else
IIF(
// Don’t synchronize default AD objects, such as Administrator
IsPresent([isCriticalSystemObject]) || 
// Don’t synchronize objects with no sAMAccountName set
IsPresent([sAMAccountName]) = False || 
// Don’t synchronize these special Exchange mailboxes
[sAMAccountName] = "SUPPORT_388945a0" || 
Left([mailNickname], 14) = "SystemMailbox{" || 
(Left([mailNickname], 4) = "CAS_" && (InStr([mailNickname], "}") > 0)) || 
(Left([sAMAccountName], 4) = "CAS_" && (InStr([sAMAccountName], "}") > 0)) ||  
// Don’t synchronize Exchange system mailboxes
CBool(IIF(IsPresent([msExchRecipientTypeDetails]), 
BitAnd([msExchRecipientTypeDetails],&H21C07000) > 0,NULL)) ||
// Don’t synchronize the Azure Active Directory Sync/DirSync service accounts
Left([sAMAccountName], 4) = "AAD_" || Left([sAMAccountName], 5) = "MSOL_" ||
// Don’t synchronize replication conflict objects
CBool(InStr(DNComponent(CRef([dn]),1),"\\0ACNF:")>0), 
// Then, If any of these OR clauses is True, then flow “True”
True, 
// Else, if not, then don’t flow anything
NULL
)

参照

概念

Azure Active Directory同期