【Microsoft Entra】Entra IDのユーザーをオンプレミスのSQLへ ―検証で分かった3つの挙動

1. はじめに

社員が入社するたびに、業務システムのデータベースへアカウントを1件ずつ登録する。異動や退職のたびに、同じ画面を開いて直す。人事システムと切り離して運用されている業務システムほど、こうした手作業が残りがちです。

Microsoft Entra ID（以下、Entra ID）には、SQLデータベース上のアカウント情報を自動で作成・更新・削除する仕組みが用意されています。SQLへのプロビジョニングと呼ばれる機能です。

取り扱う内容は、この機能の仕組みと前提条件、そして弊社で実際に検証して分かった挙動です。とくに、グループを割り当てたときにデータベース側で何が起きるかは、公式ドキュメントだけでは読み取りにくい部分でした。手順を1つずつ解説するのではなく、導入を検討する段階で押さえておきたい判断材料をまとめます。

2. SQLへのプロビジョニングの仕組み

2-1. どんな機能か（Cloud Syncとの向きの違い）

SQLへのプロビジョニングとは、Entra IDから、オンプレまたはクラウド上のリレーショナルデータベースに依存するアプリケーションに対して、ユーザーのアカウント情報を自動的に作成・更新・削除する仕組みです。

最初に押さえたいのは、同期の向きです。Microsoft Entra Connect（以下、Entra Connect）やMicrosoft Entra Cloud Sync（以下、Cloud Sync）は、Active Directory（以下、AD）からEntra IDへアカウント情報を送ります。今回の機能は逆向きで、Entra IDから業務システムのデータベースへ送ります。

2-2. 登場人物は3つ

この連携を構成する要素は、次の3つです。

• Microsoft Entra プロビジョニング サービス：クラウド側の同期エンジンです。誰を、いつ、どの属性で送るかを判断します。
• プロビジョニング エージェント：オンプレサーバーに導入し、クラウドとの通信を仲介します。
• ECMA（Extensible Connectivity Management Agent）コネクタホストと汎用SQLコネクタ：SCIM（System for Cross-domain Identity Management）の要求を、ODBC（Open Database Connectivity）経由のSQL操作へ変換します。（補足：SCIMはID情報の連携に使う業界標準の仕様、ODBCは種類の異なるデータベースに同じ手順で接続するための標準インターフェイスです。）

公式のアーキテクチャの解説にあるとおり、通信はオンプレ側からクラウドへの送信接続だけで成立するため、受信ポートの開放やDMZ（境界ネットワーク）の用意は必要ありません。

ユーザーが登録されるまでの流れは、照合用の属性で対象がすでに存在するかを確認し、なければ行を追加し、その行を識別する値（アンカー）が記録される、という順序です。2回目以降の更新は、照合用の属性ではなくアンカーで対象を特定します。そのため、アンカーに指定した列を更新しない属性をマッピングしている場合に限り、ユーザープリンシパル名（以下、UPN）を変更しても、行との対応づけは保たれます。

2-3. 設計で最初に決める4つのこと

構成作業に入る前に、次の4点を決めておきます。あとから変えると、既存レコードとの対応づけが崩れる項目です。

• アンカー属性：各レコードを一意に識別する列です。値が一意であることと、途中で変更されないことが条件になります。
  • すでにユーザーが登録されているデータベースでは、objectIdやUPNなど、Entra ID側とデータベース側の双方に同じ値が入っている列を選びます。ここが一致しないと、既存行の更新ではなく新規行の追加になります。
• DN属性：オブジェクトを指し示す識別名です。SQLのテーブルはADのような階層構造を持たないため、アンカー値から自動生成させる設定が基本になります。（補足：識別名とは、ディレクトリ内でそのオブジェクトを一意に指し示す文字列です。）
• 属性マッピング：Entra ID側の属性と、テーブルの列との対応づけです。
• 照合用の属性：初回に既存の行を探すために使う属性です。属性マッピングの画面で、列との対応づけとは別に指定します。2回目以降はアンカーで特定するため、使われるのは初回だけです。

公式チュートリアルのサンプルデータベースを例にすると、対応づけは次のようになります。「必須」欄が○の列は、テーブル側でNOT NULL制約が付いている列です。値が入らないとその行自体を追加できないため、自社のテーブルに当てはめる際は、まず必須の列を洗い出し、そのすべてにEntra ID側の属性を割り当てられるかをご確認ください。

Entra ID側の属性	テーブルの列	用途	必須
userPrincipalName	ContosoLogin	ログイン名（アンカーに指定）	－
objectId	AzureID	Entra ID側のオブジェクトID	－
mail	Email	メールアドレス	－
givenName	FirstName	名	○
surname	LastName	姓	○
mailNickname	textID	メールニックネーム	－

なお、この例はUPNをアンカーの列（ContosoLogin）にマッピングしているため、UPNを変更すると、2-2節で述べた「対応づけが保たれない」ケースにあたります。UPNが変わりうる環境では、objectIdなど変更されない値をアンカーに選んでください。

（補足：管理センターの画面では、テーブルの列は "urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:ContosoLogin" のように、長い接頭辞付きで表示されます。末尾が列名にあたります。）

3. 前提条件と構成の流れ

導入前に確認する条件を、オンプレ側とクラウド側に分けて整理します。サーバー要件とライセンスは後から変更しにくいため、この2点を先にご確認ください。

オンプレ側の要件

項目	条件
OS	Windows Server 2016以降
メモリ・.NET	4GB以上のRAM（SQLコネクタのページの記載は3GB）、.NET Framework 4.7.2
ドライバー	対象データベースに対応したODBCドライバー
ネットワーク	対象データベースへの接続と、login.microsoftonline.comおよびAzureドメインへの送信接続

※ Windows Server 2016の延長サポートは2027年1月12日に終了します（Microsoftのライフサイクル情報）。新規に構築する場合は2019以降、できれば2022または2025を選んでください。

クラウド側の要件

項目	条件
ライセンス	Microsoft Entra ID P1またはP2（EMS E3またはE5でも可）
ロール	エージェントの構成にはハイブリッドID管理者、ポータルでの構成にはアプリケーション管理者またはクラウドアプリケーション管理者

公式ドキュメントに挙げられている対応データベースは次のとおりです。

• Microsoft SQL Server および Azure SQL
• IBM DB2（9.x、10.x、11.5）
• Oracle（10g、11g、12c、18c）
• MySQL（5.x、8.x）
• PostgreSQL

構成作業は、おおむね次の順に進みます。

1. ODBCドライバーを導入し、接続用のファイルDSNを作成します。
2. Microsoft Entra管理センターで「オンプレミスのECMAアプリ」を追加します。
3. プロビジョニングエージェントをオンプレサーバーに導入します。
4. ECMAコネクタホストの構成ウィザードで、証明書とシークレットトークンを設定します。
5. 汎用SQLコネクタを作成し、スキーマ検出でアンカー属性とDN属性を指定します。
6. 管理センター側でテナントURLとトークンを入力し、「接続のテスト」を実行します。
7. 属性マッピングを設定し、対象のユーザーまたはグループを割り当てます。
8. 対象ユーザーを1人だけ指定してオンデマンドプロビジョニングで試し、結果を確認します。

この作業中に、一度足を止められた箇所がありました。ODBCドライバーの接続暗号化に関する公式ドキュメントにあるとおり、ODBC Driver 18では接続の暗号化が既定で有効になっているため、SQL Server側が自己署名証明書のままだと、データソースのテストが証明書エラーで失敗します。

「信頼されていない機関によって証明書チェーンが発行されました」と表示され、テストが失敗する

検証環境では、暗号化の設定画面で「サーバー証明書を信頼する」にチェックを入れて回避しました。この状態でテストが成功すれば、DSNの作成は完了です。

「サーバー証明書を信頼する」にチェックを入れる

各手順の画面ごとの操作は、汎用SQLコネクタの構成手順を解説した公式ドキュメントに譲り、この流れの中でつまずきやすい箇所は第6章にまとめます。

4. 基本動作の検証（新規・更新・削除・無効化）

ここからは、実際に動かして確認した結果です。この記事の検証は、2026年8月から9月にかけて、SQL Server 2022 Standard で、公式チュートリアルと同じ構成のEmployeesテーブルを対象に行っています。まずは基本となる4パターンです。

操作	期待した結果	実際の結果
ユーザーの新規割り当て	テーブルに行が追加される	追加された
属性の更新	姓名の変更がテーブルに反映される	反映された
ユーザーの削除	該当する行が削除される	プロビジョニング解除を「削除」に設定した状態で、行が削除された
必須の列に値がないユーザー	エラーとなり、プロビジョニングされない	NOT NULL制約の列が空のためエラーとなり、そのユーザーはプロビジョニングされなかった

必須の列に値がないユーザーでは、ODBCドライバーから返されたメッセージがそのままプロビジョニングログに記録されます。どの列で止まったのかは、この記録から読み取れます。

NOT NULL制約の列に値がないと、INSERTが失敗した旨がそのまま記録される

あわせて、ユーザーアカウントを無効化した場合も確認しました。想定では、エラーが出てプロビジョニングされない状態になると考えていましたが、オンデマンドプロビジョニングで実行したところ、エラーは出ずSuccessとなり、通常どおり処理されました。そして、無効化したユーザーの行は、テーブルから消えていました。

これはプロビジョニング解除の設定によるものです。プロビジョニングのしくみを解説した公式ドキュメントでは、アプリから割り当てを解除された場合、Entra IDで論理的に削除された場合、そしてサインインがブロックされた場合に、この動作が働くと説明されています。

5. 検証して分かった、押さえておきたい3つの挙動

ここからが本題です。基本動作の裏側で、想定と違った挙動が3つありました。

なお、NOT NULL制約の挙動は第4章で確認できたため、以降の検証は、制約によるエラーと切り分けるために、EmployeesテーブルのFirstNameとLastNameをNULL許容に変更したうえで実施しています。テストユーザーには姓名を設定しているため、結果は制約の有無に左右されません。

5-1. グループを割り当てても「グループ」はテーブルに作られない

Entra IDでは、アプリケーションへの割り当てをユーザー単位でもグループ単位でも行えます。では、グループを割り当てるとデータベース側には何が入るのでしょうか。割り当て方の違いが分かるように、3人のユーザーと1つのグループを次のように用意しました。

ユーザー	アプリケーションへの割り当て方
ユーザー側インポート	ユーザー単体で割り当て
グループ内メンバー側インポート	グループのメンバーのみ
ユーザー兼グループメンバー	グループのメンバーで、かつユーザー単体でも割り当て

（補足：グループ「Group検証01」には、下の2人がメンバーとして所属しています。）

① オンデマンドプロビジョニングでは判断できない

はじめに、オンデマンドプロビジョニングでグループを指定しました。「1. group のインポート」は成功するものの、「2. group がスコープ内かどうかを確認する」がSkippedとなります。詳細には Group '<グループ名>' will be skipped. EntityTypeNotSupported と表示されます。

オンデマンドでグループを指定すると、スコープの確認でスキップされる

このとき、グループのメンバーであるユーザーもテーブルに追加されませんでした。ただし画面に出るのは Skipped だけで、エラーとしては扱われません。処理が成功したのか失敗したのかを、この画面から判断することはできません。

② 通常のプロビジョニングサイクルで確認する

そこで、スケジュールされた通常のプロビジョニングサイクルの実行を待ち、プロビジョニングログを確認しました。

グループはSkipped、3人のユーザーはいずれもCreateがSuccessになる

グループオブジェクト自体はSkippedのままです。しかし3人のユーザーは、いずれもCreateがSuccessになりました。グループのメンバーであるだけのユーザーも、この段階で処理されています。テーブルを確認すると、3件とも追加されていました。

3人のユーザーが追加されている。グループに対応する行はない

グループそのものに対応する行は作られていません。理由は、オンプレアプリケーションへのプロビジョニングでは、グループがサポートの対象に含まれていないためです。第3章の構成の流れで触れたスキーマ検出でも、扱うのはユーザーのオブジェクトであり、グループはプロビジョニングの対象になりません。

5-2. グループを外したときの挙動は割り当て方で決まる

組織変更にともなってグループを整理する場面は、運用のなかでたびたび発生します。では、アプリケーションに割り当てたグループを外すと、データベースの行はどうなるのでしょうか。5-1と同じ状態から、グループの割り当てだけを解除して確認しました。

なお以降は、第4章と同じく、プロビジョニング解除を「削除」に設定した状態での結果です。

次のプロビジョニングサイクルのログを見ると、処理されたのは1件だけでした。グループのメンバーであるだけだったユーザーに対して、Disableが実行されています。

グループ経由でのみ割り当てられていたユーザーだけが処理される

テーブルを確認すると、3件あった行が2件に減っていました。消えたのは、グループのメンバーであるだけだったユーザーの行です。

残ったのは、ユーザー単体でも割り当てられている2人

割り当て方	グループ解除後に実行された処理	テーブルの行
ユーザー単体で割り当て	なし	残る
グループのメンバーのみ	Disable	削除された
グループのメンバー＋ユーザー単体でも割り当て	なし	残る

この違いは、割り当てがユーザー単位で評価されることから生まれます。グループは、メンバーをスコープに入れるための経路の1つにすぎません。別の経路として個別割り当てが残っていればスコープ内のままですが、経路が1つしかなければスコープから外れ、第4章で触れたプロビジョニング解除がそのまま動きます。

5-3. マルチバリュー属性は、値の数にかかわらず扱えない

Entra IDのユーザーには、1つの属性に複数の値を持てるものがあります。「その他のメール」やproxyAddressesが代表例です。5-1でも触れた既知の問題をまとめた公式ページには、オンプレアプリケーションへのプロビジョニングでサポートされない対象として、複数値属性と、managerのような参照属性が明記されています。

では、サポートされないことは実際にどう現れるのでしょうか。proxyAddressesを列にマッピングし、実行方法と設定を変えながら確認しました。

列にマッピングすると、ほとんどの組み合わせで失敗する

proxyAddresses を列にマッピングして実行しました。結果は、実行方法、proxyAddressesの値の数、複数値として扱う設定の3つで決まりました。

まず、スケジュールされた通常のプロビジョニングサイクルでは、どの組み合わせでも失敗します。値が1件であっても、複数値として扱う設定をオフにしていても、proxyAddresses を列にマッピングしている限りプロビジョニングは通りませんでした。

成功したのは、オンデマンドプロビジョニングの1つの組み合わせだけです。複数値として扱わない設定にしたうえで、値が1件までのユーザーを対象にした場合に限り、「4. ScimOnPremises で User をプロビジョニングする」まで到達しました。

唯一成功した組み合わせ。オンデマンドプロビジョニングで、複数値として扱わない設定、値は1件まで

それ以外はすべて失敗しました。失敗するステップは、条件によって変わります。

実行方法	proxyAddressesの値	複数値として扱う設定	結果
通常のプロビジョニングサイクル	1件以上	オン・オフのいずれも	失敗
オンデマンドプロビジョニング	1件まで	オフ	成功
	1件まで	オン	ステップ4「プロビジョニングする」で失敗
	2件以上	オフ	ステップ3「一致させる」で失敗
	2件以上	オン	ステップ3「一致させる」で失敗

以降はオンデマンドプロビジョニングでの結果です。値が2件以上の場合は、複数値として扱う設定のオン・オフにかかわらず、ステップ3で SystemForCrossDomainIdentityManagementServerError が記録され、ErrorMessage に "Could not map some attributes to the resource"（MappingException、HTTP 500）が出ます。

値が2件以上：設定にかかわらずステップ3「一致させる」で失敗する

一方、値が1件までであっても、複数値として扱う設定にすると、ステップ3までは進んだうえでステップ4で止まります。

値が1件でも、複数値として扱う設定ではステップ4「プロビジョニングする」で失敗する

複数の値を業務システム側で扱いたい場合は、次のいずれかを検討することになります。

• 式を使って、複数の値から1件だけを取り出してマッピングする
• Entra ID側で単一値の属性に寄せ、その属性をマッピングする
• データベース側で別テーブルに分け、この機能の対象外として運用する

なお、参照属性については今回検証していませんが、前述の既知の問題のページで、managerのような参照属性もサポート対象外とされています。上長情報など組織階層を業務システムに持たせたい場合は、この機能とは別の手段を用意してください。

6. 検証から導く設計・運用の勘所

ここまでの結果を踏まえて、導入前に決めておきたいことと、運用に入ってから効いてくることを整理します。

先に決めておきたいのは、次の4点です。

• 割り当てのルール：グループ経由と個別割り当てのどちらを基本にするかを決めます。
  • グループだけで運用する場合、そのグループを整理した時点で対象者がスコープから外れます。そのとき行が消えるかどうかはプロビジョニング解除の設定で決まるため、割り当てのルールとあわせて解除の設定も確認してください。
• 退職・異動時の扱い：プロビジョニング解除の設定を、人事の運用フローと突き合わせます。
  • アカウントの無効化も解除の引き金になるため、「まず無効化して様子を見る」という運用では業務システムの行が消えます。履歴を残したい場合は、データベース側で履歴用のテーブルを分ける設計が要ります。
• 属性の棚卸し：テーブルの必須列に対応する値が、対象ユーザー全員のEntra ID側に入っているかを確認します。
  1人でも値が欠けていると、そのユーザーだけプロビジョニングに失敗します。複数値属性と参照属性は使えないため、必要な情報は単一値の属性に寄せておきます。
• 操作方法の選択：テーブルを直接読み書きする方式（テーブル方式）と、あらかじめ用意したストアドプロシージャを呼び出す方式のどちらかを選びます。
  まずはテーブル方式で構いません。SQLは自動生成されます。ユーザーごとに追加の処理が必要な場合や、大量データのページングが必要な場合に、ストアドプロシージャ方式を検討します。この4点目だけは、他の3点と違って運用を始めてから見直しやすい項目です。

構成作業でつまずきやすい箇所も、あわせて挙げておきます。

症状	原因	対処
接続のテストが失敗する	エージェントの登録が完了していない	登録には10〜20分かかります。まずMicrosoft Entra Connect プロビジョニング エージェントを再起動します（ECMA2HostもRunningであることを確認します）
テナントURLが通らない	コネクタ名の表記が一致していない	大文字と小文字が区別されます。ウィザードで指定した名前と同じ表記にします
NULLを挿入できないというエラーが出る	必須列にEntra ID側の値がない	属性マッピングと、対象ユーザーの属性値を確認します

このほかの症状と対処は、トラブルシューティングの公式ドキュメントにまとめられています。

運用に入ったあとで効いてくるのは、証明書とエージェントの2点です。ECMAコネクタホストの構成時に生成される自己署名証明書には有効期限があり、切れると通信できなくなります。期限を記録しておき、切れる前に生成し直す運用が必要です。本番環境では、信頼された証明機関が発行した証明書を使ってください。

プロビジョニングエージェントは、オンプレアプリへのプロビジョニングでは自動更新の対象外です（2026年9月時点）。サポートを受けるには最新の更新を適用しておく必要があるため、更新は手動で行います。公式のバージョンリリース履歴で定期的にバージョンを確認する運用を、導入時にあわせて決めておくと安心です。

7. まとめ

弊社では、ID管理に関する他の記事も公開しています。
ご興味のある方は、ぜひこちらもあわせてご覧ください！

※このブログで参照されている、Microsoft、Microsoft Entra、Microsoft Entra ID、Microsoft Entra Connect、Microsoft Entra Cloud Sync、Active Directory、Microsoft SQL Server、Azure、Windows Server、.NET は、米国Microsoft Corporationの米国およびその他の国における商標または登録商標です。