Azure FilesをMacから使いたいが、ストレージアカウントキーや従来のActive Directory依存は増やしたくない――そんな組織にとって、2026年6月3日のMicrosoft Entra関連更新は確認すべき内容です。今回のPublic Previewでは、macOSからAzure FilesへMicrosoft Entra ID認証でアクセスできるようになり、管理されたMacユーザーがIDベースでSMBファイル共有を利用できる道が広がりました。Azure Updatesでは対象機能が「In preview」として掲載されており、Previewは非本番利用・検証向けの位置づけです。(マイクロソフト Azure)
結論から言えば、これは「すぐ全社本番展開する機能」ではなく、IntuneまたはMDM、Platform SSO、Microsoft Entra Kerberos、アクセス権設計をそろえたうえで、限定ユーザーから検証すべきセキュリティ更新です。本記事では、変更点、影響範囲、管理者が確認すべき設定、移行時に失敗しやすいポイントを実務目線で整理します。
Microsoft Entraのセキュリティ更新で何が変わったのか
今回のポイントは、Azure FilesそのものがmacOSに対応したことではありません。重要なのは、macOSからAzure FilesのSMB共有へアクセスする際に、Microsoft Entra IDを使った認証フローを利用できるようになったことです。
Microsoft Learnでは、macOS Platform Single Sign-On、いわゆるPlatform SSOを使い、Microsoft Entra参加済みのmacOSデバイスがクラウドベースのKerberos TGTを使ってAzure FilesのSMB共有へアクセスできると説明されています。構成が正しければ、ユーザーは追加の資格情報入力なしでファイル共有をマウントできます。(Microsoft Learn)
| 観点 | 従来課題になりやすかった点 | 今回のPublic Previewで見直せる点 |
|---|---|---|
| 認証方式 | ストレージアカウントキー、AD DS、個別の認証運用に依存しやすい | Microsoft Entra IDを基点にしたIDベースのアクセスへ寄せられる |
| macOS利用 | Windows中心の運用とMac利用者の運用が分かれやすい | FinderからSMB共有をマウントするMac利用者も統制対象にしやすい |
| セキュリティ | 共有キーの配布、保管、ローテーションが運用リスクになりやすい | ユーザーやグループ単位の権限管理へ移行しやすい |
| 管理負荷 | Mac向け手順だけ例外運用になりやすい | Intune/MDMとPlatform SSOを使った標準化を検討できる |
MicrosoftのAzure Storage Blogでも、macOSユーザーが資格情報プロンプトやストレージアカウントキーなしでAzure file sharesへアクセスできる点、IT管理者がキー配布やローテーションの負担を減らせる点が利点として示されています。(TECHCOMMUNITY.MICROSOFT.COM)
影響範囲はAzure Filesを使うMac混在チームが中心
この更新の影響を受けるのは、Microsoft Entra IDだけを見ているID管理者だけではありません。Azure Files、Mac端末管理、ネットワーク、アプリケーション運用まで関係します。
| 対象 | 具体例 | 確認すべきこと |
|---|---|---|
| 情シス・ID管理者 | Microsoft Entra ID、条件付きアクセス、グループ管理 | Azure Files用の認証アプリ、MFA除外、管理者同意 |
| 端末管理者 | Intune、MDM、macOS Platform SSO | 対象MacのOS、Company Portal、MDM登録、Platform SSO配布状況 |
| Azure管理者 | Storage Account、Azure Files、Private Endpoint | Microsoft Entra Kerberosの有効化、IDソース、ポート445、権限 |
| 開発・業務アプリ担当 | Mac上の制作ツール、AI/データ処理、共有フォルダー利用 | SMB共有上でのファイルロック、パス、権限エラー時の動作 |
| ヘルプデスク | Macユーザーの初回接続、権限問い合わせ | Finder接続手順、認証プロンプト発生時の切り分け |
特に対象になりやすいのは、デザイン、映像、研究、AI開発など、Mac利用者とWindows利用者が同じファイル共有を使う組織です。MicrosoftはmacOSクライアントへの対応について、クリエイティブチームや教育機関などのクロスプラットフォーム業務を想定したものとして説明しています。(マイクロソフト Azure)
一方で、未管理の個人Mac、BYOD中心の環境、テナントをまたぐ一般的な外部ユーザー共有には慎重な判断が必要です。Microsoft Entra Kerberosでは、クロステナントアクセスは現時点でサポートされていないとされています。(Microsoft Learn)
管理者が最初に確認すべき前提条件
導入前に、まず「対象ユーザーがMacを持っているか」ではなく、「そのMacを組織が管理できているか」を確認してください。今回の機能は、単にSMBパスを配れば使えるタイプの更新ではありません。
Microsoft Learnで示されているmacOS側の主な前提条件には、macOS Tahoe 26.5以降、Microsoft Intune Company Portal 5.2408.0以降、MDM登録、macOS Platform SSOの事前構成が含まれます。また、Azure Files側ではストレージアカウントでMicrosoft Entra Kerberos認証を有効化し、管理者同意を付与し、ストレージアカウントを表すEntraアプリに対するMFAを無効化する必要があります。(Microsoft Learn)
| 確認項目 | OKの状態 | よくあるNG例 |
|---|---|---|
| macOS端末 | 対象バージョンを満たし、MDM管理下にある | 個人所有MacやMDM未登録端末を対象にする |
| Platform SSO | Microsoft Entra IDでのサインイン連携が構成済み | Azure Files設定だけ先に進める |
| Company Portal | 必要バージョン以降が導入済み | 古いCompany Portalのまま検証する |
| ストレージアカウント | Microsoft Entra Kerberosを有効化済み | 既存のAD DS認証と同じアカウントで併用しようとする |
| Entraアプリ | 管理者同意とMFA除外を確認済み | 全アプリMFA強制ポリシーでKerberos発行を妨げる |
| ネットワーク | SMB用のTCP 445へ到達可能 | 社内・自宅・VPN環境で445が遮断されている |
| 権限 | 共有レベル権限とACLの両方を確認済み | Azure RBACだけ設定してファイルアクセス権を見落とす |
ここでいうMFA無効化は、ユーザー全体のMFAをやめるという意味ではありません。Azure FilesのKerberos認証に使われるストレージアカウントのEntraアプリに対して、SMBアクセスが成立するよう条件付きアクセスを設計するという意味です。全ユーザー、全クラウドアプリを広く除外する設定は避け、対象アプリと目的を明確にしてください。
設定・展開の流れ
本番に近い環境でいきなり既存共有を切り替えるのは危険です。まずは新規または検証用のStorage Accountと少数のMacユーザーで、認証、マウント、権限、業務アプリの動作を確認しましょう。
| 手順 | 作業内容 | 実務上の注意点 |
|---|---|---|
| 1 | 対象ユーザーとファイル共有を棚卸しする | Mac利用者、共有名、権限、既存マウント方法を一覧化する |
| 2 | ストレージアカウントでMicrosoft Entra Kerberosを有効化する | Azure portal、PowerShell、Azure CLIのいずれかで有効化できる |
| 3 | 自動作成されたEntraアプリへ管理者同意を付与する | 対象アプリ名はストレージアカウント名に紐づく |
| 4 | 既存共有がある場合、識別子URIを確認する | CIFS/が大文字のままだとmacOSでマウントに失敗する可能性がある |
| 5 | Kerberos SSO用のMDMプロファイルを作成する | Cloud Kerberos realm、Hosts、Realmを正しく指定する |
| 6 | IntuneまたはMDMで対象ユーザーへ配布する | Platform SSOポリシーはユーザーベースで割り当てる |
| 7 | 共有レベル権限を付与する | 必要最小限のEntraグループで割り当てる |
| 8 | Macでチケット発行、ポート、Finder接続を検証する | 認証プロンプトが出ないこと、権限どおりに操作できることを確認する |
既存共有ではCIFSの大文字小文字に注意
既存のAzure file shareをmacOSからMicrosoft Entra Kerberosで利用する場合、アプリ登録の識別子URIに含まれるCIFSを小文字のcifsへ更新する必要があります。公式ドキュメントでは、CIFS/<storageaccount>.file.core.windows.netが残っているとmacOSクライアントが認証・マウントできないため、提供されているPowerShellスクリプトで更新するよう案内されています。作業前には-WhatIfで変更内容を確認するのが安全です。(Microsoft Learn)
検証後は、Microsoft Entra IDのアプリ登録から対象ストレージアカウントのManifestを開き、識別子URIが次のように小文字になっていることを確認します。
cifs/<storageaccount>.file.core.windows.netMDMプロファイルではCloud Kerberos realmを正しく指定する
macOS側では、Microsoft Entra ID Cloud Kerberosを向くKerberos SSO MDMプロファイルを配布します。主な値は次のとおりです。
| 設定キー | 推奨値 |
|---|---|
preferredKDCs | kkdcp://login.microsoftonline.com/<tenantId>/kerberos |
Hosts | windows.net、.windows.net |
Realm | KERBEROS.MICROSOFTONLINE.COM |
usePlatformSSOTGT | true |
performKerberosOnly | true |
Microsoft Learnでは、Realmは大文字で指定すること、usePlatformSSOTGTとperformKerberosOnlyを構成することが示されています。(Microsoft Learn)
オンプレミスADリソースにもKerberos SSOする場合は、Microsoft Entra ID Cloud Kerberos用とオンプレミスAD用のプロファイルを分けて配布します。両方使う場合は、オンプレミスAD用プロファイルを先に配布する点も忘れないでください。(Microsoft Learn)
Intune配布では「デバイスチャネル」と「ユーザー割り当て」を混同しない
Intuneを使う場合は、macOSのカスタム構成プロファイルとして.mobileconfigをアップロードします。公式手順では、Deployment channelはDevice channelを選択しつつ、Assignmentsではユーザーまたはユーザーグループに割り当てる流れになっています。Platform SSOポリシーはユーザーベースのため、デバイスへ割り当てない点が重要です。(Microsoft Learn)
この部分は展開時に混乱しやすいポイントです。管理画面上の「デバイスチャネル」と「割り当て先」は別の概念として扱いましょう。
Macからの接続確認で見るべきポイント
構成が完了したら、いきなりユーザーへ案内せず、管理者側で次の順に確認します。
Kerberosチケットを確認する
Macのターミナルで次のコマンドを実行します。
app-sso platform -s出力にMicrosoft Entra ID Cloud Kerberos realmのKerberosチケットが含まれ、ticketKeyPathにtgt_cloudが表示されることを確認します。オンプレミスAD用プロファイルも配布している場合は、tgt_adも確認対象になります。(Microsoft Learn)
SMB接続に必要なポート445を確認する
Azure FilesのSMB接続では、クライアントからストレージアカウントへのTCP 445到達性が重要です。
nc -vz <storageaccountname>.file.core.windows.net 445会社ネットワーク、VPN、自宅回線、ゼロトラストネットワーク製品の経路によって、ポート445が遮断されることがあります。端末設定が正しくても、ここで失敗するとFinderからのマウントは安定しません。
FinderからSMB URLで接続する
Finderで「移動」から「サーバへ接続」を開き、次の形式で接続します。
smb://<storageaccountname>.file.core.windows.net/<sharename>構成が正しければ、ユーザーに資格情報を求めずに共有がマウントされます。プロンプトが表示される場合は、認証、MDMプロファイル、管理者同意、MFA除外、共有権限のいずれかに問題がある可能性があります。(Microsoft Learn)
移行判断で見るべきポイント
今回のPublic Previewは、すべてのAzure Files環境を直ちに置き換えるものではありません。特に既存のAD DS認証を使っている環境では、ストレージアカウント単位のIDソース設計が重要です。
Azure FilesのIDベース認証では、ストレージアカウントに対して有効化できるIDソースは1つだけです。Microsoft Entra Kerberos、オンプレミスAD DS、Microsoft Entra Domain Servicesを同じストレージアカウントで同時に使うことはできません。(Microsoft Learn)
| 進めやすいケース | 慎重に進めるケース |
|---|---|
| MacがIntuneまたはMDMで管理されている | BYODや未管理Macが中心 |
| Platform SSOをすでに導入済み、または導入計画がある | Platform SSOの設計が未着手 |
| ストレージアカウントを新規に分けて検証できる | 既存AD DS認証の共有をそのまま切り替えたい |
| Entraグループで権限管理を標準化したい | 個別ユーザーや共有キーで例外運用が多い |
| MacとWindowsの共同作業をAzure Filesへ集約したい | 外部テナントやゲストユーザー共有が主目的 |
| ネットワークでTCP 445を許可できる | 利用場所によって445が遮断されやすい |
クラウド専用IDで特定ユーザーやグループへAzure RBACを割り当てる場合は、リージョン制限にも注意が必要です。Microsoft Learnでは、クラウド専用ID向けの特定ユーザー・グループRBACサポートが一部リージョンに限定されることが示されています。(Microsoft Learn)
開発者・アプリ担当者が確認すべきこと
開発者や業務アプリ担当者は、「Finderで開けたから完了」と判断しないことが大切です。ユーザー操作では問題なくても、アプリケーションから見るとファイルパス、ロック、再接続、権限エラーの扱いが変わることがあります。
確認すべき観点は次のとおりです。
| 観点 | 確認内容 |
|---|---|
| パス指定 | Windows UNCパス前提の手順を、macOSではsmb://形式に読み替えられるか |
| 認証前提 | スクリプトやアプリ設定にストレージアカウントキーを埋め込んでいないか |
| ファイルロック | 複数人編集、制作ツール、データ処理中のロック挙動に問題がないか |
| 権限エラー | アクセス拒否時にアプリが分かりやすいエラーを返すか |
| 大量ファイル処理 | 小さなファイルを大量に扱う処理で遅延や再試行が増えないか |
| オフライン時 | ネットワーク断、VPN切断、スリープ復帰後に再接続できるか |
特に制作系ツール、AI学習データ、ログ出力先、共有テンプレート保存先などは、単純な読み書きテストだけでは不十分です。実際のファイルサイズ、同時利用人数、アプリの保存動作に近い条件で検証してください。
展開時に失敗しやすいポイント
Public Preview段階では、設定ミスをユーザー配布後に見つけるとサポート負荷が一気に増えます。以下の症状は、パイロット中に必ず切り分け手順を用意しておきましょう。
| 症状 | 主な原因 | 対応 |
|---|---|---|
| Finder接続時に資格情報を求められる | CIFS/が小文字化されていない、TGTがない、MDMプロファイル未適用 | 識別子URI、app-sso platform -s、MDM配布状況を確認 |
| 接続自体が失敗する | TCP 445が遮断されている | nc -vzで到達性を確認し、ネットワーク経路を見直す |
| 認証は通るがアクセス拒否になる | 共有レベル権限またはACL不足 | Entraグループ、Azure RBAC、ファイル/ディレクトリACLを確認 |
| 一部ユーザーだけ失敗する | グループ反映遅延、対象ユーザーへのポリシー未割り当て | 対象グループ、Intune割り当て、端末チェックインを確認 |
| MFAや条件付きアクセスで詰まる | ストレージアカウントのEntraアプリがMFA対象になっている | 除外対象を最小化して条件付きアクセスを再設計 |
| Private Endpoint利用時に認証できない | Private Link FQDNがEntraアプリに追加されていない | Microsoftのトラブルシューティング手順に沿ってFQDNを確認 |
Private EndpointまたはPrivate Link経由でMicrosoft Entra Kerberos認証を使う場合は、ストレージアカウントのMicrosoft EntraアプリへPrivate Link FQDNを追加する必要がある点も確認してください。(Microsoft Learn)
なお、macOSのKerberos SSO拡張メニューが「Not signed in」と表示されても、SMB Azure file shareアクセスには影響しない既知事項として案内されています。ユーザーに不要な操作をさせないよう、ヘルプデスク向けFAQに入れておくと混乱を減らせます。(Microsoft Learn)
セキュリティ設計で外してはいけない考え方
この更新を安全に使うには、「MacでもAzure Filesが使えるようになった」ではなく、「Macのファイル共有アクセスをMicrosoft Entraの統制下に置く」と捉えることが重要です。
実務では、次の設計を先に決めてから展開しましょう。
| 設計項目 | 推奨方針 |
|---|---|
| 権限付与 | 個人ではなくEntraグループで割り当てる |
| グループ設計 | 閲覧、共同作成、管理者を分ける |
| 共有キー | ユーザー向け手順や端末設定から排除する方向で見直す |
| 条件付きアクセス | ストレージアカウントアプリのMFA除外は最小範囲に限定する |
| 監査 | 変更前後のアプリ登録、権限、MDM配布対象を記録する |
| 展開 | いきなり全社ではなく、検証グループから段階展開する |
特にストレージアカウントキーを使った既存手順が残っている場合は、今回の検証と同時に棚卸ししてください。キーが手順書、スクリプト、端末設定、古い自動マウント設定に残っていると、Microsoft Entra IDベースへ移行しても運用リスクが残ります。
まずは限定パイロットで検証する
今回のMicrosoft Entraセキュリティ更新は、Macを含むクロスプラットフォームチームにとって大きな前進です。Azure FilesをMicrosoft Entra ID、Platform SSO、Kerberosで扱えるようになることで、ストレージアカウントキーや従来のAD依存を減らし、IDベースのファイル共有運用へ近づけます。
ただし、Public Previewである以上、最初にやるべきことは全社展開ではありません。次の順で進めるのが現実的です。
- 対象Mac、Azure Files共有、現在の認証方式を棚卸しする
- 検証用ストレージアカウントまたは検証用共有を用意する
- Platform SSOとKerberos SSO MDMプロファイルを少数ユーザーへ配布する
CIFS小文字化、管理者同意、MFA除外、権限設定を確認する- Finder接続、業務アプリ、ファイルロック、ネットワーク断を検証する
- ヘルプデスク手順とロールバック方針を作ってから対象範囲を広げる
Macユーザーの利便性だけで判断せず、ID、端末、ネットワーク、権限、サポート運用をひとつの設計として確認することが、この更新を安全に活用する近道です。
コメント