Contents
はじめに
みなさん、こんにちは。今回は Azure AD Connect クラウド プロビジョニングの代替 ID を構成する方法についてご紹介したいと思います。Azure AD Connect では、構成ウィザードの中で簡単に代替 ID が設定できましたが、クラウド プロビジョニングはかなり癖のある方法で設定する必要があります。
なお、2020 年 7 月時点のクラウド プロビジョニングはプレビューの機能であるため、今後動作に変更があるかもしれませんが、この点、ご了承くださいませー。
やりたいこと
今回は、『オンプレミス Active Directory (AD) の mail 属性を、Azure AD の UPN として同期する』というよくあるシナリオに沿って構成していきます。代替 ID というよりかは単純に属性マッピングを変更するイメージですね。先に言っておきますがめちゃくちゃ面倒くさいです。
実際に構成してみる
それでは、さっそく代替 ID を構成していきます。クラウド プロビジョニングでは、既定で定義されたスキーマを編集して属性マッピングをカスタマイズします。作業の流れは以下の通りです。
- Graph Explorer で現在のスキーマを取得する
- テキスト エディタでスキーマを編集する
- 編集したスキーマを Graph Explorer で更新する
- プロビジョニング サービスを再起動する
ひとまず、参考情報を漁ってみる
Azure AD Connect では、Synchroniztion Rule Editor で同期規則をカスタマイズしていましたが、クラウド プロビジョニングは Microsoft Graph API から属性マッピングを構成する必要があります。おおまかな手順は下記の公開情報でも紹介されていますが、これ通りやるとハマります。
クラウド プロビジョニングの属性マッピングに使用できる関数一覧です。
サービスの構造は SaaS アプリのプロビジョニングと同じなので、下記に記載された関数一覧も使えると思います。
なお、プロビジョニングのように Azure Portal から属性マッピングを編集することは操作上可能ではあるのですが、クラウド プロビジョニングではサポートされないので、必ず Graph Explorer からカスタマイズしましょう。
Graph Explorer で現在のスキーマを取得する
まずは、現在のスキーマを Graph Explorer で取得します。Graph Explorer からスキーマを取得するには、GET メソッドで以下クエリを実行します。
https://graph.microsoft.com/beta/serviceprincipals/{Service Principal Id}/synchronization/jobs/{AD2AAD Provisioning id}/schema
{Service Principal} および {AD2AAD Provisioning id} はテナントによって値が異なります。いずれも Azure Portal から確認できます。Azure Portal にグローバル管理者でアクセスし、[Azure Active Directory] – [エンタープライズ アプリケーション] をクリックします。
次に、”すべてのアプリケーション” を選択して、クラウド プロビジョニングの構成名で検索します。
検索結果に表示されたサービス プリンシパルを選択して、[プロパティ] をクリックします。ここに記載されたオブジェクト ID が {Service Principal} なので、控えておきましょう。
次に、[プロビジョニング] をクリックします。ここに記載されたジョブ ID が {AD2AAD Provisioning id} なので、これも控えておきましょう。
それぞれ控えた値を先ほどのクエリに差し込むと ☟ のような感じになります。これを Graph Explorer からクエリとして送信します。
https://graph.microsoft.com/beta/serviceprincipals/7febe673-7ac1-4e36-bb6c-1cb0c64bc2c3/synchronization/jobs/AD2AADProvisioning.982337601031441c94b2fb2d6ac9d019.0f64bc18-2e29-4933-bc20-bc7af0c56f7f/schema
Graph Explorer にアクセスし、グローバル管理者でサインインします。Directory.ReadWrite.All のアクセス許可を同意しておきましょう。
先ほどのクエリをテキスト ボックスに貼り付けて [クエリの実行] をクリックします。そうすると、[応答のプレビュー] に現在のスキーマ一覧が出力されます。スキーマ全体で 27,000 行ほどあるので、Visual Studio Code に貼り付けて編集していきましょう。
テキスト エディタでスキーマを更新する
スキーマ全体を Visual Studio Code に貼り付け、属性マッピングを編集するのですが、ユーザー オブジェクトの属性マッピングを編集する場合は、”user” および “inetOrgPersons” の 2 つのオブジェクトに定義された属性マッピングが同じ値になるよう編集する必要があります。
少し話は逸れますが、ユーザー オブジェクトは “user” および “inetOrgPersons” という 2 つの属性マッピングから同時に同期処理が行われます。いずれも同じ属性マッピング規則が構成されており、この 2 つの属性マッピング間で差異が起こらないように、両方を編集する必要があります。
では、”user” および “inetOrgPersons” の属性マッピングを編集していきます。まずは、更新するオブジェクトを見つけましょう。
それぞれのオブジェクトに定義された UserPrincipalName スキーマを見つけて、ハイライト部分を mail に変更しましょう。
こんな感じです。繰り返しになりますが “user” と “inetOrgPersons” の両方が同じ内容になるようにどちらも編集します。
以上で、属性マッピングの編集は完了です。次は、 Graph Explorer スキーマを更新します。
編集したスキーマを Graph Explorer で更新する
編集したスキーマ全体をコピーして、Graph Explorer の [要求本文] に貼り付けます。メソッドを PUT に変更して [クエリの実行] をクリックします。
属性マッピングが更新されているかを確認します。Azure Portal に戻り、[プロビジョニング] – [プロビジョニングの編集] をクリックします。
[マッピング] の “Provision Active Directory inetOrgPersons” および “Provision Active Directory users” の UserPrincipalName のソース属性が mail 属性に変更されていることが確認できました。
プロビジョニング サービスの再起動
属性マッピングを変更した後、これを適用されるためにプロビジョニング サービスを再起動します。Azure Portal のプロビジョニング メニューに戻り [プロビジョニングを再開する] をクリックします。数分後、初期同期が開始され、更新後のスキーマで同期処理が開始されます。
動作確認
最後に ☟ の動作確認をしておきましょう。
AD に新しくユーザーを作成します。このユーザーが、Azure AD 側に UPN : s.john@shmiyaza.tokyo で同期されていたら大成功です。
同期後、Azure AD 側のユーザーを確認すると、想定通り、mail 属性が UPN として同期されていました。ふぅ、、、疲れた。
さいごに
クラウド プロビジョニングは Azure AD Connect と比較して、手軽に導入できる一方で、いくつかの制限事項がある点はデメリットとしてありますが、属性マッピングをカスタマイズできる点は非常にうれしいですよね。ただ、手順が煩雑である点はもう少し改善してほしいかな。(せめて Azure Portal から編集させてほしい。)
今回は代替 ID の構成として紹介しましたが、その他の属性マッピングの変更、変換、結合、など、使用できる関数の範囲でカスタマイズ可能ですので、いろいろ試してみてください。
それでは、よい Azure AD ライフをっ 😎
コメント