Azure AD Connect の Synchronization Service Manager を利用し、非同期ユーザーを確認する方法

#はじめに
Azure AD Connect はオンプレミス AD 上のユーザー、コンピューターなどのオブジェクトを Azure AD に同期することで、オンプレミス AD 上のユーザー情報を利用して Azure AD 上のアプリケーションを利用可能にする無料の同期ツールです。

Azure AD Connect をインストールすると同梱される Synchronization Service Manager はオンプレミス AD と Azure AD 間の同期ステータスを確認できる非常に便利なツールです。

もちろん同期されたかどうかを確認するためにも利用できますが、例えば会社や部署の統廃合により、オンプレミス AD 上の一部ユーザーを同期対象から除外し、Azure AD 上から削除 (soft delete) させた時の状態を確認したい場合があると思います。

具体的には同期ルールにて「cloudFiltered  ＝ true」と設定することで、特定のユーザー属性に合致(例えば extensionAttribute に 「nosync」と設定されているユーザーは同期しない) した場合に同期対象から除外し、Azure AD からユーザーを削除することができます。

今回は、「cloudFiltered  ＝ true」と設定されている環境において、削除前、つまり、削除される予定のユーザーの確認方法と、削除された後のユーザーを確認する方法を「Synchronization Service Manager」を利用して確認してみたいと思います。

もちろん Azure ポータルのユーザー一覧で確認すれば、非同期対象のユーザーは削除されていることが確認可能です。
今回は Azure ポータルと Azure AD Connect サーバーが管理者が別の場合を想定して、Azure AD Connect サーバー上で確認する方法を検証したので、そちらの方法をご紹介します。

#やってみる
以下の順番で動作検証してみます。

1. オンプレミス AD 上にテスト ユーザー (test004) を作成する。
2. Synchronization Service Manager より対象のユーザーが Export 処理されたことを確認する。
3. テスト ユーザーに拡張属性を付与して、非同期対象にする
4. Synchronization Service Manager より次回同期処理後に削除対象であることを確認する
5. Synchronization Service Manager より対象のユーザーが Azure AD 上に存在しないことを確認する

#####1. オンプレミス AD 上にテスト ユーザー (test004) を作成する。

1-1. Active Directory 管理ツール「Active Directory ユーザーとコンピューター」を起動し、新しいユーザーを作成します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/065a7747-d6d3-dfca-ee4e-80bc396256d1.png)

1-2. 新しいオブジェクトの画面で任意のユーザー名を入力し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b165baa2-b86f-13f8-f6f7-96c16ba4cf46.png)

1-3. パスワードを指定し、「次へ」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d1b9cc2d-572b-f788-8534-a68bccb38171.png)

1-4. 確認画面で「完了」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/10cf76c3-3380-9c9b-2790-5758b3f7e8e7.png)

#####2. Synchronization Service Manager より対象のユーザーが Export 処理されたことを確認する。
テスト ユーザーを作成したので、手動で同期処理を行い、テスト ユーザーを Azure AD に同期させます。

2-1. Azure AD Connect サーバーより、 「スタート」→「Azure AD Connect」→「Synchronization Service」の順にクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/ce0e7b0d-6c30-a57f-ab8b-2487f5a520fb.png)

2-2. 画面上部の「Connectors」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c19f8887-fe68-2547-f398-cb97bdf2565f.png)

2-3. オンプレミス AD のドメイン名が表示された Connector 名を右クリックにて、「Run」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/6da59e85-bf6c-3377-fe4f-324434ac19af.png)

2-4. Run Connctor より「Delta Import」を選択し、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/cb61b0fd-000a-5bcc-ff1b-aa9bded16d00.png)

2.5 画面ショットの左下の「Adds」のリンクをクリックすると、テスト ユーザー (test004) が Azure AD Connect の CS (コネクター スペース) にインポートされたことが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/dc9dac7d-e3aa-2bff-fd35-cc023601cec9.png)

この状態がどういう状態かというと、下記画面ショットの赤枠で囲まれた状態です。
つまり、オンプレミス AD 側のコネクター スペース (CS) にテスト ユーザーのオブジェクトが Import された状態です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/95121acf-357e-4a69-013b-9d0720cda61b.png)

-参考情報
同期プロセス
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/tshoot-connect-object-not-syncing#synchronization-process

>同期プロセスでは、次のステップが実行されます。
1. AD からインポートする: Active Directory オブジェクトが Active Directory CS に取り込まれます。
2.Azure AD からインポートする: Azure AD オブジェクトが Azure AD CS に取り込まれます。
3.同期: 受信同期規則と送信同期規則は、優先順位の番号の低い方から順に実行されます。 同期規則は、デスクトップ アプリケーションから同期規則エディターにアクセスして表示することができます。 受信同期規則は、CS から MV にデータを取り込みます。 送信同期規則は、MV から CS にデータを移動します。
4.AD にエクスポートする: 同期の後、オブジェクトは Active Directory CS から Active Directory にエクスポートされます。
5.Azure AD にエクスポートする: 同期の後、オブジェクトは Azure AD CS から Azure AD にエクスポートされます。

コネクター スペース (CS) に Import された後は、メタバース (MV) というデータベースに対して Sync 処理が行われ、メタバースから Azure AD 側のコネクター スペース (CS) に対して同期処理が行われた後に、Azure AD 側のコネクター スペースから Azure AD に対して Export される、という処理の流れになります。

2-6. 手動でメタバースに対して、同期処理を走らせるためには、Run Connector より「Delta Synchronization」を選択し、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9cd9cf55-7705-2d31-0e20-bee808d628cf.png)

2-7. 同期されたかどうかを確認するためには、画面右上の「Metaverse Search」のアイコンをクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b30141b6-1a1e-07bb-7527-4373f4f0e509.png)

2-8. Metaverse Search の画面にて、Scope by Object Type が「person」を選択し、画面右の「Search」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e23dc774-5eeb-c9a7-5818-60a901b0f460.png)

2-9. 検索した結果として作成したテスト ユーザー (test004) がメタバースの中に格納されていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/3c1d43a6-cadd-6410-091c-8fdbf0f4a5c6.png)

この状態を下記画面ショットで確認すると、下記赤枠で囲まれた状態です。つまり、In Sync Rule によりテスト ユーザーのオブジェクトがメタバース (MV) に同期され、Out Sync Rule により Azure AD 側のコネクター スペース (CS) に同期された状態です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/0787ecba-abdf-a338-e74b-f5bdde881625.png)

この後の処理としては、Azure AD 側に Export 処理が行われます。
2-10. 手動で Export 処理を行うためには、Azure AD 側のコネクターを選択し、右クリックより「Run」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c0ceff3e-5c68-232e-d766-3ba53c102286.png)

2-11. Azure AD 側のコネクターが選択されていることを確認し、「Export」を選択後、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e0ae8224-2cb8-a2d0-82a0-a6d0c0b54a6d.png)

この状態を下記画面ショットで確認すると、下記赤枠で囲まれた状態です。Azure AD 側のコネクター スペース (CS) から Export 処理が行われ、Azure AD に対してテスト ユーザー (test004) が同期された状態です。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/60a8150b-425d-536d-b85a-9fd1081cbb64.png)

2-12. Azure AD に対して Export された状態を確認するためには、Azure AD 側のコネクターを選択し、「Search Connector Space」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/2dd23ff6-0694-d6b1-77a6-cecec5c27527.png)

2-13. Scope を「Exported Since」を選択し、Since の時間を手動で Export 処理をした前の時間を指定し「Search」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/f1e827e0-a026-c86e-c15c-28a382f598eb.png)

2-14. 指定した時間以降に Export されたオブジェクトが表示されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/2ec8431d-1d60-bffe-65b6-2084d9749496.png)

上記情報だけでは、test004 ユーザーかどうか判別が難しいと思います。
その場合は、画面右上の「Column Settings」をクリックしてみてください。
2-15. Attribute の中から「displayName」を選択し、画面中央の「Add」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/b9a5ec1c-d52e-40dd-fbce-bbda8aff983b.png)

2-16.「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/65e69c7a-bab5-ffa9-3fc5-a3e525fe54e2.png)

2-17. カラムに「diplayName」が追加された対象のオブジェクトが「test004」であることを確認できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/96677d11-c491-89ea-64c4-93b1e7b61546.png)

#####3. テスト ユーザーに拡張属性を付与して、非同期対象にする

非同期対象にするための前段として同期対象外のフィルター設定を「Synchronization Rules Editor」で行います。
今回はルールの作成手順の詳細は割愛します。

Microsoft の公開情報に詳細な作成方法が記載されているので参考にしてみてください。

-参考情報
否定のフィルター処理 (同期対象外の指定)
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering#negative-filtering-do-not-sync-these

今回の検証では、上記の公開情報と同様に、オンプレミス AD 上のユーザーの属性として、**extensionAttribute15 ** が **nosync** であるユーザーを同期対象外にする設定を行いました。

Synchronization Rules Editor の 「Scoping filter」を見ると下記のような感じで設定がされています。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/13b365af-8f27-dd09-88f3-b7b52f065aed.png)

#####4. Synchronization Service Manager より次回同期処理後に削除対象であることを確認する

オンプレミス AD の「extensionAttribute15」に「nosync」を設定したユーザーが Azure AD 上から soft delete 対象になっていることを確認してみます。

4-1. オンプレミス AD 上のユーザーとコンピューターからテスト ユーザー (test004) を選択し、「属性エディター」から 「extentionAttribut15」を選択後、「編集」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c69f7daf-b749-b7cb-7c70-2468a949b23f.png)

4-2.値に「nosync」と入力し「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e45ee965-4edf-1724-7c6f-77b320bc9499.png)

Azure AD Connect 上の コネクター スペースにまで、オンプレミス AD の属性が変更されたことを同期させる必要があるので、Azure AD Connct の Run Connector から Delta Import → Delta Synchronization の順に手動実行します。

4-3. オンプレミス AD 側のコネクターから Run Connector を起動し、「Delta Import」 を選択して、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/42809853-202e-382c-1633-f2a14f9ddd26.png)

4-4. Update が成功したことを確認します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d35f031a-f04f-7dee-d36d-3a7dae116594.png)

4-5. 続いて Run Connector より「Delta Synchronization」を選択し、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/59f36f0b-a7be-42c9-6b23-da8b05d9e202.png)

4-6. 「Metaverse Search」から Scope by Object Type が「person」である状態で「Search」をクリックし、出力されたテスト ユーザーの「Properties」をクリックすることで、下記画面ショットのとおり、**extentionAttribute15** に **nosync** が反映された状態でメタバース (MV) に格納されていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/c5b3bca5-52d9-bfa5-3984-a8b223aafdce.png)

この後の動作としては、 Azure AD のコネクター スペース (CS) から Export 処理が行われ、Azure AD 上のユーザーが soft delete される流れですが、実際に対象のテスト ユーザー (test004) が削除対象であるかどうかを、「Synchronization Service Manager」で確認できます。

4-7. Azure AD 側のコネクターを選択し、 Search Connector Space の画面から、Scope の項目で「Pending Export」を選択し、右側の Operation の項目で「Delete」を選択し、「Search」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/60d00b09-af3b-5dbd-9aa2-0b51333fc9d9.png)

4-8. delete 対象のユーザーが出力されます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/dd97a9f5-cc20-98bb-e834-0d8fee5d0783.png)

4-9. 画面右の「Column Settings」をクリック後に、「displayName」選択し、「Add」をクリックし、「OK」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/8cff6b22-f0ac-98ef-0c8f-363918b46243.png)

4-10. delete 対象のユーザーがテスト ユーザー (test004) であることが確認できました。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/9d6b7f48-bd1c-f2c0-a427-2112ad61d299.png)

#####5. Synchronization Service Manager より対象のユーザーが Azure AD 上に存在しないことを確認する

30分に一度の同期処理もしくは手動で差分同期を走らせることで、対象のテスト ユーザー (test004) は Azure AD から削除されます。
実際に Azure AD から削除されたかどうかは、最初に触れましたとおり、 Azure ポータルのユーザー一覧から確認するのが一番シンプルで確実な確認方法かと思います。

しかし、Azure ポータルの管理者と Azure AD Connct の管理者が別の場合、Azure ポータル側で確認できない場合があるかもしれません。
その場合を考慮して、Azure AD Connect の 「Synchronization Service Manager」から対象のテスト ユーザー (test004) が削除されたかどうかを確認してみます。

まず、確認できる方法の 1 つとしては、手動で Export 処理を行った場合は、下記画面ショットのように、Export 処理として、「Deletes」の項目に削除されたオブジェクトの数を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/f7ae15a8-b42d-d7c6-c245-ee270c4efef2.png)

削除されたオブジェクト識別名を確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/5df1a89c-5174-9a8b-eab4-cf81f698a860.png)

2 つめの確認方法としては、「Synchronization Service Manager」の「Operations」タブから delete されたログを確認できます。
Azure AD のコネクターから Export されたログを選択すると、「Delete」されたオブジェクトの数が表示されていることを確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/d0ab968b-c45b-a2e9-8172-16eeb29540c3.png)

リンクをクリックすると、対象のテスト ユーザーの識別名が削除されていることが確認できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/7a25927a-a9e8-5ee2-b4f2-319aea8a2130.png)

上記 2 つの確認方法は、手動で実行した場合は確認を明確に行えますが、自動同期処理を走らせていて、いつユーザーが削除されたかを「Synchronization Service Manager」の「Operations」タブからログを追うことは大変だと思います。

3 つめの確認方法としては、メタバース (MV) 上のユーザー属性に、「**cloudSourceAnchor**」の有無で判別する方法を紹介します。
cloudSourceAnchor は、下記 Microsoft の公開情報にもありますとおり、ユーザー オブジェクトが Azure AD に Export されると、オブジェクト情報を受け取った Azure AD が sourceAnchor を基に、 cloudSourceAnchor をメタバース (MV) 上に書き込まれます。

-参考情報
sourceAnchor の変更
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/concept-azure-ad-connect-sync-user-and-contacts#changing-sourceanchor

>オブジェクトが Azure AD にエクスポートされると、sourceAnchor は変更できなくなります。 オブジェクトがエクスポートされると、Azure AD が受け取った sourceAnchor 値を使用してメタバース属性 cloudSourceAnchor が設定されます。

逆に言うと、Azure AD からユーザーが削除される処理が走ると、メタバース属性の 「**cloudSourceAnchor**」はメタバース上から削除される、という動作になります。

具体的に、メタバース情報を見てみます。
Azure AD に同期済みのユーザーは下記画面ショットのように、「cloudSourceAnchor」が設定されています。
見ていただくと分かるように、「cloudSourceAnchor」は「sourceAnchor」をベースに作成されるので、値は同一になります。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/38b94a69-1676-0f2d-7f70-0d70e8f00df7.png)

次に、削除済み、もしくは、Azure AD に同期前のユーザーのメタバース情報を見てみると、下記画面ショットのように「cloudSourceAnchor」は設定されていません。つまりこの状態は Azure AD 上にはユーザーが存在していない、と判断できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/1859398b-8f3e-a929-ba10-27ad73aacc24.png)

上記の違いをフィルタリングで確認する方法は、「Metaverse Search」の画面から、画面右の Actions の欄より、「Add Clause」という検索条件を追加します。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/17e503f4-662e-eb0e-d537-9bb3e6458a34.png)

Attribute に「cloudSourceAnchor」を選択し、Operator に「Is not present (= cloudSourceAnchor が存在しない)」 を選択し、Value には何も指定せずに、「Search」をクリックします。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/e219bc66-a45f-94b8-1378-f886736f0a81.png)

すると、「cloudSourceAnchor」が設定されていないユーザーの一覧が取得できます。
検証対象のテスト ユーザー (test004) を含む下記ユーザーは、「cloudSourceAnchor」が設定されていないため、Azure AD 上にはユーザーが同期されていない、と判断できます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/4b4d2f13-8720-61f7-f99d-a49a05d5c453.png)

逆に Operator に「Is present (= cloudSourceAnchor が存在する)」 を選択すると、「cloudSourceAnchor」が設定されたユーザー一覧を取得できます。
これらのユーザーは Azure AD 側にユーザーが同期されているユーザーだと判断ができます。
![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/373423/fc0e1e24-8189-2db9-0829-3030ff1b1e1d.png)

#おわりに
今回は、Azure AD Connect の Synchronization Service Manager を利用して非同期対象のユーザーが Azure AD 上にいないことを確認する方法を検証してみました。一連の検証作業の中で、オンプレミス AD のコネクター スペース (CS) への Import 処理、メタバース (MV) への同期処理とメタバースから Azure AD 側のコネクター スペース (CS) への同期処理、最後に Azure AD への Export 処理までの一連の流れを確認しました。

ここまで厳密に動作を理解しなくても Azure AD Connect を利用いただくことはもちろん可能ですが、実際に、同期や削除処理を行った際に、今どこまで同期が行われているのか確認する必要が出てくるケースもあるかと思います。

その際には今回ご案内したように Synchronization Service Manager を利用することで状況を細かく確認できますので、ぜひ活用してみてください。
今回の記事が少しでも参考になれば幸いです。