Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための Microsoft Entra ID の構成

[アーティクル]
01/30/2025

次のドキュメントは、Linux システムへのアクセスを管理する方法を示すチュートリアルです。 Microsoft Entra は、その Linux システムによって信頼されているオンプレミスの LDAP ディレクトリにユーザーをプロビジョニングします。これにより、ユーザーは、ユーザー認証のためにその LDAP ディレクトリに依存する Linux システムにログインできます。ユーザーが Microsoft Entra ID から削除されると、Linux システムにログインできなくなります。

手記

この記事で説明するシナリオは、ユーザーの識別と認証に Name Services スイッチ (NSS) またはプラグ可能な認証モジュール (PAM) LDAP モジュールに既に依存している既存の Linux システムにのみ適用されます。 Azure または Azure Arc 対応の Linux VM は、代わりに Microsoft Entra 認証と統合する必要があります。 Microsoft Entra ID と OpenSSHを使用して Azure の Linux 仮想マシンにログインする方法の説明に従って、Microsoft Entra ID と OpenSSH 証明書ベースの認証を使用して Linux VM に SSH 接続するためのコア認証プラットフォームと証明機関として Microsoft Entra ID を使用できるようになりました。

Linux 認証以外の LDAP ディレクトリへのユーザーのプロビジョニングに関連するその他のシナリオについては、LDAP ディレクトリにユーザーをプロビジョニングするように Microsoft Entra ID を構成するを参照してください。

Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための前提条件

この記事では、LDAP サーバーがオンプレミス環境に既に存在し、1 つ以上の Linux または他の POSIX システムによってユーザー認証に使用されていることを前提としています。

Microsoft Entra ID から LDAP ディレクトリサーバーへのオンプレミスプロビジョニングのアーキテクチャを示す図。

オンプレミスの前提条件

PAM または NSS モジュールを使用してディレクトリサーバーに応答する Linux または他の POSIX サーバー。
ユーザーを作成、更新、削除できる POSIX スキーマ (OpenLDAP など) をサポートする LDAP ディレクトリサーバー。サポートされているディレクトリサーバーの詳細については、Generic LDAP コネクタリファレンスを参照してください。
プロビジョニングエージェントをホストするための RAM が少なくとも 3 GB のコンピューター。コンピューターには Windows Server 2016 以降のバージョンの Windows Server が必要です。また、ターゲットディレクトリサーバーへの接続と、他の Microsoft Online Services と Azure ドメイン、login.microsoftonline.com への送信接続も必要です。たとえば、Azure IaaS またはプロキシの背後でホストされている Windows Server 2016 仮想マシンがあります。 .NET Framework 4.7.2 をそのサーバーにインストールする必要があります。
省略可能: 必須ではありませんが、Microsoft Edge for Windows Server ダウンロードし、Internet Explorer の代わりに使用することをお勧めします。

クラウドの要件

Microsoft Entra ID P1 または Premium P2 (または EMS E3 または E5) を持つ Microsoft Entra テナント。

この機能を使用するには、Microsoft Entra ID P1 ライセンスが必要です。要件に適したライセンスを見つけるには、「Microsoft Entra IDの一般公開機能を比較する」を参照してください。
プロビジョニングエージェントを構成するためのハイブリッド ID 管理者ロール。
Azure portal または Microsoft Entra 管理センターでプロビジョニングを構成するためのアプリケーション管理者またはクラウドアプリケーション管理者ロール。
ディレクトリサーバースキーマでは、各 Microsoft Entra ユーザーの特定の属性を LDAP ディレクトリにプロビジョニングする必要があり、これらの属性は既に設定されている必要があります。特に、各ユーザーには、ユーザー ID 番号として一意の番号が必要です。プロビジョニングエージェントをデプロイしてユーザーをディレクトリに割り当てる前に、ユーザーの既存の属性からその番号を生成するか、Microsoft Entra スキーマを拡張する必要があります。その後、スコープ内のユーザーにその属性を設定できます。追加のディレクトリ拡張機能を作成する方法については、Graph 拡張機能のを参照してください。

その他の推奨事項と制限事項

次の箇条書きは、その他の推奨事項と制限事項です。

クラウド同期とオンプレミスアプリのプロビジョニングに同じエージェントを使用することはお勧めしません。クラウド同期には別のエージェントを使用し、1 つはオンプレミスアプリのプロビジョニングに使用することをお勧めします。
現在、AD LDS の場合、ユーザーはパスワードを使用してプロビジョニングできません。そのため、AD LDS のパスワードポリシーを無効にするか、無効な状態でユーザーをプロビジョニングする必要があります。
他のディレクトリサーバーでは、初期ランダムパスワードを設定できますが、Microsoft Entra ユーザーのパスワードをディレクトリサーバーにプロビジョニングすることはできません。
LDAP から Microsoft Entra ID へのユーザーのプロビジョニングはサポートされていません。
ディレクトリサーバーへのグループとユーザーメンバーシップのプロビジョニングはサポートされていません。

Microsoft Entra LDAP コネクタがディレクトリサーバーと対話する方法を決定する

コネクタを既存のディレクトリサーバーに展開する前に、ディレクトリサーバーと統合する方法について、組織内のディレクトリサーバーオペレーターと話し合う必要があります。収集する情報には、次のものが含まれます。

ディレクトリサーバーに接続する方法のネットワーク情報。
コネクタがディレクトリサーバーに対して自身を認証する方法。
ユーザーをモデル化するためにディレクトリサーバーが選択したスキーマ。
名前付けコンテキストの基本識別名とディレクトリ階層ルール。
ディレクトリサーバー内のユーザーを Microsoft Entra ID のユーザーに関連付ける方法。
ユーザーが Microsoft Entra ID でスコープ外になったときにはどうなるべきか。

このコネクタを展開するには、ディレクトリサーバーの構成の変更と、Microsoft Entra ID の構成の変更が必要になる場合があります。 Microsoft Entra ID を運用環境のサードパーティのディレクトリサーバーと統合する展開の場合は、お客様がディレクトリサーバーベンダー、またはこの統合のヘルプ、ガイダンス、およびサポートのために展開パートナーと協力することをお勧めします。この記事では、OpenLDAP の次のサンプル値を使用します。

構成設定	値が設定されている場所	値の例
ディレクトリサーバーのホスト名	構成ウィザードの [接続] ページ	`APP3`
ディレクトリサーバーのポート番号	構成ウィザードの [接続] ページ	636. LDAP over SSL または TLS (LDAPS) の場合は、ポート 636 を使用します。 `Start TLS`の場合は、ポート 389 を使用します。
コネクタがディレクトリサーバーに対して自身を識別するためのアカウント	構成ウィザードの [接続] ページ	`cn=admin,dc=contoso,dc=lab`
コネクタがディレクトリサーバーに対して自身を認証するためのパスワード	構成ウィザードの [接続] ページ
ディレクトリサーバー内のユーザーの構造オブジェクトクラス	構成ウィザードオブジェクトの種類ページ	`inetOrgPerson`
ディレクトリサーバー内のユーザーの補助オブジェクトクラス	Azure portal の [プロビジョニング] ページの属性マッピング	`posixAccount` と`shadowAccount`
新しいユーザーに設定する属性	構成ウィザード [属性選択] ページと Azure ポータルプロビジョニングページの属性マッピング	`cn`, `gidNumber`, `homeDirectory`, `mail`, `objectClass`, `sn`, `uid`, `uidNumber`, `userPassword`
ディレクトリサーバーに必要な名前付け階層	Azure portal の [プロビジョニング] ページの属性マッピング	新しく作成したユーザーの DN を `DC=Contoso,DC=lab` のすぐ下に設定します
Microsoft Entra ID とディレクトリサーバー間でユーザーを関連付けするための属性	Azure portal の [プロビジョニング] ページの属性マッピング	`mail`
ユーザーが Microsoft Entra ID でスコープ外になったときのプロビジョニング解除動作	構成ウィザードの [プロビジョニング解除] ページ	ディレクトリサーバーからユーザーを削除する

ディレクトリサーバーのネットワークアドレスは、ホスト名と TCP ポート番号 (通常はポート 389 または 636) です。ディレクトリサーバーが同じ Windows Server 上のコネクタと併置されている場合、またはネットワークレベルのセキュリティを使用している場合を除き、コネクタからディレクトリサーバーへのネットワーク接続は SSL または TLS を使用して保護する必要があります。コネクタは、ポート 389 上のディレクトリサーバーへの接続と、セッション内での TLS の開始を使用した TLS の有効化をサポートしています。このコネクタでは、LDAPS - LDAP over TLS のポート 636 上のディレクトリサーバーへの接続もサポートしています。

コネクタがディレクトリサーバーに対して認証を行うには、既にディレクトリサーバーで構成されている識別済みのアカウントが必要です。通常、このアカウントは識別名で識別され、パスワードまたはクライアント証明書が関連付けられています。接続されたディレクトリ内のオブジェクトに対してインポート操作とエクスポート操作を実行するには、コネクタアカウントにディレクトリのアクセス制御モデル内で十分なアクセス許可が必要です。コネクタがエクスポートするには、の書き込み アクセス許可が必要で、インポートするには、の読み取り アクセス許可が必要です。アクセス許可の構成は、ターゲットディレクトリ自体の管理エクスペリエンス内で実行されます。

ディレクトリスキーマは、ディレクトリ内の実際のエンティティを表すオブジェクトクラスと属性を指定します。コネクタは、inetOrgPersonなどの構造オブジェクトクラスで表されるユーザーと、必要に応じて追加の補助オブジェクトクラスをサポートします。コネクタがディレクトリサーバーにユーザーをプロビジョニングできるようにするには、Azure portal での構成時に、Microsoft Entra スキーマからすべての必須属性へのマッピングを定義します。これには、構造オブジェクトクラスの必須属性、その構造オブジェクトクラスのスーパークラス、および補助オブジェクトクラスの必須属性が含まれます。

また、これらのクラスの省略可能な属性の一部へのマッピングも構成する可能性があります。 Linux 認証をサポートする POSIX スキーマを持つ OpenLDAP ディレクトリサーバーでは、新しいユーザーが次の例のような属性を持つオブジェクトが必要になる場合があります。

dn: cn=bsimon,dc=Contoso,dc=lab
objectClass: inetOrgPerson
objectClass: posixAccount
objectClass: shadowAccount
cn: bsimon
gidNumber: 10000
homeDirectory: /home/bsimon
sn: simon
uid: bsimon
uidNumber: 10011
mail: bsimon@contoso.com
userPassword: initial-password

ディレクトリサーバーによって実装されるディレクトリ階層ルールでは、各ユーザーのオブジェクトが相互に、およびディレクトリ内の既存のオブジェクトにどのように関連するかを記述します。ほとんどの展開では、組織はディレクトリサーバーにフラット階層を設定することを選択しました。この階層では、ユーザーの各オブジェクトが共通の基本オブジェクトのすぐ下に配置されます。たとえば、ディレクトリサーバー内の名前付けコンテキストの基本識別名が dc=contoso,dc=com 場合、新しいユーザーは cn=alice,dc=contoso,dc=comなどの識別名を持つことになります。

ただし、より複雑なディレクトリ階層を持つ組織もあります。その場合は、コネクタの識別名マッピングを指定するときにルールを実装する必要があります。たとえば、ディレクトリサーバーでは、ユーザーが部門別の組織単位に属することが想定される場合があるため、新しいユーザーには cn=alice,ou=London,dc=contoso,dc=comなどの識別名が付けられます。コネクタは組織単位の中間オブジェクトを作成しないため、ディレクトリサーバールール階層で想定される中間オブジェクトは、ディレクトリサーバーに既に存在している必要があります。

次に、Microsoft Entra ユーザーに対応するディレクトリサーバーにユーザーが既に存在するかどうかをコネクタが判断する方法の規則を定義する必要があります。すべての LDAP ディレクトリには、ディレクトリサーバー内のオブジェクトごとに一意の識別名が付けられますが、Microsoft Entra ID のユーザーには識別名が存在しないことがよくあります。代わりに、組織は、ディレクトリサーバースキーマに異なる属性 (mail や employeeIdなど) を持つ場合があり、Microsoft Entra ID のユーザーにも存在します。次に、コネクタが新しいユーザーをディレクトリサーバーにプロビジョニングするときに、その属性の特定の値を持つユーザーがそのディレクトリに既に存在するかどうかを検索し、存在しない場合にのみディレクトリサーバーに新しいユーザーを作成できます。

既存のユーザーを更新または削除するだけでなく、LDAP ディレクトリに新しいユーザーを作成するシナリオでは、そのディレクトリサーバーを使用する Linux システムによる認証の処理方法も決定する必要があります。一部のシステムでは、ディレクトリからユーザーの SSH 公開キーまたは証明書に対してクエリを実行できます。これは、ユーザーが既にこれらのフォームの資格情報を保持している場合に適している場合があります。ただし、ディレクトリサーバーに依存するアプリケーションが先進認証プロトコルまたはより強力な資格情報をサポートしていない場合は、Microsoft Entra ID はユーザーの Microsoft Entra パスワードのプロビジョニングをサポートしていないため、ディレクトリに新しいユーザーを作成するときにアプリケーション固有のパスワードを設定する必要があります。

最後に、プロビジョニング解除の動作に同意する必要があります。コネクタが構成されていて、Microsoft Entra ID のユーザーとディレクトリ内のユーザー (ディレクトリに既に存在するユーザーまたは新しいユーザー) の間で Microsoft Entra ID がリンクされている場合、Microsoft Entra ID は Microsoft Entra ユーザーからの属性変更をディレクトリにプロビジョニングできます。

アプリケーションに割り当てられているユーザーが Microsoft Entra ID で削除された場合、Microsoft Entra ID は削除操作をディレクトリサーバーに送信します。また、ユーザーがアプリケーションを使用できない場合に、ディレクトリサーバー内のオブジェクトを Microsoft Entra ID で更新することもできます。この動作は、ディレクトリサーバーを使用するアプリケーションによって異なります。OpenLDAP などの多くのディレクトリには、ユーザーのアカウントが非アクティブ化されていることを示す既定の方法がない場合があります。

Microsoft Entra Connect プロビジョニングエージェントをインストールして構成する

Azure portal にサインインします。
エンタープライズアプリケーションに移動し、[新しいアプリケーション] 選択します。
オンプレミス ECMA アプリ アプリケーションを検索し、アプリに名前を付け、作成を選択してテナントに追加します。
メニューから、アプリケーションの プロビジョニング ページに移動します。
[開始する] を選択します。
[プロビジョニング] ページで、モードを [自動] に変更します。

[オンプレミス接続] で、[ダウンロードしてインストール] を選択し、[条項に同意してダウンロード] を選択します。

ポータルを終了してプロビジョニングエージェントのインストーラーを実行し、サービス規約に同意して、インストールを選択します。
Microsoft Entra プロビジョニングエージェント構成ウィザードを待ってから、[次 ] を選択します。
拡張機能の選択手順で、オンプレミスアプリケーションプロビジョニング選択し、次を選択します。
プロビジョニングエージェントは、オペレーティングシステムの Web ブラウザーを使用して、Microsoft Entra ID および組織の ID プロバイダーに対して認証するためのポップアップウィンドウを表示します。 Windows Server のブラウザーとして Internet Explorer を使用している場合は、JavaScript を正しく実行できるように、ブラウザーの信頼済みサイト一覧に Microsoft Web サイトを追加することが必要になる場合があります。
承認を求められたら、Microsoft Entra 管理者の資格情報を入力します。ユーザーには、少なくともハイブリッド ID 管理者のロールが必要です。
[ 確認] を選択して設定を確定します。インストールが正常に完了したら、終了選択し、プロビジョニングエージェントパッケージインストーラーを閉じてもかまいません。

オンプレミスの ECMA アプリを構成する

ポータルに戻り、オンプレミス接続 セクションで、デプロイしたエージェントを選択し、エージェントの割り当てを選択します。
構成ウィザードを使用して次の構成手順を完了したら、このブラウザーウィンドウを開いたままにしておきます。

Microsoft Entra ECMA コネクタホスト証明書を構成する

プロビジョニングエージェントがインストールされている Windows Server で、スタートメニューから Microsoft ECMA2Host 構成ウィザードを右選択し、管理者として実行します。ウィザードで必要な Windows イベントログを作成するには、Windows 管理者として実行する必要があります。
ECMA コネクタホスト構成の開始後、ウィザードを初めて実行する場合は、証明書の作成を求められます。既定のポート 8585 のままにし、[証明書 生成] を選択して証明書を生成します。自動生成された証明書は、信頼されたルートの一部として自己署名されます。 SAN はホスト名と一致します。
[保存] を選択します。

手記

新しい証明書の生成を選択した場合は、証明書の有効期限を記録して、構成ウィザードに戻り、有効期限が切れる前に証明書を生成し直すようにスケジュールしてください。

汎用 LDAP コネクタを構成する

選択したオプションによっては、一部のウィザード画面が使用できない場合があり、情報が若干異なる場合があります。次の情報を使用して、設定の手順をガイドしてください。

コネクタに対する Microsoft Entra ID の認証に使用されるシークレットトークンを生成します。アプリケーションごとに最小 12 文字で一意である必要があります。シークレットジェネレーターがまだない場合は、次のような PowerShell コマンドを使用して、ランダムな文字列の例を生成できます。
```
-join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
```
まだ実行していない場合は、スタートメニューから Microsoft ECMA2Host 構成ウィザードを起動します。
を選択します[新しいコネクタ]。

[プロパティ] ページで、画像の後にある表で指定した値をボックスに入力し、[次へ]選択します。

財産	価値
名前	コネクタに対して選択した名前。環境内のすべてのコネクタで一意である必要があります。たとえば、`LDAP`します。
自動同期タイマー (分)	120
シークレットトークン	ここにシークレットトークンを入力します。最小 12 文字にする必要があります。
拡張 DLL	汎用 LDAP コネクタの場合は、Microsoft.IAM.Connector.GenericLdap.dllを選択します。

[接続] ページで、ECMA コネクタホストがディレクトリサーバーと通信する方法を構成し、いくつかの構成オプションを設定します。画像の後にある表で指定した値をボックスに入力し、[次へ]選択します。 [次を選択すると、コネクタはディレクトリサーバーにその構成を照会します。

財産	説明
ホスト	LDAP サーバーが配置されているホスト名。このサンプルでは、ホスト名の例として `APP3` を使用します。
ポート	TCP ポート番号。ディレクトリサーバーが SSL 経由で LDAP 用に構成されている場合は、ポート 636 を使用します。 `Start TLS`の場合、またはネットワークレベルのセキュリティを使用している場合は、ポート 389 を使用します。
接続タイムアウト	180
バインド	このプロパティは、コネクタがディレクトリサーバーに対して認証する方法を指定します。 `Basic` 設定を使用するか、`SSL` または `TLS` 設定を使用し、クライアント証明書が構成されていない場合、コネクタは LDAP 単純バインドを送信して、識別名とパスワードで認証します。 `SSL` または `TLS` 設定とクライアント証明書を指定すると、コネクタは LDAP SASL `EXTERNAL` バインドを送信して、クライアント証明書で認証します。
ユーザー名	ECMA コネクタがディレクトリサーバーに対して自身を認証する方法。この例では、`cn=admin,dc=contoso,dc=lab`
パスワード	ECMA コネクタがディレクトリサーバーに対して自身を認証するユーザーのパスワード。
領域/ドメイン	この設定は、ユーザーの領域/ドメインを指定するために、バインドオプションとして `Kerberos` を選択した場合にのみ必要です。
証書	このセクションの設定は、[バインド] オプションとして `SSL` または `TLS` を選択した場合にのみ使用されます。
属性エイリアス	属性エイリアステキストボックスは、RFC4522構文を使用してスキーマで定義された属性に使用されます。これらの属性はスキーマ検出中に見つけることができず、コネクタがそれらの属性を識別する際に支援が必要です。たとえば、ディレクトリサーバーが `userCertificate;binary` を発行せず、その属性をプロビジョニングする場合、userCertificate 属性をバイナリ属性として正しく識別するには、属性エイリアスボックスに次の文字列を入力する必要があります:`userCertificate;binary`。スキーマにない特別な属性を必要としない場合は、空白のままにすることができます。
運用属性を含める	`Include operational attributes in schema` チェックボックスをオンにすると、ディレクトリサーバーによって作成された属性も含まれます。これには、オブジェクトが作成された日時や最終更新時刻などの属性が含まれます。
拡張可能な属性を含める	拡張オブジェクト (RFC4512/4.3) がディレクトリサーバーで使用されている場合は、`Include extensible attributes in schema` チェックボックスをオンにします。このオプションを有効にすると、すべての属性をすべてのオブジェクトで使用できます。このオプションを選択するとスキーマが非常に大きいため、接続されたディレクトリがこの機能を使用していない場合は、オプションを選択しないようにすることをお勧めします。
手動アンカー選択を許可する	オフのままにします。

手記

接続しようとして問題が発生し、グローバル ページに進まない場合は、ディレクトリサーバーのサービスアカウントが有効になっていることを確認してください。

グローバル ページで、必要に応じて差分変更ログの識別名と追加の LDAP 機能を構成します。このページには、LDAP サーバーによって提供される情報が事前に設定されています。表示されている値を確認し、[次へ]選択します。

財産	説明
サポートされている SASL メカニズム	上部のセクションには、SASL メカニズムの一覧など、サーバー自体によって提供される情報が表示されます。
サーバー証明書の詳細	`SSL` または `TLS` が指定されている場合、ウィザードはディレクトリサーバーから返された証明書を表示します。発行者、件名、拇印が正しいディレクトリサーバー用であることを確認します。
必須機能が見つかりました	コネクタは、必須のコントロールがルート DSE に存在することも確認します。これらのコントロールが一覧にない場合は、警告が表示されます。一部の LDAP ディレクトリでは、ルート DSE 内のすべての機能が一覧表示されず、警告が存在する場合でも、コネクタが問題なく動作する可能性があります。
サポートされているコントロール	サポートされているコントロールチェックボックスは、特定の操作の動作を制御します
差分インポート	変更ログ DN は、デルタ変更ログで使用される名前付けコンテキストです。例として cn=changelog のようにが挙げられます。デルタインポートを実行できるようにするには、この値を指定する必要があります。差分インポートを実装する必要がない場合は、このフィールドを空白にすることができます。
パスワード属性	ディレクトリサーバーが別のパスワード属性またはパスワードハッシュをサポートしている場合は、パスワードの変更先を指定できます。
パーティション名	追加のパーティションの一覧では、自動的に検出されない名前空間を追加できます。たとえば、複数のサーバーが論理クラスターを構成し、すべて同時にインポートする必要がある場合に、この設定を使用できます。 Active Directory は 1 つのフォレスト内に複数のドメインを持つことができますが、すべてのドメインが 1 つのスキーマを共有する場合と同様に、このボックスに追加の名前空間を入力することで同じものをシミュレートできます。各名前空間は異なるサーバーからインポートでき、パーティションと階層の構成ページでさらに構成されます。

[パーティション ] ページで、既定の設定をそのまま使用して、[次へ] を選択します。

[実行プロファイル] ページで、[エクスポート] チェックボックスと [フルインポート] チェックボックスが両方ともオンになっていることを確認します。次を選択します。

財産	説明
輸出	LDAP ディレクトリサーバーにデータをエクスポートするプロファイルを実行します。この実行プロファイルは必須です。
完全インポート	前に指定した LDAP ソースからすべてのデータをインポートするプロファイルを実行します。この実行プロファイルは必須です。
差分インポート	最後の完全インポートまたは差分インポート以降の LDAP からの変更のみをインポートするプロファイルを実行します。ディレクトリサーバーが必要な要件を満たしていることを確認した場合にのみ、この実行プロファイルを有効にします。詳細については、Generic LDAP コネクタリファレンスを参照してください。

[エクスポート] ページで、既定値を変更せずに [次へ] を選択します。
[フルインポート] ページで、既定値を変更せずに [次へ] を選択します。
[差分インポート] ページが表示されている場合は、既定値を変更せずに [次へ] を選択します。

[オブジェクトの種類] ページで、ボックスに入力し、[次へ] を選択します。

財産	説明
ターゲットオブジェクト	この値は、LDAP ディレクトリー・サーバー内のユーザーの構造オブジェクト・クラスです。 `inetOrgPerson`使用し、このフィールドに補助オブジェクトクラスを指定しないでください。ディレクトリサーバーに補助オブジェクトクラスが必要な場合は、Azure portal で属性マッピングを使用して構成されます。
錨	この属性の値は、ターゲットディレクトリ内のオブジェクトごとに一意である必要があります。 Microsoft Entra プロビジョニングサービスは、最初のサイクルの後にこの属性を使用して ECMA コネクタホストにクエリを実行します。通常は、`-dn-`として選択できる特定の識別名を使用します。 OpenLDAP スキーマの `uid` 属性など、複数値の属性をアンカーとして使用することはできません。
クエリ属性	この属性は Anchor と同じである必要があります。
DN	ターゲットオブジェクトの識別名。 `-dn-`を維持します。
自動生成	未確認

ECMA ホストは、ターゲットディレクトリでサポートされている属性を検出します。 Microsoft Entra ID に公開する属性を選択できます。これらの属性は、プロビジョニング用に Azure portal で構成できます。 属性の選択 ページで、必須属性として必要な属性、または Microsoft Entra ID からプロビジョニングする属性をドロップダウンリストに一度に 1 つずつ追加します。
[属性] ドロップダウンリストには、ターゲットディレクトリで検出され、構成ウィザードの [属性の選択] ページを以前使用したときには選択 "しなかった" 属性が表示されます。

objectClass 属性の Treat as single value チェックボックスがオフになっていることを確認してください。また、userPassword が設定されている場合は、userPassword 属性のチェックボックスが選択できないか、オンになっているかを確認してください。

次の属性の可視性を構成します。

属性	単一値として扱う
_distinguishedName
-dn-
パスワードのエクスポート
cn	Y
gidNumber
ホームディレクトリ
郵便	はい
objectClass
sn	Y
uid	Y
uidNumber
ユーザーパスワード	Y

関連するすべての属性が追加されたら、[次へ] を選択します。

[プロビジョニング解除 ] ページで、アプリケーションの範囲外になったときに Microsoft Entra ID でユーザーをディレクトリから削除するかどうかを指定できます。その場合は、[フロー無効にする] で [削除] を選択し、[フロー削除] で [削除] を選択します。 Set attribute value 選択した場合、前のページで選択した属性はプロビジョニング解除ページで選択できなくなります。

手記

Set 属性値を使用する場合 ブール値のみが許可されることに注意してください。

[完了] を選択します。

ECMA2Host サービスが実行されていて、ディレクトリサーバーから読み取ることができることを確認する

次の手順に従って、コネクタホストが開始され、ディレクトリサーバーから既存のユーザーが識別されたことを確認します。

Microsoft Entra ECMA コネクタホストを実行しているサーバーで、スタートを選ぶ。
必要に応じて実行を選択し、ボックスに「services.msc」を入力します。
サービスのの一覧で、Microsoft ECMA2Host が存在し、実行されていることを確認します。実行されていない場合は、[開始] を選択します。
最近サービスを開始し、ディレクトリサーバーに多数のユーザーオブジェクトがある場合は、コネクタがディレクトリサーバーとの接続を確立するまで数分待ちます。
Microsoft Entra ECMA コネクタホストを実行しているサーバーで、PowerShell を起動します。
ECMA ホストがインストールされたフォルダー (C:\Program Files\Microsoft ECMA2Hostなど) に変更します。
サブディレクトリ Troubleshootingに変更します。
次に示すように、そのディレクトリ TestECMA2HostConnection.ps1 スクリプトを実行し、コネクタ名と ObjectTypePath 値を引数として指定 cache。コネクタホストが TCP ポート 8585 でリッスンしていない場合は、-Port 引数も指定する必要があります。メッセージが表示されたら、そのコネクタ用に構成されたシークレットトークンを入力します。
```
PS C:\Program Files\Microsoft ECMA2Host\Troubleshooting> $cout = .\TestECMA2HostConnection.ps1 -ConnectorName LDAP -ObjectTypePath cache; $cout.length -gt 9
Supply values for the following parameters:
SecretToken: ************
```
スクリプトにエラーまたは警告メッセージが表示される場合は、サービスが実行されていることを確認し、コネクタ名とシークレットトークンが構成ウィザードで構成した値と一致することを確認します。
スクリプトに出力 Falseが表示された場合、コネクタは既存のユーザーのソースディレクトリサーバーにエントリを表示していません。これが新しいディレクトリサーバーのインストールである場合は、この動作が想定されるため、次のセクションに進むことができます。
ただし、ディレクトリサーバーに既に 1 人以上のユーザーが含まれているが、Falseスクリプトが表示されている場合、この状態はコネクタがディレクトリサーバーから読み取ることができなかったことを示します。プロビジョニングしようとすると、Microsoft Entra ID が、そのソースディレクトリ内のユーザーと Microsoft Entra ID のユーザーと正しく一致しない可能性があります。コネクタホストが既存のディレクトリサーバーからのオブジェクトの読み取りを完了するまで数分待ってから、スクリプトを再実行します。出力が引き続き False場合は、コネクタの構成を確認し、ディレクトリサーバーのアクセス許可によってコネクタが既存のユーザーを読み取ることを許可します。

Microsoft Entra ID からコネクタホストへの接続をテストする

ポータルでアプリケーションプロビジョニングを構成していた Web ブラウザーウィンドウに戻ります。

手記

ウィンドウがタイムアウトした場合は、エージェントを再選択する必要があります。
1. Azure portal にサインインします。
2. Enterprise アプリケーションとオンプレミス ECMA アプリアプリケーションに移動します。
3. [プロビジョニング] を選択します。
4. [概要] が表示された場合は、モードを [自動] に変更し、[オンプレミス接続] セクションで、デプロイしたエージェントを選択し、[エージェントの割り当て] を選択して 10 分間待ちます。 [概要] が表示されない場合は、[プロビジョニングの編集] に移動します。
[管理者資格情報の] セクションで、次の URL を入力します。 connectorName 部分を ECMA ホスト上のコネクタの名前 (LDAPなど) に置き換えます。 ECMA ホストの証明機関から証明書を指定した場合は、localhost を ECMA ホストがインストールされているサーバーのホスト名に置き換えます。

財産価値

テナント URL https://localhost:8585/ecma2host_connectorName/scim
コネクタの作成時に定義した シークレットトークン 値を入力します。

手記

アプリケーションにエージェントを割り当てたばかりの場合は、登録が完了するまで 10 分待ってください。接続テストは、登録が完了するまで機能しません。サーバーでプロビジョニングエージェントを再起動してエージェントの登録を強制的に完了すると、登録プロセスが高速化されます。サーバーに移動し、Windows 検索バーでサービスを検索し、Microsoft Entra Connect Provisioning Agent サービスを特定し、サービスを右選択して再起動します。
[テスト接続選択し、1 分間待ちます。
接続テストが成功し、プロビジョニングを有効にするために指定された資格情報が承認されていることを示した後、[保存] を選択します。

財産	価値
テナント URL	https://localhost:8585/ecma2host_connectorName/scim

Microsoft Entra スキーマを拡張する

ディレクトリサーバーで、ユーザーの既定の Microsoft Entra スキーマの一部ではない追加の属性が必要な場合は、プロビジョニング時に、定数から、他の Microsoft Entra 属性から変換された式から、または Microsoft Entra スキーマを拡張することによって、それらの属性の値を指定するように構成できます。

ディレクトリサーバーでユーザーに OpenLDAP POSIX スキーマの uidNumber などの属性が必要であり、その属性がユーザーの Microsoft Entra スキーマにまだ含まれていない場合、ユーザーごとに一意である必要がある場合は、式を使用して、ユーザーの他の属性からその属性を生成する必要があります。または、ディレクトリ拡張機能機能を使用して、その属性を拡張機能として追加します。

ユーザーが Active Directory Domain Services で作成され、そのディレクトリに属性がある場合は、Microsoft Entra Connect または Microsoft Entra Connect クラウド同期を使用できます。これにより、Active Directory Domain Services から Microsoft Entra ID に同期されるように属性が構成され、他のシステムへのプロビジョニングに使用できるようになります。

ユーザーが Microsoft Entra ID で生成された場合、ユーザーに格納する必要がある新しい属性ごとに、ディレクトリ拡張機能を定義する必要があります。次、プロビジョニングする予定の Microsoft Entra ユーザーを更新し、各ユーザーにこれらの属性の値を付与します。

属性マッピングを構成する

このセクションでは、Microsoft Entra ユーザーの属性と ECMA ホスト構成ウィザードで以前に選択した属性との間のマッピングを構成します。後でコネクタがディレクトリサーバーにオブジェクトを作成すると、Microsoft Entra ユーザー属性がコネクタを介してディレクトリサーバーに送信され、その新しいオブジェクトの一部になります。

Microsoft Entra 管理センターの Enterprise アプリケーションで、オンプレミス ECMA アプリ アプリケーションを選択し、プロビジョニング ページを選択します。
[プロビジョニングの編集] を選択します。
[マッピング] を展開し、[Microsoft Entra ユーザーのプロビジョニング] を選択します。このアプリケーションの属性マッピングを初めて構成した場合、プレースホルダーとして存在するマッピングは 1 つだけです。
ディレクトリサーバーのスキーマが Microsoft Entra ID で使用可能であることを確認するには、[詳細オプション表示] チェックボックスをオンにし、ScimOnPremisesの [属性リスト編集] を選択します。構成ウィザードで選択したすべての属性が一覧表示されていることを確認します。更新されない場合は、スキーマが更新されるまで数分待ってから、ナビゲーション行で [属性マッピング] 選択し、ScimOnPremises の属性リスト編集を選択してページを再読み込みします。一覧に属性が表示されたら、このページからキャンセルしてマッピングの一覧に戻ります。
ディレクトリ内のすべてのユーザーは、一意の識別名を持っている必要があります。属性マッピングを使用して、コネクタで識別名を構築する方法を指定できます。 新しいマッピングを追加を選択します。次の値を使用してマッピングを作成し、式内の識別名を、ターゲットディレクトリ内の組織単位または他のコンテナーの識別名と一致するように変更します。
- マッピングの種類: 式
- 式: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
- ターゲット属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
- このマッピングを適用する: オブジェクトの作成時のみ
ディレクトリサーバーで、objectClass 属性で複数の構造オブジェクトクラス値または補助オブジェクトクラス値を指定する必要がある場合は、その属性にマッピングを追加します。 objectClassのマッピングを追加するには、[新しいマッピングの追加]を選択します。次の値を使用してマッピングを作成し、式のオブジェクトクラス名をターゲットディレクトリスキーマの名前と一致するように変更します。
- マッピングの種類: 式
- POSIX スキーマをプロビジョニングする場合の式: Split("inetOrgPerson,posixAccount,shadowAccount",",")
- ターゲット属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
- このマッピングを適用する: オブジェクトの作成時のみ

ディレクトリサーバーの次の表の各マッピングについて、[新しいマッピングの追加]選択し、ソース属性とターゲット属性を指定します。既存のユーザーを含む既存のディレクトリにプロビジョニングする場合は、共通する属性のマッピングを編集して、その属性に対してこの属性を使用して Match オブジェクトを設定する必要があります。属性マッピングの詳細については、を参照してください。

POSIX スキーマを含む OpenLDAP の場合は、gidNumber、homeDirectory、uid、および uidNumber 属性も指定する必要があります。各ユーザーには、一意の uid と一意の uidNumberが必要です。通常、homeDirectory は、ユーザーの userID から派生した式によって設定されます。たとえば、ユーザーの uid がユーザープリンシパル名から派生した式によって生成される場合、そのユーザーのホームディレクトリの値は、ユーザープリンシパル名からも派生した同様の式によって生成される可能性があります。また、ユースケースによっては、すべてのユーザーを同じグループに含めたい場合があるため、定数から gidNumber を割り当てます。

マッピングの種類	ソース属性	ターゲット属性
直接	`displayName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:cn`
直接	`surname`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:sn`
直接	`userPrincipalName`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:mail`
表現	`ToLower(Word([userPrincipalName], 1, "@"), )`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uid`
直接	(ディレクトリに固有の属性)	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:uidNumber`
表現	`Join("/", "/home", ToLower(Word([userPrincipalName], 1, "@"), ))`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:homeDirectory`
定数	`10000`	`urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:gidNumber`

ユーザーの初期ランダムパスワードを設定するマッピングを urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword に追加します。
[保存] を選択します。

ディレクトリにプロビジョニングするユーザーに必要な属性があることを確認する

LDAP ディレクトリに既存のユーザーアカウントを持つユーザーがいる場合は、Microsoft Entra ユーザー表現に照合に必要な属性があることを確認する必要があります。

LDAP ディレクトリに新しいユーザーを作成する場合は、それらのユーザーの Microsoft Entra 表現に、ターゲットディレクトリのユーザースキーマに必要なソース属性があることを確認する必要があります。各ユーザーには、一意の uid と一意の uidNumberが必要です。

ユーザーが Active Directory Domain Services で作成され、そのディレクトリに属性がある場合は、Microsoft Entra Connect または Microsoft Entra Connect クラウド同期を使用して、その属性を Active Directory Domain Services から Microsoft Entra ID に同期して、他のシステムへのプロビジョニングに使用できるように構成できます。

Microsoft Entra ID でユーザーが作成された場合には、ユーザーに格納する必要がある新しい属性ごとに、ディレクトリ拡張機能を設定する必要があります。次、プロビジョニングする予定の Microsoft Entra ユーザーを更新し、各ユーザーにこれらの属性の値を付与します。

PowerShell を使用したユーザーの確認

Microsoft Entra ID でユーザーを更新したら、Microsoft Graph PowerShell コマンドレットを使用して、必要なすべての属性を持つユーザーのチェックを自動化できます。

たとえば、プロビジョニングで、ユーザーが DisplayName、surname、extension_656b1c479a814b1789844e76b2f459c3_MyNewPropertyの3つの属性を持つ必要があるとします。この 3 番目の属性は、uidNumberを格納するために使用されます。 Get-MgUser コマンドレットを使用して各ユーザーを取得し、必要な属性が存在するかどうかを確認できます。 Graph v1.0 Get-MgUser コマンドレットは、既定では、要求で返すプロパティの 1 つとして属性が指定されていない限り、ユーザーのディレクトリ拡張属性を返しません。

このセクションでは、Microsoft Graph PowerShell コマンドレット使用して Microsoft Entra ID を操作する方法について説明します。

このシナリオで組織が初めてこれらのコマンドレットを使用するときは、テナントで Microsoft Graph PowerShell を使用できるようにするには、グローバル管理者ロールである必要があります。後続の対話では、次のような低い特権ロールを使用できます。

ユーザー管理者(新しいユーザーの作成が予想される場合)。
アプリケーション管理者または ID ガバナンス管理者 (アプリケーションロールの割り当ての管理だけを行う場合)。

PowerShell を開きます。
Microsoft Graph PowerShell モジュールまだインストールされていない場合は、次のコマンドを使用して、Microsoft.Graph.Users モジュールなどをインストールします。
```
Install-Module Microsoft.Graph
```
モジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Microsoft Entra ID に接続します。

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

ユーザーの一覧と確認する属性を作成します。

$userPrincipalNames = (
 "alice@contoso.com",
 "bob@contoso.com",
 "carol@contoso.com" )

$requiredBaseAttributes = ("DisplayName","surname")
$requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")

各ユーザーのディレクトリに対してクエリを実行します。

$select = "id"
foreach ($a in $requiredExtensionAttributes) { $select += ","; $select += $a;}
foreach ($a in $requiredBaseAttributes) { $select += ","; $select += $a;}

foreach ($un in $userPrincipalNames) {
   $nu = Get-MgUser -UserId $un -Property $select -ErrorAction Stop
   foreach ($a in $requiredBaseAttributes) { if ($nu.$a -eq $null) { write-output "$un missing $a"} }
   foreach ($a in $requiredExtensionAttributes) { if ($nu.AdditionalProperties.ContainsKey($a) -eq $false) { write-output "$un missing $a" } }
}

LDAP ディレクトリから既存のユーザーを収集する

そのディレクトリ内のユーザーのうち、Linux 認証を使用するユーザーのスコープ内にあるユーザーを特定します。この選択は、Linux システムの構成によって異なります。一部の構成では、LDAP ディレクトリに存在するすべてのユーザーが有効なユーザーです。その他の構成では、ユーザーが特定の属性を持っているか、そのディレクトリ内のグループのメンバーであることが必要になる場合があります。
LDAP ディレクトリから CSV ファイルにユーザーのサブセットを取得するコマンドを実行します。出力に、Microsoft Entra ID との照合に使用されるユーザーの属性が含まれていることを確認します。これらの属性の例としては、従業員 ID、アカウント名または uid、電子メールアドレスがあります。
必要に応じて、ユーザーの一覧を含む CSV ファイルを、Microsoft Graph PowerShell コマンドレットがインストールされているシステム転送します。
ディレクトリから取得したすべてのユーザーの一覧が作成されたので、ディレクトリのユーザーを Microsoft Entra ID のユーザーと照合します。先に進む前に、ソースシステムとターゲットシステムの一致するユーザーに関する情報を確認します。

Microsoft Entra ID でユーザーの ID を取得する

このセクションでは、Microsoft Graph PowerShell コマンドレット使用して Microsoft Entra ID を操作する方法について説明します。

ユーザー管理者(新しいユーザーの作成が予想される場合)。
アプリケーションのロール割り当てのみを管理している場合は、アプリケーション管理者または Identity Governance Administratorを選択してください。

PowerShell を開きます。
Microsoft Graph PowerShell モジュールまだインストールされていない場合は、次のコマンドを使用して、Microsoft.Graph.Users モジュールなどをインストールします。
```
Install-Module Microsoft.Graph
```
モジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。
```
Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
```

Microsoft Entra ID に接続します。

$msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"

このコマンドを初めて使用する場合は、Microsoft Graph コマンドラインツールにこれらのアクセス許可を付与することを許可する必要があります。
アプリケーションのデータストアから取得したユーザーの一覧を PowerShell セッションに読み取ります。ユーザーの一覧が CSV ファイルに含まれている場合は、PowerShell コマンドレット Import-Csv を使用し、前のセクションのファイルの名前を引数として指定できます。

たとえば、SAP Cloud Identity Services から取得したファイルの名前が Users-exported-from-sap.csv で、現在のディレクトリにある場合は、次のコマンドを入力します。
```
$filename = ".\Users-exported-from-sap.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
別の例として、データベースまたはディレクトリを使用している場合、ファイルの名前 users.csv 現在のディレクトリにある場合は、次のコマンドを入力します。
```
$filename = ".\users.csv"
$dbusers = Import-Csv -Path $filename -Encoding UTF8
```
Microsoft Entra ID のユーザーの属性と一致する users.csv ファイルの列を選択します。

SAP Cloud Identity Services を使用している場合、既定のマッピングは、Microsoft Entra ID 属性 userPrincipalNameを持つ SAP SCIM 属性 userName です。
```
$db_match_column_name = "userName"
$azuread_match_attr_name = "userPrincipalName"
```
別の例として、データベースまたはディレクトリを使用している場合、EMailという名前の列の値がMicrosoft Entraの属性userPrincipalNameと同じであるデータベース内のユーザーがいることがあります。
```
$db_match_column_name = "EMail"
$azuread_match_attr_name = "userPrincipalName"
```

Microsoft Entra ID でこれらのユーザーの ID を取得します。

次の PowerShell スクリプトでは、前に指定した $dbusers、$db_match_column_name、および $azuread_match_attr_name 値を使用します。 Microsoft Entra ID にクエリを実行して、ソースファイル内の各レコードに対して一致する値を持つ属性を持つユーザーを見つけます。ソース SAP Cloud Identity Services、データベース、またはディレクトリから取得したファイルに多数のユーザーが存在する場合、このスクリプトが完了するまでに数分かかる場合があります。 Microsoft Entra ID に値を持つ属性がなく、contains またはその他のフィルター式を使用する必要がある場合は、このスクリプトをカスタマイズし、以下の手順 11 で別のフィルター式を使用する必要があります。

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

前のクエリの結果を表示します。エラーまたは一致が見つからないために、SAP Cloud Identity Services、データベース、またはディレクトリのいずれかのユーザーが Microsoft Entra ID に配置できなかったかどうかを確認します。

次の PowerShell スクリプトでは、見つからないレコードの数が表示されます。

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Error "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

スクリプトが完了すると、データソースのレコードが Microsoft Entra ID に存在しなかった場合にエラーが表示されます。アプリケーションのデータストアのユーザーのすべてのレコードを Microsoft Entra ID のユーザーとして配置できない場合は、一致しなかったレコードとその理由を調査する必要があります。

たとえば、アプリケーションのデータソースで対応する mail プロパティが更新されずに、Microsoft Entra ID で他のユーザーのメールアドレスと userPrincipalName が変更されている可能性があります。または、ユーザーは既に組織を離れているが、アプリケーションのデータソースにまだ存在している可能性があります。または、アプリケーションのデータソースにベンダーまたはスーパー管理者アカウントがあり、Microsoft Entra ID の特定のユーザーに対応していない場合があります。
Microsoft Entra ID に配置できなかったユーザー、またはアクティブでサインインできなかったユーザーがいて、SAP Cloud Identity Services、データベース、またはディレクトリでアクセス権を確認したり、属性を更新したりする場合は、アプリケーション、一致するルールを更新するか、Microsoft Entra ユーザーを更新または作成する必要があります。行う変更の詳細については、Microsoft Entra IDのユーザーと一致しなかったアプリケーションのマッピングとユーザーアカウントの管理に関するページを参照してください。

Microsoft Entra ID でユーザーを作成するオプションを選択した場合は、次のいずれかを使用してユーザーを一括で作成できます。
- CSV ファイル (「Microsoft Entra ID でユーザーを一括作成する」で説明されています)
- New-MgUser コマンドレット
これらの新しいユーザーには、後でアプリケーション内の既存のユーザーと一致させるために Microsoft Entra ID に必要な属性と、Microsoft Entra ID で必要な属性 (userPrincipalName、mailNickname、displayNameなど) が設定されていることを確認します。 userPrincipalName は、ディレクトリ内のすべてのユーザー間で一意である必要があります。

たとえば、EMail という名前の列の値が Microsoft Entra のユーザープリンシパル名として使用したい値であり、列 Alias の値に Microsoft Entra ID のメールニックネームが含まれ、列 Full name の値にユーザーの表示名が含まれているようなユーザーが、データベースに存在する場合があります。
```
$db_display_name_column_name = "Full name"
$db_user_principal_name_column_name = "Email"
$db_mail_nickname_column_name = "Alias"
```
次に、このスクリプトを使用して、MICROSOFT Entra ID のユーザーと一致しなかった SAP Cloud Identity Services、データベース、またはディレクトリ内のユーザーに対して Microsoft Entra ユーザーを作成できます。このスクリプトを変更して、組織で必要な Microsoft Entra 属性を追加する必要がある場合や、$azuread_match_attr_name が mailNickname でも userPrincipalNameでもない場合は、その Microsoft Entra 属性を指定する必要があります。
```
$dbu_missing_columns_list = @()
$dbu_creation_failed_list = @()
foreach ($dbu in $dbu_not_matched_list) {
   if (($null -ne $dbu.$db_display_name_column_name -and $dbu.$db_display_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_user_principal_name_column_name -and $dbu.$db_user_principal_name_column_name.Length -gt 0) -and
       ($null -ne $dbu.$db_mail_nickname_column_name -and $dbu.$db_mail_nickname_column_name.Length -gt 0)) {
      $params = @{
         accountEnabled = $false
         displayName = $dbu.$db_display_name_column_name
         mailNickname = $dbu.$db_mail_nickname_column_name
         userPrincipalName = $dbu.$db_user_principal_name_column_name
         passwordProfile = @{
           Password = -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
         }
      }
      try {
        New-MgUser -BodyParameter $params
      } catch { $dbu_creation_failed_list += $dbu; throw }
   } else {
      $dbu_missing_columns_list += $dbu
   }
}
```

不足しているユーザーを Microsoft Entra ID に追加した後、手順 7 のスクリプトをもう一度実行します。次に、手順 8. のスクリプトを実行します。エラーが報告されていないことを確認します。

$dbu_not_queried_list = @()
$dbu_not_matched_list = @()
$dbu_match_ambiguous_list = @()
$dbu_query_failed_list = @()
$azuread_match_id_list = @()
$azuread_not_enabled_list = @()
$dbu_values = @()
$dbu_duplicate_list = @()

foreach ($dbu in $dbusers) { 
   if ($null -ne $dbu.$db_match_column_name -and $dbu.$db_match_column_name.Length -gt 0) { 
      $val = $dbu.$db_match_column_name
      $escval = $val -replace "'","''"
      if ($dbu_values -contains $escval) { $dbu_duplicate_list += $dbu; continue } else { $dbu_values += $escval }
      $filter = $azuread_match_attr_name + " eq '" + $escval + "'"
      try {
         $ul = @(Get-MgUser -Filter $filter -All -Property Id,accountEnabled -ErrorAction Stop)
         if ($ul.length -eq 0) { $dbu_not_matched_list += $dbu; } elseif ($ul.length -gt 1) {$dbu_match_ambiguous_list += $dbu } else {
            $id = $ul[0].id; 
            $azuread_match_id_list += $id;
            if ($ul[0].accountEnabled -eq $false) {$azuread_not_enabled_list += $id }
         } 
      } catch { $dbu_query_failed_list += $dbu } 
    } else { $dbu_not_queried_list += $dbu }
}

$dbu_not_queried_count = $dbu_not_queried_list.Count
if ($dbu_not_queried_count -ne 0) {
  Write-Error "Unable to query for $dbu_not_queried_count records as rows lacked values for $db_match_column_name."
}
$dbu_duplicate_count = $dbu_duplicate_list.Count
if ($dbu_duplicate_count -ne 0) {
  Write-Error "Unable to locate Microsoft Entra ID users for $dbu_duplicate_count rows as multiple rows have the same value"
}
$dbu_not_matched_count = $dbu_not_matched_list.Count
if ($dbu_not_matched_count -ne 0) {
  Write-Error "Unable to locate $dbu_not_matched_count records in Microsoft Entra ID by querying for $db_match_column_name values in $azuread_match_attr_name."
}
$dbu_match_ambiguous_count = $dbu_match_ambiguous_list.Count
if ($dbu_match_ambiguous_count -ne 0) {
  Write-Error "Unable to locate $dbu_match_ambiguous_count records in Microsoft Entra ID as attribute match ambiguous."
}
$dbu_query_failed_count = $dbu_query_failed_list.Count
if ($dbu_query_failed_count -ne 0) {
  Write-Error "Unable to locate $dbu_query_failed_count records in Microsoft Entra ID as queries returned errors."
}
$azuread_not_enabled_count = $azuread_not_enabled_list.Count
if ($azuread_not_enabled_count -ne 0) {
 Write-Warning "$azuread_not_enabled_count users in Microsoft Entra ID are blocked from sign-in."
}
if ($dbu_not_queried_count -ne 0 -or $dbu_duplicate_count -ne 0 -or $dbu_not_matched_count -ne 0 -or $dbu_match_ambiguous_count -ne 0 -or $dbu_query_failed_count -ne 0 -or $azuread_not_enabled_count -ne 0) {
 Write-Output "You will need to resolve those issues before access of all existing users can be reviewed."
}
$azuread_match_count = $azuread_match_id_list.Count
Write-Output "Users corresponding to $azuread_match_count records were located in Microsoft Entra ID."

Microsoft Entra ID でアプリケーションにユーザーを割り当てる

Microsoft Entra ECMA コネクタホストが Microsoft Entra ID と通信し、属性マッピングが構成されたので、プロビジョニングの対象となるユーザーの構成に進むことができます。

重要

ハイブリッド ID 管理者ロールを使用してサインインした場合は、少なくともこのセクションのアプリケーション管理者ロールを持つアカウントでサインアウトしてサインインする必要があります。ハイブリッド ID 管理者ロールには、アプリケーションにユーザーを割り当てるアクセス許可がありません。

LDAP ディレクトリに既存のユーザーが存在する場合は、それらの既存のユーザーに対するアプリケーションロールの割り当てを作成する必要があります。を使用してアプリケーションロールの割り当てを一括で作成する方法の詳細については、Microsoft Entra IDでアプリケーションの既存ユーザーを管理するを参照してください。

LDAP ディレクトリ内の既存のユーザーをまだ更新しない場合は、必要な属性を持ち、ディレクトリサーバーにプロビジョニングされるテストユーザーを Microsoft Entra ID から選択します。

ユーザーが選択するプロパティがすべて、ディレクトリサーバースキーマの必要な属性にマップされていることを確認します。
Azure portal で、エンタープライズアプリケーション選択します。
オンプレミスの ECMA アプリアプリケーションを選択します。
左側の [管理] で、[ユーザーとグループ] を選択します。
「ユーザー/グループ追加」を選択します。
[ユーザー] で [選択なし] を選択します。
右側からユーザーを選択し、[] ボタンを選択します。「ユーザーを選択」と表示されるスクリーンショットを示します。
次に、[割り当て] を選択します。

プロビジョニングのテスト

属性がマップされ、最初のユーザーが割り当てられたので、いずれかのユーザーでオンデマンドプロビジョニングをテストできます。

Microsoft Entra ECMA コネクタホストを実行しているサーバーで、[開始] を選択します。
「run」と入力し、ボックスに「services.msc」と入力します。
サービス の一覧で、Microsoft Entra Connect Provisioning Agent サービスと、Microsoft ECMA2Host サービスの両方が実行されていることを確認します。そうでない場合は、スタートを選択します。
Azure portal で、エンタープライズアプリケーション選択します。
オンプレミスの ECMA アプリアプリケーションを選択します。
左側で プロビジョニング を選択します。
[オンデマンドでプロビジョニングする] を選択します。
いずれかのテストユーザーを検索し、プロビジョニングを選択します。
数秒後、ターゲットシステムでユーザーが正常に作成されたメッセージが表示され、ユーザー属性の一覧が表示されます。代わりにエラーが表示される場合は、トラブルシューティングプロビジョニングエラーを参照してください。

ユーザーのプロビジョニングを開始する

オンデマンドプロビジョニングのテストが成功したら、残りのユーザーを追加します。を使用してアプリケーションロールの割り当てを一括で作成する方法の詳細については、Microsoft Entra IDでアプリケーションの既存ユーザーを管理するを参照してください。

Azure portal で、アプリケーションを選択します。
左側の [管理]で、[ユーザーとグループ]を選択します。
すべてのユーザーがアプリケーションロールに割り当てられていることを確認します。
プロビジョニング構成ページに戻ります。
スコープが割り当てられたユーザーとグループのみに設定されていることを確認し、プロビジョニングの状態を [オン] にして、[保存] 選択します。
プロビジョニングが開始されるまで数分待ってください。最大で 40 分かかる場合があります。次のセクションで説明するように、プロビジョニングジョブが完了したら、

プロビジョニングエラーのトラブルシューティング

エラーが表示された場合は、[プロビジョニングログ表示] を選択します。ログで、状態が [エラー]行を探し、その行を選択します。

エラーメッセージが ユーザーの作成に失敗した場合は、ディレクトリスキーマの要件に照らして表示される属性を確認します。

詳細については、「トラブルシューティング & 推奨事項」 タブに変更してください。

トラブルシューティングエラーメッセージに objectClass 値が invalid per syntaxされている場合は、objectClass 属性へのプロビジョニング属性マッピングに、ディレクトリサーバーによって認識されるオブジェクトクラスの名前のみが含まれていることを確認します。

その他のエラーについては、オンプレミスアプリケーションプロビジョニングのトラブルシューティングを参照してください。

このアプリケーションへのプロビジョニングを一時停止する場合は、プロビジョニング構成ページで、プロビジョニングの状態をオフに変更し、[保存] 選択します。このアクションにより、プロビジョニングサービスが将来実行されなくなります。

ユーザーが正常にプロビジョニングされたことを確認する

待機した後、ディレクトリサーバーを調べて、ユーザーがプロビジョニングされていることを確認します。ディレクトリサーバーに対して実行するクエリは、ディレクトリサーバーが提供するコマンドによって異なります。

次の手順は、Linux 上の OpenLDAP を確認する方法を示しています。

OpenLDAP を使用して、システム上のコマンドシェルを使用してターミナルウィンドウを開きます。
コマンド ldapsearch -D "cn=admin,dc=contoso,dc=lab" -W -s sub -b dc=contoso,dc=lab -LLL (objectclass=inetOrgPerson) を入力します
結果の LDIF に Microsoft Entra ID からプロビジョニングされたユーザーが含まれていることを確認します。

次の手順

プロビジョニングサービスの動作、しくみ、よく寄せられる質問の詳細については、「Microsoft Entra ID を使用して SaaS アプリケーションへのユーザープロビジョニングとプロビジョニング解除を自動化し、オンプレミスアプリケーションプロビジョニングアーキテクチャをする」を参照してください。

次の方法で共有

Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための Microsoft Entra ID の構成

Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための前提条件

オンプレミスの前提条件

クラウドの要件

その他の推奨事項と制限事項

Microsoft Entra LDAP コネクタがディレクトリサーバーと対話する方法を決定する

Microsoft Entra Connect プロビジョニングエージェントをインストールして構成する

オンプレミスの ECMA アプリを構成する

Microsoft Entra ECMA コネクタホスト証明書を構成する

汎用 LDAP コネクタを構成する

ECMA2Host サービスが実行されていて、ディレクトリサーバーから読み取ることができることを確認する

Microsoft Entra ID からコネクタホストへの接続をテストする

Microsoft Entra スキーマを拡張する

属性マッピングを構成する

ディレクトリにプロビジョニングするユーザーに必要な属性があることを確認する

PowerShell を使用したユーザーの確認

LDAP ディレクトリから既存のユーザーを収集する

Microsoft Entra ID でユーザーの ID を取得する

Microsoft Entra ID でアプリケーションにユーザーを割り当てる

プロビジョニングのテスト

ユーザーのプロビジョニングを開始する

プロビジョニングエラーのトラブルシューティング

ユーザーが正常にプロビジョニングされたことを確認する

次の手順

フィードバック

その他のリソース

次の方法で共有

Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための Microsoft Entra ID の構成

Linux 認証用の LDAP ディレクトリにユーザーをプロビジョニングするための前提条件

オンプレミスの前提条件

クラウドの要件

その他の推奨事項と制限事項

Microsoft Entra LDAP コネクタがディレクトリ サーバーと対話する方法を決定する

Microsoft Entra Connect プロビジョニング エージェントをインストールして構成する

オンプレミスの ECMA アプリを構成する

Microsoft Entra ECMA コネクタ ホスト証明書を構成する

汎用 LDAP コネクタを構成する

ECMA2Host サービスが実行されていて、ディレクトリ サーバーから読み取ることができることを確認する

Microsoft Entra ID からコネクタ ホストへの接続をテストする

Microsoft Entra スキーマを拡張する

属性マッピングを構成する

ディレクトリにプロビジョニングするユーザーに必要な属性があることを確認する

PowerShell を使用したユーザーの確認

LDAP ディレクトリから既存のユーザーを収集する

Microsoft Entra ID でユーザーの ID を取得する

Microsoft Entra ID でアプリケーションにユーザーを割り当てる

プロビジョニングのテスト

ユーザーのプロビジョニングを開始する

プロビジョニング エラーのトラブルシューティング

ユーザーが正常にプロビジョニングされたことを確認する

次の手順

フィードバック

その他のリソース

Microsoft Entra LDAP コネクタがディレクトリサーバーと対話する方法を決定する

Microsoft Entra Connect プロビジョニングエージェントをインストールして構成する

Microsoft Entra ECMA コネクタホスト証明書を構成する

ECMA2Host サービスが実行されていて、ディレクトリサーバーから読み取ることができることを確認する

Microsoft Entra ID からコネクタホストへの接続をテストする

プロビジョニングエラーのトラブルシューティング