Microsoft Entra Connect Sync を使ってオンプレミス Active Directory と Microsoft Entra ID を同期している環境では、認証方式の確認が優先事項です。要点は、従来のユーザー名・パスワードを使うコネクタ認証から、証明書を使うアプリケーション ID 認証へ移行する流れが明確になっていることです。まず管理者は、現在の認証方式が ServiceAccount か Application かを確認し、未移行であれば Microsoft Entra Connect のバージョン、証明書ローテーション、同期スケジューラ、レガシー DSA アカウントの扱いを点検してください。Microsoft Learn の対象ページでは、Microsoft Entra Connect が OAuth 2.0 クライアント資格情報フローと証明書資格情報を使うアプリケーション ID を利用する方式が説明されています。(Microsoft Learn)
なお、参照先の Microsoft Learn ページ上では、確認時点の最終更新日が 2025年11月20日と表示されています。社内ナレッジや配信情報で「2026年5月23日更新」として扱っている場合でも、実作業ではページ本文、Microsoft Entra Connect のリリース履歴、現在導入済みのビルド番号を必ず照合してください。(Microsoft Learn)
Microsoft Entra Connect の認証方式で何が変わるのか
従来、Microsoft Entra Connect は Microsoft Entra Connector アカウントを使い、ユーザー名とパスワードで Microsoft Entra ID へ認証していました。今回のポイントは、この資格情報をより現代的な方式へ置き換え、Microsoft Entra ID 上の単一テナント アプリケーションと証明書資格情報を使って認証することです。(Microsoft Learn)
この方式は、Microsoft Learn では「application identity」または「application-based authentication」として説明されています。実体としては、証明書を持つアプリケーション ID、つまりサービス プリンシパルを使って Microsoft Entra ID に認証する仕組みです。トラブルシューティング資料でも、アプリケーション ベースの認証は、ユーザー名とパスワードではなく、証明書付きのサービス プリンシパルを使う方式として整理されています。(Microsoft Learn)
管理者が理解すべき影響は、エンドユーザーのサインイン画面が変わるという話ではありません。影響の中心は、Microsoft Entra Connect Sync サーバー、証明書管理、アプリ登録、サービス プリンシパル、同期スケジューラ、そしてレガシーな同期用アカウントの運用です。
まず確認すべき現在の状態
最初に行うべきことは、移行作業ではなく現状把握です。特に、同期が正常に見えていても、証明書ローテーションや次回アップグレード時に問題が出る構成があります。
| 確認項目 | 確認方法 | 判断ポイント |
|---|---|---|
| Microsoft Entra Connect のバージョン | サーバー上の製品バージョン、または Microsoft Entra 管理センター | 自動オンボードには 2.5.76.0 以降、手動オンボードには 2.5.3.0 以降が前提 |
| 現在の認証方式 | Get-ADSyncEntraConnectorCredential | ConnectorIdentityType が Application ならアプリケーション ID 認証、ServiceAccount なら従来方式 |
| 証明書の管理元 | Microsoft Entra Connect ウィザードの現在構成表示 | Microsoft Entra Connect 管理、BYOC、BYOA のどれか |
| 証明書の期限 | 現在構成表示、イベント ログ、アプリ登録 | 期限切れ前にローテーションできる状態か |
| 同期スケジューラ | Get-ADSyncScheduler | スケジューラ停止中は自動証明書ローテーションが動かない |
| 複数サーバー構成 | 本番・ステージング サーバーの構成 | サーバーごとに一意のアプリケーション ID が使われているか |
| レガシー DSA アカウント | Microsoft Entra ID のユーザー一覧、PowerShell | 移行後に不要な特権や資格情報が残っていないか |
公式ドキュメントでは、現在の認証構成は Microsoft Entra Connect ウィザードの「View or export current configuration」から確認でき、PowerShell では Get-ADSyncEntraConnectorCredential により ServiceAccount または Application の値を確認できます。(Microsoft Learn)
Get-ADSyncEntraConnectorCredentialConnectorIdentityType が ServiceAccount の場合は、まだ従来のユーザー名・パスワード型の認証を使っています。Application の場合は、アプリケーション ID 認証へ移行済みです。
影響範囲は Microsoft Entra Connect Sync を使うハイブリッド ID 環境
今回の内容は、主に Microsoft Entra Connect Sync を使ってオンプレミス Active Directory から Microsoft Entra ID へ ID 同期している環境が対象です。Microsoft Entra ID 全体のサインイン方式を一律に変えるものではなく、Microsoft Entra Connect Sync が Microsoft Entra ID へ接続する際の認証方式を安全な形にする変更です。
特に影響を受けやすいのは、次のような環境です。
| 環境 | 影響・確認ポイント |
|---|---|
| 既存の Microsoft Entra Connect Sync 環境 | 認証方式が ServiceAccount のままか、Application に移行済みかを確認する |
| 自動アップグレードを有効にしている環境 | バージョン 2.5.76.0 以降で自動的にアプリケーション認証が構成される可能性がある |
| ステージング サーバーを持つ環境 | 本番・待機系で同じコネクタ アカウントや同じアプリ登録を共有していないか確認する |
| 証明書管理を社内 PKI で統制している環境 | BYOC または BYOA を選ぶ場合、証明書作成・権限付与・ローテーション手順を運用に組み込む |
| 旧バージョンを長く使っている環境 | Microsoft Entra 管理センターから入手できる新しいバージョンへの更新計画を立てる |
Microsoft Learn では、バージョン 2.5.76.0 以降の場合、サービスがユーザー名とパスワードで認証していると、6時間以内にアプリケーション認証を自動構成すると説明されています。(Microsoft Learn)
バージョン要件と更新経路を確認する
アプリケーション ID 認証を扱う前に、Microsoft Entra Connect Sync の更新経路も確認しておく必要があります。公式ドキュメントでは、新しい Microsoft Entra Connect Sync バージョンは Microsoft Entra 管理センター経由で提供され、Microsoft Download Center にはリリースされないと説明されています。(Microsoft Learn)
主な要件は次のとおりです。
| 目的 | 必要なバージョン・条件 |
|---|---|
| 手動オンボード | Microsoft Entra Connect 2.5.3.0 以降 |
| 自動オンボード | Microsoft Entra Connect 2.5.76.0 以降 |
| BYOA の手順実行 | Microsoft Entra Connect Sync 2.5.76.0 以降 |
| 管理者ロール | 少なくとも Hybrid Identity Administrator ロール |
| 推奨セキュリティ要件 | TPM 2.0 の利用を強く推奨 |
また、Microsoft Entra Connect のバージョン履歴では、2026年9月30日までに少なくとも 2.5.79.0 へアップグレードしていない場合、Microsoft Entra Connect Sync の同期サービスが動作しなくなると案内されています。これはアプリケーション ID 認証そのものだけでなく、ハイブリッド ID 基盤全体の継続運用に関わるため、同時に確認すべき重要項目です。(Microsoft Learn)
3つの管理方式をどう選ぶか
Microsoft Entra Connect のアプリケーション ID 認証では、アプリケーションと証明書の管理方法として大きく3つの選択肢があります。結論から言えば、多くの環境では既定の「Microsoft Entra Connect によって管理」を優先するのが現実的です。証明書の作成、ローテーション、削除を Microsoft Entra Connect 側に任せられるため、運用ミスを減らしやすいからです。(Microsoft Learn)
| 方式 | 管理するもの | 向いている環境 | 注意点 |
|---|---|---|---|
| Microsoft Entra Connect によって管理 | アプリケーションと証明書を Microsoft Entra Connect が管理 | 標準構成、証明書運用をシンプルにしたい環境 | スケジューラ停止中は自動ローテーションできない |
| BYOC | アプリは既定、証明書は管理者が用意 | 社内 PKI、HSM、TPM を使って証明書ライフサイクルを統制したい環境 | 証明書の作成、秘密キー保護、ローテーション、削除を管理者が担う |
| BYOA | アプリケーション、アクセス許可、証明書を管理者が用意 | アプリ登録・権限付与を厳格に統制したい大規模環境 | Microsoft Graph PowerShell、アプリ権限、証明書権限の設計が必要 |
既定方式では、Microsoft Entra Connect は証明書を CURRENT_USER ストアに保存し、既定で 90 日間の証明書を生成します。証明書はスケジューラにより期限到来を確認され、自動的にローテーションされます。ただし、スケジューラが停止していると自動ローテーションは実行されません。(Microsoft Learn)
BYOC では、証明書は LOCAL_MACHINE ストアに保存する必要があり、管理者が証明書の作成、ローテーション、不要または期限切れ証明書の削除を担当します。Microsoft は、秘密キー保護のために TPM または HSM によるハードウェアベースのセキュリティ境界を推奨しています。(Microsoft Learn)
証明書管理で確認すべきポイント
アプリケーション ID 認証の成否は、証明書管理に大きく依存します。特に BYOC と BYOA を選ぶ場合は、証明書を「作成できた」だけでは不十分です。Microsoft Entra Connect Sync が秘密キーを使って署名できること、秘密キーが不要にエクスポート可能になっていないこと、ローテーション後に古い証明書が残り続けないことまで確認する必要があります。
BYOC と BYOA では、公式ドキュメント上で次の証明書要件が示されています。(Microsoft Learn)
| 項目 | 要件 |
|---|---|
| KeyUsage | DigitalSignature |
| KeyLength | 2048 |
| KeyAlgorithm | RSA |
| KeyHashAlgorithm | SHA256 |
| 保存場所 | LOCAL_MACHINE ストア |
| 秘密キー | エクスポート不可としてマーク |
| 秘密キーの利用権限 | Microsoft Entra Connect Sync アカウントに署名用アクセス許可を付与 |
| 推奨保護 | TPM または HSM |
実務上の失敗例として多いのは、証明書をローカル コンピューターではなくユーザー ストアに置いてしまう、秘密キーへのアクセス権を ADSync サービス アカウントに付与していない、.cer ではなく秘密キー付きファイルを誤って扱おうとする、といったケースです。
移行前に行うべき準備
移行は、同期基盤に関わる変更です。小さな設定変更に見えても、失敗するとユーザー、グループ、パスワード ハッシュ、パスワード ライトバックなどの同期に影響する可能性があります。作業前には、次の情報を記録しておくと切り戻しや原因調査がしやすくなります。
| 準備項目 | 記録する内容 |
|---|---|
| 現在の認証方式 | ConnectorIdentityType の値 |
| Microsoft Entra Connect バージョン | 導入済みビルド番号、アップグレード予定ビルド |
| 同期状態 | 直近の同期成功時刻、エラー有無 |
| スケジューラ状態 | SyncCycleEnabled が true か false か |
| アプリケーション ID | アプリケーション クライアント ID |
| 証明書情報 | thumbprint、SHA256 hash、有効期限、発行者 |
| 既存 DSA アカウント | UPN、権限、削除予定の有無 |
| ステージング構成 | 本番・待機系それぞれのサーバー名、機械識別子、アプリ登録 |
確認コマンドの例は次のとおりです。
Get-ADSyncEntraConnectorCredential
Get-ADSyncSchedulerBYOC や BYOA で証明書を扱う場合は、証明書の SHA256 ハッシュも確認します。PowerShell 7 と古い PowerShell ではハッシュ文字列化の書き方が異なるため、公式手順に沿って実行するのが安全です。(Microsoft Learn)
標準構成での移行手順
多くの環境では、既定の「Microsoft Entra Connect によって管理」を使う構成が最も扱いやすい選択肢です。証明書のライフサイクルを Microsoft Entra Connect に任せられるため、独自証明書の運用負荷を抑えられます。
標準的な流れは次のとおりです。
| 手順 | 作業内容 | 確認ポイント |
|---|---|---|
| 事前確認 | バージョン、同期状態、認証方式、スケジューラを確認 | ServiceAccount か Application かを把握 |
| バージョン更新 | 必要に応じて Microsoft Entra 管理センターから更新 | 2.5.76.0 以降なら自動構成の対象 |
| 自動構成を待つ | 条件を満たす場合、6時間以内にアプリケーション認証が構成される | 作業後に必ず確認 |
| 手動構成 | 自動構成されない場合、ウィザードで構成 | Additional tasks から実行 |
| 動作確認 | 同期、イベント ログ、アプリ登録、証明書期限を確認 | 認証エラーや証明書エラーがないか |
| レガシー整理 | 安定稼働後、不要な DSA アカウントを削除または権限縮小 | 削除前に同期成功を確認 |
手動で切り替える場合は、Microsoft Entra Connect ウィザードを起動し、「Additional tasks」から「Configure application-based authentication to Microsoft Entra ID」を選択します。BYOC または BYOA を使う場合は、ウィザードだけでなく PowerShell による構成が必要です。(Microsoft Learn)
BYOC を使う場合の注意点
BYOC は、証明書を組織側で管理したい場合の選択肢です。社内 PKI、HSM、TPM、証明書更新手順、監査要件が整っている組織では有効ですが、標準構成より運用責任は重くなります。
BYOC で特に重要なのは、証明書を LOCAL_MACHINE ストアに保存し、Microsoft Entra Connect Sync だけが秘密キーへアクセスできるようにすることです。公式手順では、証明書を Microsoft Entra アプリ登録へアップロードし、秘密キーへの読み取り権限を ADSync サービス アカウントへ付与したうえで、スケジューラを一時停止して証明書ローテーション コマンドを実行する流れが示されています。(Microsoft Learn)
作業中は、次の順序を崩さないことが重要です。
| 順序 | 作業 | 失敗しやすい点 |
|---|---|---|
| 1 | 証明書を作成する | 秘密キーがエクスポート可能になっている |
| 2 | .cer をエクスポートする | 秘密キー付きでエクスポートしようとする |
| 3 | Microsoft Entra アプリ登録へ証明書をアップロードする | 対象アプリを取り違える |
| 4 | SHA256 ハッシュを取得する | Thumbprint と SHA256 hash を混同する |
| 5 | ADSync サービス アカウントに秘密キー権限を付与する | 同期サービスが署名できず認証に失敗する |
| 6 | 同期スケジューラを停止する | 同期中に資格情報を切り替える |
| 7 | 証明書ローテーション コマンドを実行する | モジュール未読み込み、PowerShell バージョン差異で失敗する |
| 8 | 構成を確認する | 確認前に古い証明書や旧アカウントを削除してしまう |
| 9 | スケジューラを再開する | 再開忘れで同期が止まる |
証明書ローテーションでは、次のようなコマンドが使われます。
Set-ADSyncScheduler -SyncCycleEnabled $false
Import-Module -Name "C:\Program Files\Microsoft Azure AD Sync\Bin\ADSync"
Invoke-ADSyncApplicationCredentialRotation -CertificateSHA256Hash $certHash
Set-ADSyncScheduler -SyncCycleEnabled $truePowerShell 7 から ADSync モジュールを読み込む場合は、-UseWindowsPowerShell の利用が案内されています。(Microsoft Learn)
BYOA を使う場合はアプリ権限の設計が重要
BYOA は、アプリケーション登録そのものを管理者が用意する方式です。証明書だけでなく、アプリケーション、サービス プリンシパル、必要なアプリケーション権限も組織側で管理します。標準構成や BYOC より自由度は高い一方、設計ミスの影響も大きくなります。
公式手順では、Microsoft Graph PowerShell を使ってアプリケーションとサービス プリンシパルを作成し、Microsoft Entra AD Synchronization Service への ADSynchronization.ReadWrite.All など、必要なアプリ ロールを割り当てる流れが示されています。パスワード ライトバックを使う場合は、Microsoft password reset service 側の追加ロールも考慮します。(Microsoft Learn)
BYOA を選ぶ判断基準は次のとおりです。
| 判断項目 | BYOA を検討すべきケース |
|---|---|
| アプリ登録の命名・所有者管理 | 全社ルールに沿ってアプリ登録を統制したい |
| 権限レビュー | アプリ ロール割り当てを監査対象にしたい |
| 証明書ライフサイクル | 社内 PKI や HSM と連携した証明書更新が必須 |
| 複数環境管理 | 本番、検証、DR 環境でアプリを明確に分離したい |
| 自動化 | IaC や運用スクリプトで構成を標準化したい |
一方で、アプリケーション権限や証明書の更新を十分に運用できない場合、BYOA は過剰です。特別な統制要件がなければ、既定方式または BYOC を優先するほうが安全に運用しやすいでしょう。
証明書ローテーションの監視ポイント
Microsoft Entra Connect が管理する既定方式では、証明書の有効期限が近づくと自動ローテーションされます。ただし、自動だから放置してよいわけではありません。スケジューラが停止していると自動ローテーションは実行されず、期限切れによって同期が止まる可能性があります。(Microsoft Learn)
公式ドキュメントでは、証明書の有効期間の 70% 以上を消費すると警告が出ると説明されています。90日証明書の場合、目安として63日程度で警告が始まります。警告は Event ID 1011、期限切れエラーは Event ID 1012 として Application イベント ログに記録されます。(Microsoft Learn)
| イベント | 意味 | 管理者の対応 |
|---|---|---|
| Event ID 1011 | 証明書有効期間の 70% 以上を消費 | スケジューラ状態とローテーション予定を確認 |
| Event ID 1012 | 証明書が期限切れ | 速やかに証明書を更新し、同期復旧を確認 |
| Event ID 1014 | TPM が使われていない場合の警告 | BYOC/BYOA では TPM/HSM 利用を再検討 |
| old credential 削除失敗 | 古い証明書資格情報の削除に失敗 | Remove-EntraApplicationKey による整理を検討 |
既定方式で Microsoft Entra Connect が証明書を管理している場合でも、古い証明書資格情報の削除に失敗するとイベント ログにエラーが出ます。その場合は、対象の CertificateId を確認し、PowerShell で古いキーを削除する手順が案内されています。(Microsoft Learn)
Remove-EntraApplicationKey -CertificateId <certificateId>移行後はレガシー サービス アカウントを整理する
アプリケーション ID 認証へ移行し、Microsoft Entra Connect Sync が期待どおり動作していることを確認したら、従来の DSA ユーザー名・パスワード サービス アカウントを整理します。公式ドキュメントでは、移行後にレガシー DSA サービス アカウントを PowerShell で削除することが強く推奨されています。カスタム アカウントなど削除できない場合は、権限を下げて DSA ロールを外します。(Microsoft Learn)
$HACredential = Get-Credential
Remove-ADSyncAADServiceAccount -AADCredential $HACredential -Name <serviceAccountName>ここで注意したいのは、移行直後にいきなり削除しないことです。最低限、次の確認を終えてから整理してください。
| 確認項目 | 理由 |
|---|---|
ConnectorIdentityType が Application | アプリケーション ID 認証へ切り替わっていることを確認するため |
| 直近の同期が成功 | 認証だけでなく実同期が成功していることを確認するため |
| 証明書情報が正しい | 誤った証明書や期限切れ証明書で動いていないか確認するため |
| ステージング サーバーも確認済み | 待機系だけ旧資格情報に依存している可能性があるため |
| 切り戻し手順がある | 障害時に慌てて高権限アカウントを使わないため |
ロールと権限管理で見落としやすい点
アプリケーション ID 認証では、アプリケーション管理者ロールの扱いにも注意が必要です。公式ドキュメントでは、Application Administrator ロールはアプリケーション資格情報を管理でき、Connect Sync などのアプリケーションに資格情報を追加して、そのアプリケーション ID を偽装できる可能性があると説明されています。(Microsoft Learn)
つまり、同期基盤の保護は Microsoft Entra Connect サーバーだけの話ではありません。Microsoft Entra ID 側で、アプリ登録を管理できるユーザー、証明書を追加できるユーザー、アプリケーション権限へ同意できるユーザーも見直す必要があります。
実務では、次のように整理すると判断しやすくなります。
| 対象 | 見直す内容 |
|---|---|
| Application Administrator | 常設付与を避け、必要時のみの昇格にできないか |
| Hybrid Identity Administrator | Microsoft Entra Connect 管理担当者に限定されているか |
| Global Administrator | 通常作業で使っていないか |
| アプリ登録の所有者 | 退職者・異動者が残っていないか |
| 証明書管理者 | 秘密キー、証明書更新、削除の責任者が明確か |
特に避けたいのは、同期用のコネクタ アカウントに Global Administrator を使うことです。トラブルシューティング資料でも、Microsoft Entra Connect サーバーが侵害された場合にテナント全体のリスクになるため、Microsoft Entra Connector アカウントとして Global Administrator を使わないよう警告されています。(Microsoft Learn)
複数サーバー・ステージング構成での注意点
本番サーバーとステージング サーバーを持つ環境では、特に慎重な確認が必要です。アプリケーション ベースの認証は、1台の Microsoft Entra Connect インスタンスにつき一意のアプリケーション ID を使う前提です。複数サーバーが同じカスタム Microsoft Entra Connector アカウントを共有していると、同じアプリ登録やサービス プリンシパルを使ってしまい、片方の証明書更新がもう一方の認証を壊す可能性があります。(Microsoft Learn)
また、Microsoft Entra Connect が入ったサーバーをクローンして別の本番サーバーにする運用も危険です。トラブルシューティング資料では、クローンにより同じ machine identifier を共有し、サーバー ID が衝突する問題が説明されています。(Microsoft Learn)
複数サーバー環境では、次の観点で確認してください。
| 確認項目 | 推奨対応 |
|---|---|
| 本番・ステージングで同じコネクタ アカウントを使っていないか | サーバーごとに一意のアプリケーション ID を持たせる |
| アプリ登録が1つしかないのにサーバーが複数ないか | ConnectSyncProvisioning_<Servername>_<SyncMachineIdentifier> のようにサーバー単位で分離されているか確認 |
| クローン展開していないか | machine identifier の重複を確認 |
| 証明書ローテーション後に片系が失敗していないか | Application イベント ログと同期状態を両方確認 |
| 障害系の復旧手順があるか | 作業順序を本番・ステージング別に文書化する |
この問題が発生すると、AADSTS700027 や「certificate with identifier used to sign the client assertion is not registered on application」といった証明書不一致エラーが出ることがあります。(Microsoft Learn)
古い Synchronization Service Manager UI の操作に注意
アプリケーション ID 認証へ移行した後、古いバージョンや特定の状態では Synchronization Service Manager UI の操作が問題を起こすことがあります。トラブルシューティング資料では、自動アップグレード後に ABA が有効になった環境で、Synchronization Service Manager の Microsoft Entra コネクタ プロパティを開いて OK を押すだけでも、必要な ABA パラメーターが消える可能性があると説明されています。(Microsoft Learn)
この問題が起きると、現在の証明書が有効な間は同期が続くことがありますが、自動証明書ロールオーバーが失敗し、次回更新時に同期が中断するリスクがあります。Microsoft は、ABA が有効な場合、Microsoft Entra Connect ウィザードまたは文書化された PowerShell コマンドを使って構成変更するよう案内しています。(Microsoft Learn)
バージョン履歴では、2.5.76.0 や 2.5.190.0 に対して Synchronization Service Manager UI を使わない注意が記載され、2.6.1.0 ではこの問題が修正されたと説明されています。(Microsoft Learn)
管理者がすぐ実施すべきチェックリスト
Microsoft Entra のアプリケーション ID 認証に関して、管理者が優先して確認すべき項目を実務向けに整理すると次のとおりです。
| 優先度 | チェック項目 | 対応 |
|---|---|---|
| 高 | Microsoft Entra Connect のバージョン | 2.5.76.0 以降か、さらに最新更新が必要か確認 |
| 高 | 現在の認証方式 | Get-ADSyncEntraConnectorCredential で Application か確認 |
| 高 | 同期スケジューラ | 停止中でないか確認。停止中なら自動ローテーション不可 |
| 高 | 証明書期限 | 70% 警告、期限切れ、イベント ログを監視 |
| 高 | レガシー DSA アカウント | 移行後に削除または権限縮小 |
| 中 | Application Administrator | アプリ資格情報を追加できるユーザーを見直す |
| 中 | ステージング サーバー | サーバーごとに一意のアプリケーション ID か確認 |
| 中 | BYOC/BYOA 証明書 | LOCAL_MACHINE、秘密キー権限、非エクスポートを確認 |
| 中 | 古い UI 操作 | Synchronization Service Manager でコネクタ設定を編集しない |
| 低 | 手順書 | 証明書更新、切り戻し、監査ログ確認を運用手順に反映 |
開発者・ID基盤担当者が確認すべきポイント
開発者や ID 基盤の自動化担当者は、単に PowerShell コマンドを実行するだけでなく、アプリ登録と権限の設計を確認する必要があります。特に BYOA を使う場合、Microsoft Graph PowerShell でアプリケーションとサービス プリンシパルを作成し、必要なアプリ ロールを割り当てます。パスワード ライトバックを有効にしている場合は、追加の Password Reset Service 関連ロールも必要です。(Microsoft Learn)
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| アプリ登録名 | サーバー名、環境名、本番・検証の区別が分かる命名か |
| 所有者 | 個人依存ではなく、管理グループや運用チームで管理できるか |
| アプリ権限 | 必要なアプリ ロールだけが付与されているか |
| 証明書更新 | 更新手順が自動化または定期運用に組み込まれているか |
| 監査 | アプリ資格情報追加、権限同意、証明書更新を追跡できるか |
| 障害復旧 | 証明書期限切れ、秘密キー権限不足、アプリ削除時の復旧手順があるか |
独自スクリプトで Microsoft Entra Connect の内部構成を直接変更するのは避けるべきです。公式トラブルシューティングでも、構成変更には Microsoft Entra Connect ウィザードまたは文書化された PowerShell コマンドを使うよう案内されています。(Microsoft Learn)
よくある疑問
エンドユーザーにすぐ影響はありますか
通常、変更の中心は Microsoft Entra Connect Sync サーバーが Microsoft Entra ID へ認証する方式です。そのため、ユーザーのサインイン画面が直接変わるものではありません。ただし、認証方式の切り替えや証明書ローテーションに失敗して同期が止まると、ユーザー属性、グループ、パスワード関連の反映遅延や停止につながる可能性があります。
既定方式と BYOC はどちらを選ぶべきですか
特別な証明書統制要件がなければ、既定方式が第一候補です。Microsoft Entra Connect が証明書の作成、ローテーション、削除を管理するため、運用負荷を抑えられます。社内 PKI、HSM、証明書棚卸し、鍵管理ポリシーが明確にある場合は BYOC を検討します。
BYOA はどのような組織向けですか
BYOA は、アプリ登録とサービス プリンシパルを組織側で完全に管理したい環境向けです。大規模組織、厳格な監査要件、IaC によるアプリ登録管理、環境別の権限分離が必要な場合に向いています。反対に、証明書更新やアプリ権限管理を継続的に運用できない場合は避けたほうが安全です。
移行後にレガシー DSA アカウントはすぐ消してよいですか
同期成功、認証方式、証明書情報、ステージング サーバーの状態を確認してから削除してください。公式ドキュメントでは、アプリケーション ベースの認証へ移行し、Microsoft Entra Connect Sync が期待どおり動作していることを確認した後に、レガシー DSA サービス アカウントを削除することが推奨されています。(Microsoft Learn)
問題が出た場合は従来方式へ戻せますか
公式手順では、PowerShell を使ってレガシー サービス アカウントへロールバックする方法が示されています。ただし、ロールバック時には DSA アカウントが再作成され、反映まで最大 15 分かかる場合があるため、作業前にスケジューラを停止し、手順と影響を確認してから実施する必要があります。(Microsoft Learn)
失敗を避けるための実務ポイント
今回の Microsoft Entra Connect のアプリケーション ID 認証は、単なる認証方式の置き換えではありません。実務では、証明書ローテーション、アプリ登録、ロール管理、複数サーバー構成、古い UI 操作の影響まで含めて見直す必要があります。
まず実施すべきことは、次の3つです。
Get-ADSyncEntraConnectorCredentialで現在の認証方式を確認する。- Microsoft Entra Connect のバージョンと 2026年9月30日までのアップグレード要件を確認する。
- 証明書期限、同期スケジューラ、レガシー DSA アカウント、ステージング サーバーの構成を棚卸しする。
そのうえで、標準構成なら Microsoft Entra Connect 管理の証明書ローテーションが正しく動く状態を維持し、BYOC や BYOA を選ぶなら証明書ライフサイクルとアプリ権限管理を運用手順に落とし込んでください。Microsoft Entra のセキュリティ更新は「適用して終わり」ではなく、同期が止まらないこと、不要な資格情報が残らないこと、証明書更新を継続できることまで確認して初めて完了です。
コメント