「パスワードのない世界」を実現する「Windows Hello for Business」のオンプレ展開をリアルレポート（その6）：vNextに備えよ！ 次期Windows Serverのココに注目（65：特別編）（1/3 ページ）
Windows Server 2016による「Windows Hello for Business」のオンプレミス展開を検証し、実装のポイントやユーザーエクスペリエンスをレポート。今回は、Azure AD参加PC／ドメイン参加PCのセットアップとエクスペリエンス、トラブルシューティングを解説します。
Windows Hello for Businessのオンプレミス展開を実践・検証
本稿では、最新版のWindows Server 2016とWindows 10を使用して「Windows Hello for Business」（旧称、Microsoft Passport for Work）のオンプレミス展開を実装し、その機能を検証していきます。
前回は、「デバイス登録サービス」の有効化とWindows 10デバイスのディレクトリ同期、自動デバイス登録の準備を解説しました。今回は、Azure Active Directory（Azure AD）参加PC／ドメイン参加PCのセットアップとエクスペリエンス、トラブルシューティングを解説します。
- Windows Helloとは（マイクロソフト）
- Windows Hello生体認証の企業利用（Windows IT Center）
Azure AD参加PCのセットアップとエクスペリエンス
本稿における検証の目的は「Windows Hello for Businessのオンプレミス展開」ですが、比較のため、まずはAzure AD参加のWindows Hello for Businessをセットアップしてみます。
ただし、Azure AD参加に使用する資格情報は「Azure ADの組織アカウント（ユーザー名＠ドメイン名.onmicrosoft.com）」ではなく、オンプレミスの「Active Directoryのドメインユーザーアカウント（ユーザー名＠Active DirectoryドメインのDNS名）」です。Azure ADのディレクトリとオンプレミスのActive Directoryドメインをディレクトリ統合すると、これが実現できるようになります。
●ルートCA証明書と追加のセキュリティ確認の準備
Azure AD参加のセットアップでは、ユーザーのパスワードに加え、追加のセキュリティ確認による本人確認が要求されます。この要件に対応するために、Azure ADのディレクトリに同期されたオンプレミスのドメインユーザーアカウントで「多要素認証（Azure MFA）」を有効化しておきます。
それには、Azureクラシックポータルでディレクトリの「ユーザー」ページを開き、「MULTI-FACTOR AUTHの管理」をクリックして、「多要素認証」ページを開きます。ここで、Azure AD参加に使用するオンプレミスのドメインユーザーを選択し、「multi-factor authを有効にする」をクリックします（画面1）。なお、この手順は、Windows Hello for Businessのオンプレミス展開では必須ではありません。
Azure AD参加をセットアップするWindows 10コンピュータには、ローカルアカウントでサインインします。ローカルアカウントでサインインしたら、オンプレミスの「Active Directory証明書サービス」の「エンタープライズPKI」の「ルートCA証明書」のエクスポートファイル（.cer）を、ローカルコンピュータの「信頼されたルート証明機関」証明書ストアにインポートします。ドメインに参加していないコンピュータを「Active Directoryフェデレーションサービス（AD FS）」で認証するためには、エンタープライズPKIのルートCA証明書を信頼するようにしておくことが重要です。
次に、「Microsoft Edge」または「Internet Explorer」で「https://aka.ms/MFASetup」のURLにアクセスし、追加のセキュリティ確認方法（多要素認証の方法）をセットアップします。Microsoft Azureのサインインページが表示されるので、テキストボックスにオンプレミスのActive Directoryのドメインユーザーのユーザー名を電子メールアドレス形式（ユーザー名＠Active DirectoryドメインのDNS名）で入力し、「続行」をクリックします。
すると、「組織のサインインページ」（Webアプリケーションプロキシが提供）に自動的にリダイレクトされるので、ユーザーのパスワードを入力し、「サインイン」をクリックします。「お客様の管理者が、このアカウントに追加のセキュリティ検査を設定することを必須としています」と表示されるので「今すぐセットアップ」をクリックして、追加のセキュリティ確認方法を設定します。
追加のセキュリティ確認方法としては、携帯電話や会社の電話への音声確認、携帯電話へのSMSメッセージによるコード送信、モバイルアプリ（Android、iOS、Windows Phone、またはWindows 10 Mobileの「Microsoft Authenticator」が必要）を選択できます（画面2）。
追加のセキュリティ確認方法のセットアップが完了すると、Azure ADのユーザー向けアカウントポータルである「アクセスパネル」の「プロファイル」ページ（https://account.activedirectory.windowsazure.com/profile）が開きます。「プロファイル」ページの「追加のセキュリティの確認」を開くと、追加のセキュリティ確認方法の変更や追加、既定の確認方法の選択が可能です。なお、追加のセキュリティ確認方法を事前にセットアップしていない場合は、Azure AD参加のセットアップ中に設定を要求されます。
●Azure AD参加のセットアップ
ここまでの設定でAzure AD参加の準備ができたので、セットアップを開始します。「設定」の「アカウント」にある「職場または学校にアクセスする」を開き、「＋接続」ボタンをクリックします。「職場または学校アカウントのセットアップ」ウィザードが開始するので、最初のページで「別の操作：このデバイスをAzure Active Directoryに参加させる」をクリックします（画面3）。
なお、ここのテキストボックスにオンプレミスのドメインユーザーアカウントを指定した場合は、Azure AD参加ではなく、「社内参加」でセットアップすることになります。ちなみに、Windows 10 バージョン1511の場合は、「設定」の「システム」→「バージョン情報」にある「Azure ADに参加」ボタンをクリックして、Azure AD参加のセットアップを開始します。Azure AD参加の開始方法がWindows 10 バージョン1607から変更になっていることに注意してください。
「サインインしましょう」のページで「職場または学校アカウントのユーザー名として、テキストボックスにオンプレミスのActive Directoryのドメインユーザーのユーザー名を電子メールアドレス形式（ユーザー名＠Active DirectoryドメインのDNS名）で入力します。カーソルをパスワード欄に移動すると、自動的に組織のサインインページにリダイレクトされるので、パスワードを入力し、「サインイン」をクリックします。
すると、先ほどセットアップした追加のセキュリティ確認の方法が自動開始されるので、確認方法に応じた検証（SMSメッセージの場合は携帯電話に受信した確認コードを入力する）を行います。本人であることが検証されると、「これがあなたの組織のネットワークであることを確認してください」と表示されるので、「参加する」をクリックします（画面4）。「デバイスを設定中です。しばらくお待ちください」の後に「これで完了です」と表示されたら、「完了」をクリックします。
現在のユーザーをWindowsからいったんサインアウトし、Azure AD参加をセットアップしたオンプレミスのドメインユーザーアカウントのユーザー名（電子メールアドレス形式）とパスワードでサインインします。
生体認証に対応したデバイスがある場合は、「Windows Helloへようこそ！」のページが表示され、Windows Helloの生体認証のセットアップ（今回は指紋登録）を行います。続いて、「PINのセットアップ」が始まるので、PINを設定します（画面5）。Microsoft IntuneでPINのポリシーを設定している場合は、その要件が「PINの要件」に示されます。PINを設定すると、「間もなく準備が完了します」と表示されるので「OK」ボタンをクリックしてサインインします。PINの設定によってデバイスがAzure ADに登録され、Windows Hello for Businessが利用可能になります。
●クラウドアプリと社内リソースへのSSOアクセスを検証
Azure AD参加とWindows Hello for Businessのセットアップが完了したら、いったんサインアウトし、PINまたは生体認証でサインインします。なお、Windows Hello for Business用のPINや生体認証が使用可能になるまでには、しばらく時間がかかることがあります。その場合、「このオプションは一時的に利用できなくなっています」と表示されます。
PINまたは生体認証でサインイン後、Office 365のOfficeポータル（https://portal.office.com/）やSharePoint Onlineなどのアプリは、追加の認証を求められることなく、シングルサインオン（SSO）でアクセスすることができました。
また、Webアプリケーションプロキシで公開したイントラネットWebサイトや「ワークフォルダー」へのアクセスに関しても、組織のサインインポータルが一瞬表示されますが、自動的に認証が完了します。AD FSで有効にしたプライマリー認証方法「Microsoft Passport認証」でSSOアクセスできているようです（画面6）。なお、WebアプリケーションプロキシでWindows認証構成のワークフォルダーをパススルーで公開している場合は、Windows Hello for Businessではなく、保存された資格情報が使用されます。
ちなみに、Azure AD参加ではなく、社内参加でセットアップした場合も、Windows Hello for Businessのセットアップが行われました。しかし、クラウドアプリと社内リソースのアクセスでは、どちらも組織のサインインページが表示され、フォーム認証を行う必要がありましたが、これは筆者の予想通りの動作です。WindowsへのサインインにWindows Hello for Businessを構成したアカウントの資格情報を使用していないため、Windowsのサインイン認証と組織のアカウントのどちらの資格情報でアクセスするか、それとも全く別の資格情報でアクセスするか、指示する必要があるからだと思います。
Copyright © ITmedia, Inc. All Rights Reserved.
ITmediaはアイティメディア株式会社の登録商標です。