エンタープライズ環境を運用するうえで、認証基盤のアップグレードは避けて通れない重要事項です。Microsoft Entra（旧Azure AD）関連サービスの新機能を活用するため、Azure AD ConnectからEntra AD Connectへ切り替える場面が増えています。今回はオンプレミス環境とクラウド環境をシームレスに連携させるためのアップグレード方法や、onPremisesObjectIdentifier属性に関する具体的な確認ポイントについて徹底解説します。
Azure AD ConnectからEntra AD Connectへのアップグレード全体像
アップグレードの大きな目的は、最新のMicrosoft Entra側の同期機能やセキュリティ強化に対応することです。今後のクラウド認証トレンドを考えると、Azure AD ConnectからEntra AD Connectへの移行は非常に重要なステップと言えます。特にクラウド同期を安定して行うには、新しいバージョンの同期エンジンや属性管理が必要になり、いずれは旧バージョンのサポートが切れてしまう可能性もあります。そのため、早めの検証と準備が欠かせません。
アップグレードのメリットと背景
Azure AD ConnectからEntra AD Connectへの移行には、クラウド認証の強化や新しい属性サポートなど複数のメリットがあります。Microsoft Entra Cloud Sync機能が拡充されたことで、ユーザー・グループなどのオブジェクト管理がよりシンプルかつ高速に行えるようになりました。最新リリースではセキュリティパッチの適用や高可用性に関する機能強化も進んでおり、企業規模を問わず運用リスクを軽減できます。
スイング方式の概要
既存環境を使いながら、新しいサーバー上でMicrosoft Entra AD Connectのスタンバイ環境を構築し、切り替えタイミングで本番稼働を置き換える方法を「スイング方式」と呼びます。この方式をとることで、万が一のトラブル発生時にも旧サーバーへの切り戻しが容易になります。以下にスイング方式の簡単な手順を示します。
- 新サーバーにEntra AD Connectをインストール
- 旧サーバーから構成をエクスポートして、新サーバーにインポート
- 新サーバーで同期をテスト（スタンバイモード）
- 切り替えタイミングで旧サーバーをスタンバイモードにし、新サーバーをアクティブに
この流れを踏むことで、業務影響を最小化しつつ、新しい同期環境へ移行できます。
スイング方式のメリット
- 低リスク: トラブル時に旧環境へ戻せるため、移行作業におけるリスクを軽減
- 段階的テスト: 同期ルールや属性マッピングをあらかじめテストできる
- 移行の柔軟性: 業務スケジュールに合わせて最適なタイミングで切り替え可能
スイング方式の注意点
- ライセンスや接続制限: 同時に稼働させるサーバー数の制限に注意
- 設定ファイルの齟齬: 旧サーバーの設定をインポートする際、バージョン差異により不要なルールが残る可能性がある
- 切り替え後のログ確認: 新環境での同期動作を定常的に監視し、正しく動作しているか確認が必要
onPremisesObjectIdentifier属性の更新が発生する理由
アップグレードの際に多くの問い合わせが寄せられるのが、ユーザーごとにonPremisesObjectIdentifierが更新対象として検出される問題です。実はこれは「不具合」ではなく、新しいバージョンにおけるデフォルト同期ルールの仕様変更によるものです。
onPremisesObjectIdentifierとは何か
onPremisesObjectIdentifierは、Microsoft Entra Cloud Syncで必須となる属性の一つです。オンプレミスのActive Directoryオブジェクトと、クラウド側のオブジェクトを一意に紐付けるための識別子として利用されます。最新バージョンの同期エンジンでは、これが標準の同期ルールに組み込まれています。
旧バージョンからの移行時に起こる変化
旧バージョン（Azure AD Connect 2.2.1.0など）ではonPremisesObjectIdentifierが同期ルールに含まれていない、もしくはオプション的に扱われていた場合があります。しかしバージョン2.2.8.0以降では、この属性が標準で含まれるようになり、設定をインポートしたタイミングで「新しく値が付与されるオブジェクト」として認識されます。その結果、エクスポートの差分確認を行うと「OldValueがブランク」「NewValueには識別子が入る」という更新が大量に検出されることになります。
想定される更新例
以下のように、多くのユーザーで同様の更新が報告されます。実際のログ例を簡易表にすると、下記のような形で検出されるイメージです。
| オブジェクト | 属性 | OldValue | NewValue |
|---|---|---|---|
| ユーザーA | onPremisesObjectIdentifier | 12345abc-… | |
| ユーザーB | onPremisesObjectIdentifier | 67890def-… |
ほとんどの場合、OldValueは空欄（ブランク）でNewValueに固有の文字列が入るのが特徴です。
問題がないことを確認するためのチェックポイント
これらの更新が大量に検出されると、一見「大規模な変更が発生するのでは」と心配になりがちです。しかし多くの場合、このonPremisesObjectIdentifierの差分検出は想定される正常な挙動です。以下のポイントを押さえておくと、より安心して作業を進められます。
既存のオブジェクトIDとの競合がないか
onPremisesObjectIdentifierを新たに同期することで、既存のobjectGUIDやImmutableIDといった他のID属性と競合しないかをチェックします。基本的には問題ありませんが、独自に拡張した属性がある場合は、カスタムルールと衝突しないように注意しましょう。
同期が失敗していないか
Azure AD Connectの同期サービス（Microsoft Entra AD Connectの場合は同等）を起動して、実際に同期が成功していることを確認します。onPremisesObjectIdentifierの値の差分のみが検出されているなら、基本的には失敗することはありません。ただし、他の属性にも影響が出ていないかをログやConnect Healthでチェックしましょう。
不要な再作成や削除が起きていないか
ユーザーアカウントやグループが突然削除されたり、別のオブジェクトとして再作成されたりしていないかを確認します。onPremisesObjectIdentifierの追加はあくまで属性に値が付与されるだけであり、オブジェクト自体を削除再作成するわけではありません。そのため、通常であればユーザーへの影響は限定的です。
スタンバイサーバー切り替え時の具体的な手順
スイング方式では、新サーバーをスタンバイ（Staging Mode）にして十分なテストを行った後、既存サーバーとの切り替えを行います。ここでは基本的な流れと注意点を解説します。
1. エクスポートファイルの確認
- 旧サーバーからエクスポートした構成ファイルを分析し、新サーバー上でインポートする前に差分を把握しておきます。
- onPremisesObjectIdentifierに関する追加が大量に見つかった場合も、基本的には想定内の動作です。
- もし意図しない属性の削除や編集が含まれていた場合は、カスタムルールを見直す必要があります。
2. テスト同期（試験的運用）の実施
- スタンバイサーバー側で同期を有効化する前に、テスト用のOU（組織単位）や限定されたユーザーのみ同期対象にして動作確認を行うのがおすすめです。
- 大規模なユーザー数を抱える企業では、一部部署やグループだけを同期対象にして試運転をすることで、性能面の問題や想定外のエラーを早期発見できます。
テスト同期時のPowerShellコマンド例
スクリプトで制御する場合、下記のようなコマンドで確認できます。
Import-Module ADSync
Start-ADSyncSyncCycle -PolicyType Delta
Get-ADSyncConnectorRunStatus
Delta同期（差分同期）を実行してログを確認し、エラーがないかを確かめます。
3. 本番切り替え
- 旧サーバーをStaging Modeに変更し、新サーバー側をアクティブモードに切り替えます。
- 切り替え直後は同期サービスのイベントログやMicrosoft Entra Connect Healthをこまめに監視します。
- 大きなエラーやアカウントの消失などがなければ、問題なく切り替えが完了したと判断できます。
4. ロールバック（切り戻し）の準備
- 本番環境で重大な不具合が発生した場合、旧サーバーを再びアクティブに戻す必要があります。
- 切り替え前の状態をバックアップするほか、サーバー切り替え手順書を明確に残しておくと安心です。
- 可能であればテスト環境を作り、本番切り戻しの手順をシミュレーションしておくとより安全です。
同期上の懸念と運用ベストプラクティス
onPremisesObjectIdentifierの更新自体は想定された仕様変更であり、重大な障害を引き起こすものではありません。ただし、移行後も安定運用を継続するためにいくつかのポイントを把握しておきましょう。
同期エラーログの監視
- 切り替え後しばらくは、Synchronisation Service Managerやイベントビューアーを細かくチェックし、エラーが出ていないかをモニタリングします。
- Microsoft Entra Connect Healthを導入している場合、ポータル上のアラート機能で重要度の高いエラーを見逃さないようにできます。
大規模環境の注意点
- 数万から数十万ユーザー規模になると、同期サイクルの完了に時間を要するケースがあります。
- onPremisesObjectIdentifierの大量更新は、一時的に同期プロセスに負荷をかける可能性がありますが、あくまでも一度の属性追加が主です。通常は時間経過とともに落ち着きます。
- パフォーマンス上の懸念がある場合は、同期スケジュールを制御し、夜間や業務ピーク外の時間帯に実施することを推奨します。
スケジュール設定の例
# 自動同期のスケジュールを無効化
Set-ADSyncScheduler -SchedulerType Custom
# 2時間に1回差分同期を実施する設定例
$sch = New-Object -TypeName Microsoft.IdentityManagement.PowerShell.SyncSchedule
$sch.DelayInitial = (New-TimeSpan -Minutes 15)
$sch.PeriodicSyncInterval = (New-TimeSpan -Hours 2)
Set-ADSyncScheduler -SyncCycleEnabled $true -CustomSyncCycleInterval $sch.PeriodicSyncInterval
このようにカスタムスケジュールを組むことで、業務に影響が少ない時間帯に負荷を集中させられます。
まとめと今後の展望
Azure AD ConnectからEntra AD Connectへのアップグレードに伴い、onPremisesObjectIdentifierの追加や更新が多発するのはバージョン2.2.8.0以降のデフォルト仕様に由来するもので、ほとんどの場合は問題ありません。
もしエクスポート時や最初の同期で大量の更新が報告されても、適切に手順を踏んでいる限りは大きな不具合を引き起こす心配は少ないでしょう。
今後、Microsoft Entra（Azure AD）側の機能拡充に伴い、さらに新たな属性が追加される可能性や、Syncエンジンのアップデートが行われる可能性も考えられます。常に最新のリリースノートをチェックし、適切なタイミングでテストやバージョンアップを行うことが、セキュリティと利便性を両立するうえで大切です。
運用担当者へのおすすめアクション
- バージョン情報の確認: Microsoft公式ドキュメントやリリースノートを定期的にチェックし、最新情報を把握する。
- テスト環境の維持: 本番環境と同等のテスト環境を用意し、アップデートや属性追加などの影響を事前に試す。
- 監視体制の強化: Microsoft Entra Connect Healthや独自のログ収集システムを活用して、リアルタイムでエラーを検知できる環境を整える。
- 社内周知の徹底: onPremisesObjectIdentifierの更新による影響や作業手順などをドキュメント化し、サポート担当者やユーザー管理担当者と共有する。
実運用の声：よくある質問と回答
最後に、現場でよく聞かれる質問と、それに対するシンプルな回答をQ&A形式でまとめます。
Q1. onPremisesObjectIdentifierの更新によって、ユーザーアカウントがロックされたりするリスクはありますか？
A1. ほぼありません。あくまで属性が追加または更新されるだけで、ユーザーのパスワードやグループメンバーシップには直接影響しません。
Q2. アップグレードのタイミングで既存のアカウント情報が消失する可能性は？
A2. 適切な移行手順を踏んでいれば、既存アカウントが削除されるリスクは低いです。スイング方式の場合、旧サーバーでの同期を温存したままテストできるため、ロールバックも容易です。
Q3. 同期スケジュールを調整する際の目安は？
A3. 同期対象ユーザー数とピーク時間帯の負荷を考慮して決めます。夜間や稼働の少ない時間に完全同期を実施するケースが多いです。大企業の場合は1～3時間おきの差分同期を基本とし、週末や深夜帯に完全同期を計画することがあります。
Q4. Azure AD Connect Healthを導入するメリットは？
A4. 管理ポータル上から同期エラーのアラートを受け取れたり、レポートを一元管理できたりする点です。障害発生時の原因切り分けにも役立ち、運用コストの削減につながります。
総括：onPremisesObjectIdentifierの更新は想定内
結論として、バージョン2.2.8.0以降でonPremisesObjectIdentifierが標準ルールに追加されたことにより、アップグレードの際にユーザー全員の属性が更新されたように見えるケースが多発します。しかし、それはMicrosoft Entra Cloud Syncに対応した正常な動作です。大量の更新ログを見ても慌てず、以下の点を遵守すれば円滑にアップグレードを進められます。
- 事前に構成ファイルや同期ルールの差分を確認する
- 新サーバーをスタンバイ（Staging Mode）で一度テスト運用する
- 切り替え後もログを継続的に監視し、問題があればすぐに切り戻しできるように準備する
Microsoftは今後もEntra関連サービスのアップデートを継続的に行うと予想されます。常に最新情報をキャッチアップしながら、適切なタイミングで環境をアップグレードし、セキュリティと利便性を高めていきましょう。
コメント