Azure AD のセルフサービスパスワードリセットを試してみた！準備編

2019年7月1日掲載

皆さん、こんにちは！
法人のお客さま向けにMicrosoft Azureの提案と導入を担当しているエキスパートSEの中山です。

Microsoft AzureはIaaSを中心によく触っているのですが、最近、Azure ADのPremiumエディションを触る機会ができましたので、以前から気になっていた、セルフサービスパスワードリセットについて、現在プレビュー版のモバイルアプリコード認証を含めて試してみました。

本記事は、セルフサービスパスワードリセットの検証環境を構築する「準備編」と、実際にユーザー目線でセルフサービスパスワードリセットを試してみた「実施編」の2回に分けて掲載します。

1. セルフサービスパスワードリセットとは？

セルフサービスパスワードリセット（SSPR）とは、オンプレミスのADドメインのログオンパスワードや、Azure ADで認証するWebアプリのサインインパスワードを忘れたユーザが、ユーザ自身で自分のパスワードを安全にリセットできる機能です。

毎日の日課としてログインすればパスワードを忘れることはないと思いますが、長期休暇などログインしていない期間が長いと、いざ業務を開始しようとするとパスワードがうろ覚えになっていたという経験はありませんか？

このとき自社のヘルプデスク窓口にパスワードリセットを依頼すると、手続きが煩雑であったり、ようやく承認を得てもリセットが実際に完了するまではオンライン業務が一切できませんので、生産性が落ちてしまいます。

これを解決するセルフサービスパスワードリセットは以下の点で有効な仕組みなので、是非ご一読ください！

ユーザのメリット：パスワードを忘れた際にすみやかに回復でき、業務効率の低下を防ぐ

管理面のメリット：企業の管理者工数の削減やヘルプデスクの負荷軽減が可能

2. 検証環境の説明

オンプレミスにADドメインをお持ちのお客さまを想定して、検証環境は以下のシナリオとしました。

オンプレミスにADドメインがあり、オンプレミスのADサーバとAzure AD上に、同一のユーザアカウントを持っています。（ハイブリッドユーザです）
ユーザアカウントは、Azure AD Connect により同期されています。
ADドメインにログオンしたユーザアカウントで、Webアプリ（Office 365ポータル）にシングルサインオンします。
ユーザが、自身でパスワードを変更できる環境を提供します。かつ、その変更後のパスワードをオンプレミスの ADサーバに同期させます。

このシナリオを実現する検証環境は以下の図になります。

擬似オンプレミス環境は、弊社のクラウドサービスである、ホワイトクラウド ASPIRE上に構築しました。

検証環境のポイントは以下の通りです。

オンプレミスのADドメインは、1フォレスト1ドメインとします。
Azure ADではカスタムドメインを追加し、オンプレミスのADドメイン名と同一にします。
Azure AD Connectは、パスワードハッシュ同期およびシームレスSSOの設定とします。
クライアントPCとAzure AD Connectサーバは、オンプレミスのADドメインに参加します。
Azure ADは、Premium P2ライセンスを使います。（P1でもかまいません）
※ハイブリッドユーザでセルフサービスパスワードリセットを行うには、パスワードライトバックが必要です。これは、Azure ADのPremiumライセンスの機能です。
ファイアウォールは、オンプレミス⇒インターネットの通信を許可します。インターネット⇒オンプレミスの通信は拒否します。

3. 検証環境の構築

環境構築の流れは以下の通りです。

なお最初にお伝えしておきますが、検証では動作確認のための最低限の設定を行いましたので、実環境では設計に沿った最適な設定を行う必要があるかと思います。この点はご了承ください。

3.1 Azure AD Connectのインストール

まずは、Azure AD Connectをインストールします。

（１）Microsoft ダウンロードセンターから、Azure AD Connectをダウンロードします。

※2019年6月12日時点では、最新バージョンは、1.3.21.0 となります。

（２）ダウンロードしたファイル（AzureADConnect.msi）を、Azure AD Connectをインストールするサーバ上で実行します。

Azure AD Connectのインストールでは、「簡単設定」と「カスタム設定」を選択できますが、今回はパスワードハッシュ同期としますので、「簡単設定」を選択しました。

Azure AD Connectのインストールには、「Azure AD グローバル管理者」および「オンプレミスのADドメインのエンタープライズ管理者」のユーザアカウントとパスワード入力が必要となります。

※Azure AD Connectをインストールするサーバではドメイン管理者でログオンしてインストールを実行する必要があります。ローカル管理者でログオンしてインストールを実行すると、この時点で”フォレストへの接続を確立できません”エラーが表示されました。

Azure AD Connectがインストールされた後、OSを再起動します。（OSを再起動しないと、 ADSyncの便利なPowerShell モジュールが使えません）

Azure AD Connectの同期が行われると、Azure AD上では以下のようになります。

この状態で、オンプレミスのADサーバのユーザアカウントはAzure ADに同期されていることが確認できます。同期されたユーザは、ソースが「Windows Server AD」となります。

同期されたユーザアカウントは、以下の例では「test user01」という名前のユーザです。

※同期されたユーザはAzureポータルから削除することはできません。

ちなみに、Microsoft 365 管理センターの「アクティブなユーザー」にも、同期されたユーザが表示されていることが確認できます。

3.2 シームレスSSOの有効化

次に、Azure AD ConnectでシームレスSSOを有効化します。

（１）Azure AD Connectのセットアップウィザードを実行します。

セットアップウィザードから、「ユーザーサインインの変更」－「ユーザーサインイン」の設定画面で、「シングルサインオンを有効にする」をチェックします。

（２）シームレスSSOを行うためには、クライアントPC上でイントラネットゾーンの設定を変更します。

具体的には、“https://autologon.microsoftazuread-sso.com”を、ブラウザーのイントラネットゾーンに明示的に追加します。

これを行うことにより、ブラウザーは Kerberos チケットを上記URLに送信するようになりますので、結果としてシームレスSSOが実現できます。

検証では以下のサイトを参考に、グループポリシーで適用しました。

グループポリシーで適用する方法

https://docs.microsoft.com/ja-jp/azure/active-directory/hybrid/how-to-connect-sso-quick-start#group-policy-option---detailed-steps

3.3 シームレスSSOの動作確認

ADドメインにログオンしたクライアントPC上のGoogle Chrome ウェブブラウザから、Office 365ポータル（https://portal.office.com）にアクセスしたところ、ユーザ名の入力（もしくは選択）の後、パスワードの入力なしでOffice365のポータルにサインインできました。