はじめに
こんにちは、エーピーコミュニケーションズ ACS事業部の内田です。
2026年5月19日に、Azure Files SMBにおけるEntra-Only IDによる認証がGA（一般提供）されました。
本記事では、本GAについての概要および実際の構築手順を紹介します。
なお、今回の構築手順は、AVD（Azure Virtual Desktop）用のプロファイルサーバーをEntra-Only IDによる認証で構築するための設定を中心に解説し、AVDそのものの構築手順については含みません。
本GAの概要
これまで Azure FilesのSMB共有で、ユーザーやグループごとのアクセス許可（ディレクトリ・ファイル単位のACL）を制御する場合には、オンプレミスの Active Directory（AD）やハイブリッド同期、あるいはマネージドドメインコントローラー（Microsoft Entra Domain Services）が必要でした。
今回のアップデートにより、Microsoft Entra IDのみで完結する認証が可能になり、ADへの依存が解消されました。
導入による主なメリット
- 運用の簡素化:
ドメイン参加や VPN、複雑なネットワーク設定に縛られません。
- コスト削減:
ドメインコントローラー（仮想マシン）のコンピューティングコストや、Entra Connect等の同期インフラの運用負荷を削減できます。Entra-Only ID認証は、HDD 共有、SSD（Premium）共有のどちらでも利用可能であり、既存の課金モデルのままで認証方式を最新化するだけで利用可能です。
- ハイブリッドID構成との共存:
既存のAD環境を維持したまま、新しいプロジェクトや特定の部門から段階的にEntra ID専用のアクセスへ移行していくことができます。
- セキュリティの強化:
ゼロトラストの原則に基づき、Intune統合によるネイティブ認証が可能です。
- 場所を選ばないアクセス:
リモートワーク環境からでも、安全かつシームレスにファイルへアクセスできます。
なぜADなしでSMBアクセスができるのか
Entra ID自体がKerberosキー配布センター（KDC）として機能するようになったためです。
これにより、クライアントはクラウド上で直接Kerberosチケットを取得できるようになりました。
アクセス権限の設定も、引き続きNTFS ACLを利用でき、Entra-Onlyユーザーにも適用可能です。
アクセス許可は Azure ポータルで直接管理できるため、ドメイン参加済みクライアントを介在させずにアクセス許可を構成可能になり、運用のボトルネックとなっていた依存関係が解消されています。
具体的な活用シーン
1. VDIの最適化
AVDなどの環境で、ユーザープロファイル（FSLogix）の管理を劇的に簡素化します。
- ドメインレスな運用:
従来の AD やハイブリッド同期（Entra Connect）が不要になり、運用コストを削減できます。
- B2B 外部ユーザーの受け入れ:
外部パートナーが自社の既存 ID を使用してFSLogixプロファイルにアクセスできるため、重複アカウントの作成が不要になります。
2. 分散拠点・リモートワークでのファイル共有
VPNや複雑なネットワーク設定なしで、どこからでも安全にSMB共有へアクセスできます。
- VPN 不要のアクセス:
Entra参加済みデバイスから直接認証できるため、リモートワーカーの利便性が向上します。
- 迅速なオンボーディング:
新しい従業員にはEntraグループを通じて権限を付与するだけで、即座にファイルアクセスを許可できます。
3. 複雑な AD 環境を持つ業界（石油・ガスなど）
遠隔地や複数のドメイン・フォレストが混在する環境でのデータ管理を簡素化します。
- マルチドメインの解消:
複雑な信頼関係やハイブリッドインフラに依存せず、Entra IDひとつで世界中の拠点から重要なデータセットへ安全にアクセス可能です。
低接続環境での信頼性: VPN への依存を減らすことで、通信環境が不安定な現場でも安定した認証を実現します。
利用時の前提条件/注意事項
以下の公式ドキュメントに情報がまとまっています。 ここでは、主要な5つの情報を記載します。
①オペレーティングシステムの制限
Entra-Only IDを使用するには、以下のいずれかのオペレーティングシステムを使用する必要があります。
- Windows 11 Enterprise/Pro（シングルセッションまたはマルチセッション）
- 最新の累積更新プログラムがインストールされたWindows Server 2025
②MFAの制限
Microsoft Entra Kerberosは、Microsoft Entra Kerberosで構成されたAzureファイル共有へのアクセスにMFAを使用することをサポートしていません。
条件付きアクセスポリシーの MFA 対象から、自動作成されたストレージアカウント用アプリ（[Storage Account] <ストレージアカウント名>.file.core.windows.net）を明示的に除外する必要があります。
これを忘れると、サインイン時にKerberosチケットの取得に失敗し、システムエラー 1327 が発生します。
③IDソースの制限
ストレージアカウントで有効にできるIDソース（認証方法）は1つだけです。
既にオンプレミスAD(AD DS)やEntra Domain Servicesを利用している場合、それらを無効にしないとEntra Kerberosを有効化できません。
④B2B（ゲストユーザー）の制限
外部テナントのユーザー（B2B ゲスト）がAzure Filesにアクセスできるのは、現在のところAVD上で実行されるFSLogixシナリオのみに限定されています。
通常のPCからネットワークドライブとして直接マウントすることはできません。
⑤リージョンの制限（RBAC）
Entra-Only IDに対する特定のユーザー/グループへのRBAC割り当ては、順次展開されています。
利用したいリージョンがEntra Kerberosの地域別提供状況に含まれているか、事前に確認しておきましょう。
AVD + FSLogixを「Entra IDのみ」で構築する
では実際に、AVD用のプロファイルサーバーをEntra-Only ID認証のAzure Filesで構築してみます。
今回触れるのは以下の部分となります。
- ストレージアカウントでEntra Kerberosを有効化
- Entra IDアプリケーションへの管理者同意
- 共有レベルの権限（RBAC）割り当て
- ポータルからのNTFS ACL設定
- クライアント（セッションホスト）の設定
- FSLogixの構成
- 接続確認
ストレージアカウントでEntra Kerberos を有効化
①[Azureポータル]→[ストレージアカウント]→[データストレージ]→[クラシックファイル共有]→[IDベースのアクセス]から設定します。
②[手順１：IDソースを有効にする]の項目にて、[Microsoft Entra Kerberos]の[セットアップ]を押下します。
③[Microsoft Entra Kerberos]にチェックを入れて、[保存]を押下します。
※Entra IDのみの構成では[ドメインサービス]の項目は入力不要です。
共有レベルの権限（RBAC）割り当て
必要に応じて、ファイル共有へのアクセス権限の設定をします。
①[手順２：共有レベルのアクセス許可の設定]の項目にて、[既定の共有レベルのアクセス許可]を、[認証されているすべてのユーザーとグループについてアクセス許可を有効にする]にします。
②[該当するロールの選択]にて、必要な権限を選択します。
③[保存]を押下します。
Entra ID アプリケーションへの管理者同意
①[Azureポータル]→[Microsoft Entra ID]→[アプリの登録]に遷移し、[すべてのアプリケーション]タブから、プロファイルコンテナとして利用するストレージアカウント（[Storage Account] <ストレージアカウント名>.file.core.windows.net）を押下します。
②[APIのアクセス許可]に遷移し、[構成されたアクセス許可]内にある[<テナント名>に管理者の同意を与えます]を押下します。
③[管理者の同意の確認を与えます]の表示が出たら、[はい]を押下します。
ポータルからのNTFS ACL設定
①作成したファイル共有のページに遷移し、[参照]→[ディレクトリの追加]から、プロファイル用の親フォルダーを作成します。
②作成したフォルダーの右にある[...]から、[アクセスの管理]を押下します。
③必要に応じてNTFS ACLを変更し、[保存]を押下します。
画像の例では、デフォルト値から以下の二つの変更を行うことにより、ユーザー自身以外のユーザープロファイルの操作を防いでいます。
- [NT AUTHORITY\Authenticated Users]の適用対象を[このフォルダーに適用されます]に変更
- [BUILTIN\Users]を削除
クライアント（セッションホスト）の設定
マスターイメージを構成する際、VMに以下の設定を入れます。
今回はコマンドでレジストリの設定をします。
ここに記載している以外にもFSLogixやAVDに関する設定はあるので、要件に合わせて設定を入れてください。
①クライアントでのEntra Kerberos機能有効化
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1
②Credential Managerの資格情報キーをプロファイルへ紐づけ
FSLogix等のローミングプロファイルとMicrosoft Entra IDを併用する場合、Credential Managerの資格情報キーを読み込み中のプロファイルに紐付ける設定が重要です。
この構成により、利用環境が特定のVMに固定されるのを防ぎ、複数のVM間でシームレスにプロファイルを活用できるようになります。
reg add HKLM\Software\Policies\Microsoft\AzureADAccount /v LoadCredKeyFromProfile /t REG_DWORD /d 1
③Profile Containerの有効化
reg add "HKLM\Software\FSLogix\Profiles" /v Enabled /t REG_DWORD /d 1 /f
④プロファイルの格納先の指定
プロファイルの格納先を指定します。 ファイル共有の[共有URL]から成型して値を用意します。 今回の場合、プロファイルの親フォルダーとして作成した[profile-root]フォルダーのパス（\\entraonly1is0n6.file.core.windows.net\profile\profile-root）を設定します。
reg add "HKLM\Software\FSLogix\Profiles" /v VHDLocations /t REG_SZ /d "\\<ストレージアカウント名>.file.core.windows.net\<ファイル共有名>\<プロファイル保存先フォルダー名>" /f
⑤ローカルプロファイルが存在していた場合は削除
reg add "HKLM\Software\FSLogix\Profiles" /v DeleteLocalProfileWhenVHDShouldApply /t REG_DWORD /d 1 /f
セッションホストの作成
セッションホストの作成の際、[参加するドメイン]の項目で[Microsoft Entra ID]を指定します。
Host Poolの設定（RDPプロパティ）
セッションホストへの接続元の端末がEntra参加していない場合や、Windowsデスクトップクライアント以外から接続できるようにするためには、カスタムRDPプロパティとして[targetisaadjoined:i:1]をホストプールに追加します。
接続確認
ここまでの設定を元に作成したセッションホストに対して接続してみます。
接続後、指定したプロファイル用親フォルダー配下にユーザーごとのプロファイルフォルダーが作成されていることを確認できます（画像の例では、vdi-test01とvdi-test02の2ユーザー分）。
NTFS ACLにより、他ユーザーのプロファイルフォルダーの中身を見たり変更したりできなくなっていることが確認できます。
まとめ
Azure FilesのEntra-Only ID対応は、既存のAD環境を否定するものではなく、「より柔軟でモダンな選択肢」を提供するものです。
ハイブリッド環境でも利用できるため、現在の資産を活かしつつ、少しずつ管理負荷の少ないクラウドネイティブな構成へとシフトしていくための、新しい構築の選択肢として検討してみてください。
ACS 事業部のご紹介
私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。
また、一緒に働いていただける仲間も募集中です！
今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。
※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です
