Azure AD Connect の同期プロセスを理解&同期規則をカスタムする

皆さんお久しぶりです。Miyaです。

繁忙期の3月も無事に納めて落ち着いてきたので、久しぶりに投稿してみました。

今回は、Azure AD Connect (以下、AADConnect)のアーキテクチャ部分を解説しながら、既定のルールをカスタムする方法について簡単にご紹介したいと思います。

AADConnectは、Office 365を導入する企業では欠かせない役割で、誰でも簡単にインストール・構成できる一方で、設定をカスタムすることでかなり凝ったID同期が実現できる夢のある製品で「よく出来ているなぁ」と感心しますね。

本記事は、Microsoft Docsの情報に加えて、私の検証した内容を混ぜ込んだメモ書きになりますが、是非参考にしてみてください。

スポンサーリンク:

AADConnect とは?

AADConnectとは、オンプレミスのActive Directory (以下、オンプレAD)と、Azure Active Directory (以下、Azure AD)のID情報を統合するIdentity同期の役割を持ったMicrosoftが提供する製品です。

AAD Connectは、Microsoft Identity Manager(MIM)と呼ばれる、MicrosoftのID統合ソリューションの製品と同じ同期エンジンを搭載しており、Azure ADを認証基盤とするOffice 365には欠かせない役割の一つです。

Azure AD Connect

↑の構成によって、利用者はオンプレADのIDとパスワードでOffice 365にログインすることが出来ることから、「ハイブリッドID」とも呼ばれていますね。

よくある属性マッピングなどの処理も実現出来る素晴らしい製品です。本記事では、AADConnectの同期エンジンのアーキテクチャを理解しながら、簡単な同期規則を作っていきたいと思います。

AADConnect 同期エンジンの領域について

本記事では、以下のシステム構成をベースに話を進めていきます。よくある、マルチフォレスト&シングルテナントの構成になります。

Azure AD Connect

AADConnectは、接続されたデータソース間でデータオブジェクトを双方向で同期することが出来ます。

この接続されたデータソースは、今回でいうところのオンプレADと、Azure ADに該当し、これらはConnected Directories(CD)と呼ぶことがあります。

Azure AD Connect

これらの接続されたデータソースからオブジェクト情報を取得した後、同期エンジンはコネクタスペース(CSメタバース(MV)と呼ばれれる二つの名前空間の中で同期プロセスを処理します。

コネクタスペース(CS)/ メタバース(MV)とは

コネクタスペース(CS)は、接続されたデータソースから取得したオブジェクト情報を”とりあえず配置”するステージング領域です。

コネクタスペースは個々のデータソース毎に専用で用意されています。同期エンジンは、データソースから取得したオブジェクト情報の変更を検出し、ステージング領域に格納します。

同期エンジンは、コネクタスペースに格納されたオブジェクト情報を基に、すべてのデータソースから取得したオブジェクト情報が集約するストレージ領域にオブジェクトを作成します。このストレージ領域をメタバース(MV)と呼びます。

同期エンジンはメタバースのオブジェクト情報を使用して、同期先のデータソースのコネクタスペースにオブジェクトを作成することも出来ます。

Azure AD Connect

同期エンジンは、これらの領域にあるオブジェクト情報を基に同期プロセスを実行し、データソース間でオブジェクト情報をやり取りしているのです。

コネクタスペースはデータソースから取得したオブジェクト情報が格納されたステージング領域、メタバースはすべてのデータソースから得たオブジェクト情報を集約するストレージ領域である。

AADConnect 同期フローについて

同期エンジンは、コネクタスペースとメタバースの領域からオブジェクト情報を読み書きしています。

ここでは、各領域で生成されるオブジェクトを、オンプレAD→Azure ADへ同期するフローと照らし合わせながら確認していきます。以下はその概要図となります。

Azure AD Connect

まず、①でデータソースから対象のオブジェクトを取得して、専用のコネクタスペースにオブジェクトを生成します。この生成されたオブジェクトをステージングオブジェクトと呼びます。

Azure AD Connect

ステージングオブジェクトは、さらにインポートオブジェクト/エクスポートオブジェクトの二つに分類されます。インポートされたオブジェクトはコネクタスペース内でインポートオブジェクトとしてマークされます。

同期エンジンは、コネクタスペースに生成されたインポートオブジェクト情報をもとに、同期規則に従ってメタバースオブジェクトを生成します。

この時、同期エンジンはステージングオブジェクトとメタバースオブジェクトが対になるようにリンクを確立します。このようにリンクが確立されたオブジェクトを結合オブジェクトと呼び、逆にリンクが確立されていないオブジェクトを非結合オブジェクトと呼びます。

Azure AD Connect

このリンクが確立されることによって、メタバースオブジェクトの属性値を更新することが出来る仕組みになっています。

次に同期エンジンは、新規作成されたメタバースオブジェクトを、同期規則に従ってAzure ADのコネクタスペースにステージングオブジェクトを生成します。これがエクスポートオブジェクトになります。

Azure AD Connect

エクスポート保留中のフラグがセットされたステージングオブジェクトは、次のExport処理でAzure ADへ変更がプッシュされ、Azure AD側に新規ユーザーが生成される動きとなります。

Azure AD Connect

ステージングオブジェクトとメタバースオブジェクトには、リンクが確立されているため、その後の属性変更などを検出すると、同期エンジンはそれをメタバースオブジェクトに反映させて同期処理を実行します。

同期プロセスの実行プロファイルについて

同期プロセスは、Import/Synchronization/Exportの3つのプロファイルを実行してID同期を実現しています。Synchronization Service Managerで同期状況を確認したことのある方なら馴染み深いとは思います。

Azure AD Connect

Importプロセス

Importプロセスでは、同期エンジンが接続されたデータソースから取得したオブジェクト情報をコネクタスペースに”ステージングオブジェクト”として格納します。

オブジェクトに変更(Add,Update,Delete…など)が検出されると、新しいステージングオブジェクトを生成するか、既存のステージングオブジェクトの情報を更新します。

Synchronizationプロセス

Synchronizationプロセスは同期エンジンが、コネクタスペース内で検出された変更をメタバースに反映させるのと(Inbound)、メタバース内で検出された変更をコネクタスペースに反映させる(Outbound)2つの更新が発生します。

Azure AD Connect

【Inbound】

コネクタスペース内で検出された変更情報をメタバースに反映させる同期処理で、Projection/Join/Import attribute flow の3つのプロセスが処理されます。

プロセス 処理
Projection Projectionは、メタバースオブジェクトを新規生成するプロセス。

つまり、インポートオブジェクト(非結合オブジェクト)のみを対象としたプロセス。

インポートオブジェクトとメタバースオブジェクトの間でリンクを確立し、結合オブジェクトを生成する。

Join Projectionと同様で、インポートオブジェクトとメタバースオブジェクトの間にリンクを確立し、結合オブジェクトを生成する。

Joinは既存のメタバースオブジェクトに対してリンクを確立するのに対して、Projectionは新規メタバースオブジェクトに対するリンクの確立を意味する。

Import attribute flow ProjectionやJoinの結合処理が完了した後、Import attribute flowがリンクされたメタバースオブジェクトの属性値を更新する。

【Outbound】

メタバース内で検出された変更情報をコネクタスペース内に反映させる同期処理で、Provisioning/Deprovisioning/Export attribute flow の3つのプロセスが処理されます。

プロセス 処理
Provisioning Provisioningは、メタバースオブジェクトに変更が検出されると、コネクタスペース内に結合オブジェクトを作成・変更・リンクの切断(非結合オブジェクト)するプロセス。

リンクが切断されたオブジェクトを検出すると、Deprovisioningがトリガーされる。

Deprovisioning Provisioningにおいて、Deprovisioningがトリガーされた場合に、対象のオブジェクトを削除するプロセス。
Export attribute flow Provisioningによって結合処理が完了した後、Export attribute flowがリンクされたステージングオブジェクト(エクスポートオブジェクト)の属性値を更新する。

Exportプロセス

Exportプロセスでは、同期エンジンがOutboundプロセスによって生成されたステージングオブジェクト(エクスポートオブジェクト)を接続先のデータソース(今回でいうとAzure AD)へ変更情報をプッシュする処理になります。本処理を終えれば、無事にAzure ADへ変更情報が行き届き、オブジェクトが生成・変更・削除などの更新がかかるわけです。

ざっと、プロセス毎の動きを解説してきましたが、実際にオンプレADで新規作成したユーザーオブジェクトがAzure ADにまで同期される一連の流れを確認していきたいと思います。

まずは、オンプレADで作成した「Miyazaki」というユーザーオブジェクトを同期エンジンでImportし、コネクタスペースにステージングジェクトが生成されるところまで確認します。

Azure AD Connect

Synchronization Service Managerから、オンプレADのConnectorに定義されている”Full Import”プロファイルを実行してみます。Staging領域に一つのステージングオブジェクトが”Add”されているのが分かりますね。

Azure AD Connect

コネクタスペース内を確認すると、「Miyazaki」というユーザーオブジェクトが生成されていることが確認できます。尚、この時点ではSynchronizationプロセスが実行されていないため、非結合オブジェクトとしてインポート保留中のフラグがセットされている状態です。

Azure AD Connect

次にオンプレADのConnectorに定義されている”Full Synchronization”プロファイルを実行し、メタバースオブジェクト、ステージングオブジェクト(エクスポートオブジェクト)を結合オブジェクトとして生成します。

Azure AD Connect

InboundではProjectionによってメタバースオブジェクトに「Miyazaki」が生成されていることと、OutboundではProvisioningによってコネクタスペースに結合オブジェクトが生成されていることが確認できます。また、Export attribute flowによって、コネクタスペース内に属性情報が反映されていることが分かります。

Azure AD Connect

メタバース内を確認すると、「Miyazaki」オブジェクトが生成されていることが確認できます。

Azure AD Connect

最後に、Azure AD側のConnectorに定義されている”Export”プロファイルを実行し、Azure ADへ変更情報をプッシュします。

Azure AD Connect

Export実行後、エクスポート保留中のフラグがセットされた「Miyazaki」オブジェクトがデータソース(Azure AD)にプッシュされていることが分かります。

Azure AD Connect

Office 365管理者画面には「Miyazaki」がユーザーとして同期されていますね。

Azure AD Connect

AADConnect 同期規則について

AADConnectの同期エンジンは、InboundとOutboundの処理の中で同期規則に従った更新処理が行われます。

この同期規則は、”Synchronization Rules Editor”から既定のルールが確認出来るのと、管理者は同画面で既定のルールをカスタムしたり、新たに同期規則を構成することが出来ます。

同期処理には、いくつかのモジュールが組み込まれており、それらを使って一つの同期規則を仕上げていきます。以下が代表的なモジュールになります。

モジュール 処理
Scope Scopeモジュールは、オブジェクトを評価し、後続の処理の対象に含めるか否かを決定する。
Join Joinモジュールは、ソース内のオブジェクトとターゲット内のオブジェクトのリンク確立する手段を決定する。
Transform Transformモジュールは、ソースからターゲットへの属性フローの変換規則を定義する。

それでは、既定で定義されているInboundプロセスの”in from AD – User Join”を確認していきます。この同期規則は名の通り、ユーザーオブジェクトのJoin(リンク確立)を定義したものです。

“Description”メニューでは、同期規則のパラメーターが確認できます。優先度(Precedence)は類似する同期ルールとの競合を防ぐための優先順位であり、値が小さいほど優先順位が高くなります。

Azure AD Connect

Scope

Scopeモジュールは、”Scoping filter”から詳細な規則が確認出来ます。

Scopeモジュールは、対象オブジェクトの属性値を評価し、同期規則の処理に含めるかどうかを決定します。つまり、ここで記述されているScope規則に該当しないユーザーオブジェクトはメタバースに生成されてないということを意味しています。

Scopeは、”Group“と”Clause“のくくりで定義されています。同一Group内のClauseはAND、Group間はOR条件で解釈されます。例えば下記の例では、【Company属性が”contoso” かつ mail属性が”contoso.com”で終わる】 またはflags属性に”1″入っている】という解釈がされます。

Azure AD Connect

”in from AD – User Join”では、【isCriticalSystemObject属性が”True”でない かつ adminDescription属性が”User_”で始まらない」というScope条件が入っています。

オブジェクトの属性値とその値を演算子で結ぶだけの簡易な構成であるため、割と簡単に操作できるかと思いますが、既存ルールの編集は大事故につながる恐れがあるので止めておきましょう。

尚、利用可能な演算子についてはMicrosoft Docsで解説されているので参考にしてください。
Title:Azure AD Connect 同期: 宣言型のプロビジョニングについて

Join

Joinモジュールは、ソース内のオブジェクトと、ターゲット内のオブジェクトのリンク確立を定義するモジュールです。

Scopeと同様の演算子で、上から順番に評価されます。いずれかのGroupに一致すればそのルールが適用されてリンクが確立されます。(以降のGroupは評価されません。)

”in from AD – User Join”のJoinを確認すると、ソース属性として1つ目に”mS-DS-ConsistencyGuid”、2つ目に”ObjectGUID”が、ターゲットのsourceAnchorBinaryに紐づけられていることが確認できます。

Azure AD Connect

尚、いずれのGroupにも一致しないオブジェクトがあった場合は、”Desctiprion”メニューの”Link Type”が参照されるらしいです。これがProvisioningの場合は、メタバース内にオブジェクトが生成されるそう。

Transform

Transformモジュールは、ソースからターゲットへの属性変更フローを定義するモジュールです。

ユーザーオブジェクトの属性同期を定義している”in from AD – User Common”のTransformationsを確認します。

Azure AD Connect

”Flow Type”, ”Target Attribute”, ”Source”, ”Apply Once”, ”Merge Type”で構成されています。

列名 内容
Flow Type 属性の同期方式を決定する。Direct、Expression、Constantから選択する。

Direct:ソースとターゲット間の属性を直接同期する。

Expression:リテラル、パラメーター、関数を使ってターゲットの属性に同期する。

Constant:任意の文字列をターゲットの属性に同期する。

Target Attribute ターゲットオブジェクトの同期先属性を決定する。
Source Target Attributeへ同期するソースの属性、文字列を決定する。
Apply Once 永続的に属性同期するか否かを決定する。

チェックをONにすると、最初のオブジェクト生成時のみ属性が同期される。

Merge Type 属性の変更方法を決定する。Update、Replace、Merge、MergeCaseInsensitiveから選択する。

Update:属性を更新して同期する。

Replace:Updateと同じであり、使用することはない。らしい。

Merge:既存の属性値に結合する形で同期する。

MergeCaseInsensitive:Mergeと大文字小文字の重複処理が異なる。らしい。

Merge Typeの”Merge”はProxyAddressesなどの配列型属性に対して結合処理したい場合に使うケースが多いのでしょうか?基本はUpdateで問題ありません。

また、FlowTypeが”Expression”の場合、リテラル、パラメーター、関数を使った属性加工を構成することが出来ます。何かしらの加工をする場合は、Expressionで構成するケースが多いかと思います。

少し話は逸れますが、AADConnectはMIMと同じ同期エンジンを使っていることから、宣言型のプロビジョニング(というのでしょうか?)をベースに設計されており、管理者がプログラミングをせずともRules Editorから同期規則を記述することを可能としています。

属性同期フローで使用される式言語には、Microsoft Visual Basic for Applications(VBA)のサブセットが使われており、関数は下記のリファレンスが参考になります。
Title:Visual Basicの関数リファレンス

パラメーターは既定で以下のものが用意されており、PowerShellから独自パラメーターも定義できるそうです。

パラメーター名 Comment (コメント)
Domain.Netbios 現在インポートされているドメインの NetBIOS 形式 (FABRIKAMSALES など)
Domain.FQDN 現在インポートされているドメインの FQDN 形式 (sales.fabrikam.com など)
Domain.LDAP 現在インポートされているドメインの LDAP 形式 (DC=sales,DC=fabrikam,DC=com など)
Forest.Netbios 現在インポートされているフォレスト名の NetBIOS 形式 (FABRIKAMCORP など)
Forest.FQDN 現在インポートされているフォレスト名の FQDN 形式 (fabrikam.com など)
Forest.LDAP 現在インポートされているフォレスト名の LDAP 形式 (DC=fabrikam,DC=com など)

AADConnect 同期規則のカスタム

さて、Azure AD Connectの同期エンジンの動作について理解したところで、以下のよくある属性加工をご紹介したいと思います。

mail属性をUPN属性にマッピングする

特定属性を条件にフィルタリングする

いくらかやり方はありますが、今回はInboundの同期規則を構成して実現したいと思います。

mail属性をUPN属性にマッピングする

オンプレADのmail属性をAzure ADのUPNへマッピングする規則をInboundの同期規則で記述します。

Azure AD Connect

Synchronization Rules Editorコンソールを起動して、フィルター条件を以下のように絞ると、”in from AD – User AccountEnabled”と”in from AD – User Common”が表示されます。

パラメーター
Direction Inbound
MV Object Type preson
Connector contoso.com
Connector Object Type user
Connector Attribute UserPrincipalName

Azure AD Connect

表示された二つのルールに対して[Edit]からルールを変更するのですが、この時以下のメッセージが表示されます。

Azure AD Connect

”Yes”は今の同期規則を無効にして、複製したものでカスタム新規作成する方法、”No”は今の同期規則をそのまま編集する方法となります。既定の同期規則は無効にしてそっとしておくのが安全かと思うので、”Yes”で複製します。

複製する場合、優先度(Precedence)が”-1”となっているため、100未満の数字(他の同期規則と重複しない優先度)を設定しましょう。

Azure AD Connect

Transformationsメニューから、Target AttributesがUserPrincipalNameの規則を探し、Sourceを以下の値に変更します。

■変更前

IIF(IsPresent([userPrincipalName]),[userPrincipalName], IIF(IsPresent([sAMAccountName]),[sAMAccountName]&”@”&%Domain.FQDN%),Error(“AccountName is not present”)))

■変更後

IIF(IsPresent([mail]),[mail], IIF(IsPresent([sAMAccountName]),([sAMAccountName]&”@”&%Domain.FQDN%),Error(“AccountName is not present”)))

ルールの内容はすごく単純で、mail属性に値があればその値を、なければsAMAccountNameに”@contoso.com”を付けてUserPrincipalNameに同期するというルールに変更します。

”in from AD – User AccountEnabled”と”in from AD – User Common”に↑の設定をしたら、Full Import してみます。

コネクタスペースに生成されたオブジェクトには、UserPrincipalNameが「s-miya@contoso.com」でセットされています。

Azure AD Connect

次に、Full Synchronizationを実行して、先ほど構成した同期規則を適用します。

先ほど構成したカスタムルールが適用されていることと、メタバースオブジェクトのUserPrincipalNameがmail属性の値に書き換わっていることが確認できます。

Azure AD Connect

特定属性を条件にフィルタリングする

AADConnectは特定OUに絞ったフィルタリングを構成ウィザードから設定できますが、今回は特定属性としてflag属性に”1”が入っているオブジェクトのみ同期するルールを構成します。

Azure AD Connect

まず、flags属性はImport対象外の属性のため、Synchronization Service ManagerからオンプレADのConnectorのPropertiesでflags属性を同期するようチェックします。

Azure AD Connect

次に、Synchronization Rules Editorを起動して、[Add new rule]から同期規則を新規作成します。

Azure AD Connect

Scoping filterメニューで以下のように条件式を組みます。

Azure AD Connect

Transformationsメニューでは、以下のように同期規則を構成します。cloudFilterの値がTrueに設定されている場合、そのオブジェクトはコネクタスペースにProvisioningされなくなります。

Azure AD Connect

オンプレADのConnectorでFull Importしてみると、「Itakura」、「Miyazaki」の二つのユーザーオブジェクトが生成されています。

Azure AD Connect

次に、Full Synchronizationしてみると、メタバースオブジェクトに「Itakura」、「Miyazaki」が生成されていますが、「Itakura」は”cloudFilter”に”True”が入っていることが確認できます。これにより、Azure ADのコネクタスペースに「Itakura」というステージングオブジェクトは生成されなくなります。

Azure AD Connect

おわりに

長くなってしまいましたが、Azure AD Connectの優秀さが伝われば幸いです。

ただ単に構成ウィザードを流すだけで同期構成が取れる素晴らしいAzure AD Connectですが、同期プロセスをある程度理解しておけば、困ったときに必ずお役に立てる製品です。

小難しい話ばかりとなってしまいましたが、Azure AD Connectをカスタムする際は是非参考にしてみてください。

それでは、良いOffice 365ライフをっ♪

スポンサーリンク