多くの企業でオンプレミスのActive Directoryを長年利用してきた背景から、Azure ADとの同期設定にまつわるトラブルや懸念を抱えている方は少なくありません。特にUPNサフィックスの変更や重複ユーザーの発生は、運用に大きな影響を及ぼす可能性があります。ここでは、オンプレミスADをAzure AD(Microsoft Entra ID)へ同期する際に押さえておきたいポイントを、詳しく解説していきます。
オンプレミスADとAzure ADを同期する必要性
オンプレミスADをAzure ADと同期するメリットは、クラウドサービスと社内システムをシームレスに連携できる点にあります。今後Power BIやOffice 365などのサービスを活用する際、ユーザーアカウントを一元管理し、シングルサインオンやセキュリティ強化を実現できるのは大きな利点です。
しかし、オンプレミス環境で使用しているドメインサフィックスが.localや.internalなどの内部専用ドメインになっている場合、Azure AD側に同期する際に問題が発生しやすいため、事前に正しい知識を身につけておくことが重要です。
同期における典型的な課題
- オンプレミスで利用しているUPNサフィックスが外部公開向けのドメインでないため、クラウドに対応したUPNへ切り替える必要がある。
- 既にAzure AD上に同じメールアドレスやユーザーIDでアカウントが存在している場合、重複ユーザーが生成されるリスクがある。
- UPN変更によって、社内で動作している古いシステムや認証環境に影響が出る可能性がある。
UPNとは何か
UPN(User Principal Name)は「ユーザー名@ドメイン名」の形式で表されるユーザーの一意識別子です。Windowsログオン時にSAMアカウント名(例: DOMAIN\username)を利用するケースが多い一方、クラウド認証やOffice 365のログインにはUPNが用いられるケースが増えています。そのため、Azure ADへの同期を成功させるには、正しいUPNの設定が不可欠となります。
UPN変更によるシステムへの影響と対策
UPNサフィックスを.comやonmicrosoft.comへ変更する場合、社内システムでUPNを参照していると影響が出る可能性があります。特にサードパーティ製のアプリケーションがユーザーIDとしてUPNを直接活用している場合は、ログイン不可や認証エラーなどのトラブルが発生しやすくなります。
影響度を見極めるための確認項目
- 主要アプリケーションの認証方式
KerberosやNTLM認証を行っている社内Webアプリケーション、ファイルサーバーなどが、SAMアカウント名を使用しているのかUPNを使用しているのかを確認します。一般的にはSAMアカウント名のみで済むシステムが多いですが、一部製品ではUPNをユーザーIDとして扱っている場合があります。 - オンプレミスExchangeやハイブリッドExchangeの構成
オンプレミスExchangeとExchange Onlineを併用しているケースでは、メールアドレスとUPNの整合性が重要です。Exchangeハイブリッド環境でメールフローに問題が生じないかチェックが必要です。 - レガシー認証の存在
古いバージョンのWindows Serverや非Microsoft製品など、レガシー認証を使う環境がある場合、それらがUPNベースで認証しないかを調べます。
UPN変更時に考慮すべき対策
- 段階的移行: まずテストユーザーを対象にUPN変更を行い、問題なくクラウド側にサインインできるかを確認します。少数のパイロットグループを設定して影響を把握し、問題がなければ徐々に全体に適用していくのが望ましいです。
- アナウンスとドキュメント整備: 社内ユーザーに対し、今後のログインIDがどのように変更されるかを周知します。特にメールアドレスでのサインインとUPNが異なる場合、わかりやすいガイドやFAQを用意しましょう。
- バックアップとロールバックプラン: ADスナップショットやシステムのバックアップを取得し、万一問題が起きた場合に迅速に元の状態に戻せるよう準備します。
Azure AD Connect(Microsoft Entra Connect)による同期設定
Azure AD Connectは、オンプレミスADとAzure ADを連携させるための必須ツールといえます。現在は「Microsoft Entra Connect」という新しい名称や機能拡張も登場しており、同期のみならずハイブリッド認証やパススルー認証などの高度な機能を利用できます。
導入手順の一般的な流れ
- Azure ADにカスタムドメインを追加
Azureポータルの「カスタムドメイン」メニューから所有しているドメイン(例: example.com)を追加し、TXTレコードやMXレコードの設定でドメイン所有権を検証します。これによりAzure AD側で`.com`などの外部ドメインが利用可能になります。 - オンプレミスADにUPNサフィックスを追加
Active Directoryドメインと信頼関係のプロパティから、代替UPNサフィックス(Alternate UPN Suffix)を設定します。もともと`.local`や`.internal`などしかなかった場合、新たに`.com`や組織の独自ドメインを追加します。 - ユーザーアカウントのUPN変更
オンプレミスAD上のユーザーオブジェクトに対して、必要に応じてUPNサフィックスを切り替えます。パイロットユーザーから変更を始め、影響を確認後に全ユーザーへ展開するのが安全です。 - Azure AD Connectのインストールと初期設定
Azure AD Connectをサーバーにインストールし、Express SettingsかCustom Settingsを選んでセットアップを行います。同期の方式(パスワードハッシュ同期、パススルー認証、フェデレーションなど)やドメイン/OUの選択を行い、同期範囲を設定します。 - 同期の動作確認と監視
Azureポータルでユーザーのステータスや属性が正しく同期されているか確認します。初回同期には時間がかかる場合がありますが、その後は変更が行われるたびに定期的に同期されます。
重複ユーザー回避のためのマッチング
同期時に誤って重複アカウントが作成される主な原因は、オンプレミスADとAzure ADで別々に作成されたユーザー情報に重複する属性(例: メールアドレス、UPN)が存在することです。以下にマッチング方法を示します。
| マッチング方式 | 主な判定属性 | 特徴 |
|---|---|---|
| ソフトマッチ (Soft Match) | Mail属性, ProxyAddresses 主にPrimary SMTPアドレス | 既存のクラウドアカウントと属性を照合してマッチングする。既に存在するメールアドレスとADユーザーのMail属性が一致すると、同一ユーザーと認識されやすい。 |
| ハードマッチ (Hard Match) | ImmutableID (オンプレはObjectGUID) | PowerShellなどを使ってImmutableIDを強制的に設定し、オンプレミスADのObjectGUIDと紐付ける。重複を確実に回避したい場合に利用する。 |
PowerShellでImmutableIDを手動設定する例
# 1. オンプレミスADのユーザーのObjectGUIDを確認
Get-ADUser -Identity "ユーザー名" -Properties objectGUID
# 2. 確認したobjectGUIDをBase64へ変換
# 以下は例: $guid = [System.Guid]("xxxx-xxxx-xxxx-xxxx")
$immutableId = [System.Convert]::ToBase64String($guid.ToByteArray())
# 3. Azure AD側のユーザーにImmutableIDを設定
Set-MsolUser -UserPrincipalName "ユーザーUPN@ドメイン" -ImmutableId $immutableId上記手順により、Azure ADに存在するユーザーのImmutableIDをオンプレミスADのObjectGUIDと一致させられます。すでにAzure ADにユーザーが存在し、手動でマッチングさせる必要があるケースでは有効な方法です。
実運用での注意点とベストプラクティス
ライセンスとメールデータの扱い
すでにクラウド側でOffice 365やPower BIなどのライセンスを割り当てているユーザーがいる場合、誤って重複アカウントを作成してしまうと、ライセンス移行やメールデータの統合に手間取ることがあります。重複ユーザーを無理に削除するとデータが消失する恐れもあるため、慎重な対応が必要です。
段階的移行(ステージング)とユーザーコミュニケーション
UPNを一括で変更してしまうと、影響範囲が広大になり、予期しないトラブルのリスクが高まります。最初はIT部門や小規模のパイロットグループに対して変更を実施し、運用に支障が出ないかを確認してから全社展開を行うほうが安全です。変更を実施する際は、ユーザーに対し新しいログイン方法やメールアドレスが今後どのように扱われるかを周知し、サポート体制を整えておきましょう。
同期後の監視と運用管理
Azure AD Connectには「Synchronization Service Manager」や「Event Viewer」など、同期の状態を監視するツールが備わっています。特に同期エラーが発生した場合、イベントログや同期ツールのログをチェックし、原因を特定して対処が必要です。以下のようなポイントを定期的にモニタリングしましょう。
- 同期の失敗状況: どのオブジェクト(ユーザー、グループなど)が同期に失敗しているか、エラーコードは何か。
- コネクタの状態: オンプレミスADとAzure AD、それぞれのコネクタが正常に動作しているか。
- パスワードハッシュ同期: パスワードハッシュの同期が失敗している場合、ユーザーがクラウドサービスへサインインできない原因となる。
運用負荷軽減のための対策
- 自動同期スケジュールの見直し: デフォルトでは30分ごとに差分同期が行われますが、変更頻度や組織の都合に合わせて適切に調整してください。
- エラー通知の自動化: PowerShellスクリプトやAzure Automationなどを活用し、同期エラーがあればメールやTeamsに通知する仕組みを構築すると、トラブルシューティングを迅速に行えます。
- 監査ログ・レポートの活用: Azure ADにはサインインログや監査ログが用意されています。定期的に確認することで、アカウントに不審な操作がないかを把握しやすくなります。
ローカルドメインを維持したい場合の代替策
どうしてもUPNサフィックスを変更できない、あるいは大規模変更に踏み切るのが難しい場合は、以下のような代替策を検討します。
ProxyAddressesの活用
オンプレミスADのユーザー属性にあるproxyAddressesを使い、クラウドで利用するログイン用のSMTPアドレスを設定する方法があります。たとえば、オンプレミスADのUPNがuser@example.localのままでも、proxyAddressesにSMTP:user@example.comを登録しておき、クラウド側ではuser@example.comをログインIDとして使うようにできます。
別のログインIDの周知
ユーザーがクラウドにサインインする際、user@example.comのように「.com」ドメインのIDを使うよう案内し、オンプレミス環境では従来どおりの.localを内部的に利用する方法です。ただし、管理面が煩雑になるため、長期的にはUPNの統一が望ましいとされています。
まとめ
オンプレミスADをAzure AD(Microsoft Entra ID)と同期させる場合、UPNサフィックスの扱いや重複ユーザー回避が大きな課題となります。UPN変更による影響はシステムごとに異なるため、まずは影響範囲を正しく把握し、必要に応じて段階的な移行計画を立てましょう。具体的には、以下のステップを踏むとリスクを最小化できます。
- Azure ADにカスタムドメインを登録・検証する。
- オンプレミスADに代替UPNサフィックスを追加し、UPNを正しい外部ドメインへ切り替える準備をする。
- パイロットユーザーを用いてUPN変更や同期テストを行い、影響範囲を確認する。
- Azure AD Connect(Microsoft Entra Connect)でSoft Match/Hard Matchを理解し、重複ユーザー発生を防ぐよう設定する。
- 本番ユーザーへ段階的に移行しながら、同期エラーや認証トラブルを綿密にモニタリングする。
UPN変更が難しい場合は、ProxyAddressesの設定などを活用して外部ドメインでのサインインを行う方法もありますが、長期的にはUPNの統一が管理上やサイバーセキュリティ面で有利です。今後、Power BIやOffice 365などクラウドサービスをより深く活用していくのであれば、早い段階での整理が大きなメリットにつながります。
最後に、本番導入前のテスト環境や段階的移行は不可欠です。事前に十分な検証を行い、運用担当者やユーザーへの周知を徹底することで、スムーズなクラウド移行を実現していきましょう。
コメント