[Azure AD]Duo Securityを使った3rdパーティ多要素認証を行う

こんにちは、富士榮です。

昨年10月に公表されてから時間が経ってしまいましたが、Azure Active Directory（Azure AD）でマイクロソフト純正の多要素認証プロバイダ（いわゆる買収したPhoneFactorですね）ではなく、サードパーティの多要素認証プロバイダ（今のところ、RSA、Duo、Trusonaの3社）を使って多要素認証が出来るようになっています。（現在、Preview）
※ちなみにAzure AD Premium P2のライセンスが必要な機能です。高いので私はトライアル版を使っています。

公式ブログ
　Azure AD + 3rd party MFA = Azure AD Custom Controls
　https://blogs.technet.microsoft.com/cbernier/2017/10/16/azure-ad-3rd-party-mfa-azure-ad-custom-controls/


ようやく試してみましたので、簡単に紹介して行きます。
ちなみに今回はDuoを試してみました。
（RSAはトライアル版がなかったのと、Trusonaは個別に設定をしてもらわないとダメらしく断念しました）

後、ちなみに自前でカスタムMFAプロバイダを作ってAzure ADと連携させるってこともプロトコル上は可能になっていますが、現状はマイクロソフトに承認を受けたプロバイダしか登録が出来ないということなので、こちらはもし調整がついたらやってみたいと思います。

では早速。

◆Duoのアカウントを作る

まずはココからです。
Duoのサイトへアクセスし、右上にあるStart Trialをクリックすると無償トライアルへのサインアップが出来ます。

登録を進めると、アカウントのアクティベーションを行う場面が出てきます。

ここではDuo MobileというモバイルアプリをインストールしてQRコードを読み込む必要があります。

早速インストールしてADD AccountでQRコードを読み込みます。
うまく追加できるとこんな感じでアカウントが表示されます。

横道にそれますがDuo Mobileは端末の状態を確認して問題があると警告を出してくれます。問題があると画面の下部に表示されるのでFix Nowをタップすると詳細が見れます。

今回はiOSが最新でない、という警告でした。他にもTouch IDが有効になっているか、とか脱獄していないか、などについて確認が行われます。

なんだかんだでセットアップが完了するとDuoの管理コンソールへたどり着きます。

ひとまずこれでDuoのアカウント作成は完了です。

◆Azure ADと接続するためのアプリケーション設定を行う

ややこしいんですが、Azure ADから見てDuoはIdentity Providerです。ということは、Duoから見るとAzure ADはRP、つまりアプリケーション（OAuthクライアント）となります。
（ちなみにAzure ADとDuoの間はOpenID Connectで繋がります）

ということで、Duo上にAzure ADをアプリケーションとして登録する必要があるのですが、DuoではプリセットでAzure ADと接続するための設定が入っていますので、こちらのテンプレートを使っていけば非常に簡単にセットアップが出来ます。

アプリケーションの検索画面に「Microsoft」とキーワードを入れるとAD FSやOWAなどと共にAzure ADが出てきますので、こちらを選択します。

アプリケーション設定画面に行くとシンプルに「Authorize」というボタンが現れますので、こちらをクリックしていきます。

するとAzure ADのログイン画面が出てきますので、管理者でログインします。するとAzure ADのディレクトリへの読み取り権限などを要求されるので認可を行います。
ちなみに、DuoでMFAしてログインする通常の流れにおいてはDuoがIdP、Azure ADがRPという構成ですが、ここではディレクトリの情報を読み出すためにDuoがRP、Azure ADがIdPという構成になります。ややこしいですね。

上手くいくと、Duoの管理画面にAzure ADに設定するための構成情報（json）が表示されます。

ここで表示されるjsonは後でAzure AD側に設定するのでコピーしておきます。

これでDuo側の設定は完了です。
非常にシンプルです。

◆Azure AD側にDuoをカスタムMFAプロバイダとして登録する

DuoのようなカスタムMFAプロバイダは条件付きアクセスの一つの条件として扱われます。そのため、設定は条件付きアクセスの中のCustom controlsというメニューから行います。（Azure AD Premium P2のライセンスが割り当たっていないとこのメニューは出てきません）

ここでNew custom controlをクリックすると、いきなり巨大なテキストボックスが現れるので、先ほどのjsonを貼り付けてCreateをクリックします。

これで完了です。
上手くいけば、こんな感じで一覧にDuoが出てきます。

後は、普通の条件付きアクセスと同じです。
ポリシーを書く時のControlとしてDuoMFAを要求する、という形で設定すると条件に当てはまったアクセスだとDuoのMFAが要求されます。

◆テストしてみる

ポリシーの作成が終わったら念のためポリシーの適用が正しく行われるか確認してみます。
　※事前に確認するには先日紹介したWhat Ifを使うと便利です。
　http://idmlab.eidentity.jp/2018/01/azure-adwhat-if.html

該当のユーザでの初回アクセスだとMFA設定を促されますので、画面に従いMFA設定を進めます。

利用するMFAの方法を選択します。

モバイルを選択したので、携帯の番号は入れさせられます。この辺りはAzure AD純正のMFAと一緒ですね。

何故かモバイルの種類を選択させられます。アプリのインストールを促すためでしょう。

既にインストール済みなのでI have Duo mobile installedを選んでスキップします。

ここでようやくQRコードが出てくるので先ほど管理者がやったのと同じくアプリを使ってアクティベーションを行います。

上手くアクティベーションが終わると、認証の方法を指定します。
毎回方法を聞いてくるか、PUSH通知 or ワンタイムコードの表示をあらかじめ指定しておくことが出来ます。
ここでは毎回方法を聞いてくるように指定しました。

ここで設定が終わったので、ようやく実際のMFAです。（次からはこの画面がスタート地点になります）
毎回聞いてくるように指定をしたので、方法を選択する画面が表示されます。

PUSHを選択するとモバイルアプリに通知がされてきます。

この辺りは純正と同じですね。
ここでApproveをするとログインが完了します。

◆補足（id_token_hintの利用について）

ちなみに、アプリ⇒Azure AD⇒Duoという流れでFederationが連鎖している状態でのMFAをやろうと思うと、セッション管理をちゃんと実施しないといけません。通常はAzure ADのIdPがDuo、という構成だとDuoで認証されたらそのままAzure ADでも認証されたことにしてしまうためです。
Azure ADが外部MFAプロバイダ連携をする際、セッションをコントロールするためにid_token_hintというものを使っています。

OpenID Connect coreのスペックではid_token_hintについて以下のように記載されています。

Authorization Server が以前発行した ID Token. Client が認証した End-User の現在もしくは過去のセッションに関するヒントとして利用される. もしこの ID Token に紐づく End-User が認証済, もしくはこのリクエスト中で認証された場合, Authorization Server はポジティブレスポンスを返す. さもなければ, Authorization Server は login_required のようなエラーを返す (SHOULD).

つまり、最初にAzure ADでID/PWDで認証された結果の情報をid_token_hintに入れた状態でDuoへ渡し、Duoで追加の認証が上手く行われたらポジティブレスポンス（何を返すか、についてはjsonの中に書いてある通りで、Duoの場合はMfaDoneというメッセージを返します）をAzure ADへ返します。

Azure ADからDuoへPOSTされるid_token_hint。認証されたユーザの情報が入っています。

これに対してDuoからの返事となるid_token。成功したのでMfaDoneが返っています。

細かくはスペックを読みましょう。
http://openid-foundation-japan.github.io/openid-connect-core-1_0.ja.html

11/30までにAzure AD管理者がやっておくべきこと：条件付きアクセスの設定移行

こんにちは、富士榮です。

いよいよ今月末（11月30日）でAzureクラシックポータル（旧ポータル）が廃止されます。

公式アナウンス）Marching into the future of the Azure AD admin experience: retiring the Azure AD classic portal
https://cloudblogs.microsoft.com/enterprisemobility/2017/09/18/marching-into-the-future-of-the-azure-ad-admin-experience-retiring-the-azure-classic-portal/

Azure ADの管理機能も「ほぼ」新ポータルへ移行されたのですが、旧ポータルでアプリケーション単位で設定をしてきた条件付きアクセスの設定が新ポータルの条件付きアクセスでは触れず、メンテナンスは新・旧でバラバラに行う必要がありました。

この状態で旧ポータルを廃止されるとかなり困ったことになるのですが、先日ようやくマイグレーションパス（というか緩和措置？）が発表されました。

公式アナウンス）This one is important: Time to migrate your v1.0 Conditional Access policies to v2.0!
https://cloudblogs.microsoft.com/enterprisemobility/2017/10/23/this-one-is-important-time-to-migrate-your-v1-0-conditional-access-policies-to-v2-0/

簡単に言うと、旧ポータルの条件付きアクセス（v1.0）を新ポータルの条件付きアクセス（v2.0）でも見えるようになる（だけ）の機能の発表です。

11月30日の廃止の1か月前のアナウンスというタイトな感じなので、早くやっておかないとハマりそうな感じ満載です。（しかもPreview機能という・・・このまま永遠にPreviewなんだと思いますが）

ということで、早速試してみます。

◆旧ポータルの状態の確認

まずは旧ポータルで現状を確認しましょう。アプリケーションの構成から条件付きアクセスの確認をすることが出来ます。そういえばネットワークの場所ベースとデバイスベースが独立したメニューになっていたんですね。この画面も見納めかと思うと画面ショットを撮りまくっておきたい気分になります。

◆新ポータルから旧ポリシーを確認する

既に皆さんの新ポータルから旧ポリシーが確認出来るようになっていますので、見てみましょう。Active Directoryを開き、条件付きアクセスを見ると、Classic Policies（Preview）というメニューが追加されています。

メニューを開くと、

• [アプリケーション名] MFA and location policy（場所ベースの場合）
• [アプリケーション名] Device policy（デバイスベースの場合）

という形でポリシーが見えるようになっています。

ポリシーを選択するとどのようなポリシーだったのか、内容の確認ができます。

では、早速移行してみます。

◆信頼済みIPリストの移行

まず、旧ポリシーでは信頼済みIPとして多要素認証の管理画面で指定したネットワークリスト（上限50個）しか指定できませんでした。
もちろん新ポータルでも多要素認証で指定したネットワークリストも使えますが、数の上限があるのと、一覧で書くしかないので使い勝手があまりよくありませんので、せっかくなのでこの機会にNamed Locationsを使いましょう。こちらを使えば、ネットワークに名前を付けることが出来るので、例えば事務所のロケーション毎にネットワークアドレス群に名前を付けて管理することが可能です。

もちろん、この画面からConfigure MFA trusted IPsをクリックすれば多要素認証のネットワークリストを確認・設定することが可能ですので、こちらから設定を移行しましょう。

新規Named Locationを追加するとネットワークに付ける名前、指定方法（IPレンジか、国や地域）、信頼済みIPとして扱うかどうか、実際のネットワークリストの指定を行うことが出来ます。ここへ多要素認証の信頼済みIPリストを移行しておきましょう。

◆ポリシーの移行（作り直し）

条件となるネットワークの移行が終わったら、旧ポリシーを参考に新ポリシーを作成します。
設定すべき項目は以下の通りです。

• ポリシー名 : 任意の名前
• 対象のユーザ・グループ : ポリシーの適用対象、除外対象ユーザ・グループの指定
• 対象のアプリケーション : ポリシーの適用対象、除外対象アプリケーションの指定
• 適用条件 : ポリシーの適用条件（ネットワーク、デバイス状態）
• アクセスコントロール : 条件にマッチした場合のアクションの指定（多要素認証の要求やアクセスのブロック）
• セッション : 現状はまだPreviewですが、一部のアプリケーション（SharePoint Online）における制限やCloud App Securityと連携したコントロールが出来ます。

まずは、適用対象のユーザとグループです。

よく使うポリシーとしてInclude（適用対象）に全員を入れておいて、Exclude（除外対象）に一部のグループを入れておいて一時的に多要素認証のデバイス（スマホなど）を忘れた人を救済する、というポリシーです。

次にアプリケーションです。
旧ポータルではアプリケーション単位にポリシーを作成する必要がありましたが、新ポータルでは全体に適用する共通ポリシーや一部の選択したアプリケーションへ適用するポリシーを作成することも可能になりましたので、この機会にポリシーの見直しをしても良いかも知れません。

次に適用条件です。
今回は移行元がネットワークの場所ベースの条件付きアクセスだったので、Locations設定でInclude（適用対象）をすべて、Exclude（除外対象）を信頼済みネットワークとして指定します。（ここでAll trusted locationsとすると多要素認証の信頼済みIPリストと、信頼済みとするにチェックを入れたNamed locationの両方のorをとったものが対象となります）

後はアクセスコントロールです。
条件にマッチした場合に多要素認証を要求する場合は、Grant accessにしてRequire multi-factor authenticationを指定しておけば大丈夫です。

最後に、ポリシーをEnableにして保存すれば適用が開始されます。

◆旧ポリシーを無効化し、動作確認を行う

ここで重要な注意点です。
新ポータルからは旧ポータルで作成したポリシーを無効にすることしかできません。失敗しても再度有効化しようとすると旧ポータルへアクセスして有効化しないといけません。
つまり、12月1日以降に新ポータルで無効化した旧ポリシーは二度と有効化することが出来ない、ということなのでリカバリーが出来る状態での動作確認は11月30日までしか出来ない、ということです。

しっかり計画を立てておきましょう。

新ポータルから旧ポリシーを無効化するには、先ほどのメニューより旧ポータルを選び、Disableをクリックするだけです。

後は動作確認として、適用条件に合致した・合致しない状態でアプリケーションへアクセスし、望んだ状態になるかどうか確認してください。

ということで、管理者の皆さんは急いでテスト～移行しておきましょう。