見出し画像

ServiceNow で AzureAD と連携する Multi-Provider SSO を構成する～Ver. San Diego～

hamster_8686

はじめに

ServiceNow と AzureAD を連携させて、AzureAD にいるユーザで SSO が出来るようにしたい。
しかし、公式のマニュアルを見ても、情報が古かったり自分の組織に合わない設定値が記載されていたりと、結構混乱した。
同じ問題に直面している ServiceNow エンジニアの方々にも、San Diego から新しく SSO を構築される方々向けにも、自分のためにもこの記事が役に立てれば幸いだ。
なお、今回行うのは、ServiceNow のローカルユーザ（二要素認証付き）と、AzureAD の SSO を行うユーザ（二要素認証なし）の 2 種類のユーザが混ざった環境構築を行う。

### 現状まだ工事中ですが、設定に関するところはほぼ完成しています ###


参考にした URL

実際に SSO を構築する

ServiceNow 側設定

1. まずは Developer 環境をたてる

今回は本番環境にいきなり設定変更を行う前に、事前に動作確認を行う目的で Developer 環境を構築した。
https://developer.servicenow.com/

「Start Building」から、開発環境のバージョンを選び、デプロイする。
割とすぐ出来る。

Admin とパスワードが表示されるので控えておく。

2. 日本語化プラグインのインストール

詳しい手順は省くが、Plugin より日本語化「I18N: Japanese Translations」を「Activate」をクリックしてインストールする。
2-3時間かかるとのこと。
実際にやってみたところ、一晩ほどかかった…
完了後に、完了したよーのメールが届く。
# 関係ないけど、Plugin 一覧を表示するときも1分くらい待つのよね…

#1 プラグインインストールしている間、手持ち無沙汰なのでデモデータを削除してみる

出来るかわからないけど、本番環境の状態に極力合わせたいため、Demo data remove を行う。
「Start Building を行った Developer サイトから、デモデータを消せるようなので消してみた。

【参考】
【ServiceNow】開発インスタンス設定（初期状態に戻したい・デモデータ消したいなど） | メケブログ (mekeblog.com)

3. 二要素認証の設定

画面上側の検索バーより、以下を入力する。
sys_properties.list

以下の項目を検索し、設定を変更する。
glide.authenticate.multifactor を false から true に変更


User Administration → Users（ユーザー管理 → ユーザー or 組織 → ユーザーでもOK）に移動し、
[ New ] ボタンをクリックして新しいユーザ作成画面を開く。

画面上側の灰色部分を右クリックし、[ Configure ] > [ Form Design ] （フォームデザインんでも、フォームでもどちらでも）をクリック
Fields から「 Multi 」を検索して、[ Emable Multifactor Authentication ] （[マルチファクター認証を有効にする]）をドラッグ＆ドロップで追加する。

これで、ユーザ個別に MFA を行うかどうかを設定することが出来る。なお、デフォルトをどっちにするかも設定が可能で、
ディクショナリ設定からデフォルトをFalseかTrueに変更すること制御できる。

4. Multi-Provider SSO プラグインの導入

All > System Applications > All Available Applications > All から、「Integration - Multiple Provider Single Sign-On Installer」
をインストールする

┗ Multi-Provider SSO の設定

画面上部の「すべて」タブをクリックし、検索バーから、
sys_properties.list

glide.sso.acr.enabled を False から True に変更
# これは SSO の Pluginが入っていれば表示される項目
Multi-Provider SSO Properties から、 [Enable multiple provider SSO] を有効化する。

5. ここで試しに一つユーザを作成して、MFA が有効になっているかを確認

ユーザを新規追加後、プライベートブラウズで開いて、新しく作ったユーザでログインを試みる。
以下のような画面が表示されれば MFA の設定は問題なし。

#2 大事なことなので、自身が行ったアップデートログをお気に入りに追加しておく

顧客アップデート」をお気に入りに追加
「sys_update_xml.list」を追加しておこう
検索しても中々出てこない情報なので、いつでもアクセスできるようにしておく。
# 代替機能としては更新セットがあるとおもわれるが、詳細には確認していないので特に触れない


6. ここで SSO を有効化しようとするが、問題が発生

マルチプロバイダー SSO → プロパティ より、
SSO を有効化しようとするが、これには SSO アカウント復旧（ACR）を有効にする必要がある、との警告が表示される。

素直に、「ページ」のリンクをクリックし、ACR の設定画面へ飛ぶ。

ステップ2 にある「こちらから」をクリックするとアカウント復旧設定が呼び出される。

「新しいコードを生成」から、管理者のアカウント復旧用コードを Authenticator などに登録しておこう。
終わった後、「アカウントの復旧の有効化」をクリックする。

改めてSSO設定画面に戻ると、グレーアウトしていた設定が有効になっているため、「複数のプロバイダ SSO を有効にします」にチェックを入れて保存する。

7. AzureAD - ServiceNow アプリの登録

各種設定を行っていく。
まずは、AzureADにログイン後、すべてのサービスから「エンタープライズアプリケーション」をクリックし、「新しいアプリケーション」から ServiceNow を検索して追加する。

8. AzureAD - SAML の設定

┠ 基本的な SAML 構成

「シングルサインオン」の項目へ進み、SAMLを選択する。
「基本的な SAML 構成」を編集し、以下の画像のように入力する
なお、サインオンURLについては、ServiceNow 側の「IDプロバイダー設定」が完了していないと設定が出来ないため、一旦「応答 URL (Assertion Consumer Service URL)」と同じにしておく。
・識別子（エンティティ ID）
https://<インスタンス名>.service-now.com

・応答 URL
https://<インスタンス名>.service-now.com/navpage.do

・サインオン URL
https://<インスタンス名>.service-now.com/navpage.do

┠ SAML 署名証明書

AzureAD側の、「SAML 署名証明書」から、「フェデレーションメタデータXML」をダウンロードする。
ダウンロード後、中身をコピーしておく。

9. ID プロバイダー設定

マルチプロバイダー SSO → ID プロバイダー へ進み、
画面右上にある「新規」をクリックする。
SSO の種類は 「SAML」

ServiceNow側のIDプロバイダー作成時に表示される、インポートの画面で「XML」を選択してデータをインポートする。

ここで、「ID プロバイダーの SingleLogoutRequest」は不要みたいなので削除しておく。
名前は、ServiceNow ID プロバイダー一覧に表示される名前になるため、これ変更しておく。
NameIDポリシーを、以下の設定値に変更する。
これ割と罠だと思うので余談ですが、AzureAD から XML で持ってきた値が、実際に ServiceNow でそのまま SSO やってみるとエラー吐いちゃうんですよね。
実際のエラーは省略しますが、結局 AzureAD 側の ServiceNow で SSO する方法のドキュメントページがあって、そこには以下の記載がありました。
ドキュメントと配布するファイルは状態を揃えてほしかったですが、まぁ仕方なし。

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

設定値を変更したら、「更新」をクリック。

ちなみに、ドキュメントだとここで X509 証明書をインストールするように言われるが、XML で導入を行った段階で自動的に X509 証明書が入っている。
更新した ID プロバイダーの下の方へスクロールすると、「https://sts.windows.net/」から始まる証明書が組み込まれていることがわかるので、参考までに。

更新後、対象のIDプロバイダーを右クリックして「sys_id のコピー」を押してコピーしておく。


10. AzureAD - SAML の設定修正

「8. AzureAD - SAML の設定」 - 「基本的な SAML 構成」の時に設定したサインオン URL を修正する。
先ほどコピーした sys_id をここで貼り付ける。

https://<ServiceNow インスタンス名>.service-now.com/login_with_sso.do?glide_sso_id=<sys_id 貼り付け>

11. SSO ログインテスト

試しに SSO をしてみる。
Azure AD 上に実際に作成されているユーザを適当に一つ作成し、そのユーザと同じメールアドレスプロパティを持つユーザを ServiceNow でも作成しておく。
結局のところ SSO は、お互いの環境に共通しているユーザ情報がないと SSO が出来ないのよね。
今回、「マルチプロバイダー SSO → プロパティ」の時に設定した値が「email」なので、email をもとに SSO ログイン検証が行われる理解でいる。
そのため、ServiceNow 側と Azure AD 側で異なる姓名や表示名で作成していても、同じメールアドレスさえ使っていれば SSO が出来るようだ。

ID プロバイダー画面から「テスト接続」を行い、結果を確認する。

SSO Logout Test Results は、Azure AD 側の設定で、省略可能と表記されていた「ログアウト URL」が空欄のままだと出る。
クリティカルなエラーではないので無視する。
気になる場合は、ログアウト URL に値を入れておこう。

ここで2点ほどトラブルシューティング

  1. 「User:XXXXXX not found」というエラーが表示された
     → 「Identity Provider's SingleLogoutRequest」の値が入っているとテストが失敗（スルー）されてしまうため、その値は不要であるため削除すること。

  2. SSO テスト接続の結果（ポップアップ）が表示されない。
     → ポップアップを禁止していないブラウザが前提だが、「NameIDポリシー」をデフォルトのままにしていることが原因
    「urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified」に変更すると出てくる。

###工事中です###

この記事が気に入ったらサポートをしてみませんか？