IdPプロビジョニングからMicrosoftEntraConnect同期への移行

はじめに

こんにちは、IT本部IT戦略部テクニカルオペレーショングループの矢島です。
DeNAグループにおけるITシステム・ツールの導入企画から運用管理、運用改善などを担当しています。

2023年にDeNAグループでは、Microsoft Entra ID(旧名称: Azure AD)への同期を、IdP(Identity Provider)プロビジョニングからMicrosoft Entra Connect(旧名称: Azure AD Connect)へ移行しました。
今回のBlogでは上記の移行事例を紹介します。

この記事の流れ

以下の章に分けて記載します。

移行の背景
移行準備
本番移行作業
エラーへの対応
まとめ

移行の背景

DeNAグループでは、一部の部門やユーザーにおいてMicrosoftの各種サブスクリプションサービスを利用しています。
利用時はMicrosoft Entra ID（以下、Entra IDと記載します）へユーザー情報を登録し、ライセンスを割り当てる必要があります。
これまでのユーザー情報登録は「オンプレミスのActive Directory (以下、ADと記載します) → IdP → Entra ID」の順で同期を行っていました。
今回、同期方法を変更したきっかけは「Microsoft Intuneの導入検討」です。
Windows PCの端末管理やキッティングの自動化・作業効率化を目的として、IntuneのPoCを実施することにしました。
実施の前提条件として「Intuneを動作させる場合はEntra ID上にPCデバイス情報を同期する」必要があることが判明しました。
しかし、これまでのIdPを経由した方法ではPCデバイス情報の同期が不可能であり、同期方法を変更する必要がありました。
PCデバイス情報の連携方法を調査・検討した結果、Microsoftが用意している「Entra Connect」へ変更することが最適と判断し、今回の移行を進めることになりました。

移行準備

本番環境でいきなりの移行はリスクが大きいため、まずは検証環境を構築しました。
具体的には

検証用オンプレミスAD環境の構築
検証用IdP環境の構築
検証用Entra ID環境の構築
検証用ユーザーデータ及びPCデバイスデータの登録の4点を行い、完全に本番環境と切り離した状態で検証できるよう準備しました。
検証環境の構築後は、以下の順序で検証作業を行いました。
連携切替の実施
切替後の動作確認
切替失敗時を想定したレストアの実施及びレストアデータの確認
イレギュラーなデータや、過去に連携トラブルを起こしたことのあるアカウントの動作確認
- 長いアカウント名や特殊なアカウントを抽出して実施検証において特に注意したのは以下の視点です
Microsoftの各種サブスクリプションサービスの利用に影響がないこと
切替前後のデータ比較において差分が生じないこと
Entra ID連携先の各システムにおいてアカウントプロパティの「見え方」に変更がないこと
- Entra ID連携先システムの例：Office365/各種Azureサブスクリプション/Azureポータル上の権限ロール

本番移行作業

検証により移行手順の安全性を確認した後、本番移行作業を開始しました。
手順通りに作業を進めましたが、移行時に同期されたAD上のエントリ約62,000件に対し、約2,600件のエラーが発生しました。
エラー内容を確認した結果「ユーザー及び連携先システムへ影響がないもの」と判断できたため、切り戻しは実施せず、移行後の「事後作業」としてエラーを解消する方針としました。

発生したエラーへの対応

本番移行で発生したエラーは以下の2種類でした。

Attribute Value Must Be Unique：ユーザーのメールアドレスが、「連絡先」オブジェクトに登録している内容と重複していると発生するエラー
Data Validation Failed：ユーザーのメールアドレスに「Entra IDで非対応の文字」が含まれていると発生するエラー

発生したエラー（2,571件）

「Attribute Value Must Be Unique」エラーは、過去にメールアドレスを「連絡先」に追加する運用をしていたことが原因でした。現在は利用がないオブジェクトである裏付けが取れたため、エラーが検知されたアカウントの「連絡先」オブジェクトを削除してエラーを解消しました。
「Data Validation Failed」エラーは、メールアドレスに「+（プラス記号）」などEntra IDに登録できない文字が含まれていることが原因で発生していました。
参考：セルフサービスパスワードリセットポリシー - Microsoft Entra ID
エラーの原因は単純ですが、以下の理由により解消対応は慎重に実施しました。
それは「IdPから各種サービスへのユーザープロビジョニング(ユーザー自動作成機能)」で「別の新規ユーザーと誤認される」場合があるためです。
誤認が発生するメカニズムは以下の通りです。
各種SaaSへのユーザープロビジョニングは「AD→IdP→各種SaaS」の順で行います
SaaSでは「原則としてメールアドレスを基にユーザーIDを作成」します
オンプレAD上のメールアドレスを変更すると、IdPを通じて連携され、SaaSにおいて「現在登録されていないメールアドレス＝新規ユーザーである」と誤認されます

メールアドレスの変更が「新規ユーザー」と誤認される例

上記の理由から、エラーが発生しているユーザーアカウントの「各種SaaS利用状況」を全て洗い出し、メールアドレス変更の影響有無を調査しました。
メールアドレスの変更が利用中のSaaSアカウントへ影響を及ぼす場合は「予めADと連携先システムの両方のメールアドレスを修正」し、システム利用に影響を与えないようにしました。
1件ずつ作業を行う必要があり時間を要す作業でしたが、結果として各SaaSアカウントに影響を与えずに全てのエラーを解消できました。

まとめ

当社のAD環境は長年に渡って運用しています。状況により運用ルールを変更してきたため、現在の運用メンバーが認識していないオブジェクトや設定値が存在していました。
事前の検証で全てのエラー要因を潰すことができなかったことに悔しさは残ります。
一方で移行作業時のエラーについて、ユーザーへの影響有無を正確かつ迅速に確認・判断できた点は良い動きができたと考えています。
また、同期方法を変更したことで過去に作成された不要なADオブジェクトを整理できた点も嬉しいポイントでした。

最後に

私の所属するテクニカルオペレーショングループでは新しい仲間を募集しています。
当グループでは、DeNAグループ全社IT環境の運用管理にとどまらず「業務改善や効率化・省力化」を目的とした様々な取り組みを行っています。
ご興味がある方はぜひ下記リンクから内容をご覧ください。
【社内システム】テクニカルオペレーション〜社内システムの運用改善でグループ全社へ価値を届けるメンバー募集〜