【Microsoft Entra】オンプレミスLDAPディレクトリへの自動プロビジョニング入門 ― AD LDS連携を例に

この記事のポイント

「Microsoft Entra ID（旧Azure AD）でユーザーを一元管理したい。でも社内には、今もLDAPでユーザー情報を引きにいく“昔ながらのアプリ”が残っている」——そんな環境は少なくありません。Active Directory ドメインサービス（AD DS）とEntra IDの同期はよく知られていますが、AD DS以外のLDAPディレクトリ（AD LDSやOpenLDAPなど）へEntra側からユーザーを流し込む方法は、意外と情報がまとまっていません。

本記事では、Microsoftが提供するオンプレミスアプリケーション プロビジョニングの仕組みを使い、Entra IDからLDAPディレクトリ（例としてAD LDS）へユーザーを自動プロビジョニングする構成を、公式ドキュメントをもとに整理します。実際に手を動かす前の“全体像の地図”としてお読みください。

01この構成で実現できること

このソリューションの目的は、Entra IDに割り当てたユーザーを、オンプレミスのLDAPディレクトリへ自動で反映し続けることです。Entra側でアプリにユーザーを割り当てる・割り当てを外すといった変化が起きるたびに、ディレクトリ側のオブジェクトが追加・更新・削除されます。

たとえば次のような場面で役立ちます。

02全体アーキテクチャ ― 4つの登場人物

仕組みを理解するうえで、登場人物を整理しておくと迷いません。クラウドからオンプレミスへ、次の順でユーザー情報が流れていきます。

つまり、「Entra（司令塔）→ エージェント → ECMA2Host → 汎用LDAPコネクタ → LDAPディレクトリ」という一本の経路でユーザー情報が運ばれる、と捉えると全体像がすっきりします。

03前提条件 ― オンプレミスとクラウド

オンプレミス側

クラウド側

04対応するLDAPサーバーと重要な制限事項

汎用LDAPコネクタは、ルートDSEやベンダー名・バージョン、スキーマを調べてLDAPサーバーを識別します。代表的な対応サーバーは次のとおりです（一部抜粋）。

導入前に必ず押さえておきたいのが、「この仕組みでは“できない”こと」です。ここを理解しておくと、設計段階での手戻りを防げます。

053つの実行プロファイル

コネクタがディレクトリとどうやり取りするかは、実行プロファイルで決まります。3種類あり、それぞれ役割が異なります。

構成ウィザードでは、最低限「エクスポート」と「フル インポート」の両方を有効にします。差分インポートは、ディレクトリ側が要件（例：OpenLDAPならアクセスログオーバーレイの有効化）を満たす場合にのみ使います。

06構成の流れ ― 5つのステップ

実際の構成は、大きく次の5ステップで進みます。各ステップの“勘どころ”をまとめました。

07属性マッピングのポイント

接続テストが通ったら、Entraユーザーの属性とディレクトリの属性を対応づけます。LDAP特有の“押さえどころ”がいくつかあります。

① 識別名（DN）の組み立て

ディレクトリ内の各ユーザーには一意の識別名（DN）が必要です。式マッピングでDNを組み立てます。AD LDSへプロビジョニングする例では、次のような式を-dn-ターゲット属性に割り当てます（コンテナーのDNは自組織に合わせて変更します）。

Join("", "CN=", Word([userPrincipalName], 1, "@"), ",CN=CloudUsers,DC=*****,DC=local")

② objectClass / userPrincipalName / 無効フラグ

③ パスワードの扱い

AD LDS以外のディレクトリではuserPasswordへ初期ランダムパスワードを設定するマッピングを追加できますが、AD LDSにはuserPasswordのマッピングはありません。この点が次章の制限につながります。

08つまずきやすいポイント

実際に構成すると、いくつか“仕様を知らないと悩む”ポイントに行き当たります。代表的なものを挙げます。

AD LDSのパスワード問題

最大の注意点がこれです。現状、AD LDSへはパスワード付きでユーザーをプロビジョニングできません。一方で、AD LDSの既定のパスワードポリシーは「パスワードのないアカウントを有効化できない」ため、そのままだとアカウント有効化の操作が拒否されてしまいます。対処は次の2択になります。

LDAPS（ポート636）でのつまずき

SSL/TLSで接続する場合、証明書の格納先ストアの誤りやCNGキーの非互換により、有効化に失敗するケースがあります。サーバー証明書の発行者・サブジェクト・拇印が、接続先ディレクトリのものと一致しているかを構成ウィザードの「グローバル」ページで確認しましょう。

サービスとログの確認

09まとめ

Microsoft Entra IDからオンプレミスのLDAPディレクトリへのプロビジョニングは、「Entra → エージェント → ECMA2Host → 汎用LDAPコネクタ → LDAPディレクトリ」という一本の経路でユーザー情報を運ぶ仕組みです。要点を整理すると次のとおりです。

「クラウドでIDを一元管理しつつ、社内のLDAP依存アプリも活かしたい」という現実的な要件に応えられるのが、この構成の価値です。まずは検証用のAD LDS環境で一通りの流れを試し、制限事項を体感してから本番設計に進むのがおすすめです。