次の方法で共有


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

次のドキュメントは、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 ServicesAzure ドメインへの送信接続が必要です。 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 のユーザーには識別名が存在しません。 その代わり、組織のディレクトリ サーバー スキーマに、mailemployeeId などの異なる属性があり、それが 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 プロビジョニング エージェントをインストールして構成する

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

[自動] を選択しているスクリーンショット。

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

エージェントのダウンロード場所のスクリーンショット。

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

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

  1. ポータルに戻り、[オンプレミス接続] セクションで、デプロイしたエージェントを選択し、[エージェントの割り当て] を選択します。

    エージェントを選択して割り当てる方法を示すスクリーンショット。

  2. このブラウザー ウィンドウを開いたままにして、構成ウィザードを使用して構成の次の手順を完了します。

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

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

注意

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

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

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

  1. コネクタに対する Microsoft Entra ID の認証のために使用するシークレット トークンを生成します。 これは、アプリケーションごとに最小 12 文字で、一意である必要があります。 シークレット ジェネレーターがまだない場合は、次のような PowerShell コマンドを使用して、ランダムな文字列の例を生成できます。

    -join (((48..90) + (96..122)) * 16 | Get-Random -Count 16 | % {[char]$_})
    
  2. まだ実行していない場合は、スタート メニューから Microsoft ECMA2Host 構成ウィザードを起動します。

  3. [新しいコネクタ] を選択します。 新しいコネクタの選択を示すスクリーンショット。

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

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

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

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

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

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

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

  10. [フル インポート] ページで、既定値を変更せずに [次へ] をクリックします。

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

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

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

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

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

注意

[Set attribute value](Set 属性値)を使用すると、ブール値のみが許可されることに注意してください。

  1. [完了] を選択します。

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

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

  1. Microsoft Entra ECMA コネクタ ホストを実行しているサーバーで、[開始] を選択します。
  2. [実行] を必要に応じて選択し、ボックスに「services.msc」と入力します。
  3. サービス リストで、Microsoft ECMA2Host が確実に存在し、実行中であるようにします。 実行されていない場合は、[開始] を選択します。 サービスが稼働中であることを示すスクリーンショット。
  4. 最近サービスを開始し、ディレクトリ サーバーに多数のユーザー オブジェクトがある場合は、コネクタがディレクトリ サーバーとの接続を確立するまで数分待ってください。
  5. Microsoft Entra ECMA コネクタ ホストを実行しているサーバーで、PowerShell を起動します。
  6. ECMA ホストがインストールされたフォルダー (C:\Program Files\Microsoft ECMA2Host など) に移動します。
  7. サブディレクトリ Troubleshooting に移動します。
  8. 次に示すように、そのディレクトリでスクリプト TestECMA2HostConnection.ps1 を実行し、コネクタ名と ObjectTypePathcache を引数として指定します。 コネクタ ホストが 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: ************
    
  9. スクリプトにエラーまたは警告メッセージが表示される場合は、サービスが実行されていることを確認し、コネクタ名とシークレット トークンが構成ウィザードで構成した値と一致していることを確認します。
  10. スクリプトに出力 False が表示される場合、コネクタは既存のユーザーのソース ディレクトリ サーバー内のエントリを認識していません。 これが新しいディレクトリ サーバーのインストールである場合、この動作は予期されたものであり、次のセクションに進むことができます。
  11. ただし、ディレクトリ サーバーに既に 1 人以上のユーザーが含まれているにもかかわらず、スクリプトは False を表示している場合、この状態はコネクタがディレクトリ サーバーから読み取れなかったことを示します。 プロビジョニングを試みた場合、Microsoft Entra ID でそのソース ディレクトリ内のユーザーと Microsoft Entra ID のユーザーが正しくマッチングされない可能性があります。 コネクタ ホストが既存のディレクトリ サーバーからのオブジェクトの読み取りを完了するまで数分待ってから、スクリプトを再実行します。 出力が引き続き False である場合は、コネクタの構成とディレクトリ サーバーのアクセス許可によってコネクタが既存のユーザーを読み取れるようにしていることを確認します。

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

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

    注意

    ウィンドウがタイムアウトした場合は、エージェントを再選択する必要があります。

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

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

    Note

    アプリケーションにエージェントを割り当てたばかりの場合は、登録が完了するまで 10 分間お待ちください。 登録が完了するまで、接続テストは機能しません。 サーバーでプロビジョニング エージェントを再起動してエージェントの登録を強制的に完了すると、登録プロセスを高速化することができます。 サーバーに移動して、Windows 検索バーでサービスを検索し、Microsoft Entra Connect プロビジョニング エージェント サービスを見つけたら、サービスを右クリックして再起動します。

  4. [接続のテスト] をクリックし、1 分待ちます。

  5. 接続テストが成功し、指定された資格情報が認可されてプロビジョニングが有効になったことが示されたら、[保存] を選択します
    エージェントのテストを示すスクリーンショット。

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 ユーザーの属性がコネクタを介してディレクトリ サーバーに送信され、その新しいオブジェクトの一部になります。

  1. Microsoft Entra 管理センターの [エンタープライズ アプリケーション] で、[オンプレミス ECMA アプリ] アプリケーションを選んでから、[プロビジョニング] ページを選びます。

  2. [プロビジョニングの編集] を選択します。

  3. [マッピング] を展開し、[Microsoft Entra ユーザーのプロビジョニング] を選びます。 このアプリケーションの属性マッピングを初めて構成した場合、プレースホルダーのマッピングは 1 つだけ存在します。

  4. ディレクトリ サーバーのスキーマが Microsoft Entra ID で使用可能であることを確認するには、[詳細オプションの表示] チェック ボックスをオンにして、[ScimOnPremises の属性リストの編集] を選択します。 構成ウィザードで選択したすべての属性が一覧表示されていることを確認します。 そうでない場合は、スキーマが更新されるまで数分待ってから、ナビゲーション行で [属性マッピング] を選択し、[ScimOnPremises の属性リストの編集] をもう一度選択してページを再読み込みします。 属性が一覧表示されたら、このページをキャンセルしてマッピングの一覧に戻ります。

  5. ディレクトリ内のすべてのユーザーが一意の識別名を持っている必要があります。 属性マッピングを使用して、コネクタで識別名を構築する方法を指定できます。 [新しいマッピングの追加] を選択します。 以下の値を使用してマッピングを作成し、式内の識別名を、組織単位またはターゲット ディレクトリ内の他のコンテナーの識別名と一致するように変更します。

    • マッピングの種類: 式
    • 式: Join("", "CN=", Word([userPrincipalName], 1, "@"), ",DC=Contoso,DC=lab")
    • ターゲット属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:-dn-
    • このマッピングを適用する: オブジェクトの作成時のみ
  6. ディレクトリ サーバーで objectClass 属性に複数の構造型オブジェクト クラス値または補助オブジェクト クラス値を指定する必要がある場合は、その属性にマッピングを追加します。 objectClass のマッピングを追加するには、[新しいマッピングの追加] を選択します。 次の値を使用してマッピングを作成し、式のオブジェクト クラス名をターゲット ディレクトリ スキーマの名前と一致するように変更します。

    • マッピングの種類: 式
    • 式 (POSIX スキーマをプロビジョニングする場合): Split("inetOrgPerson,posixAccount,shadowAccount",",")
    • ターゲット属性: urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:objectClass
    • このマッピングを適用する: オブジェクトの作成時のみ
  7. 次の表のディレクトリ サーバーの各マッピングについて、[新しいマッピングの追加] を選択し、基になる属性とターゲット属性を指定します。 既存のユーザーを含む既存のディレクトリにプロビジョニングしている場合は、共通する属性のマッピングを編集して、[この属性を使用してオブジェクトを照合する] をその属性に設定する必要があります。 属性マッピングの詳細については、こちらを参照してください。

    POSIX スキーマを使用する OpenLDAP の場合は、gidNumberhomeDirectoryuid および 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
  8. ユーザーの初期ランダム パスワードを設定するマッピングを urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:userPassword に追加します。

  9. [保存] を選択します。

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

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 コマンドレットを使用して、必要な属性のユーザー チェックを自動化できます。

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

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

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

  • ユーザー管理者、新しいユーザーの作成が予測される場合。
  • アプリケーション管理者または ID ガバナンス管理者、アプリケーション ロールの割り当ての管理だけを行う場合。
  1. PowerShell を開きます。

  2. Microsoft Graph PowerShell モジュールがまだインストールされていない場合は、次のコマンドを使用して Microsoft.Graph.Users モジュールなどをインストールします。

    Install-Module Microsoft.Graph
    

    これらのモジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
    
  3. Microsoft Entra ID に接続します。

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.Read.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"
    
  4. ユーザーの一覧と、チェックする属性を作成します。

    $userPrincipalNames = (
     "alice@contoso.com",
     "bob@contoso.com",
     "carol@contoso.com" )
    
    $requiredBaseAttributes = ("DisplayName","surname")
    $requiredExtensionAttributes = ("extension_656b1c479a814b1789844e76b2f459c3_MyNewProperty")
    
  5. 各ユーザーのディレクトリに対してクエリを実行します。

    $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 ディレクトリから既存のユーザーを収集する

  1. そのディレクトリ内のユーザーのうちのどれだけが、Linux 認証を持つユーザーのスコープ内に存在するかを識別します。 この選択は、Linux システムの構成によって異なります。 一部の構成では、LDAP ディレクトリに存在するすべてのユーザーが有効なユーザーとなります。 他の構成では、ユーザーが特定の属性を持っているか、またはそのディレクトリ内のグループのメンバーであることが必要な場合もあります。

  2. ユーザーのサブセットを LDAP ディレクトリから CSV ファイルに取得するコマンドを実行します。 その出力には、Microsoft Entra ID との照合に使用されるユーザーの属性が必ず含まれるようにしてください。 これらの属性の例には、従業員 ID、アカウント名または uid、電子メール アドレスなどがあります。

  3. 必要に応じて、ユーザーの一覧を含む CSV ファイルを Microsoft Graph PowerShell コマンドレットがインストールされているシステムに転送します。

  4. これで、ディレクトリから取得されたすべてのユーザーのリストが用意できたので、ディレクトリのそれらのユーザーを Microsoft Entra ID 内のユーザーと照合します。 先に進む前に、ソース システムとターゲット システム内のユーザーの照合に関する情報を確認します。

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

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

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

  • ユーザー管理者、新しいユーザーの作成が予測される場合。
  • アプリケーション管理者または ID ガバナンス管理者、アプリケーション ロールの割り当ての管理だけを行う場合。
  1. PowerShell を開きます。

  2. Microsoft Graph PowerShell モジュールがまだインストールされていない場合は、次のコマンドを使用して Microsoft.Graph.Users モジュールなどをインストールします。

    Install-Module Microsoft.Graph
    

    これらのモジュールが既にインストールされている場合は、最新バージョンを使用していることを確認します。

    Update-Module microsoft.graph.users,microsoft.graph.identity.governance,microsoft.graph.applications
    
  3. Microsoft Entra ID に接続します。

    $msg = Connect-MgGraph -ContextScope Process -Scopes "User.ReadWrite.All,Application.ReadWrite.All,AppRoleAssignment.ReadWrite.All,EntitlementManagement.ReadWrite.All"
    
  4. このコマンドを初めて使用する場合は、Microsoft Graph コマンド ライン ツールにこれらのアクセス許可を付与することを許可する必要があります。

  5. アプリケーションのデータ ストアから取得したユーザーの一覧を、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
    
  6. 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"
    
  7. 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 }
    }
    
    
  8. 前のクエリの結果を表示します。 エラーまたは一致が見つからないために、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." 
    
  9. このスクリプトは、完了時に、データ ソースのいずれかのレコードが Microsoft Entra ID に見つからなかった場合はエラーを示します。 アプリケーションのデータ ストアのユーザーのレコードのうち Microsoft Entra ID 内のユーザーとして見つからなかったものがある場合は、どのレコードが一致しなかったのかとその理由を調査する必要があります。

    たとえば、ユーザーのメールアドレスと userPrincipalName が Microsoft Entra ID で変更されたのに、アプリケーションのデータ ソースでそれに対応する mail プロパティが更新されていない可能性があります。 または、ユーザーは既に組織を離れているが、まだアプリケーションのデータ ソースに存在する可能性があります。 あるいは、アプリケーションのデータ ソースに、Microsoft Entra ID 内のどの特定のユーザーにも対応していないベンダーまたはスーパー管理者アカウントが存在する可能性もあります。

  10. Microsoft Entra ID で見つけられなかったか、またはアクティブかつサインインできる状態でなかったユーザーが存在したが、そのアクセスをレビューしたり、その属性を SAP Cloud Identity Services、データベース、またはディレクトリで更新したい場合は、アプリケーションまたは照合ルールを更新するか、そのユーザー用の Microsoft Entra ユーザーを更新する必要があります。 どの変更を行うかの詳細については、「Microsoft Entra ID のユーザーと一致しなかったアプリケーションのマッピングとユーザー アカウントを管理する」を参照してください。

    Microsoft Entra ID でユーザーを作成するオプションを選択した場合、次のいずれかを使用してユーザーを一括で作成できます。

    これらの新しいユーザーに、Microsoft Entra ID が後でアプリケーション内の既存のユーザーと一致するために必要な属性と、Microsoft Entra ID で必要な属性 (userPrincipalNamemailNicknamedisplayName を含む) が設定されていることを確認します。 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_namemailNickname でも 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
       }
    }
    
  11. 不足しているすべてのユーザーを 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 から必要な属性を持ち、ディレクトリ サーバーにプロビジョニングされるテスト ユーザーを選択します。

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

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

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

  1. Microsoft Entra ECMA コネクタ ホストを実行しているサーバーで、[開始] を選択します。

  2. 「run」 と入力し、ボックスに 「services.msc」 と入力します。

  3. [サービス] の一覧で、Microsoft Entra Connect プロビジョニング エージェント サービスと Microsoft ECMA2Host サービスの両方が実行されていることを確認します。 そうでない場合は、 [開始] を選択します。

  4. Azure portal で、 [エンタープライズ アプリケーション] を選択します。

  5. [オンプレミスの ECMA アプリ] アプリケーションを選択します。

  6. 左側で プロビジョニング を選択します。

  7. [Provision on demand] (オンデマンドでプロビジョニングする) を選択します。

  8. テスト ユーザーのものを検索し、 [プロビジョニング] を選択します。 オンデマンド プロビジョニングのテストを示すスクリーンショット。

  9. 数秒後に、ターゲット システムでユーザーが正常に作成されましたというメッセージが表示され、ユーザー属性の一覧が表示されます。 そうではなくエラーが表示される場合は、プロビジョニング エラーのトラブルシューティングに関する記事を参照してください。

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

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

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

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

エラーが表示された場合は、[プロビジョニング ログの表示] を選択します。 [状態] が [失敗] になっている行をログで確認し、その行をクリックします。

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

詳細については、[トラブルシューティングと推奨事項] タブに移動します。

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

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

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

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

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

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

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

次のステップ