Entra IDはActive Directoryの置き換えではない

マイクロソフトは2026年9月から、パスキーをEntra IDの既定の認証方式にする。SMSや音声通話を有効にしているユーザーは自動的にパスキーの登録を促され、2027年2月にはマイクロソフトが自社で提供するSMS・音声認証の配信が終了する。規制上の要件などで継続が必要な場合は、Microsoft Security Store経由でサードパーティの通信事業者を選ぶことになる。MFAにおけるSMSや音声通話による追加認証をパスキー方式にするには、Entra IDが必須というわけではないが、企業の認証基盤やシングルサインオン（SSO）をEntra IDに統合する動きも活発化している。

なおパスキーとは、FIDO2／WebAuthnの規格に基づく公開鍵ペアの資格情報を指す用語である。iCloudキーチェーンやGoogleパスワードマネージャーなどに保管される「同期パスキー」と、FIDO2セキュリティキーやWindows Helloのように端末に固定される「デバイス連結パスキー」の両方を含む。本稿で「パスキー方式」と呼ぶのは、デバイスの生体認証やセキュリティキーを使ったパスワードレス認証全般のことである。

2027年2月以降のマイクロソフトのMFA認証方針に対応するには、単にSMS認証を廃止するだけでは不十分だ。追加認証やリスクベース認証をより安全なものにするために、Authenticatorアプリ、FIDO2のようなパスワードレス認証、トークンやデバイスの生体認証などと組み合わせた認証が推奨される。

オンプレミスだけのシステムならActive Directoryに多要素認証の仕組みを組み合わせる構成で対応可能だが、クラウドサービスやクラウドシステムと併用している場合（ハイブリッド構成）は、オンプレミスとクラウドシステムのIDをどう連携させる（させない）のかを考える必要がある。

ハイブリッド構成では、オンプレミスのActive DirectoryのアカウントをクラウドのEntra IDへ同期させ、ひとつのIDとして扱えるようにする（ID統合）。そのうえで認証方式として、パスワード、FIDO2やWindows Helloによるパスワードレス、あるいは外部のIdPとのフェデレーションを組み合わせて使うことになる。

まずは、Entra IDの基本的な機能、Active Directoryや認証サーバーとの関係を整理する。

Active Directoryはオンプレミス環境で、ユーザー、グループ、コンピューター、組織単位（OU）といったディレクトリオブジェクトをドメインという枠組みで統合管理するものだ。これらを主体として、ファイルサーバーや業務システム、プリンターなどへのアクセス権や実行権限を制御する。認証にはKerberosを使い、ドメインに参加した端末やサーバー、業務アプリへのシングルサインオンもKerberosが担う。なお、Wi-FiやVPNの接続認証にはRADIUS（NPS）をActive Directoryと連携させて使うが、これはアプリのSSOとは別の仕組みである。

これに対してEntra IDは、クラウド側で稼働するID認証基盤である。もともとは「Azure Active Directory（AAD）」と呼ばれていたが、当初からMicrosoft 365のディレクトリでもあり、Azure専用のサービスではなかった。SaaSアプリ全般に対する統合的なアクセス制御やシングルサインオンを担ってきた。2023年7月にMicrosoft Entra IDへ改称されたのは、「Azure」の名称がAzure専用と誤解されやすく、製品ファミリ全体を整理する必要があったためだ。機能やライセンス、サインインURL、APIに改称による変更はない。

Active DirectoryとEntra IDは対象とする環境がオンプレミス向けとクラウド向けで異なるため、通常は両者を共存させたハイブリッドID環境を利用する。SSOやID統合という意味では、どちらかに集約させたいところだが（マイクロソフトは、クラウド化が可能ならEntra IDへの集約を推奨している）、Entra ID自体がActive Directoryの機能をすべて包含しているわけではない。Entra IDはLDAPもKerberosも話さず、SMBのファイルサーバーの認可も直接は行えない。システムがActive Directoryのアカウントやロールに依存している場合もあり、Entra IDへの完全移行は簡単ではない。

クラウド側のシステムはEntra IDで完結できるが、オンプレミスシステムが存在する場合、オンプレミスのActive DirectoryのIDをEntra IDへ同期（認証連携）させて使う方式が一般的だ。この場合、Active Directory Domain Services（AD DS）は、Entra IDから見たオンプレミスのLDAP、Kerberos、GPO基盤として機能する。

Entra IDとActive Directoryとのハイブリッド構成におけるそれぞれの役割と認証連携の関係を図示すると図1のようになる。

Entra IDに同期されたIDを持つPC・クライアントデバイス（Entraハイブリッド参加済みデバイス）は、Windowsへのサインイン時に、オンプレミスのドメインコントローラーからKerberosの認証チケット（TGT）を受け取ると同時に、Entra IDからプライマリ更新トークン（Primary Refresh Token、PRT）を取得する。TGTとPRTは別系統の資格情報であり、一方が他方に変換されるわけではない。TGTはオンプレミスリソースへのアクセスに、PRTはクラウドへのアクセスに使われる。

クライアントがクラウドアプリを使うときは、PRTを提示してEntra IDにアクセストークンを要求する。Entra IDはこのタイミングで条件付きアクセスを評価し、ユーザー、デバイスの準拠状態、場所、リスクなどの条件を満たしていればアクセストークンを発行する。なおユーザーのパスワードをどこで検証するかは方式によって異なる。パスワードハッシュ同期（PHS）ならEntra ID側で完結し、パススルー認証（PTA）ならオンプレミスのエージェントに問い合わせ、フェデレーションならAD FSに委任する。

クラウド環境やリモートワークが普及し、VPN接続やバーチャルデスクトップ環境へのシフトも進んでいる。オンプレミス（イントラネット）とクラウド（インターネット・Web）の区別があいまいなものになり、守るべき境界がネットワークからID（認証）へと変わってきている。ゼロトラスト、ZTNA（ゼロトラストネットワークアクセス）、多要素認証（MFA）、リスクベース認証の拡大、そして多数のシステムアカウントの認証を統合できる認証基盤が求められている。

Entra IDはこのようなニーズ、環境の変化に対応するため開発された。主要な機能は以下のとおりだ。

認証とSSO：OAuth 2.0・OpenID Connect・SAML対応
柔軟なアクセス制御：リソースの権限に加えリスクベースでMFA要求や動的ブロック
MFA：パスキー・FIDO2・Windows Hello・Authenticator対応
柔軟なID保護：機械学習によるコンテキスト依存リスクの検知・対応
柔軟なID管理：ゲスト・アプリ・AIにも統合IDを発行

Entra IDはクラウドベースのため、管理はテナント単位で行われる。Active Directoryでは、オンプレミスのため管理対象はフォレスト、ドメインと階層構造を持つ。ドメインに参加できるのは基本的にオンプレミスのWindows端末やサーバーだが、Entra IDでは、SaaS、外部ID、AIエージェントなども対象となる。アクセス制御の考え方も異なる。Active DirectoryはグループポリシーによってPCやサーバーに設定を静的に適用するが、Entra IDは認証のたびにデバイスの状態や場所、リスクといった条件を動的に評価し、許可・追加認証・ブロックを決める。

Entra IDは、クラウドシフトやAI活用を考えると移行するメリットはある。むしろ必然かもしれない。だが、移行に際して考慮すべき事項や課題もある。

まずEntra ID導入時点での考慮事項の筆頭は、どのようなレベルで導入するかの決定だ。オンプレミスのAD DSを残すのか、残さないのか。クラウド上のシステムやサービスだけをEntra IDに統合するのか、オンプレミスの既存システムを生かしてEntra IDとActive Directoryのアカウントを連携させるのか。なおEntra IDはマイクロソフトが運営するクラウドサービスであり、自社のプライベートクラウドに実装することはできない。オンプレミス側にKerberosやLDAPが必要な場合は、AD DSを残すか、Azure上のマネージドサービスであるMicrosoft Entra Domain Servicesを使うことになる。

他のシステム導入やリプレースと同様に既存システムやアセットの洗い出しも必要だ。とくにハイブリッド運用の場合、認証基盤をRADIUSやKerberosを踏襲するのか、FIDO2に移行するのか。導入範囲や規模の計画が必要だ。関連して必要な機能や要件に合わせたライセンスプランを決定しなければならない。無料プランも用意されているが、条件付きアクセスやリスクベース認証、ID保護など業務利用では欠かせない機能は有料プラン（P1／P2／Entra Suite）で提供される。

アクセス制御が静的な設定の適用から認証時の条件評価へと変わるので、インシデント対応や対策手順などもクラウドを考慮したものに変える必要があるかもしれない。