次の方法で共有

Microsoft Entra ID を使用した自動ユーザー プロビジョニング用に Workday を構成する

この記事の目的は、Workday からオンプレミス Active Directory (AD) に worker プロファイルをプロビジョニングするために実行する必要がある手順を示することです。

注

Workday からプロビジョニングするユーザーにオンプレミスの AD アカウントと Microsoft Entra アカウントが必要な場合は、この記事を使用します。

  • Workday のユーザーが Microsoft Entra アカウント (クラウド専用ユーザー) のみを必要とする場合は、 Workday から Microsoft Entra ID への ユーザー プロビジョニングの構成に関する記事を参照してください。
  • Microsoft Entra ID から Workday への電子メール アドレス、ユーザー名、電話番号などの属性の書き戻しを構成するには、 Workday ライトバックの構成に関する記事を参照してください。

次のビデオでは、Workday とのプロビジョニング統合を計画するときに必要な手順の簡単な概要について説明します。

概要

Microsoft Entra ユーザー プロビジョニング サービスは、ユーザー アカウントをプロビジョニングするために Workday Human Resources API と統合されます。 Microsoft Entra のユーザー プロビジョニング サービスでサポートされている Workday ユーザー プロビジョニング ワークフローは、次の人事管理および ID ライフサイクル管理シナリオを自動化します。

新着情報

このセクションでは、最新の Workday 統合の機能強化について説明します。 包括的な更新プログラム、計画された変更、アーカイブの一覧については、「Microsoft Entra ID の新機能」を参照してください。

  • 2020 年 10 月 - Workday のオンデマンド プロビジョニングが有効になりました。オンデマンド プロビジョニングを使用すると、Workday で特定のユーザー プロファイルのエンド ツー エンド プロビジョニングをテストして、属性マッピングと式ロジックを確認できるようになりました。

  • 2020 年 5 月 - Workday に電話番号を書き戻す機能: メールとユーザー名に加えて、Microsoft Entra ID から Workday に職場の電話番号と携帯電話番号を書き戻すようになりました。 詳細については、 ライトバック アプリのチュートリアルを参照してください。

  • 2020 年 4 月 - Workday Web Services (WWS) API の最新バージョンのサポート: Workday では、3 月と 9 月に年 2 回、ビジネス目標の達成と従業員の需要の変化に役立つ機能豊富な更新プログラムを提供しています。 Workday が提供する新機能を活用していただくため、使用する WWS API バージョンを接続 URL で直接指定できます。 Workday API バージョンを指定する方法の詳細については、 Workday 接続の構成に関するセクションを参照してください。

このユーザー プロビジョニング ソリューションが最適な場合

この Workday ユーザー プロビジョニング ソリューションは、次のお客様に最適です。

  • Workday ユーザー プロビジョニング用に事前に構築されたクラウドベースのソリューションを求めている組織

  • Workday から Active Directory、または Microsoft Entra ID への直接ユーザー プロビジョニングを必要とする組織

  • Workday HCM モジュールから取得したデータを使用してユーザーをプロビジョニングする必要がある組織 ( Get_Workersを参照)

  • Workday HCM モジュールで検出された変更のみに基づいて、ユーザーの参加、移動、および離脱の動作を自動的に 1 つ以上の Active Directory フォレスト、ドメイン、OU に同期させる必要がある組織 (Get_Workersを参照)

  • 電子メールに Microsoft 365 を使用している組織

ソリューションのアーキテクチャ

このセクションでは、一般的なハイブリッド環境に向けた、エンド ツー エンドのユーザー プロビジョニング ソリューションのアーキテクチャについて説明します。 2 つの関連するフローがあります。

  • 権限のある HR データ フロー – Workday からオンプレミス Active Directory へ: このフローでは、新規採用、転送、退職などの worker イベントが最初にクラウド Workday HR テナントで発生し、次にイベント データが Microsoft Entra ID とプロビジョニング エージェントを介してオンプレミスの Active Directory に流れます。 イベントによっては、AD での作成/更新/有効化/無効化の操作に至る可能性があります。
  • ライトバック フロー – オンプレミスの Active Directory から Workday へ: Active Directory でアカウントの作成が完了すると、Microsoft Entra Connect を介して Microsoft Entra ID と同期され、メール、ユーザー名、電話番号などの情報を Workday に書き戻すことができます。

概要の概念図。

エンド ツー エンドのユーザー データ フロー

  1. 人事チームは、Workday HCM で社員のトランザクション (参加者/異動者/休暇者または新規雇用/移動/退職) を実行します
  2. Microsoft Entra プロビジョニング サービスは、Workday HR からの、スケジュールされた ID の同期を実行し、オンプレミスの Active Directory との同期のために処理する必要がある変更を識別します。
  3. Microsoft Entra プロビジョニング サービスは、AD アカウントの作成/更新/有効化/無効化の操作を含む要求ペイロードを使用して、オンプレミスの Microsoft Entra Connect プロビジョニング エージェントを呼び出します。
  4. Microsoft Entra Connect プロビジョニング エージェントは、サービス アカウントを使用して AD アカウントのデータを追加/更新します。
  5. Microsoft Entra Connect (AD の同期エンジン) は、デルタ同期を実行して AD 内の更新をプルします。
  6. Active Directory の更新は、Microsoft Entra ID と同期されます。
  7. Workday Writeback アプリが構成されている場合、電子メール、ユーザー名、電話番号などの属性が Workday に書き戻されます。

デプロイの計画

Workday から Active Directory へのユーザー プロビジョニングを構成するには、次のようなさまざまな側面をカバーする膨大な計画が必要です。

  • Microsoft Entra Connect プロビジョニング エージェントの設定
  • デプロイする Workday から AD へのユーザー プロビジョニング アプリの数
  • 一致する正しい識別子、属性マッピング、変換、スコープ フィルターの選択

包括的なガイドラインと推奨されるベスト プラクティスについては、 クラウド人事デプロイ計画 を参照してください。

Workday の統合システム ユーザーの構成

すべての Workday プロビジョニング コネクタに共通する要件は、Workday Human Resources API に接続するために、Workday 統合システム ユーザーの資格情報を必要とすることです。 このセクションでは、Workday で統合システムのユーザーを作成する方法について説明します。次のセクションがあります。

注

この手順を省略し、代わりに Workday 管理者アカウントをシステム統合アカウントとして使用することもできます。 これはデモでは問題なく動作するかもしれませんが、本番環境での展開にはお勧めできません。

統合システム ユーザーの作成

統合システム ユーザーを作成するには:

  1. 管理者アカウントを使用して Workday テナントにサインインします。 Workday アプリケーションで、検索ボックスに「ユーザーの作成」と入力し、[統合システム ユーザーの作成] をクリックします。

    ユーザーの作成のスクリーンショット。

  2. 新しい 統合システム・ユーザー のユーザー名とパスワードを指定して、「統合システム・ユーザーの作成」タスクを完了します。

    • [ 次のサインイン時に新しいパスワードを要求する ] オプションはオフのままにします。このユーザーはプログラムでログオンしているためです。
    • ユーザーのセッションが途中でタイムアウトするのを防ぐ、セッション タイムアウト分 の既定値は 0 のままにします。
    • 統合システムのパスワードを持つユーザーが Workday にログインできないようにするセキュリティレイヤーが追加されているため、[ UI セッションを許可しない ] オプションを選択します。

    統合システム ユーザーの作成のスクリーンショット。

統合セキュリティ グループの作成

この手順では、Workday 内に、制約のない、または制約付きの統合システム セキュリティ グループを作成し、このグループに、前の手順で作成した統合システム ユーザーを割り当てます。

セキュリティ グループを作成するには:

  1. 検索ボックスに「セキュリティ グループの作成」と入力し、[ セキュリティ グループの作成] をクリックします。

    検索ボックスに入力された

  2. [セキュリティ グループの作成] タスクを完了します。

    • Workday のセキュリティ グループには次の 2 種類があります。

      • 無制限： セキュリティ グループのすべてのメンバーは、そのグループによって保護されているすべてのデータ インスタンスにアクセスできます。
      • 制約： すべてのセキュリティ グループ メンバーは、セキュリティ グループがアクセスできるデータ インスタンス (行) のサブセットにコンテキスト アクセスできます。

    • 統合に適したセキュリティ グループの種類を選択するには、Workday 統合パートナーに確認してください。

    • グループの種類がわかったら、[テナントされたセキュリティ グループの種類] ドロップダウンから [統合システム セキュリティ グループ (制約なし)] または [統合システム セキュリティ グループ (制約あり)] を選択します。

      CreateSecurity グループのスクリーンショット。

  3. セキュリティ グループの作成が成功した後、セキュリティ グループにメンバーを割り当てることができるページが表示されます。 前の手順で作成した新しい統合システム ユーザーをこのセキュリティ グループに追加します。 "制約付き" セキュリティ グループを使用する場合は、適切な組織の範囲を選択する必要があります。

    [セキュリティ グループの編集] のスクリーンショット。

ドメイン セキュリティ ポリシーのアクセス許可の構成

この手順では、セキュリティ グループに、社員データについての "ドメイン セキュリティ" ポリシーのアクセス許可を付与します。

ドメイン セキュリティ ポリシーのアクセス許可を構成するには:

  1. 検索ボックスに 「セキュリティ グループのメンバーシップとアクセス」 と入力し、レポート リンクをクリックします。

    Search セキュリティ グループ メンバーシップのスクリーンショット。

  2. 前の手順で作成したセキュリティ グループを検索して選択します。

    [セキュリティ グループの選択] のスクリーンショット。

  3. グループ名の横にある省略記号 (...) をクリックし、メニューの [セキュリティ グループ] > [セキュリティ グループのドメインアクセス許可の維持] を選択します

    [ドメインのアクセス許可を管理] のスクリーンショット。

  4. [統合のアクセス許可] で、Put アクセスを許可するドメイン セキュリティ ポリシーの一覧に次のドメインを追加します

    • 外部アカウントのプロビジョニング
    • ワーカー データ: パブリック ワーカー レポート
    • 個人データ: 職場の連絡先情報 (Microsoft Entra ID から Workday に連絡先データを書き戻す場合に必要)
    • Workday アカウント (Microsoft Entra ID から Workday にユーザー名/UPN を書き戻す場合に必要)

  5. [統合のアクセス許可] で、アクセスを許可するドメイン セキュリティ ポリシーの一覧に次のドメインを追加します

    • 労働者データ: 労働者
    • ワーカーデータ: すべての職位
    • ワーカー データ: 現在のスタッフ情報
    • ワーカーデータ: ワーカープロファイルのビジネスタイトル
    • ワーカーデータ: 有資格作業者 (省略可能 - プロビジョニング用のワーカー資格データを取得するためにこれを追加)
    • Worker データ: スキルとエクスペリエンス (省略可能 - プロビジョニング用の worker スキル データを取得するためにこれを追加)

  6. 以上の手順が完了すると、次のようなアクセス許可画面が表示されます。

    すべてのドメインセキュリティ権限のスクリーンショット。

  7. 次の画面で [ OK] を クリックし 、[完了] をクリックして構成を完了します。

ビジネス プロセス セキュリティ ポリシーのアクセス許可の構成

この手順では、セキュリティ グループに、社員データについての "ビジネス プロセス セキュリティ" ポリシーのアクセス許可を付与します。

注

この手順は、Workday Writeback アプリのコネクタを設定するためにのみ必要です。

ビジネス プロセス セキュリティ ポリシーのアクセス許可を構成するには:

  1. 検索ボックスに 「業務プロセス ポリシー 」と入力し、[ ビジネス プロセス セキュリティ ポリシーの編集 ] タスクのリンクをクリックします。

    検索ボックスに [ビジネス プロセス ポリシー] と [ビジネス プロセス セキュリティ ポリシーの編集 - タスク] が選択されていることを示すスクリーンショット。

  2. [ 業務プロセスの種類 ] ボックスで、[ 連絡先 ] を検索し、[ Work Contact Change Business Process] を選択し、[OK] をクリック します。

    [ビジネス プロセス のセキュリティ ポリシーの編集] ページと、[ビジネス プロセスの種類] メニューで選択された [Work Contact Change]\(勤務先の連絡先の変更\) を示すスクリーンショット。

  3. [ ビジネス プロセス セキュリティ ポリシーの編集 ] ページで、[ 仕事用連絡先情報の変更 (Web サービス)] セクションまでスクロールします。

  4. 新しい統合システム セキュリティ グループを選択し、Web サービス要求を開始できるセキュリティ グループの一覧に追加します。

    ビジネス プロセス セキュリティ ポリシーのスクリーンショット。

  5. 完了をクリックします。

セキュリティ ポリシーの変更のアクティブ化

セキュリティ ポリシーの変更をアクティブにするには:

  1. 検索ボックスに「アクティブ化」と入力し、[保留中の セキュリティ ポリシーの変更をアクティブ化する] リンクをクリックします。

    「Activate」のスクリーンショット。

  2. 監査目的でコメントを入力して、[保留中のセキュリティ ポリシー変更のアクティブ化] タスクを開始し、[OK] をクリック します。

  3. 次の画面で[ 確認]チェックボックスをオンにしてタスクを完了し、[ OK]をクリックします。

    [保留中のセキュリティのアクティブ化] のスクリーンショット。

プロビジョニング エージェントのインストールの前提条件

次のセクションに進む前に 、プロビジョニング エージェントのインストールの前提条件 を確認します。

Workday から Active Directory へのユーザー プロビジョニングの構成

このセクションでは、Workday から、統合の範囲内にある各 Active Directory ドメインへのユーザー アカウントのプロビジョニングの手順について説明します。

パート 1: プロビジョニング コネクタ アプリを追加し、プロビジョニング エージェントをダウンロードする

Workday から Active Directory へのプロビジョニングを構成するには:

  1. Microsoft Entra 管理センターに、少なくともクラウド アプリケーション管理者としてサインインします。

  2. Entra ID>エンタープライズ アプリ>新しいアプリケーションに移動します。

  3. Workday から Active Directory へのユーザー プロビジョニングを検索し、ギャラリーからそのアプリを追加します。

  4. アプリが追加され、アプリの詳細画面が表示されたら、[ プロビジョニング] を選択します。

  5. [プロビジョニングモード] を [自動] に変更します。

  6. 表示された情報バナーをクリックして、プロビジョニング エージェントをダウンロードします。

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

パート 2: オンプレミス プロビジョニング エージェントのインストールと構成

オンプレミスの Active Directory にプロビジョニングするには、目的の Active Directory ドメインへのネットワーク アクセスを備えたドメイン参加済みのサーバーに、プロビジョニング エージェントがインストールされている必要があります。

ダウンロードしたエージェント インストーラーをサーバー ホストに転送し、「エージェントのインストール」セクションに記載されている手順に従ってエージェントの構成を完了します。

パート 3: プロビジョニング アプリで Workday と Active Directory への接続を構成する

この手順では、Workday および Active Directory との接続を確立します。

  1. Microsoft Entra 管理センターに、少なくともクラウド アプリケーション管理者としてサインインします。

  2. パート 1 で作成した >> Workday to Active Directory ユーザー プロビジョニング アプリを参照します。

  3. 次のように、[ 管理者資格情報] セクションに入力します。

    • Workday ユーザー名 – テナント ドメイン名が追加された Workday 統合システム アカウントのユーザー名を入力します。 次のようになります: username@tenant_name

    • Workday パスワード – Workday 統合システム アカウントのパスワードを入力します

    • Workday Web Services API URL – テナントの Workday Web サービス エンドポイントの URL を入力します。 URL によって、コネクタで使用される Workday Web Services API のバージョンが決まります。

      URL 形式 使用される WWS API のバージョン XPATH の変更が必要
      https://####.workday.com/ccx/service/tenantName v21.1 いいえ
      https://####.workday.com/ccx/service/tenantName/Human_Resources v21.1 いいえ
      https://####.workday.com/ccx/service/tenantName/Human_Resources/v##.# v##.# はい

      注

      URL にバージョン情報が指定されていない場合、アプリでは Workday Web Services (WWS) v21.1 が使用され、アプリに付属している既定の XPATH API 式の変更は必要ありません。 特定の WWS API バージョンを使用するには、URL の中にバージョン番号を指定します
      例: https://wd3-impl-services1.workday.com/ccx/service/contoso4/Human_Resources/v34.0

      WWS API v30.0 以降を使用している場合は、プロビジョニング ジョブを有効にする前に、[>] セクションと [>] セクションを参照する Workday の属性リストの編集で XPATH API 式を更新してください。

    • Active Directory フォレスト - エージェントに登録されている Active Directory ドメインの "名前" です。 ドロップダウンを使用して、プロビジョニングのターゲット ドメインを選択します。 通常、この値は次のような文字列です: contoso.com

    • Active Directory コンテナー - エージェントが既定でユーザー アカウントを作成するコンテナー DN を入力します。 例: OU=Standard Users,OU=Users,DC=contoso,DC=test

      注

      この設定は、 parentDistinguishedName 属性が属性マッピングで構成されていない場合にのみ、ユーザー アカウントの作成で有効になります。 この設定は、ユーザーの検索や更新の操作には使用されません。 ドメインのサブツリー全体が、検索操作の範囲内になります。

    • 通知メール – メール アドレスを入力し、[失敗した場合にメールを送信する] チェック ボックスをオンにします。

      注

      プロビジョニング ジョブが 検疫 状態になった場合、Microsoft Entra プロビジョニング サービスは電子メール通知を送信します。

    • [ テスト接続 ] ボタンをクリックします。 接続テストが成功した場合は、上部にある [保存 ] ボタンをクリックします。 失敗する場合は、エージェントのセットアップで構成された Workday 資格情報と AD 資格情報が有効であることを再確認します。

    • 資格情報が正常に保存されると、[マッピング] セクションに既定のマッピングの [Synchronize Workday Workers to On Premises Active Directory]\(Workday Workers をオンプレミス Active Directory に同期する\) が表示されます

パート 4:属性マッピングの構成

このセクションでは、ユーザー データが Workday から Active Directory に移動する方法を構成します。

  1. [ マッピング] の [プロビジョニング] タブで、[ Workday Worker をオンプレミス Active Directory に同期する] をクリックします。

  2. [ ソース オブジェクト スコープ] フィールドでは、属性ベースのフィルターのセットを定義することで、AD へのプロビジョニングのスコープに含める Workday のユーザー セットを選択できます。 既定のスコープは、"Workday のすべてのユーザー" です。 フィルターの例:

    • 例: 1000000 から 2000000 (2000000 を除く) までの Worker ID を持つユーザーにスコープを設定

      • 属性:WorkerID

      • 演算子:REGEX Match

      • 値:(1[0-9][0-9][0-9][0-9][0-9][0-9])

    • 例:臨時社員ではなく、従業員のみ

      • 属性:EmployeeID

      • 演算子: NULL でない

    ヒント

    初めてプロビジョニング アプリを構成するときは、属性マッピングと式をテストして検証し、目的の結果が得られていることを確認する必要があります。 Microsoft では、ソース オブジェクト スコープとオンデマンド プロビジョニングでスコープ フィルターを使用して、Workday のいくつかのテスト ユーザーとマッピングをテストすることをお勧めします。 マッピングが機能していることを確認したら、フィルターを削除するか、徐々に拡張してより多くのユーザーを含めることができます。

    注意事項

    プロビジョニング エンジンの既定の動作では、スコープ外に出るユーザーが無効化または削除されます。 これはご使用の Workday と AD の統合には望ましくない場合があります。 この既定の動作をオーバーライドするには、記事「スコープ外のユーザー アカウントの削除をスキップする」を参照してください

  3. [ ターゲット オブジェクト アクション] フィールドでは、Active Directory で実行されるアクションをグローバルにフィルター処理できます。 作成 と 更新 が最も一般的です。

  4. [ 属性マッピング ] セクションでは、個々の Workday 属性を Active Directory 属性にマップする方法を定義できます。

  5. 既存の属性マッピングをクリックして更新するか、画面の下部にある [ 新しいマッピングの追加 ] をクリックして新しいマッピングを追加します。 個々の属性マッピングは、次のプロパティをサポートしています。

    • マッピングの種類

    • ソース属性 - Workday のユーザー属性。 探している属性が存在しない場合は、 Workday ユーザー属性の一覧のカスタマイズを参照してください。

    • 既定値 – 省略可能。 ソース属性に空の値がある場合、マッピングではこの値が代わりに書き込まれます。 最も一般的な構成では、これを空白のままにします。

    • ターゲット属性 – Active Directory のユーザー属性。

    • この属性を使用してオブジェクトを照合 します。このマッピングを使用して、Workday と Active Directory の間でユーザーを一意に識別する必要があるかどうか。 この値は、通常、Workday の Worker ID フィールドで設定され、通常は Active Directory の従業員 ID 属性のいずれかにマップされます。

    • 一致する優先順位 – 複数の一致する属性を設定できます。 複数の場合は、このフィールドで定義された順序で評価されます。 1 件でも一致が見つかると、一致する属性の評価はそれ以上行われません。

    • このマッピングを適用する

      • 常に – ユーザー作成アクションと更新アクションの両方にこのマッピングを適用する

      • 作成時のみ - ユーザー作成アクションにのみこのマッピングを適用する

  6. マッピングを保存するには、[Attribute-Mapping] セクションの上部にある [ 保存 ] をクリックします。

    [保存] アクションが選択されている [属性マッピング] ページを示すスクリーンショット。

Workday と Active Directory との間の属性マッピングの例と、一般的に使用される式を次に示します

  • parentDistinguishedName 属性にマップされる式は、1 つ以上の Workday ソース属性に基づいてユーザーを別の OU にプロビジョニングするために使用されます。 この例では、所在する市区町村に基づいて、異なる OU にユーザーを配置しています。

  • Active Directory の userPrincipalName 属性は、重複除去関数 SelectUniqueValue を使用して生成されます。この関数は、ターゲット AD ドメインに生成された値が存在するかどうかをチェックし、一意の場合にのみ設定します。

  • ここに式の記述に関するドキュメントがあります。 このセクションでは、特殊文字を削除する方法の例についても紹介しています。

WORKDAY 属性 ACTIVE DIRECTORY 属性 ID 一致の有無 作成/更新
WorkerID 従業員ID はい 作成時のみ書き込まれる
PreferredNameData cn 作成時のみ書き込まれる
SelectUniqueValue( Join("@", Join("." , [FirstName], [LastName]), "contoso.com"), Join("@", Join(".", Mid([FirstName], 1, 1), [LastName]), "contoso.com"), Join("@", Join(".", Mid([FirstName], 1, 2), [LastName]), "contoso.com")) ユーザープリンシパル名 作成時のみ書き込まれる
Replace(Mid(Replace([UserID], , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , ) sAMAccountName (ユーザーログオン名) 作成時のみ書き込まれる
Switch([Active], , "0", "真", "1", "偽") アカウントが無効化されました 作成時 + 更新時
FirstName givenName 作成時 + 更新時
LastName エスエヌ 作成時 + 更新時
PreferredNameData 表示名 作成時 + 更新時
会社 会社 作成時 + 更新時
監督組織 部 作成時 + 更新時
ManagerReference マネージャー 作成時 + 更新時
BusinessTitle タイトル 作成時 + 更新時
AddressLineData 住所 作成時 + 更新時
自治体 l 作成時 + 更新時
CountryReferenceTwoLetter 会社 作成時 + 更新時
CountryReferenceTwoLetter c 作成時 + 更新時
CountryRegionReference 聖 作成時 + 更新時
WorkSpaceReference 物理配送オフィス名 作成時 + 更新時
PostalCode 郵便番号 作成時 + 更新時
勤務先主要電話番号 電話番号 作成時 + 更新時
ファックス ファクシミリ電話番号 作成時 + 更新時
モバイル 携帯電話 作成時 + 更新時
LocalReference 優先言語 作成時 + 更新時
Switch([市区町村], "OU=Default Users,DC=contoso,DC=com", "Dallas", "OU=Dallas,OU=Users,DC=contoso,DC=com", "Austin", "OU=Austin,OU=Users,DC=contoso,DC=com", "Seattle", "OU=Seattle,OU=Users,DC=contoso,DC=com", "London", "OU=London,OU=Users,DC=contoso,DC=com") 親ディスティングイッシュド・ネーム 作成時 + 更新時

属性マッピングの構成が完了したら、オンデマンド プロビジョニングを使用して 1 人のユーザーのプロビジョニング を テストし、 ユーザー プロビジョニング サービスを有効にして起動できます。

ユーザー プロビジョニングの有効化と起動

Workday プロビジョニング アプリの構成が完了し、オンデマンド プロビジョニングを使用して 1 人のユーザーのプロビジョニング を確認したら、プロビジョニング サービスを有効にすることができます。

ヒント

既定では、プロビジョニング サービスを有効にすると、スコープ内のすべてのユーザーに対してプロビジョニング操作が開始されます。 マッピングのエラーまたは Workday データの問題がある場合、プロビジョニング ジョブが失敗し、検疫状態になる可能性があります。 これを回避するには、ベスト プラクティスとして、すべてのユーザーの完全同期を起動する前に、オンデマンド プロビジョニングを使用して、ソース オブジェクト スコープ フィルターを構成し、少数のテスト ユーザーで属性マッピングをテストすることをお勧めします。 マッピングが機能し、目的の結果が得られていることを確認したら、フィルターを削除するか、徐々に拡張してより多くのユーザーを含めることができます。

  1. [ プロビジョニング ] ブレードに移動し、[ プロビジョニングの開始] をクリックします。

  2. この操作により初期同期が開始されます。これに要する時間は Workday テナントのユーザー数に応じて変わります。 進行状況バーをチェックして、同期サイクルの進行状況を追跡できます。

  3. いつでも、Microsoft Entra 管理センターの [ プロビジョニング ] タブで、プロビジョニング サービスが実行したアクションを確認します。 プロビジョニング ログには、Workday から読み込まれたユーザーや、その後 Active Directory に追加または更新されたユーザーなど、プロビジョニング サービスによって実行された個々の同期イベントがすべて表示されます。 プロビジョニング ログを確認してプロビジョニング エラーを修正する方法の手順については、トラブルシューティングに関するセクションを参照してください。

  4. 初期同期が完了すると、次に示すように、[ プロビジョニング ] タブに監査概要レポートが書き込まれます。

    プロビジョニングの進行状況バーのスクリーンショット

よくあるご質問 (FAQ)

ソリューションの機能に関する質問

Workday の新規採用者を処理するときに、ソリューションは Active Directory の新規ユーザー アカウントのパスワードをどのように設定しますか。

オンプレミス プロビジョニング エージェントで、新しい AD アカウントの作成要求を受け取ると、AD サーバーによって定義されたパスワードの複雑さの要件を満たすように設計された複雑なランダム パスワードが自動的に生成され、それがユーザー オブジェクトに設定されます。 このパスワードはどこにも記録されません。

ソリューションは、プロビジョニング操作の完了後にメール通知を送信することをサポートしていますか。

いいえ。プロビジョニング操作の完了後のメール通知送信は、現在のリリースではサポートされていません。

ソリューションでは、Microsoft Entra クラウドまたはプロビジョニング エージェント レイヤーに Workday ユーザープロファイルがキャッシュされますか。

いいえ。このソリューションではユーザー プロファイルのキャッシュが保持されません。 Microsoft Entra プロビジョニング サービスは単なるデータ プロセッサとして機能し、Workday からデータを読み取り、ターゲット Active Directory または Microsoft Entra に書き込みます。 ユーザーのプライバシーとデータ保持に関する詳細については、「 個人データの管理 」セクションを参照してください。

ソリューションは、オンプレミスの AD グループをユーザーに割り当てることをサポートしていますか。

この機能は現在サポートされていません。 推奨される回避策は、Microsoft Graph API エンドポイントにクエリを実行して ログ データをプロビジョニング し、グループの割り当てなどのシナリオをトリガーするために使用する PowerShell スクリプトをデプロイすることです。 この PowerShell スクリプトは、タスク スケジューラにアタッチして、プロビジョニング エージェントを実行している同じボックスにデプロイできます。

Workday の従業員プロファイルのクエリと更新にこのソリューションが使用する Workday API はどれですか。

現在、このソリューションは次の Workday API を使用しています。

  • [管理者資格情報] セクションで使用される Workday Web サービス API URL 形式によって、Get_Workersに使用される API のバージョンが決まります

    • URL の形式が https://####.workday.com/ccx/service/tenantName の場合は、API v21.1 が使用されます。
    • URL の形式が https://####.workday.com/ccx/service/tenantName/Human_Resources の場合は、API v21.1 が使用されます。
    • URL 形式が https://####.workday.com/ccx/service/tenantName/Human_Resources/v##.# の場合は、指定された API バージョンが使用されます。 (例: v34.0 が指定されると、これが使用されます)。

  • Workday メール書き戻し機能は Change_Work_Contact_Information (v30.0) を使用します

  • Workday ユーザー名書き戻し機能は Update_Workday_Account (v31.2) を使用します

2 つの Microsoft Entra テナントを持つ Workday HCM テナントは構成できますか。

はい。この構成はサポートされています。 このシナリオを構成する手順の概要を次に示します。

  • プロビジョニング エージェント 1 をデプロイし、Microsoft Entra テナント 1 に登録します。
  • プロビジョニング エージェント 2 をデプロイし、Microsoft Entra テナント 2 に登録します。
  • 各プロビジョニング エージェントが管理する "子ドメイン" に基づいて、各エージェントとドメインを構成します。 1 つのエージェントで複数のドメインを処理できます。
  • Microsoft Entra 管理センターで、各テナントの Workday to AD User Provisioning アプリを設定し、それぞれのドメインと共に構成します。

今後のリリースや機能強化の方向性を決める上でお客様のフィードバックはとても貴重です。 Microsoft Entra ID のフィードバック フォーラムで、すべてのフィードバックを歓迎し、アイデアや改善の提案を送信することをお勧めします。 Workday 統合に関連する特定のフィードバックについては、 カテゴリ SaaS アプリケーション を選択し、Workday キーワードを使用して検索し、 Workday に関連する既存のフィードバックを見つけます。

UserVoice Workday のスクリーンショット。

新しいアイデアを提案するときは、他のユーザーが既に同様の機能を提案しているかどうかを確認してください。 その場合は、機能や機能強化のリクエストに賛成を投票することができます。 また、特定のユース ケースについてコメントを残してアイデアを支持していることを示し、その機能がお客様にとってどのように価値があるかを示すこともできます。

プロビジョニング エージェントに関する質問

プロビジョニング エージェントの一般提供 (GA) バージョンは何ですか。

プロビジョニング エージェントの最新の GA バージョンについては、 Microsoft Entra Connect プロビジョニング エージェントのバージョン リリース履歴 を参照してください。

プロビジョニング エージェントのバージョンを確認する方法を教えてください。

  1. プロビジョニング エージェントがインストールされている Windows サーバーにサインインします。
  2. [コントロール パネル]>[プログラムのインストールを取り消す]または[プログラムの変更]メニューに移動します。
  3. Microsoft Entra Connect プロビジョニング エージェントのエントリに対応するバージョンを探します。

Microsoft からプロビジョニング エージェントの更新プログラムは自動的にプッシュされますか。

はい。Windows サービス Microsoft Entra Connect Agent Updater が稼働している場合、Microsoft はプロビジョニング エージェントを自動的に更新します。

Microsoft Entra Connect を実行しているのと同じサーバーにプロビジョニング エージェントをインストールできますか。

はい、Microsoft Entra Connect を実行しているのと同じサーバーにプロビジョニング エージェントをインストールすることができます。

構成時に、プロビジョニング エージェントでは Microsoft Entra 管理者の資格情報が求められます。 エージェントでは、資格情報がサーバー上のローカルに保存されますか。

構成時に、プロビジョニング エージェントでは、Microsoft Entra テナントに接続するときにのみ、Microsoft Entra 管理者の資格情報が求められます。 エージェントでは、資格情報がサーバー上のローカルに保存されません。 ただし、ローカルの Windows パスワード コンテナー内の オンプレミス Active Directory ドメイン への接続に使用される資格情報は保持されます。

送信 HTTP 通信にプロキシ サーバーを使用するようにプロビジョニング エージェントを構成するにはどうすればよいですか。

プロビジョニング エージェントは送信プロキシの使用をサポートしています。 エージェント 構成ファイルC:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.configを編集して構成できます。終了 </configuration> タグの直前のファイルの末尾に、次の行を追加します。 変数 [proxy-server] と [proxy-port] をお客様のプロキシ サーバー名とポート値に置き換えてください。

    <system.net>
          <defaultProxy enabled="true" useDefaultCredentials="true">
             <proxy
                usesystemdefault="true"
                proxyaddress="http://[proxy-server]:[proxy-port]"
                bypassonlocal="true"
             />
         </defaultProxy>
    </system.net>

プロビジョニング エージェントが Microsoft Entra テナントと通信できること、ファイアウォールがエージェントに必要なポートをブロックしていないことを確認するにはどうすればよいですか。

必要なすべてのポートが開いているかどうかを確認することもできます。

1 つのプロビジョニング エージェントを複数の AD ドメインをプロビジョニングするように構成できますか。

はい。1 つのプロビジョニング エージェントは、そのエージェントから各ドメイン コントローラーへの通信経路がある限り、複数の AD ドメインを処理するように構成できます。 高可用性を確保し、フェールオーバーをサポートするために、同じ AD ドメインのセットにサービスを提供する 3 つのプロビジョニング エージェントのグループを設定することをお勧めします。

プロビジョニング エージェントに関連付けられているドメインの登録を解除するにはどうすればよいですか。

*、Microsoft Entra テナントのテナント ID を 取得します。

  • プロビジョニング エージェントを実行している Windows サーバーにサインインします。

  • Windows 管理者として PowerShell を開きます。

  • 登録スクリプトを含むディレクトリに移動し、[tenant ID] パラメーターをお客様のテナント ID の値に置き換えて、次のコマンドを実行します。

    cd "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\RegistrationPowershell\Modules\PSModulesFolder"
Import-Module "C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\RegistrationPowershell\Modules\PSModulesFolder\MicrosoftEntraPrivateNetworkConnectorPSModule.psd1"
Get-PublishedResources -TenantId "[tenant ID]"

  • 表示されるエージェントの一覧から、id が AD ドメイン名と等しいリソースの フィールドの値をコピーします。

  • このコマンドに ID 値を貼り付けて、PowerShell でコマンドを実行します。

    Remove-PublishedResource -ResourceId "[resource ID]" -TenantId "[tenant ID]"

  • Agent configuration (エージェントの構成) ウィザードを再実行します。

  • 以前にこのドメインに割り当てられていた他のエージェントがある場合は、すべて再構成する必要があります。

プロビジョニング エージェントをアンインストールするにはどうすればよいですか。

  • プロビジョニング エージェントがインストールされている Windows サーバーにサインインします。
  • [コントロール パネル] に移動>プログラムメニューのインストールまたは変更を行う
  • 次のプログラムをアンインストールします。
    • Microsoft Entra Connect プロビジョニング エージェント
    • Microsoft Entra Connect エージェント アップデーター
    • Microsoft Entra Connect プロビジョニング エージェント パッケージ

Workday から AD への属性マッピングと構成に関する質問

Workday プロビジョニング属性マッピングとスキーマの作業用コピーをバックアップまたはエクスポートするにはどうすればよいですか。

Microsoft Graph API を使用して、Workday のユーザー プロビジョニング構成をエクスポートできます。 詳細については、「 Workday ユーザー プロビジョニング属性マッピング構成のエクスポートとインポート 」セクションの手順を参照してください。

Workday と Active Directory にカスタム属性があります。 カスタム属性と連携するようにソリューションを構成するにはどうすればよいですか。

このソリューションは、カスタムの Workday 属性と Active Directory 属性をサポートしています。 カスタム属性をマッピング スキーマに追加するには、[ 属性マッピング ] ブレードを開き、下にスクロールして [ 詳細オプションの表示] セクションを展開します。

属性リストの編集のスクリーンショット。

カスタム Workday 属性を追加するには、 Workday の [属性リストの編集] オプションを選択し、カスタム AD 属性を追加するには、[ オンプレミス Active Directory] の [属性リストの編集] オプションを選択します。

関連項目:

Workday の変更に基づいて AD 内の属性のみを更新し、新しい AD アカウントを作成しないようにソリューションを構成するにはどうすればよいですか。

この構成は、次に示すように、[属性マッピング] ブレードでターゲット オブジェクト アクションを設定することで実現できます。

Update アクションのスクリーンショット。

Workday から AD 方向の更新操作のみを実行するには、[更新] チェックボックスをオンにします。

ユーザーの写真を Workday から Active Directory にプロビジョニングできますか。

現在、このソリューションでは、Active Directory での thumbnailPhoto や jpegPhoto などのバイナリ属性の設定はサポートされていません。

  • Workday Provisioning アプリの [プロビジョニング] ブレードに移動します。

  • [属性マッピング] をクリックします

  • [ マッピング] で、[ Workday Worker をオンプレミス Active Directory に同期 する] (または [Workday Worker を Microsoft Entra ID に同期する] を選択します)。

  • [属性マッピング] ページで、下にスクロールして [詳細オプションの表示] チェックボックスをオンにします。 Workday の [属性リストの編集] をクリックします

  • 開いたブレードで「Mobile」属性を見つけ、行をクリックしてAPI 式を編集できるようにします。Mobile GDPR のスクリーンショット。

  • API 式を次の新しい式に置き換えます。この式は、Workday で "Public Usage Flag" が "True" に設定されている場合にのみ、職場の携帯電話番号を取得します。

     wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Contact_Data/wd:Phone_Data[translate(string(wd:Phone_Device_Type_Reference/@wd:Descriptor),'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ')='MOBILE' and translate(string(wd:Usage_Data/wd:Type_Data/wd:Type_Reference/@wd:Descriptor),'abcdefghijklmnopqrstuvwxyz','ABCDEFGHIJKLMNOPQRSTUVWXYZ')='WORK' and string(wd:Usage_Data/@wd:Public)='1']/@wd:Formatted_Phone

  • 属性リストを保存します。

  • 属性マッピングを保存します。

  • 現在の状態を消去して、完全な同期を再開します。

ユーザーの部署/国/市区町村の属性に基づいて AD の表示名の書式を設定し、地域の差異を処理するにはどうすればよいですか。

ユーザーの部署と国/地域に関する情報も提供されるように、AD で displayName 属性を構成することは一般的な要件です。 たとえば、John Smith が米国のマーケティング部門で働いている場合、 displayName を Smith、John (Marketing-US) として表示できます。

CN またはdisplayName を構築するためのこのような要件を処理して、会社、部署、市区町村、国/地域などの属性を含める方法を次に示します。

  • 各 Workday 属性は、基になる XPATH API 式を使用して取得されます。これは、 属性マッピング -> 詳細セクション -> Workday の属性リストの編集で構成できます。 Workday PreferredFirstName、 PreferredLastName、 Company 属性、 SupervisoryOrganization 属性の既定の XPATH API 式を次に示します。

    Workday 属性 API XPATH 式
    優先使用名 wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Preferred_Name_Data/wd:Name_Detail_Data/wd:First_Name/text()
    希望の苗字 wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Name_Data/wd:Preferred_Name_Data/wd:Name_Detail_Data/wd:Last_Name/text()
    [会社] wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data[wd:Organization_Data/wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']='Company']/wd:Organization_Reference/@wd:Descriptor
    監督組織 wd:Worker/wd:Worker_Data/wd:Organization_Data/wd:Worker_Organization_Data/wd:Organization_Data[wd:Organization_Type_Reference/wd:ID[@wd:type='Organization_Type_ID']='Supervisory']/wd:Organization_Name/text()

    上記の API 式がお客様の Workday テナント構成で有効であることをお客様の Workday チームに確認してください。 必要に応じて、 Workday ユーザー属性の一覧のカスタマイズセクションの説明に従って編集できます。

  • 同様に、Workday に存在する国/地域情報は、次の XPATH を使用して取得されます: wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference

    Workday 属性リスト セクションで使用できる国/地域関連の属性が 5 つあります。

    Workday 属性 API XPATH 式
    CountryReference wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[@wd:type='ISO_3166-1_Alpha-3_Code']/text()
    カントリーリファレンスフレンドリー wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/@wd:Descriptor
    国参照数値 wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[@wd:type='ISO_3166-1_Numeric-3_Code']/text()
    国リファレンス2文字 wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Reference/wd:ID[@wd:type='ISO_3166-1_Alpha-2_Code']/text()
    国地域リファレンス wd:Worker/wd:Worker_Data/wd:Employment_Data/wd:Position_Data/wd:Business_Site_Summary_Data/wd:Address_Data/wd:Country_Region_Reference/@wd:Descriptor

    上の API 式がお客様の Workday テナント構成で有効であることをお客様の Workday チームに確認してください。 必要に応じて、 Workday ユーザー属性の一覧のカスタマイズセクションの説明に従って編集できます。

  • 正しい属性マッピング式を構築するには、どの Workday 属性が "正式に" ユーザーの姓、名、国/地域、部署を表すかを特定します。 属性がそれぞれ PreferredFirstName、 PreferredLastName、 CountryReferenceTwoLetter 、 SupervisoryOrganization であるとします。 これを使用して、次のように AD displayName 属性の式を作成し 、Smith、John (Marketing-US) などの表示名を取得できます。

     Append(Join(", ",[PreferredLastName],[PreferredFirstName]), Join(""," (",[SupervisoryOrganization],"-",[CountryReferenceTwoLetter],")"))

    適切な式を作成したら、[属性マッピング] テーブルを編集し、 displayName 属性マッピングを次のように変更します。 DisplayName マッピングのスクリーンショット。

  • 上記の例を拡張して、Workday から取得した都市名を短縮形の値に変換し、それを使用して Smith、John (CHI)、Doe、Jane (NYC) などの表示名を作成すると、この結果は、Workday 市区町村属性を決定変数として使用して実現できます。

    Switch
(
  [Municipality],
  Join(", ", [PreferredLastName], [PreferredFirstName]),  
       "Chicago", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(CHI)"),
       "New York", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(NYC)"),
       "Phoenix", Append(Join(", ",[PreferredLastName], [PreferredFirstName]), "(PHX)")
)

    関連項目:

SelectUniqueValue を使用して samAccountName 属性の一意の値を生成する方法を教えてください。

たとえば、Workday の FirstName 属性と LastName 属性の組み合わせを使用して、samAccountName 属性の一意の値を生成するとします。 以下の式を基にして始めることができます。

SelectUniqueValue(
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,1), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , ),
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,2), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , ),
    Replace(Mid(Replace(NormalizeDiacritics(StripSpaces(Join("",  Mid([FirstName],1,3), [LastName]))), , "([\\/\\\\\\[\\]\\:\\;\\|\\=\\,\\+\\*\\?\\<\\>])", , "", , ), 1, 20), , "(\\.)*$", , "", , )
)

上の式は次のように機能します。ユーザーが John Smith の場合は、まず JSmith の生成が試行され、JSmith が既に存在する場合は JoSmith が生成され、それが存在する場合は JohSmith が生成されます。 また、この式により、生成される値が samAccountName に関連付けられている長さの制限と特殊文字の制限を満たしていることも保証されます。

関連項目:

分音記号を使用する文字を削除し、通常の英語のアルファベットに変換するにはどうすればよいですか。

NormalizeDiacritics 関数を使用して、ユーザーの電子メール アドレスまたは CN 値を構築しながら、ユーザーの名と姓の特殊文字を削除します。

トラブルシューティングのヒント

このセクションでは、Microsoft Entra プロビジョニング ログと Windows Server イベント ビューアー ログを使用して、Workday 統合に関するプロビジョニングの問題を解決する方法について、具体的なガイダンスを提供します。 これは、「チュートリアル: 自動ユーザー アカウント プロビジョニングに関するレポート」でキャプチャした一般的なトラブルシューティング手順と概念に基づいています

このセクションでは、トラブルシューティングの次の側面について説明しています。

イベント ビューアー ログを出力するようにプロビジョニング エージェントを構成する

  1. プロビジョニング エージェントがデプロイされている Windows Server マシンにサインインします。

  2. サービス Microsoft Entra Connect プロビジョニング エージェントを停止します。

  3. 元の構成ファイルのコピーを作成 します:C:\Program Files\Microsoft Azure AD Connect Provisioning Agent\AADConnectProvisioningAgent.exe.config。

  4. 既存の <system.diagnostics> セクションを以下の内容に置き換えます。

    • リスナー構成 etw は EventViewer ログにメッセージを出力します
    • リスナー構成 textWriterListener は、トレース メッセージをファイル ProvAgentTrace.logに送信します。 高度なトラブルシューティングを行う場合のみ、textWriterListener に関連した行をコメント解除してください。
      <system.diagnostics>
      <sources>
      <source name="AAD Connect Provisioning Agent">
          <listeners>
          <add name="console"/>
          <add name="etw"/>
          <!-- <add name="textWriterListener"/> -->
          </listeners>
      </source>
      </sources>
      <sharedListeners>
      <add name="console" type="System.Diagnostics.ConsoleTraceListener" initializeData="false"/>
      <add name="etw" type="System.Diagnostics.EventLogTraceListener" initializeData="Azure AD Connect Provisioning Agent">
          <filter type="System.Diagnostics.EventTypeFilter" initializeData="All"/>
      </add>
      <!-- <add name="textWriterListener" type="System.Diagnostics.TextWriterTraceListener" initializeData="C:/ProgramData/Microsoft/Azure AD Connect Provisioning Agent/Trace/ProvAgentTrace.log"/> -->
      </sharedListeners>
  </system.diagnostics>

  5. サービス Microsoft Entra Connect プロビジョニング エージェントを開始します。

エージェントのトラブルシューティングのための Windows イベント ビューアーの設定

  1. プロビジョニング エージェントがデプロイされている Windows Server マシンにサインインします。

  2. Windows Server イベント ビューアー デスクトップ アプリを開きます。

  3. [Windows ログ > アプリケーション] を選択します。

  4. 次に示すようにフィルター "-5" を指定して、ソースの Microsoft Entra Connect プロビジョニング エージェントでログに記録されたすべてのイベントを表示し、イベント ID が "5" のイベントを除外するには、[現在のログのフィルター]... オプションを使用します。

    注

    イベント ID 5 でキャプチャされるのは Microsoft Entra クラウド サービスに対するエージェントのブートストラップ メッセージであるため、ログ ファイルを分析する間はフィルターで除外します。

    Windows イベント ビューアーのスクリーンショット。

  5. [ OK] を クリックし、結果ビューを 日付と時刻 の列で並べ替えます。

サービスのトラブルシューティングのための Microsoft Entra 管理センター プロビジョニング ログの設定

  1. Microsoft Entra 管理センターを起動し、Workday プロビジョニング アプリケーションの [プロビジョニング] セクションに移動します。

  2. [プロビジョニング ログ] ページの [列 ] ボタンを使用して、ビューに次の列 (日付、アクティビティ、状態、状態の理由) のみを表示します。 この構成にすることで、トラブルシューティングに関連するデータのみに確実に集中できます。

    プロビジョニング ログ列のスクリーンショット。

  3. [ターゲット] および [日付範囲] クエリ パラメーターを使用して、ビューをフィルター処理します。

    • Target クエリ パラメーターを Workday worker オブジェクトの "Worker ID" または "Employee ID" に設定します。
    • 日付範囲を、プロビジョニングに関するエラーや問題を調査する適切な期間に設定します。

    プロビジョニング ログ フィルターのスクリーンショット。

AD ユーザー アカウントの作成操作のログの概要

Workday の新入社員が検出されると (たとえば、Employee ID 21023 とします)、Microsoft Entra プロビジョニング サービスは、ワーカーの新しい AD ユーザー アカウントの作成を試み、プロセスで次に説明するように 4 つのプロビジョニング ログ レコードを作成します。

プロビジョニング ログの作成操作のスクリーンショット。

プロビジョニング ログ レコードのいずれかをクリックすると、[ アクティビティの詳細] ページが開きます。 各ログ レコードの種類に対して [ アクティビティの詳細] ページが表示される内容を次に示します。

  • Workday インポート レコード: このログ レコードには、Workday からフェッチされたワーカー情報が表示されます。 ログ レコードの [追加の詳細] セクションの情報を使用して、Workday からのデータのフェッチに関する問題のトラブルシューティングを行います。 レコードの例を、各フィールドの解釈方法についてのポインターと共に次に示します。

    ErrorCode : None  // Use the error code captured here to troubleshoot Workday issues
EventName : EntryImportAdd // For full sync, value is "EntryImportAdd" and for delta sync, value is "EntryImport"
JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID (usually the Worker ID or Employee ID field)
SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the record

  • AD インポート レコード: このログ レコードには、AD からフェッチされたアカウントの情報が表示されます。 最初のユーザー作成時には AD アカウントがないため、アクティビティの [状態の理由] は、その照合 ID 属性値を持つアカウントが Active Directory に見つからなかったことを示します。 ログ レコードの [追加の詳細] セクションの情報を使用して、Workday からのデータのフェッチに関する問題のトラブルシューティングを行います。 レコードの例を、各フィールドの解釈方法についてのポインターと共に次に示します。

    ErrorCode : None // Use the error code captured here to troubleshoot Workday issues
EventName : EntryImportObjectNotFound // Implies that object wasn't found in AD
JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID

    この AD インポート操作に対応する Provisioning Agent ログ レコードを検索するには、Windows イベント ビューアーのログを開き、[ 検索...] メニュー オプションを使用して、照合 ID/結合プロパティの属性値 (この場合 は 21023) を含むログ エントリを検索します。

    [検索] のスクリーンショット。

    イベント ID = 9 のエントリを探します。このエントリには、エージェントが AD アカウントを取得するために使用する LDAP 検索フィルターが用意されています。 これが一意のユーザー エントリを取得するための適切な検索フィルターであるかどうかを確認できます。

    イベント ID = 2 の直後のレコードは、検索操作の結果と、結果が返されたかどうかをキャプチャします。

  • 同期規則アクション レコード: このログ レコードには、属性マッピング ルールと構成されたスコープ フィルターの結果と、受信 Workday イベントを処理するために実行されるプロビジョニング アクションが表示されます。 ログ レコードの [追加の詳細] セクションの情報を使用して、同期アクションに関する問題のトラブルシューティングを行います。 レコードの例を、各フィールドの解釈方法についてのポインターと共に次に示します。

    ErrorCode : None // Use the error code captured here to troubleshoot sync issues
EventName : EntrySynchronizationAdd // Implies that the object is added
JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID
SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the profile in Workday

    属性マッピング式に問題がある場合、または受信 Workday データに問題がある場合 (たとえば、必須の属性値が空または null)、この段階で、失敗の詳細を示す ErrorCode を使用して失敗を確認します。

  • AD エクスポート レコード: このログ レコードには、AD アカウントの作成操作の結果と、プロセスで設定された属性値が表示されます。 アカウント作成操作に関する問題をトラブルシューティングするには、ログ レコードの [追加の詳細] セクションの情報を使用します。 レコードの例を、各フィールドの解釈方法についてのポインターと共に次に示します。 [追加の詳細] セクションで、"EventName" は "EntryExportAdd" に設定され、"JoiningProperty" は [Matching ID](照合 ID) 属性の値に設定され、"SourceAnchor" はそのレコードに関連付けられた WorkdayID (WID) に設定され、"TargetAnchor" は新しく作成されたユーザーの AD の "ObjectGuid" 属性の値に設定されます。

    ErrorCode : None // Use the error code captured here to troubleshoot AD account creation issues
EventName : EntryExportAdd // Implies that object is created
JoiningProperty : 21023 // Value of the Workday attribute that serves as the Matching ID
SourceAnchor : a071861412de4c2486eb10e5ae0834c3 // set to the WorkdayID (WID) associated with the profile in Workday
TargetAnchor : aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb // set to the value of the AD "objectGuid" attribute of the new user

    この AD エクスポート操作に対応するプロビジョニング エージェントのログ レコードを検索するには、Windows イベント ビューアーのログを開き、[ 検索...] メニュー オプションを使用して、照合 ID/結合プロパティの属性値 (この場合 は 21023) を含むログ エントリを検索します。

    イベント ID = 2 のエクスポート操作のタイムスタンプに対応する HTTP POST レコードを探します。 このレコードには、プロビジョニング サービスからプロビジョニング エージェントに送信された属性値が含まれます。

    [プロビジョニング エージェント] ログの

    上記のイベントの直後に、AD アカウント作成操作の応答をキャプチャする別のイベントがあるはずです。 このイベントは、AD で作成された新しい objectGuid を返し、それがプロビジョニング サービスの TargetAnchor 属性として設定されます。

    AD で作成された objectGuid が強調表示された [プロビジョニング エージェント] ログを示すスクリーンショット。

マネージャーの更新操作のログの概要

manager 属性は AD の参照属性です。 プロビジョニング サービスでは、ユーザー作成操作の一環として manager 属性は設定されません。 代わりに、ユーザーの AD アカウントが作成された後、 更新 操作の一部としてマネージャー属性が設定されます。 上記の例を展開すると、Workday で従業員 ID "21451" を持つ新入社員がアクティブになり、新入社員のマネージャー (21023) に既に AD アカウントがあるとします。 このシナリオでは、ユーザー 21451 のプロビジョニング ログを検索すると、5 つのエントリが表示されます。

Manager Update のスクリーンショット。

最初の 4 つのレコードは、ユーザー作成操作の一部として調べたものと似ています。 5 つ目のレコードは、manager 属性の更新に関連付けられたエクスポートです。 ログ レコードには、マネージャーの objectGuid 属性を使用して実行される AD アカウント マネージャーの更新操作の結果が表示されます。

// Modified Properties
Name : manager
New Value : "aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb" // objectGuid of the user 21023

// Additional Details
ErrorCode : None // Use the error code captured here to troubleshoot AD account creation issues
EventName : EntryExportUpdate // Implies that object is created
JoiningProperty : 21451 // Value of the Workday attribute that serves as the Matching ID
SourceAnchor : 9603bf594b9901693f307815bf21870a // WorkdayID of the user
TargetAnchor : 43b668e7-1d73-401c-a00a-fed14d31a1a8 // objectGuid of the user 21451

よく発生するエラーの解決

このセクションでは、Workday ユーザーのプロビジョニングでよく見られるエラーとその解決方法について説明します。 エラーは次のように分類されます。

プロビジョニング エージェントのエラー

# エラーのシナリオ 考えられる原因 推奨される解決方法
1. サービス 'Microsoft Entra Connect Provisioning Agent' (AADConnectProvisioningAgent) の起動に失敗しました。プロビジョニング エージェントのインストール中にエラー メッセージが表示されました。システムを起動するための十分な特権があることを確認します。 通常、このエラーはプロビジョニング エージェントをドメイン コントローラーにインストールしようとしたときに、グループ ポリシーがサービスの開始を妨げた場合に発生します。 前のバージョンのエージェントを実行していて、それを新しいインストールの開始前にアンインストールしなかった場合にもこれが表示されます。 DC 以外のサーバーにプロビジョニング エージェントをインストールします。 新しいエージェントをインストールする前に、必ず以前のバージョンのエージェントをアンインストールします。
2. Windows サービス 'Microsoft Entra Connect プロビジョニング エージェント' は 開始 状態であり、 実行中 の状態には切り替わりません。 エージェント ウィザードは、インストールの一環として、サーバーにローカル アカウント (NT Service\AADConnectProvisioningAgent) を作成します。これは、サービスの開始に使用されるログオン アカウントです。 Windows サーバー上のセキュリティ ポリシーにより、ローカル アカウントでサービスを実行できない場合は、このエラーが発生します。 サービス コンソールを開きます。 Windows サービスの 'Microsoft Entra Connect Provisioning Agent' を右クリックし、ログオン タブでサービスを実行するドメイン管理者のアカウントを指定します。 サービスを再起動します。
3. Active Directory の接続手順で AD ドメインを使用してプロビジョニング エージェントを構成する場合、ウィザードで AD スキーマを読み込もうとする時間が長く、最終的にタイムアウトになります。 通常、このエラーは、ファイアウォールの問題のためにウィザードから AD ドメイン コントローラー サーバーに接続できない場合に表示されます。 [Active Directory の接続] ウィザード画面で、AD ドメインの資格情報を入力するときに、[Select domain controller priority] (ドメイン コントローラーの優先順位の選択) というオプションがあります。 このオプションは、エージェント サーバーと同じサイト内にあるドメイン コントローラーを選択し、通信をブロックするファイアウォール規則がないようにするために使用します。

接続エラー

プロビジョニング サービスが Workday または Active Directory に接続できない場合は、プロビジョニングが検疫状態になる可能性があります。 次の表を使用して、接続の問題を解決します。

# エラーのシナリオ 考えられる原因 推奨される解決方法
1. [ 接続のテスト] をクリックすると、エラー メッセージが表示されます。 Active Directory への接続中にエラーが発生しました。オンプレミスのプロビジョニング エージェントが実行されており、正しい Active Directory ドメインで構成されていることを確認してください。 通常、このエラーは、プロビジョニング エージェントが実行されていないか、Microsoft Entra ID とプロビジョニング エージェントとの間の通信をブロックしているファイアウォールがある場合に発生します。 ドメインがエージェント ウィザードで構成されていない場合にもこのエラーが表示されることがあります。 Windows サーバーで Services コンソールを開き、エージェントが実行されていることを確認します。 プロビジョニング エージェント ウィザードを開き、正しいドメインがエージェントに登録されていることを確認します。
2. プロビジョニング ジョブが週末 (金曜から土曜) にかけて検疫状態になり、同期にエラーがあるというメール通知を受け取ります。 このエラーの一般的な原因の 1 つは、スケジュールされている Workday のダウンタイムです。 Workday の実装テナントを使用する場合、Workday には、週末にかけて (通常は金曜日の夜から土曜日の朝まで) スケジュールされた実装テナントのダウンタイムがあり、その期間中は Workday に接続できないため、Workday プロビジョニング アプリが検疫状態になる可能性があります。 Workday 実装テナントがオンラインに戻ると、通常の状態に戻ります。 ごくまれに、テナントの更新により統合システム ユーザーのパスワードが変更された場合、またはアカウントがロックまたは期限切れの状態にある場合にも、このエラーが表示されることがあります。 Workday 管理者または統合パートナーに連絡して、ダウンタイム期間中に Workday がアラート メッセージを無視するようにダウンタイムをスケジュールし、Workday インスタンスがオンラインに戻ったら可用性を確認します。

AD ユーザー アカウントの作成エラー

# エラーのシナリオ 考えられる原因 推奨される解決方法
1. プロビジョニング ログでエクスポート操作が失敗し、 エラー: OperationsError-SvcErr: 操作エラーが発生しました。ディレクトリ サービスには上位参照が構成されていないため、このフォレスト外のオブジェクトへの紹介を発行できません。 このエラーは、通常、 Active Directory コンテナー OU が正しく設定されていない場合、または parentDistinguishedName に使用される式マッピングに問題がある場合に表示されます。 OU パラメーターについて誤字がないかActive Directory コンテナーを確認します。 属性マッピングで parentDistinguishedName を 使用している場合は、常に AD ドメイン内の既知のコンテナーに評価されることを確認します。 プロビジョニング ログで Export イベントを調べて、生成された値を確認します。
2. プロビジョニングログのエクスポート操作に失敗し、エラーコード: SystemForCrossDomainIdentityManagementBadResponse とメッセージ エラー: ConstraintViolation-AtrErr: 要求の値が無効です。属性の値が許容範囲内にありませんでした。\nエラーの詳細: CONSTRAINT_ATT_TYPE - 属性名「会社」が発生しました。 このエラーは 会社 の属性に固有のものですが、 CN などの他の属性でもこのエラーが表示される場合があります。 このエラーは、AD で適用されたスキーマ制約が原因で発生します。 既定では、AD の company や CN などの属性の上限は 64 文字です。 Workday に由来する値が 64 文字を超える場合は、このエラー メッセージが表示されます。 プロビジョニング ログの Export イベントを調べて、エラー メッセージで報告された属性の値を確認します。 Mid 関数を使用して Workday からの値を切り捨てるか、長さの制約が類似していない AD 属性へのマッピングを変更することを検討してください。

AD ユーザー アカウントの更新エラー

AD ユーザー アカウントの更新プロセス中に、プロビジョニング サービスでは Workday と AD の両方から情報が読み取られ、属性マッピング規則を実行して、変更を反映する必要があるかどうかを判断します。 それに応じて更新イベントがトリガーされます。 これらの手順のいずれかで障害が発生した場合は、プロビジョニング ログに記録されます。 次の表を使用して、一般的な更新エラーを解決します。

# エラーのシナリオ 考えられる原因 推奨される解決方法
1. EventName = EntrySynchronizationError および ErrorCode = EndpointUnavailable というメッセージを含むプロビジョニング ログの同期規則アクションの失敗。 このエラーは、オンプレミスのプロビジョニング エージェントで処理エラーが発生したために、プロビジョニング サービスで Active Directory からユーザー プロファイル データを取得できない場合に発生します。 プロビジョニング エージェントのイベント ビューアー ログで、読み取り操作に関する問題を示すエラー イベントを確認します (イベント ID 2 でフィルター)。
2. AD の特定のユーザーについて、AD の manager 属性が更新されません。 このエラーで最も可能性が高い原因は、スコープ規則を使用していて、ユーザーのマネージャーがスコープに含まれていないことです。 マネージャーの照合 ID 属性 (EmployeeID など) がターゲット AD ドメインに見つからないか、正しい値に設定されていない場合も、この問題が発生する可能性があります。 スコープ フィルターを確認し、スコープ内にマネージャー ユーザーを追加します。 AD 内のマネージャーのプロファイルを調べて、照合 ID 属性の値があることを確認してください。

構成の確認

このセクションでは、Workday 主導のユーザー プロビジョニング構成をさらに拡張、カスタマイズ、および管理する方法について説明します。 次のトピックについて説明します。

Workday のユーザー属性リストをカスタマイズする

Active Directory と Microsoft Entra ID の Workday プロビジョニング アプリにはどちらも、Workday のユーザー属性の選択元となる既定のリストが含まれています。 ただしこれらのリストに、すべてが含まれているわけではありません。 Workday は、想定されるさまざまなユーザー属性を数多くサポートしていますが、それらのユーザー属性には、標準の属性と特定の Workday テナントに固有の属性とがあります。

Microsoft Entra プロビジョニング サービスでは、リストまたは Workday 属性をカスタマイズして、人事 API の Get_Workers 操作で公開されるすべての属性を含めることができます。

この変更を行うには、 Workday Studio を使用して、使用する属性を表す XPath 式を抽出し、高度な属性エディターを使用してプロビジョニング構成に追加する必要があります。

Workday ユーザー属性の XPath 式を取得するには:

  1. Workday Studio をダウンロードしてインストールします。 インストーラーにアクセスするには、Workday コミュニティ アカウントが必要です。

  2. Workday Web Services ディレクトリから、使用する予定の WWS API バージョンに固有の Workday Human_Resources WSDL ファイルをダウンロードします

  3. Workday Studio を起動します。

  4. コマンド バーから、 Workday > Test Web Service in Tester オプションを 選択します。

  5. [ 外部] を選択し、手順 2 でダウンロードしたHuman_Resources WSDL ファイルを選択します。

    Workday Studio で開いている

  6. [場所] フィールドをhttps://IMPL-CC.workday.com/ccx/service/TENANT/Human_Resourcesに設定しますが、"IMPL-CC" を実際のインスタンスの種類に置き換え、"TENANT" を実際のテナント名に置き換えます。

  7. 操作をGet_Workersに設定する

  8. [要求/応答] ウィンドウの下にある小さな 構成 リンクをクリックして、Workday の資格情報を設定します。 [認証] をオンにし、Workday 統合システム アカウントのユーザー名とパスワードを入力します。 必ずユーザー名をname@tenantとして書式設定し、 WS-Security UsernameToken オプションを選択したままにします。 [ユーザー名] と [パスワード] が入力され、[WS-Security ユーザー名トークン] が選択されている [セキュリティ] タブを示すスクリーンショット。

  9. [ OK] を選択します。

  10. [ 要求 ] ウィンドウで、下の XML を貼り付けます。 Employee_IDを Workday テナントの実際のユーザーの従業員 ID に設定します。 wd:version を、使用する予定の WWS のバージョンに設定します。 抽出対象となる属性が設定されているユーザーを選択します。

    <?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="https://www.w3.org/2001/XMLSchema">
  <env:Body>
    <wd:Get_Workers_Request xmlns:wd="urn:com.workday/bsvc" wd:version="v21.1">
      <wd:Request_References wd:Skip_Non_Existing_Instances="true">
        <wd:Worker_Reference>
          <wd:ID wd:type="Employee_ID">21008</wd:ID>
        </wd:Worker_Reference>
      </wd:Request_References>
      <wd:Response_Group>
        <wd:Include_Reference>true</wd:Include_Reference>
        <wd:Include_Personal_Information>true</wd:Include_Personal_Information>
        <wd:Include_Employment_Information>true</wd:Include_Employment_Information>
        <wd:Include_Management_Chain_Data>true</wd:Include_Management_Chain_Data>
        <wd:Include_Organizations>true</wd:Include_Organizations>
        <wd:Include_Reference>true</wd:Include_Reference>
        <wd:Include_Transaction_Log_Data>true</wd:Include_Transaction_Log_Data>
        <wd:Include_Photo>true</wd:Include_Photo>
        <wd:Include_User_Account>true</wd:Include_User_Account>
      <wd:Include_Roles>true</wd:Include_Roles>
      </wd:Response_Group>
    </wd:Get_Workers_Request>
  </env:Body>
</env:Envelope>

  11. [ 要求の送信 ] (緑色の矢印) をクリックしてコマンドを実行します。 成功した場合は、応答ウィンドウに 応答 が表示されます。 エラーではなく、入力したユーザー ID のデータが応答に含まれていることを確認します。

  12. 成功した場合は、[ 応答 ] ウィンドウから XML をコピーし、XML ファイルとして保存します。

  13. Workday Studio のコマンド バーで、[ ファイル] > [ファイルを開く] を選択し、保存した XML ファイルを開きます。 この操作で、Workday Studio の XML エディターにファイルが開きます。

  14. ファイル ツリーで、 /env: Envelope > env: Body > wd:Get_Workers_Response > wd:Response_Data > wd: Worker 内を移動して、ユーザーのデータを検索します。

  15. wd: Worker で、追加する属性を見つけて選択します。

  16. 選択した属性の XPath 式を [ドキュメント パス ] フィールドからコピーします。

  17. コピーした式から /env:Envelope/env:Body/wd:Get_Workers_Response/wd:Response_Data/ プレフィックスを削除します。

  18. コピーした式の最後の項目がノード (例: "/wd: Birth_Date") の場合は、式の末尾に /text() を追加します。 最後の項目が属性 (例: "/@wd: type") の場合、これは不要です。

  19. 最終的には、wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Birth_Date/text() のようになっている必要があります。 この値は、コピーして Microsoft Entra 管理センターに入力する値です。

カスタム Workday ユーザー属性をプロビジョニング構成に追加するには:

  1. このチュートリアルで前述したように、 Microsoft Entra 管理センターを起動し、Workday プロビジョニング アプリケーションの [プロビジョニング] セクションに移動します。

  2. [プロビジョニングの状態] を [オフ] に設定し、[保存] を選択します。 この手順を使用すると、変更を反映するタイミングを、確実に準備ができたときにするのに役立ちます。

  3. [ マッピング] で、[ Workday Worker をオンプレミス Active Directory に同期 する] (または [Workday Worker を Microsoft Entra ID に同期する] を選択します)。

  4. 次の画面の一番下までスクロールし、[ 詳細オプションの表示] を選択します。

  5. Workday の [属性リストの編集] を選択します。

  6. 属性リストの一番下にある入力フィールドまでスクロールします。

  7. [ 名前] に、属性の表示名を入力します。

  8. [ 種類] で、属性に適切に対応する型を選択します (文字列 が最も一般的です)。

  9. [API 式] に、Workday Studio からコピーした XPath 式を入力します。 例: wd:Worker/wd:Worker_Data/wd:Personal_Data/wd:Birth_Date/text()

  10. [ 属性の追加] を選択します。

    Workday Studio のスクリーンショット。

  11. 上の [保存] を選択し、ダイアログボックスで [はい ] を選択します。 [属性マッピング] 画面がまだ開いている場合は閉じてください。

  12. メインの [ プロビジョニング ] タブに戻り、[ Workday Worker をオンプレミスの Active Directory に同期 する ( または Worker を Microsoft Entra ID に同期する)] をもう一度選択します。

  13. [ 新しいマッピングの追加] を選択します。

  14. これで、新しい属性が ソース属性 の一覧に表示されます。

  15. 必要に応じて新しい属性のマッピングを追加します。

  16. 完了したら、[プロビジョニングの状態] を [オン] に戻して保存します。

構成のエクスポートとインポート

プロビジョニング構成のエクスポートとインポートに関する記事を参照してください

個人データの管理

Active Directory 用の Workday プロビジョニング ソリューションでは、オンプレミスの Windows サーバー上にプロビジョニング エージェントをインストールする必要があります。このエージェントでは、Workday から AD への属性マッピングに応じて個人データを含む可能性があるログが Windows イベント ログに作成されます。 ユーザーのプライバシー義務を遵守するために、イベント ログを消去する Windows のスケジュールされたタスクを設定することで、48 時間を超えてイベント ログにデータが保持されないようにすることができます。

Microsoft Entra プロビジョニング サービスは、GDPR 分類の データ プロセッサ カテゴリに分類されます。 このサービスは、データ プロセッサ パイプラインとして、重要なパートナーやエンド コンシューマーにデータ処理サービスを提供するものです。 Microsoft Entra プロビジョニング サービスは、ユーザー データを生成せず、収集する個人データをどれにするか、およびその用途について、独立した制御はありません。 Microsoft Entra ID プロビジョニング サービスでのデータの取得、集計、分析、およびレポートは、既存のエンタープライズ データに基づいて行われます。

注

個人データの表示または削除の詳細については、GDPR サイトに 対する Windows データ主体の要求 に関する Microsoft のガイダンスを確認してください。 GDPR に関する一般的な情報については、 Microsoft セキュリティ センターの GDPR セクション と Service Trust ポータルの GDPR セクションを参照してください。

データ保持に関しては、Microsoft Entra プロビジョニング サービスでは 30 日を超えてレポートの生成、分析の実行、または分析情報の提供を行いません。 そのため Microsoft Entra プロビジョニング サービスでは、いかなるデータも 30 日間を超えて格納、処理、保持されることはありません。 この設計は、GDPR の規制、Microsoft のプライバシー コンプライアンス規則、および Microsoft Entra ID のデータ リテンション ポリシーに準拠したものです。

関連コンテンツ