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

[アーティクル]
02/13/2024

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

Note

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

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

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

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

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

オンプレミスの前提条件

PAM または NSS モジュールを使用してディレクトリサーバーに応答する Linux または他の POSIX サーバー。
ユーザーを作成、更新、削除できる POSIX スキーマ (OpenLDAP など) をサポートする LDAP ディレクトリサーバー。サポートされているディレクトリサーバーの詳細については、「汎用 LDAP コネクタリファレンス」を参照してください。
プロビジョニングエージェントをホストするための RAM が 3 GB 以上のコンピューター。このコンピューターには、Windows Server 2016 以降のバージョンの Windows Server の搭載、およびターゲットディレクトリへの接続と login.microsoftonline.com、その他の Microsoft Online Services、Azure ドメインへの送信接続が必要です。 1 つの例は、Azure IaaS でホストされているか、またはプロキシの背後にある Windows Server 2016 仮想マシンです。そのサーバーに .NET Framework 4.7.2 をインストールする必要があります。
省略可能: 必須ではありませんが、Windows Server 用の Microsoft Edge をダウンロードし、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 管理センターでプロビジョニングを構成するためのアプリケーション管理者ロールまたはクラウドアプリケーション管理者ロール。
LDAP ディレクトリにプロビジョニングされる Microsoft Entra ユーザーには、ディレクトリサーバースキーマで必要となる各ユーザーに固有の属性が既に設定されている必要があります。特に、各ユーザーには、ユーザー 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 portal の [プロビジョニング] ページの属性マッピング	`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 サーバー上のコネクタと併置されている場合またはネットワークレベルのセキュリティを使用している場合を除き、コネクタからディレクトリサーバーへのネットワーク接続は SSL または TLS を使用して保護する必要があります。コネクタでは、ポート 389 でのディレクトリサーバーへの接続と、セッション内での TLS の有効化に Start 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 アプリ アプリケーションを検索し、アプリに名前を付けて、[作成] を選択してテナントに追加します。
メニューから、アプリケーションの [プロビジョニング] ページに移動します。
[Get started](作業を開始する) を選択します。
[プロビジョニング] ページで、モードを [自動] に変更します。

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

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

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

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

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

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

注意

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

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

選択するオプションによっては、ウィザードの一部の画面を使用できない場合があり、情報も多少異なる可能性があります。次の情報を使用して構成を進めます。

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

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

プロパティ	値
名前	コネクタに対して選択した名前。これは、環境内のすべてのコネクタで一意である必要があります。たとえば、`LDAP` のようにします。
AutoSync タイマー (分)	120
シークレットトークン	ここにシークレットトークンを入力します。 12 文字以上である必要があります。
拡張 DLL	汎用 LDAP コネクタの場合、Microsoft.IAM.Connector.GenericLdap.dll を選択します。

[接続] ページで、ECMA Connector Host がディレクトリサーバーと通信する方法を構成し、いくつかの構成オプションを設定します。画像の下にある表に指定される値をボックスに入力し、[次へ] を選択します。 [次へ] を選択すると、コネクタによって、ディレクトリサーバーへの構成のクエリが実行されます。

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

Note

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

[グローバル] ページで、必要に応じて、差分変更ログの識別名およびその他の LDAP 機能を構成します。このページには、LDAP サーバーから提供された情報があらかじめ設定されています。表示されている値を確認し、[次へ] を選択します。

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

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

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

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

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

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

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

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

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

次の属性の表示範囲を構成します。

Attribute 1 つの値として扱う

_distinguishedName

-dn-

export_password

cn Y

gidNumber

homeDirectory

mail Y

objectClass

sn Y

uid Y

uidNumber

userPassword Y

関連するすべての属性が追加されたら、[次へ] を選択します。
[プロビジョニング解除] ページでは、ユーザーがアプリケーションの範囲外になったときに Microsoft Entra ID にディレクトリからユーザーを削除させるかどうかを指定することができます。その場合は、[フローの無効化] で [削除] を選択し、[フローの削除] で [削除] を選択します。 Set attribute value が選択されている場合は、前のページで選択した属性を [プロビジョニング解除] ページで選択することはできません。

Attribute	1 つの値として扱う
_distinguishedName
-dn-
export_password
cn	Y
gidNumber
homeDirectory
mail	Y
objectClass
sn	Y
uid	Y
uidNumber
userPassword	Y

注意

[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. [エンタープライズアプリケーション] の [On-premises ECMA app](オンプレミス ECMA アプリ) アプリケーションに移動します。
3. [プロビジョニング] をクリックします。
4. [概要] が表示された場合は、モードを [自動] に変更し、[オンプレミス接続] セクションで、デプロイしたエージェントを選択し、[エージェントの割り当て] を選択して 10 分間待ちます。それ以外の場合は、[プロビジョニングの編集] に移動します。
[管理者資格情報] セクションで、次の URL を入力します。 connectorName の部分を ECMA ホスト上のコネクタの名前 (LDAP など) に置き換えます。 ECMA ホストの証明機関の証明書を提供した場合は、localhost を ECMA ホストがインストールされているサーバーのホスト名に置き換えます。

プロパティ値

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

Note

アプリケーションにエージェントを割り当てたばかりの場合は、登録が完了するまで 10 分間お待ちください。登録が完了するまで、接続テストは機能しません。サーバーでプロビジョニングエージェントを再起動してエージェントの登録を強制的に完了すると、登録プロセスを高速化することができます。サーバーに移動して、Windows 検索バーでサービスを検索し、Microsoft Entra Connect プロビジョニングエージェント サービスを見つけたら、サービスを右クリックして再起動します。
[接続のテスト] をクリックし、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 管理センターの [エンタープライズアプリケーション] で、[オンプレミス 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
- このマッピングを適用する: オブジェクトの作成時のみ

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

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`
Expression	`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`
Expression	`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 が必要です。

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 を操作する方法を示します。

ユーザー管理者、新しいユーザーの作成が予測される場合。
アプリケーション管理者または 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.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 内のユーザーとして見つからなかったものがある場合は、どのレコードが一致しなかったのかとその理由を調査する必要があります。

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

Microsoft Entra ID でユーザーを作成するオプションを選択した場合、次のいずれかを使用してユーザーを一括で作成できます。
- CSV ファイル (「Microsoft Entra 管理センターでのユーザーの一括作成」で説明されています)
- 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"
```
そのような場合、このスクリプトを使用して、SAP Cloud Identity Services、データベース、またはディレクトリにある Microsoft Entra ID のユーザと一致しなかったユーザに対して 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 ディレクトリに既存のユーザーが存在する場合は、それらの既存のユーザー向けのアプリケーションロールの割り当てを作成する必要があります。 New-MgServicePrincipalAppRoleAssignedTo を使用してアプリケーションロールの割り当てを一括作成する方法の詳細については、「Microsoft Entra ID のアプリケーションの既存のユーザーの管理」に関する記事をご覧ください。

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

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

プロビジョニングをテストする

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

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

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

オンデマンドプロビジョニングのテストが成功したら、残りのユーザーを追加します。 New-MgServicePrincipalAppRoleAssignedTo を使用してアプリケーションロールの割り当てを一括作成する方法の詳細については、「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 からコネクタホストへの接続をテストする

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