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をクリックするだけです。

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

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