Microsoft EntraだけでAzure FilesのSMB共有へアクセスできる「Entra-only identities with Azure Files」が一般提供になりました。結論から言うと、Azure Filesのファイル共有に対して、オンプレミスActive Directory、Microsoft Entra Connectによる同期、Microsoft Entra Domain Services、ドメインコントローラーを前提にしないクラウドネイティブなSMB認証を選べるようになった点が大きな変更です。(Microsoft Azure)
ただし、既存のAzure Files環境が自動的に切り替わるわけではありません。ストレージアカウントの認証方式、クライアントOS、RBAC、NTFS ACL、条件付きアクセス、リージョン対応を確認せずに展開すると、「認証は通るがアクセスできない」「一部ユーザーだけマウントできない」といったトラブルにつながります。
この記事では、2026年5月22日前後に公開・更新されたMicrosoft公式情報をもとに、Microsoft Entra管理者、Azure管理者、AVD担当者、アプリ開発者が確認すべき変更点と展開時の注意点を整理します。
Entra-only identities with Azure Filesで何が変わったのか
Entra-only identities with Azure Filesは、Azure FilesのSMBアクセスにMicrosoft Entra IDのクラウド専用IDを使えるようにする機能です。従来、Azure FilesでIDベースのSMBアクセスを実現する場合、オンプレミスAD DS、Microsoft Entra Domain Services、またはハイブリッドID構成が前提になるケースが多くありました。
今回の一般提供により、クラウド専用のMicrosoft Entra IDユーザーやグループを使って、Azure FilesのSMB共有へKerberosベースでアクセスできる構成が現実的な選択肢になりました。Microsoftの説明では、SMBプロトコル自体は維持しながら、Kerberosチケットの発行とID検証をMicrosoft Entra ID側で処理する仕組みです。(Microsoft Azure)
| 観点 | 従来の代表的な構成 | Entra-only identities with Azure Files |
|---|---|---|
| 認証基盤 | AD DS、Entra Domain Services、ハイブリッドID | Microsoft Entra IDのクラウド専用ID |
| SMBアクセス | ドメイン参加やDCへの到達性が課題になりやすい | Entra参加済みクライアントからクラウドIDでアクセス |
| 運用負荷 | DC、同期、ネットワーク、ドメイン管理が必要 | AD依存を減らしやすい |
| 権限管理 | Azure RBACとWindows ACLの組み合わせ | Azure RBACとNTFS ACLを引き続き利用 |
| 主な用途 | 既存ファイルサーバー移行、AVD、業務アプリ | クラウドネイティブなAVD、リモートワーク、クラウド専用テナント |
重要なのは、「Azure FilesがSMB共有であること」は変わらない点です。ファイルアクセスの考え方は、共有レベルのアクセス許可と、ディレクトリ・ファイル単位のNTFS ACLを組み合わせる従来のWindowsファイルサーバーに近いモデルです。Azure Filesでは、共有レベルの権限はAzure RBAC、ディレクトリ・ファイルレベルの権限はWindows ACLで制御します。(Microsoft Learn)
今回の一般提供で影響を受ける環境
今回の更新で特に恩恵が大きいのは、Active Directoryを新規に構築したくない、または段階的にAD依存を減らしたい組織です。Microsoftは、Azure Files SMBでEntra-only identitiesが一般提供となり、HDD/SSD共有および全課金モデルで追加コストなしに利用できると説明しています。(Microsoft Azure)
Azure Virtual DesktopとFSLogixを使う環境
最も分かりやすい活用シーンは、Azure Virtual DesktopのFSLogixプロファイルコンテナーです。Entra参加済みのセッションホストとクラウド専用IDを組み合わせ、FSLogixプロファイルをAzure Filesに保存する構成を取りやすくなります。Microsoft Learnでも、FSLogixプロファイルをAzure Files上に保存し、Microsoft Entra Kerberosでアクセスする構成が説明されています。(Microsoft Learn)
これまでAVDでFSLogixを使うために、プロファイル保存先だけのためにAD DSやEntra Domain Servicesを用意していた環境では、設計の見直し候補になります。特に、新規AVD環境、既存ADとの接続を最小化したい拠点、外部パートナー向けVDIでは検討価値があります。
ただし、B2B外部IDのSMBサポートは、現時点ではAzure Virtual Desktop上のFSLogixシナリオに限定されます。一般的なファイル共有用途で、他テナントのゲストユーザーへそのままSMB共有を開放できると考えるのは危険です。(Microsoft Learn)
クラウド専用テナントのファイル共有
Microsoft 365中心で運用しており、オンプレミスADを持たない組織でも、Azure Filesを社内ファイル共有として使いやすくなります。新入社員をMicrosoft Entraグループに追加し、Azure Files側で共有レベルのRBACとNTFS ACLを設定することで、ファイル共有のアクセス制御をクラウド側に寄せられます。
ただし、ローカルPCからの直接利用では、クライアント要件とSMB通信経路の確認が必要です。すべてのWindows端末やmacOS端末が同じように使えるわけではありません。
既存AD環境を段階的に縮小したい組織
既存のAD DSをすぐ廃止するのではなく、新規ファイル共有や新規AVD環境からMicrosoft Entra Kerberosへ寄せる使い方が現実的です。Microsoft公式ブログでも、ハイブリッドIDとクラウドネイティブIDを併用しながら、Active Directoryの依存を減らしていくシナリオに触れています。(Microsoft Azure)
既存の業務アプリ、GPO、ファイルサーバー、サービスアカウントがAD前提で動いている場合は、一括移行ではなく「新規ワークロードから適用」が安全です。
管理者が最初に確認すべき前提条件
Entra-only identities with Azure Filesを使う前に、まずストレージアカウント、クライアント、権限、条件付きアクセスを確認します。ここを飛ばすと、本番展開後に原因調査が難しくなります。
| 確認項目 | 見るべきポイント | 判断基準 |
|---|---|---|
| ストレージアカウント | 既にAD DSやEntra Domain ServicesをIDソースにしていないか | Azure FilesのIDソースはストレージアカウントごとに1つだけ |
| クライアントOS | Windows 11、Windows Server 2025など対応OSか | クラウド専用IDでは対応OSが限定される |
| 参加状態 | Microsoft Entra joinedまたはEntra hybrid joinedか | AD参加のみ、Entra Domain Services参加のみは対象外 |
| リージョン | 利用リージョンが対応範囲か | クラウド専用IDの特定ユーザー・グループ向けRBACは一部リージョンに制限あり |
| 権限設計 | RBACとNTFS ACLの両方を設計しているか | RBACだけではディレクトリ・ファイル単位の制御は完結しない |
| 条件付きアクセス | ストレージアカウントのEntraアプリがMFA対象になっていないか | MFA除外を忘れるとSMBマウントに失敗する可能性がある |
Microsoft Learnでは、クラウド専用IDでMicrosoft Entra Kerberosを使う場合、Windows 11 Enterprise/Pro single or multi-session、または最新の累積更新プログラムを適用したWindows Server 2025が前提として示されています。また、クライアントはMicrosoft Entra joinedまたはMicrosoft Entra hybrid joinedである必要があります。(Microsoft Learn)
ストレージアカウントのIDソースは1つだけ
Azure FilesのIDベース認証では、1つのストレージアカウントに対して有効化できるIDソースは1つだけです。既にAD DSまたはMicrosoft Entra Domain Servicesを使っているストレージアカウントに対し、Microsoft Entra Kerberosを同時に有効化することはできません。(Microsoft Learn)
そのため、既存共有をすぐ切り替えるよりも、次のように分けて考えるのが安全です。
| 状況 | 推奨される進め方 |
|---|---|
| 新規のAVD環境 | 新しいストレージアカウントでEntra Kerberosを有効化して検証 |
| 既存AD DS連携のAzure Files | 既存環境を維持し、別ストレージアカウントで移行検証 |
| オンプレファイルサーバー移行 | データ、ACL、利用端末、アプリ依存を棚卸しして段階移行 |
| クラウド専用テナント | 最初からEntra Kerberos前提でストレージアカウントを作成 |
既存の本番ファイル共有がある場合は、認証方式の切り替えを「設定変更」ではなく「移行プロジェクト」として扱うべきです。ファイル共有は利用者の業務停止に直結しやすいため、PoC、パイロット、段階展開の順に進めます。
設定時に見るべき主要ポイント
Microsoft Entra Kerberosを有効化する
Azure FilesでMicrosoft Entra Kerberos認証を有効化するには、Azureポータル、Azure PowerShell、Azure CLIを利用できます。Azure CLIでは、ストレージアカウントに対して --enable-files-aadkerb true を指定する形式が公式ドキュメントで示されています。(Microsoft Learn)
az storage account update \
--name <storageAccountName> \
--resource-group <resourceGroupName> \
--enable-files-aadkerb truePowerShellでは、次のような設定を行います。
Set-AzStorageAccount `
-ResourceGroupName <resourceGroupName> `
-StorageAccountName <storageAccountName> `
-EnableAzureActiveDirectoryKerberosForFile $true実務では、ポータルで検証してからBicep、Terraform、PowerShell、Azure CLIなどで再現可能な形に落とし込むのがよいでしょう。設定差分が追えないまま本番環境へ展開すると、権限トラブル時の切り戻しが難しくなります。
自動作成されるサービスプリンシパルへ管理者同意を付与する
Microsoft Entra Kerberosを有効化すると、ストレージアカウントに対応するEntraアプリケーションが作成されます。公式手順では、このアプリケーションに対して、openid、profile、User.ReadのAPIアクセス許可に管理者同意を付与する必要があります。(Microsoft Learn)
ここで注意したいのは、このサービスプリンシパルを通常の業務アプリのように自由に編集しないことです。Microsoft Learnでは、ドキュメントに記載された内容以外の編集を行うとエラーになる可能性があると説明されています。(Microsoft Learn)
クラウド専用グループ対応を有効化する
クラウド専用IDでMicrosoft Entra Kerberosを使う場合、アプリケーションマニフェストのタグ更新が必要です。公式ドキュメントでは、この設定を行わないと認証に失敗するとされています。(Microsoft Learn)
また、Kerberosチケットに含められるグループSIDは最大1,010個です。オンプレミス由来のグループSIDとクラウドグループSIDを合わせて上限を超えると、Kerberosチケットを発行できません。大規模組織では、対象ユーザーのグループ所属数を事前に確認してください。(Microsoft Learn)
条件付きアクセスのMFA除外を確認する
Microsoft Entra Kerberosでは、Azure FilesへのSMBアクセス時にMFAを使うことはサポートされていません。条件付きアクセスで「すべてのクラウドアプリにMFAを要求」といったポリシーを設定している場合、ストレージアカウントを表すEntraアプリをMFAポリシーから除外する必要があります。(Microsoft Learn)
除外しない場合、net use で共有をマウントしようとした際に、アカウント制限によりサインインできない旨のエラーが出る可能性があります。セキュリティを弱めるのではなく、SMBのサイレント認証に必要な例外として、対象アプリを明確に限定して運用することが重要です。
権限設計はRBACとNTFS ACLを分けて考える
Azure Filesのアクセス制御でよくある失敗は、「RBACを付けたからファイルにアクセスできるはず」と考えてしまうことです。Azure Filesでは、共有レベルの権限が入口のゲートになり、その先のディレクトリ・ファイル操作はWindows ACLで制御されます。(Microsoft Learn)
| レイヤー | 役割 | 例 |
|---|---|---|
| 共有レベル | 共有に入れるかを制御 | Storage File Data SMB Share Reader、Contributorなど |
| ディレクトリレベル | フォルダー単位の読み書きを制御 | 部署フォルダー、プロジェクトフォルダー |
| ファイルレベル | 個別ファイルの詳細権限を制御 | 読み取り専用、変更、所有者変更など |
Microsoft Learnでは、共有レベル権限は多くの場合、特定のMicrosoft Entraユーザーまたはグループに割り当て、細かい制御はWindows ACLで行う構成が最も安全だと説明されています。(Microsoft Learn)
クラウド専用IDではACL設定方法に注意する
クラウド専用IDでEntra Kerberosを使う場合、Windows File Explorerや icacls でのACL設定はサポートされていません。AzureポータルまたはPowerShellのRestSetAclsモジュールを使う必要があります。(Microsoft Learn)
これは現場でつまずきやすいポイントです。従来のファイルサーバー管理に慣れている管理者ほど、エクスプローラーのセキュリティタブから権限を設定しようとしがちです。クラウド専用IDを使う場合は、権限変更手順も運用手順書に明記しておきましょう。
クライアント側の設定も必要
Microsoft Entra Kerberosを有効化しただけでは、クライアントが自動的にKerberosチケットを取得できるとは限りません。公式手順では、Azure Files共有をマウントする各クライアントでEntra Kerberos機能を有効化する必要があります。方法はIntune、グループポリシー、レジストリのいずれかです。(Microsoft Learn)
Intuneを使う場合は、Kerberos/CloudKerberosTicketRetrievalEnabled を有効化します。Microsoft Learnでは、Azure Virtual Desktopのマルチセッション環境ではOMA-URIではなくSettings Catalogを使うよう注意されています。(Microsoft Learn)
レジストリで検証する場合は、次のような設定例が示されています。
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1設定後すぐに反映されない場合があるため、ポリシー更新または再起動を含めて検証計画を立てます。
既存AD DS連携ストレージとの共存に注意する
同じクライアントから、Microsoft Entra Kerberosのストレージアカウントと、オンプレミスAD DS連携のストレージアカウントの両方に接続する場合は注意が必要です。Microsoft Learnでは、Entra Kerberosのクライアント設定を適用した後、AD DS統合済みストレージアカウントにも接続するにはKerberos realm mappingの設定が必要と説明されています。(Microsoft Learn)
つまり、既存のAzure Files利用環境がある組織では、クライアント設定を全社一括で配布する前に、どのストレージアカウントがどの認証方式を使っているかを棚卸しする必要があります。
移行・展開の進め方
本番環境へ適用する場合は、次の順序で進めると失敗しにくくなります。
| フェーズ | 実施内容 | 成功条件 |
|---|---|---|
| 棚卸し | 既存ファイル共有、ストレージアカウント、認証方式、利用者、端末を確認 | AD DS依存の有無が分かる |
| 対象選定 | AVD、クラウド専用部署、新規プロジェクト共有などを選ぶ | 影響範囲が限定されている |
| PoC | 新規ストレージアカウントでEntra Kerberosを有効化 | テストユーザーでマウントと権限確認ができる |
| 権限設計 | RBAC、NTFS ACL、Entraグループを設計 | 最小権限で運用できる |
| クライアント展開 | IntuneまたはGPOでKerberosチケット取得設定を配布 | 対象端末で安定してアクセスできる |
| データ移行 | 必要に応じてファイルとACLを移行 | ACLを保持したまま移行できる |
| パイロット | 一部ユーザーで業務利用 | 認証失敗、権限不足、遅延を解消できる |
| 本番展開 | 段階的に利用者を拡大 | 問い合わせ対応手順が整っている |
オンプレミスファイルサーバーからAzure Filesへ移行する場合、Azure Filesはディレクトリ・ファイルレベルのACLを保持できます。Microsoft Learnでは、Azure File SyncやRobocopyの /copy:s など、一般的なファイル移行ツールでACLを保持できることが説明されています。(Microsoft Learn)
ただし、ACLを保持できることと、移行後に期待通りアクセス制御が効くことは別です。移行元のSID、Entraグループ、RBAC、NTFS ACLが新しい認証方式で正しく解決されるかを、必ずテストユーザーで確認してください。
開発者が確認すべきポイント
開発者にとって重要なのは、「ユーザーのSMBアクセス」と「アプリケーションからのアクセス」を混同しないことです。
Entra-only identities with Azure Filesは、主にSMBアクセスでクラウド専用IDを使うための更新です。一方、アプリケーションコードからAzure Filesを操作する場合は、Azure Files REST API、Azure SDK、OAuth、Managed Identityなど別の選択肢もあります。Microsoftのドキュメントでは、Azure Files RESTアクセスに対してAzure Identityクライアントライブラリや DefaultAzureCredential を使う例が紹介されています。(Microsoft Learn)
また、Azure Files SMBではManaged Identityサポートも一般提供されています。アプリケーション、VM、AzureサービスからAzure Filesへアクセスする場合は、ユーザーIDでSMB共有をマウントするのではなく、Managed Identityでシークレットレスに接続できるかを検討してください。(Microsoft Azure)
| 開発・運用シーン | 選ぶべき方向性 |
|---|---|
| AVDユーザーのFSLogixプロファイル | Entra Kerberos + Azure Files SMB |
| 社内ユーザーのファイル共有 | Entra Kerberos + RBAC + NTFS ACL |
| Azure VM上のアプリがSMBで共有へアクセス | Managed Identity for Azure Files SMBを検討 |
| WebアプリやバッチがREST APIでファイル操作 | Azure SDK + DefaultAzureCredentialを検討 |
| 既存コードがストレージアカウントキーを保持 | キー依存を減らし、IDベースアクセスへ移行検討 |
実務では、まず「そのアクセスは人間のユーザーによるSMBアクセスなのか、アプリケーションのデータアクセスなのか」を分けて設計します。ここを混ぜると、不要な共有キー、過剰なRBAC、管理できないマウントスクリプトが増えます。
展開時に起きやすいトラブルと対処
| 症状 | 主な原因 | 対処 |
|---|---|---|
| RBACを付けたのにアクセスできない | NTFS ACLが未設定、またはRBAC反映待ち | ACLを確認し、権限反映を待って再試行 |
| クラウド専用ユーザーでACLを設定できない | File Explorerやicaclsを使っている | AzureポータルまたはRestSetAclsを使う |
net use でサインイン制限エラーが出る | 条件付きアクセスのMFA対象になっている | ストレージアカウントのEntraアプリをMFAポリシーから除外 |
| 一部ユーザーだけ認証に失敗する | グループSID数が多すぎる可能性 | グループ所属数を整理し、対象グループを絞る |
| プライベートエンドポイント経由で失敗する | Private Link FQDNがEntraアプリに追加されていない | ストレージアカウントのEntraアプリにPrivate Link FQDNを追加 |
| 既存AD DS連携の共有に接続できない | クライアント側のEntra Kerberos設定との共存未対応 | Kerberos realm mappingを設定 |
| B2Bユーザーが通常のファイル共有にアクセスできない | 外部IDサポート範囲外 | AVD FSLogixシナリオかどうかを確認 |
特に見落としやすいのは、共有レベル権限の反映時間です。Microsoft Learnでは、共有レベルの権限変更は通常30分以内に反映されるものの、それ以上かかる場合があると説明されています。設定直後のアクセス失敗を、すぐに構成ミスと判断しないようにしましょう。(Microsoft Learn)
今すぐ管理者が行うべき確認
Entra-only identities with Azure Filesは、すべての環境で即時移行すべき機能ではありません。しかし、今後Azure Filesを新規導入する環境、AVDをクラウドネイティブに構成したい環境、AD依存を減らしたい組織では、早めに標準設計へ組み込む価値があります。
まずは次の順で確認してください。
- Azure Filesを利用しているストレージアカウントと認証方式を一覧化する
- 新規または更改予定のAVD/FSLogix環境があるか確認する
- 対象ユーザーがクラウド専用IDかハイブリッドIDかを整理する
- クライアントOSとEntra参加状態を確認する
- RBACとNTFS ACLの設計方針を決める
- 条件付きアクセスでストレージアカウントアプリのMFA除外が必要か確認する
- 小規模な検証用ストレージアカウントでPoCを行う
今回の更新は、単なるAzure Filesの認証オプション追加ではなく、Windowsファイル共有をクラウドネイティブIDで扱うための大きな一歩です。既存ADをすぐなくすための機能としてではなく、「新しいファイル共有、AVD、アプリ基盤をAD非依存で作るための選択肢」として評価すると、導入判断を誤りにくくなります。
コメント