こんにちは。Microsoft 365 のデバイスとアプリ管理機能の導入を担当している曽根です。
本記事では、弊社のサービスである ADFS on Cloud の利用を終了し、フェデレーション認証から Azure AD 単体の認証に移行した事例を紹介します。
認証の切り替え後、Azure AD 条件付きアクセスによる Windows 10 のデバイスベースのアクセス制御を行うため、Hybrid Azure AD Join および Microsoft Intune 登録も行いましたので併せて紹介します。
事例内で利用する機能の概要について記載します。
ADFS は、Microsoft が開発した ID アクセスソリューションです。ADFS により、オンプレミス AD の認証で、クラウドの認証も行えます。 ADFS は、物理的なリソースとして ADFS サーバーの他、Web アプリケーションプロキシ（以降 WAP）サーバーが必要となります。 WAP は、インターネット経由の ADFS への認証要求を代替するリバースプロキシとして機能します。 社外クライアントからの ADFS への認証要求を受信し、社外クライアントの代わりにオンプレミスに構築された ADFS へ認証を行います。
AoC はお客様が既にお持ちの オンプレミスのドメインコントローラー（以降 DC） をクラウド上の DC（読み取り専用）と同期することで、クラウドに構築した ADFS を利用し、Office 365 や各種クラウドサービスを オンプレミス AD と連携させる SBT のサービスです。
AoC は 2022 年 7 月時点で新規販売を終了しています。
MECM は、Microsoft が開発した資産管理ソリューションです。 Windows デバイスの更新プログラムの管理、アプリケーション配布、キッティングの簡略化などが行えます。
MECM 管理対象の Windows デバイスを Microsoft Intune で管理したい場合、共同管理機能を有効化する必要があります。
Microsoft が開発したモバイルデバイス管理ソリューションです。 クラウド上で管理できるモバイルデバイスの設定、アプリ配布/保護を行うことができます。
HAADJ は Windows デバイスを Azure AD に登録する際の手法の 1 つで、既にオンプレミス AD に参加しているデバイスを Azure AD にも参加させたい場合に利用します。 HAADJ が前提条件となっている機能もあり、今回は、MECM の共同管理が該当します。 ID 同期に必要な Azure AD Connect（以降 AADC）サーバーを用意し、オンプレミス AD のコンピューターオブジェクトを Azure AD に同期する必要があります。
導入規模は日本と海外の複数の国に拠点があり、ユーザーが約 3,000 名、Windows10 が約 3,000 台、iPhone/iPad が約 500 台です。
オンプレミス AD の ID が Azure AD に同期されており、Windows10 については MECM で管理されていました。
Microsoft ではセキュリティ強化の観点から ADFS の廃止を推奨しており、後続の章に記載のメリットが大きいため、Azure AD 単体の認証に移行することが決定しました。
ADFS を廃止し、Azure AD 単体の認証とすることで以下 3 つメリットがあります。
以下に ３ つのメリットの詳細を記載します。
ADFS の場合、冗長構成として最低でも ADFS サーバー 2 台、WAP サーバー 2 台の計 4 台のサーバーが必要となります。また、企業ネットワークにサーバーを配置するため、その他 NW 機器の設定管理も必要となります。
Azure AD 単体の認証に切り替えることで、ADFS 関連のサーバーが不要となり、サーバー費用や運用管理工数を削減することができます。
今回のお客様の場合、SBT の AoC にてサーバーを管理しているため、AoC の利用料金が削減されました。
ADFS 構成の状態で Azure AD に Windows10 デバイスを登録すると、認証時に PRT（プライマリ更新トークン）が発行され、ADFS を経由せずに Azure AD への認証が可能となり、クレームルールによるアクセス制御が適用されないシナリオが発生してしまいます。
たとえば社外からのアクセスを ADFS クレームで制御していた場合でも、PRT により社外からアクセスが可能となります。
ADFS を経由しない時間は基本認証と先進認証で異なり、先進認証の場合は、最大 90 日間 ADFS を経由せずにアクセス可能となります。（PRT の有効期限は 14 日間ですが、14 日間に 1 度でも認証すれば最大で 90 日間有効）
>基本認証を利用した Exchange Online の場合は ADFS を経由せずに 24 時間のアクセスが可能となります。
※2022 年 10 月から Exchange Online の基本認証の廃止が順次開始される予定です。
Azure AD 直接認証時のアクセスは、Azure AD 条件付きアクセスを利用することで制御することができます。
条件付きアクセスでは、Azure AD 上に登録されたアプリに対するアクセスを社内からは Intune に登録されている端末のみ許可し、社外からは Intune に登録されている端末のみ許可し、且つ、多要素認証を強制させることも可能です。
条件付きアクセス利用時の補足となりますが、グローバル IP アドレス（場所）を利用してアクセス制御する場合、最新の認証を使用するモバイルまたはデスクトップ アプリケーションが、更新トークンを使用して新しいアクセストークンを取得するときに場所の評価が行われます。
既定で、この評価が行われるのは 1 時間に 1 回です。
そのため、社内から社外に端末を持ち出した際には、この評価が行われる 1 時間の間は社内向けのポリシーが適用されます。
Azure AD に対してフェデレーション解除コマンドを実行することにより、テナント全体でフェデレーション認証から Azure AD 単体の認証に切り替えることができます。 全ユーザーを一度に切り替えることによる業務影響を最小限に抑えるため、ステージドロールアウト機能を利用して段階的に展開を行いました。
全ユーザーへの展開準備が整うまでには、以下工程を実施し、5 か月程度かかりました。
全ユーザーへの展開は、Azure AD 認証への切り替えと HAADJ を同時に行うと予期せぬトラブルが発生した際に切り分けが困難となるため、Azure AD 認証への切り替えが完了した後に HAADJ を実施する流れとしました。
Azure AD 認証への切り替えおよび HAADJ/Intune 登録を行うための流れについて説明します。
Azure AD 認証に切り替えるにあたって検討が必要となった項目と、実際の移行の流れについて説明します。 まず、下表の項目の実装方針を検討しました。
| 検討項目 | 概要（例） |
|---|---|
| 新 AADC の構築場所 | AADC サーバーの構築場所を決める。 |
| 先進認証の有効化 | Exchange Online の基本認証の無効化が 2022 年 10 月から開始される。また、段階的移行（ステージドロールアウト機能）の前提条件に必要であるため、先進認証を有効化する必要がある。 |
| パスワード認証方式の選択 | ID 同期されている環境であるため、以下 2 パターンからの選択となり、パススルー認証では専用のサーバーが必要となる。
オンプレミス DC 上でのみパスワードを管理したいという要件が無い限りは、基本はパスワードハッシュ同期を選択する。 |
| パスワードライトバック/セルフパスワードリセットの有効化 | ユーザー自身で Azure AD 上のパスワードリセットを可能とするためには、AADC のパスワードライトバック機能および Azure AD 上のセルフパスワードリセット機能を有効化する必要がある。 |
| 条件付きアクセスの構成 | Intune 登録前にクラウドアプリへのアクセスをデバイスベース（Intune 登録必須）にはできないため、まずは、場所ベース（グローバル IP アドレス）によるアクセス制御を行うよう構成する。 |
| オブジェクト同期ルール | オンプレミス上のユーザー/グループ/連絡先/コンピューターを Azure AD に同期する方法について検討する。 |
| ADFS を認証プロバイダー(IdP) としているアプリケーションの移行 | Office365 以外に ADFS 認証を利用しているアプリケーションを確認する。対象となるアプリケーションが存在する場合は Azure AD への移行要否を確認する。 |
各項目の実装方針確定後、以下の流れで認証の切り替えを実施しました。
続いて、HAADJ と Intune 登録を行うにあたって検討が必要となった項目と、実際の登録までの流れについて説明します。 まず、以下の項目の実装方針を検討しました。
| 検討項目 | 概要（例） |
|---|---|
| Windows10 の Azure AD 登録方式 | 以下 3 パターンから選択する。
|
| MECM 共同管理の有効化 | Windows10 が MECM で管理されている場合、Intune 機能が利用できるよう共同管理を有効化する必要がある。 |
| 条件付きアクセスの構成 | クラウドアプリへのアクセスをデバイスベース（HAADJ または Intune 登録された端末のみ許可）でアクセス制御できるよう構成する。 |
| 共有端末の考慮 | Azure AD 登録の端末では Intune の状態が他ユーザーに引き継がれないため、条件付きアクセスでブロックされないよう考慮する。 |
| キッティング | 実際の利用者のユーザーとデバイスが紐づくよう検討する。 |
| HAADJ の制御 | Windows10 端末上で HAADJ タスクを有効化させるため、GPO/MECM にて設定を展開する。 |
| Intune 自動登録の制御 | HAADJ 端末のみ Intune 自動登録を制御できるため、Intune 自動登録の有効化を GPO にて実施する。 |
| グループベースのライセンス付与 | 利用場所にテナントのリージョンが動的に登録されてしまうため、海外ユーザーの運用を検討する。 |
各項目の実装方針確定後、以下の流れで HAADJ および Intune 登録に必要な機能を実装しました。
導入後の運用については、同期対象となる属性値の変更などを行わない限り、基本的には各企業様の IT 部門で対応が可能と考えますが、今回の企業様は弊社の Office365 ヘルプデスクの EMS オプションにて導入後のサポートをさせていただきました。
弊社の Office365 ヘルプデスクの EMS オプションでは、Azure AD 関連のみならず Intune/MECM/MDE などの製品もサポート対象となります。
対象製品を導入しており、技術的なサポートを必要としている場合は、一度ご検討ください。
導入時に様々なトラブルが発生し、調査/対応を実施しました。
トラブルの対処法については本記事には記載しませんが、以下にトラブルの一例を記載します。
AoC の利用を終了し、フェデレーション認証から Azure AD 認証に切り替える事例の紹介は以上です。
今回は、認証の切り替えに加えて、Windows デバイスの HAADJ および Intune 登録を行いました。
切り替え時の障害を考慮し、「ステージドロールアウト機能を利用した段階的な認証切替およびフェデレーション解除」と「HAADJ および Intune 登録の展開」を分けて実施しましたが、それでも多くのトラブルが発生し解決に時間を要しました。
お客様の環境特有のトラブルも多く発生するため、切り替えの期間短縮を優先せず、各種展開を同時に行わずに分けて実施することで、業務影響を最小限に抑えられることを実感しました。
Azure AD認証への切り替えに「興味を持った。」「検討したい。」場合は、お気軽に弊社までお問い合わせください。
「Microsoft 365 導入・運用支援サービス」はこちら
最後まで読んでいただきありがとうございました。
