Help us understand the problem. What is going on with this article?

Azure AD と ServiceNow を SAML 連携し、シングル サインオンとユーザー プロビジョニングができるまでの環境を一から構成する

はじめに

ITSM (IT Service Management) は、 IT による資産管理やワークフロー管理などの業務管理を効率化する考え方で、ServiceNow は、その ITSM を実現るための SaaS アプリケーションの 1 つです。

Azure AD と SAML 連携することで、Azure AD ユーザーが、そのまま ServiceNow のユーザーとして利用可能になります。
また、ユーザー プロビジョニングの機能を使うことで、ServiceNow 側で新規にユーザーを準備する必要がなくなります。
※オンプレミス AD から Azure AD Connect を利用して Azure AD 側にユーザーを同期済みであれば、オンプレミス AD 上のユーザーをそのまま ServiceNow のユーザーとして利用可能となります。

今回は、ServiceNow の無償版の Developer エディションを利用して、Azure AD と ServiceNow を SAML 連携し、ユーザー プロビジョニングするまでの一連の手順を動作検証してみたいと思います。

やってみる

手順の概要は下記となります。

  1. ServiceNow Developer エディションを入手する
  2. Azure AD と ServiceNow を SAML 連携する
  3. テストユーザーを作成して、シングル サインオン できるか確認する
  4. ユーザー プロビジョニングの設定をして、ServiceNow にユーザーが自動作成されることを確認する
1. ServiceNow Developer エディションを入手する

ServiceNow の Developer エディションの入手方法は、以下 Qiita の記事にも詳しく書かれているので参考にしてみてください。

-参考情報
ServiceNowのお試しインスタンスを利用する
URL:https://qiita.com/diapers_and_snow/items/35a37e51c9435b2c968b

まず、Developer サイト (https://developer.servicenow.com/app.do#!/home) にアクセスします。

画面右上の「REGISTER」をクリックします。
image.png

必要な情報を入力して、「Sign Up」をクリックします。
Email に Activation に必要な Link が送られてくるので、必ず受信可能なアドレスを指定してください。
image.png

一度 Developer エディションを入手済みのメールアドレスを指定している場合、下記画面ショットのように既にこのアドレスは使われていると表示され、エラーになります。
image.png

メールアドレスを確認して Activation するように促されます。
image.png

このような形でメールが届くので、リンクをクリックします。
image.png

Activation と完了したので、「Sign In」をクリックします。
image.png

Registration 時に指定してメールアドレスを入力して、「Next」をクリックします。
image.png

Registration 時に設定したパスワードを入力して、「Sign in」をクリックします。
image.png

ServiceNow Developer Agreement に関する画面がポップアップ表示されるので、チェックを入れて、「Submit」をクリックします。
内容としてはこの Program は限定的であくまで Developer 目的であること、商用目的で利用しないこと、などが書かれています。
検証目的として利用する分には問題ない、と認識しています。
image.png

「*」で表示されている必須項目を選択、入力して、「Submit」をクリックします。
image.png

画面左上の「MANAGE」をクリックし、「Instance」を選択します。
image.png

画面左にある、「Request Instance」をクリックします。
image.png

どういう目的で ServiceNow の developer instance を利用するのか聞かれるので、理由を記入して、「I understand」をクリックします。
※理由は適宜置き換えてください。
image.png

リリース バージョンを都市名で利用しているようですね。一番新しいバージョンが「Orlando」になるので、「Orlando」を選択した状態で、画面下の「Request Instance」をクリックします。
image.png

ちなみに直近の 5 バージョンは、「Kingston」→「London」→「Madrid]→「New York」→「Orlando (2020 年 1 月)」の順のようです。
image.png

「Instance名」、「URL」、「admin パスワード」は重要な情報になるので、画面ショットを取るなりコピーするなりなどして控えてください。
image.png

URL をクリックすると、Login 画面に遷移するので、admin と admin パスワードを入力して「Login」をクリックします。
image.png

新しい「admin」パスワードを設定するように要求されるので、新しいパスワードを設定し、「Submit」をクリックします。
image.png

System Administrator をして Login が出来ました。これで Developer エディションの入手は完了です。
image.png

2. Azure AD と ServiceNow を SAML 連携する

Azure AD のギャラリー内にあるアプリケーションではれば、Microsoft 公開情報に手順が記載されています。
ServiceNow もギャラリー内の SaaS アプリケーションなので、下記 Microsoft 公開情報に書かれています。

-参考情報
チュートリアル:Azure Active Directory シングル サインオン (SSO) と ServiceNow の統合
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/servicenow-tutorial

上記公開情報を参考にしつつ環境を構成してみます。

Azure ポータルより、「Azure Active Directory」→「エンタープライズ アプリケーション」の順に選択し、画面上の「+新しいアプリケーション」をクリックします。
image.png

検索ボックスにて、「ServiceNow」と入力すると、下記画面ショットのように「ServiceNow」アプリケーションが表示されるので、アイコンをクリックします。
image.png

画面右下の「追加」をクリックします。
image.png

正常に追加されました、と表示されることを確認します。
image.png

ServiceNow の概要画面より左ペインの「シングル サインオン」をクリックします。
image.png

シングル サインオン方式の選択画面より、「SAML」をクリックします。
image.png

シングル サインオンのセットアップ画面が表示されます。ここからまずは Azure AD 側の設定を開始します。
image.png

基本的な SAML 構成の欄の右上の「鉛筆マークをクリックします。」
image.png

以下のように各必須項目を設定します。

項目 意味
識別子 (エンティティ ID) https://instance-name.service-now.com アプリケーションを一意に識別するために設定する値
応答 URL https://*.service-now.com/* Azure AD 側から払い出したトークンの受け取り先を指定するために必要
サインオン URL https://instance-name.service-now.com/navpage.do シングル サインオンしたい特定のアプリケーションの URL を指定するために必要

各 SAML 設定値の意味については、別記事で説明していますので参考にしていただければ幸いです。

-参考情報
Azure AD の SAML 構成に必要な設定項目とその意味、動作の説明について
URL:https://qiita.com/Shinya-Yamaguchi/items/ee2c1ee4660bc75cf235

以下のように設定し、画面上部の「保存」をクリックします。
image.png

構成が正常に保存されることを確認します。
image.png

次に SAML 署名証明書欄にて、フェデレーション メタデータ URL の右のアイコンをクリックし、コピーします。
コピーした URL をテキストファイルなどに保存しておきます。
image.png

証明書 (Base64) の右にある「ダウンロード」のリンクをクリックします。
image.png

このような形で証明書が保存されていることを確認します。
image.png

次に ServiceNow を利用するユーザーを割り当てます。左ペインの「ユーザーとグループ」をクリックします。
image.png

画面上部の「ユーザーの追加」をクリックします。
image.png

ユーザーとグループにて、シングル サインオンさせたいユーザーを選択し、「選択」をクリックします。
image.png

選択後、画面左下の「割り当て」をクリックします。
image.png

割り当てが成功することを確認します。
image.png

今度は ServiceNow 側の構成を行います。管理コンソールより、左ペインの「System Definition」→「Plugins」の順にクリックします。
image.png

検索ボックスで「Integration - Multiple Provider Single Sign-On Installer」と入力し、表示される Plugin を画面右下の「Install」をクリックします。
image.png

下記画面がポップアップ表示されるので、「Activate」をクリックします。
image.png

Activate が完了すると下記画面が表示されるので、「Close & Reload Form」をクリックします。
image.png

左ペインより、「Multi-Provider SSO」→「Properties」の順にクリックします。
image.png

下記画面が表示されます。
image.png

下記画面ショットのように、すべてのチェック ボックスにチェックを入れて、「Save」をクリックします。
image.png

Update が成功したことを確認します。
image.png

この後の ServiceNow 側の構成は「自動」もしくは「手動」で行うことができると Microsoft の公開情報に書いてあります。
作業を簡略化できるに越したことはないので、「自動」で構成できる手順を試してみます。
実際には手作業をしているので、「半自動」ですね。

Azure AD の ServiceNow シングルサインオンの構成画面より、ServiceNow のセットアップの欄にある、「ステップ バイ ステップの手順の表示」のリンクをクリックします。
image.png

下記画面がポップアップ表示されるので、ServiceNow インスタンス名が自動入力されていることを確認し、「管理ユーザー名」と「管理パスワード」を入力し、「今すぐ構成」をクリックします。
image.png

シングル サインオンが正常に構成されました。表示されることを確認します。
image.png

実際に構成されたかどうかを確認します。
ServiceNow の管理コンソールより、左ペインの「Multi-Provider SSO」→「Identity Providers」の順にクリックします。
image.png

Identity Provider 一覧より、「Microsoft Azure Federated Single Sign-On」のリンクをクリックします。
この Identity Provider が自動で作成されたことになります。
image.png

下記画面のように、各項目が自動入力されていることを確認します。
この中で、SingleLogoutRequest は公開情報にも記載されているとおり不要なので削除します。
image.png

SingleLogoutRequrst を削除した変更後が下記です。
image.png

同 Identity Provider の画面を下にスクロールさせ、X.509 Certificates の項目の「Edit」をクリックします。
image.png

X.509 Certificates List の中に、選択した証明書が含まれていることを確認し、「Save」をクリックします。
image.png

Identity Provider 画面の上部にある、「Test Connection」をクリックします。
image.png

このまま実行すると、下記画面ショットのように失敗します。
image.png

原因の特定に時間を要しましたが、後述する「Single Sign-On Script」のファイル名が、手動で構成した場合に構成される、「MultiSSOv2_SAML2_custom」に変更する必要がありました。「MultiSSO_SAML2_Update1」で実行すると何度試してもテストに失敗します。

具体的には、画面真ん中あたりにある、「Advanced」タブの「Single Sign-On Script」を修正します。
現行は、「MultiSSO_SAML2_Update1」になっています。
image.png

これを「MultiSSOv2_SAML2_custom」に変更します。変更後、再度「Test Connection」をクリックします。
image.png

Azure AD の認証エンドポイントにリダイレクトされるので、ServiceNow に割り当て済みの UPN を入力して「次へ」をクリックします。
image.png

パスワードを入力して、「サインイン」をクリックします。
image.png

SSO Logout 以外がすべて OK になっていることを確認し、「Activate」をクリックします。
image.png

3. テストユーザーを作成して、シングル サインオン できるか確認する

これで ServiceNow にシングル サインオンできる環境ができました。
まだ、ServiceNow 側にユーザーが管理者しか存在しないので、手動でテスト接続のためのユーザーを作成します。

ServiceNow 管理ポータルの左ペインより、「System Security」→「Users」の順にクリックします。
image.png

画面上部の「New」をクリックします。
image.png

Azure AD シングル サインオンを行うユーザーとして割り当て済みのユーザー情報 (test001@yamarara.work) の情報を入力し、左下の「Submit」をクリックします。
image.png

シングル サインオンの接続テストをします。
Inprivate ブラウザにてアクセス パネルの URL (myapps.microsoft.com) を入力します。

Azure AD の認証エンドポイントにリダイレクトされるので、UPN を入力して「次へ」をクリックします。
image.png

パスワードを入力して「サインイン」をクリックします。
image.png

アクセス パネルより、「ServiceNow」のタイルをクリックします。
image.png

Test001 として ServiceNow のポータルにサインインできていることを確認します。
image.png

以上で Azure AD と ServiceNow を SAML 連携して Azure AD ユーザーで ServiceNow にシングル サインオンできるところまで構成できました。
最後の章では、ユーザー プロビジョニングを構成して、ServiceNow に Azure AD ユーザーを同期する構成を行います。

4. ユーザー プロビジョニングの設定をして、ServiceNow にユーザーが自動作成されることを確認する

ServiceNow のユーザー プロビジョニングの構成手順は下記 Microsoft の公開情報にも詳しく記載されています。

-参考情報
チュートリアル:自動ユーザー プロビジョニングのために ServiceNow を構成する
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/servicenow-provisioning-tutorial

今回は、上記公開を参考にしつつ実際に Azure AD 上のユーザーがプロビジョニングされるか試してみます。
※以降の手順は、既にシングル サインオンは構成済みの前提です。

Azure AD の「エンタープライズ アプリケーション」→「ServiceNow」→「Provisioning」の順にクリックします。
image.png

プロビジョニング モードを「手動」から「自動」に変更します。
image.png

必須項目として、「インスタンス名」、「管理ユーザー名」、「管理者パスワード」が必要であることが確認できます。
image.png

各項目は既にシングル サインオンの項目で設定した内容と同じです。順番に入力し、「テスト接続」をクリックします。
image.png

プロビジョニングを有効にする権限があります、と表示されることを確認します。
image.png

画面上部の「保存」ボタンをクリックします。
※保存前に、エラー時にメールの通知を求める場合は、「エラーが発生したときにメール通知を送信します」にチェックを入れ、通知先のメールアドレスを入力し、「保存」ボタンをクリックします。
image.png

ServiceNow が正常に更新されました、と表示されることを確認します。
image.png

プロビジョニングの状態の項目で「オフ」から「オン」に変更し、画面上部の「保存」をクリックします。
※一旦マッピングはデフォルトの状態でプロビジョニングしてみます。
※また、範囲は「割り当てられたユーザーとグループのみを同期する」を選択します。
image.png

更新が成功することを確認します。
image.png

何名か ServiceNow の「ユーザーとグループ」から Azure AD ユーザーを選択して割り当てます。
image.png

まずはテストとして、下記ユーザーが ServiceNow にプロビジョニングされるかどうか確認します。
image.png

時間をおいて再度プロビジョニングの状態を見ると、ServiceNow に割り当てたユーザー 8 名分がプロビジョニングされていることが確認できます。
image.png

実際に ServiceNow 側にプロビジョニングされているかどうか確認してみます。
ServiceNow 管理ポータルより、「System Security」→「Users and Groups」→「Users」の順にクリックします。
image.png

下記画面ショットのように、8 ユーザー分が ServiceNow にプロビジョニングされていることが確認できました。
image.png

上記はマッピングを何もいじらないデフォルトのマッピングでのプロビジョニングでした。
以降はオンプレミス AD の属性を Azure AD に同期し、その特定の属性を ServiceNow にプロビジョニングさせる方法について検証します。

具体的には、会社名である「Company」と部署名である「Department」を ServiceNow にプロビジョニングさせたいと思います。
マッピングのイメージとしては下記のとおりです。

Active Directory Azure Active Directory ServiceNow
company companyName company
department department department

オンプレミス AD の属性は以下のとおりです。
image.png

image.png

これからの属性を Azure AD Connect を使うことで、Azure AD に同期されます。
同期されたかどうかの確認方法の 1 つとして、Graph エクスプローラーを使ってみます。

Graph エクスプローラーの URL (https://developer.microsoft.com/ja-jp/graph/graph-explorer) にアクセスします。
画面左の「サインイン」をクリックします。
image.png

グローバル管理者の資格情報を入力、もしくはサインイン済みの場合は、下記画面ショットのようにサインイン済みをクリックします。
image.png

下記画面ショットのように要求ヘッダーを「beta」、URLを「https://graph.microsoft.com/beta/users/UPN」を指定し、 「クエリを実行」をクリックします。
image.png

以下のように、「companyName」と「department」が含まれていることを確認します。

{
    "@odata.context": "https://graph.microsoft.com/beta/$metadata#users/$entity",
    "id": "8ca1c204-7e03-490e-800b-51fee1c1a0be",
    "deletedDateTime": null,
    "accountEnabled": true,
    "ageGroup": null,
    "businessPhones": [],
    "city": null,
    "createdDateTime": "2020-02-09T12:19:23Z",
    "creationType": null,
    "companyName": "Microsoft",
    "consentProvidedForMinor": null,
    "country": null,
    "department": "123456",
    "displayName": "test005",
    "employeeId": null,
    "faxNumber": null,
    "givenName": null,
    "imAddresses": [],
    "isResourceAccount": null,
    "jobTitle": null,
    "legalAgeGroupClassification": null,
    "mail": null,
    "mailNickname": "test005",
    "mobilePhone": null,
    "onPremisesDistinguishedName": "CN=test005,CN=Users,DC=yamarara,DC=work",
    "officeLocation": null,
    "onPremisesDomainName": "yamarara.work",
    "onPremisesImmutableId": "h6K2SRn9akOlItKBHW/WTQ==",
    "onPremisesLastSyncDateTime": "2020-02-09T12:49:47Z",
    "onPremisesSecurityIdentifier": "S-1-5-21-1097185730-2812765690-2216997822-16101",
    "onPremisesSamAccountName": "test005",
    "onPremisesSyncEnabled": true,
    "onPremisesUserPrincipalName": "test005@yamarara.work",
    "otherMails": [],
    "passwordPolicies": "DisablePasswordExpiration",
    "passwordProfile": null,
    "postalCode": null,
    "preferredDataLocation": null,
    "preferredLanguage": null,
    "proxyAddresses": [],
    "refreshTokensValidFromDateTime": "2020-02-09T12:17:13Z",
    "showInAddressList": null,
    "signInSessionsValidFromDateTime": "2020-02-09T12:17:13Z",
    "state": null,
    "streetAddress": null,
    "surname": "test005",
    "usageLocation": null,
    "userPrincipalName": "test005@yamarara.work",
    "externalUserState": null,
    "externalUserStateChangeDateTime": null,
    "userType": "Member",
    "assignedLicenses": [],
    "assignedPlans": [],
    "deviceKeys": [],
    "identities": [
        {
            "signInType": "userPrincipalName",
            "issuer": "shyamag020.onmicrosoft.com",
            "issuerAssignedId": "test005@yamarara.work"
        }
    ],
    "onPremisesExtensionAttributes": {
        "extensionAttribute1": null,
        "extensionAttribute2": null,
        "extensionAttribute3": null,
        "extensionAttribute4": null,
        "extensionAttribute5": null,
        "extensionAttribute6": null,
        "extensionAttribute7": null,
        "extensionAttribute8": null,
        "extensionAttribute9": null,
        "extensionAttribute10": null,
        "extensionAttribute11": null,
        "extensionAttribute12": null,
        "extensionAttribute13": null,
        "extensionAttribute14": null,
        "extensionAttribute15": null
    },
    "onPremisesProvisioningErrors": [],
    "provisionedPlans": []
}

この状態で Azure AD までプロビジョニングしたい属性が同期されました。
次は、Azure AD のマッピング設定により、ServiceNow にプロビジョニングしたい属性のマッピングを構成します。
「エンタープライズ アプリケーション」→「ServiceNow」→「プロビジョニング」の順にクリックし、マッピング欄の「Synchronize Azure Active Directory Users to ServiceNow」をクリックします。
image.png

属性マッピングの欄の一番下にある、「新しいマッピングの追加」をクリックします。
image.png

属性の編集の項目にて、それぞれ以下のように構成して、「OK」をクリックします。

マッピングの種類 ソース属性 対象の属性 この属性を使用してオブジェクトを照合する このマッピングを適用する
直接 companyName company いいえ 常時
直接 department department いいえ 常時

以下のとおりマッピングが 2 種類追加されていることを確認し、画面上部の「保存」をクリックします。
image.png

再同期される旨の確認画面が表示されるので、「はい」をクリックします。
image.png

更新が正常に行われたことを確認します。
image.png

さきほど新規に作成した test005@yamarara.work を ServiceNow に割り当てます。
image.png

プロビジョニングの状態を見てみると、「1 エラーを再試行しています。」と表示されています、右にある「監査ログの表示」のリンクをクリックします。
image.png

監査ログの詳細を見てみると、「Department」の値が「Invalid」と記載されています。
どうやら「Company」はプロビジョニングできているが、「Department」は失敗しているようです。
ServiceNow 側の状態を見てみます。
image.png

Test005 ユーザーの「View」→「ServicePortal」の順にクリックします。
image.png

すると、Compamy には値が入っていますが、「Department」には値が入っていません。プロビジョニングされていませんね。
image.png

これには理由があって、Microsoft の公開情報にも記載がされています。

-参考情報
トラブルシューティングのヒント
URL:https://docs.microsoft.com/ja-jp/azure/active-directory/saas-apps/servicenow-provisioning-tutorial#troubleshooting-tips

InvalidLookupReference: ServiceNow の Department や Location などの特定の属性をプロビジョニングする場合、値は ServiceNow の参照テーブルに既に存在している必要があります。 たとえば、ServiceNow のテーブル名の挿入テーブルに 2 つの場所 (シアトル、ロサンゼルス) と 3 つの部門 (営業、財務、マーケティング) があるとします。 部門が "営業" で場所が "シアトル" のユーザーをプロビジョニングしようとすると、ユーザーは正常にプロビジョニングされます。 部門 "営業" と場所 "LA" のユーザーをプロビジョニングしようとすると、ユーザーはプロビジョニングされません。 LA という場所を ServiceNow の参照テーブルに追加するか、ServiceNow の形式に合わせて Azure AD のユーザー属性を更新する必要があります。

つまり、ServiceNow にプロビジョニングするためには、予め ServiceNow 側の参照テーブルに属性を定義させておく必要があるわけです。
ちなみに、なぜ Compamy の「Microsoft」がプロビジョニングできたかというと、既に ServiceNow 側に「Compamy」の一覧として「Microsoft」が存在していたからです。

これは、Developer 版だからこそだと思いますが、Developer 版を使うとデモ用に複数の属性が予めインポートされた状態で利用できるためです。
実際に確認してみましょう。
ServiceNow 管理ポータルの左ペインより、「Companies」をクリックします。
image.png

Microsoft で検索すると、下記画面ショットのように、会社の一覧として「Microsoft」が確認できます。リンクをクリックしてみます。
image.png

テストデータとしてしっかりと定義されており、メンバーとして「test005@yamarara.work」が追加されていることが確認できます。
image.png

同じように「department」の一覧に「123456」を定義してみます。
管理ポータルの左ペインより、「Organization」→「Departments」の順にクリックします。
image.png

既存の「Department」は下記であることが確認できます、画面上部の「New」をクリックします。
image.png

以下のように「Name」に「123456」と入力し、「Submit」をクリックします。
image.png

一覧に「123456」が作成されたことを確認します。この状態で再度プロビジョニングを実行してみます。
image.png

Azure AD のプロビジョニングの状態を見ると、エラーが無くなりました。監査ログの表示のリンクをクリックします。
image.png

test005@yamarara.work の Export が成功していることが確認できました。
image.png

ServiceNow のユーザーの項目を見ると、「Department」に「123456」がプロビジョニングされました。
image.png

以上のように、Azure AD 上の属性をプロビジョニングする場合には、事前に ServiceNow 側の該当属性を定義(作成)しておく必要が有ることが分かりました。

おわりに

今回は、一から ServiceNow の検証環境を入手し、Azure AD との SAML 連携を構成しシングル サインオンが確認できたのと、ユーザー プロビジョニングを構成して、オンプレミス AD ユーザーの特定の属性(company と department) を ServiceNow にプロビジョニングさせる動作を確認できました。

上述の属性以外についても、ServiceNow 側に属性が定義されていない場合は、今回の手順のように ServiceNow 側で定義してあげることで、プロビジョニングは動作すると思います。

また、仮に動作しなくても Azure AD の監査ログを確認することで、手掛かりを得ることができます。
今回の記事が少しでも参考になれば幸いです。

Shinya-Yamaguchi
しがないシステム エンジニア。 週に1回ペースを目標に主に Azure Active Directory に関する動作検証を行い、その結果を Qiita にアウトプットしています。 また、本記事は個人的な検証内容を基に記事を書いておりますので、あくまで参考程度にしていただけますと幸いでございます。 最近は、会社近くの丸亀製麺に一人で食べに行くのが習慣になっています。
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした