Microsoft Ignite 2025 に参加してきましたので、その中でも発表されていた、Azure Files のクラウド専用 ID での認証について、検証してみました。
クラウド専用 ID とは、Active Directory Domain Service や Entra ID Domain Services を利用せず、Entra ID のみを利用して作成・管理される、Entra ID 上にのみ存在するアカウントのことです。
補足
このクラウド専用 ID での認証は、このブログを執筆時点 ( 検証は 2026年1月20日 時点 ) では、プレビュー機能となります。
今後、仕様が大幅に変わることが想定されますので、必ず最新の情報を確認いただくようにお願いします
(Update 2026/05/21)
クラウド専用 ID による認証は、2026/05/19 に正式リリースされました。(参考: Azure Files Entra-Only identities: Advancing cloud-native identity and security)
これに伴い、本記事も内容を最新の情報に更新しています。
TL;DR
このブログでは、Azure Files のクラウド専用 ID によるアクセス制御について以下を実施。
- Azure Files のクラウド専用 ID によるアクセス制御機能
2026/01/20現在 プレビュー機能を検証 - Azure CLI と bicep を用いた検証環境の構築方法を検証
- 検証の結果として、ファイル共有上のフォルダ・ファイル単位のアクセス制御の設定方法・診断設定ログの確認方法を記載
- 特にクラウド専用 ID における SID と 表示名等の紐づけにはMicrosoft Graph の利用が必須
Azure Files のクラウド専用 ID による ID ベースの認証について (Updated: 2026/05/21)
Azure Files を SMB 共有として利用する場合、ID ベースの認証が利用可能です。
これまでは、ID ベースの認証を利用する場合、Microsoft Entra Connect等を利用して、Microsoft Entra ID にオンプレミスから同期されたハイブリッドアカウントや、Microsoft Entra Domain Services の利用が必須でした。
最近、この ID ベースの認証において、クラウド専用 ID、つまりMicrosoft Entra ID上のみで作成・存在しているIDを利用することが可能となりました。
これによって、クラウド専用 ID でも、以下の前提条件を満たすことで ID ベースの認証を利用可能になりました。
クラウド専用 ID を利用するための最小限の前提条件:
Azure 上の構成の要件
- Azure ストレージ アカウント(Azure Files)の認証方法(ID連携で利用する認証方法)には、Microsoft Entra Kerberos を利用すること
- ストレージ アカウントの実体となる Microsoft Entra アプリに対しては、多要素認証 (MFA) を無効にする必要があること
- 利用可能なアカウントはサブスクリプションのテナント配下のアカウントのみであること (外部ユーザーは、現在 AVD 上で FSLogix を利用するシナリオのみサポート)
- Kerberos チケットの暗号化方式は、AES-256のみである
- 既定の共有レベルのアクセス許可 を利用するか、一部サポートされるリージョンでは、共有レベルのアクセス許可としてユーザーやグループに対してアクセス権限を付与すること
- (企業環境向け補足)Entra のアプリケーション管理ポリシーで、サービス プリンシパルへの対称キー追加が制限されている場合は、「Storage Resource Provider」(app ID:
a6aa9161-5291-40bb-8c5c-923b567bee3b)に対する例外付与が必要になります
アクセス元の端末の要件
- オペレーティングシステムがWindows 11 Enterprise/Pro のシングルもしくはマルチセッションか、最新の累積更新プログラムがインストールされたWindows Server 2025であること
- WinHTTP Web プロキシ自動検出サービス (WinHttpAutoProxySvc) が実行中の状態であること
- IP ヘルパー サービス (iphlpsvc) が実行中の状態であること
- アクセス元の端末が、Microsoft Entra 参加済みまたはハイブリッド参加済みであること
上記の要件は一見複雑に見えます。
しかし、Azure Files にアクセスする端末が最新の Windows Update を適用した Windows 11 または Windows Server 2025 で、かつ Microsoft Entra ID に参加済みであれば、基本的に利用可能です。
補足
Microsoft Entra ハイブリッド参加済みになるためには、Active Directory Domain Serviceが必要のため、クラウド専用 ID をEntra IDのみで利用する場合は、Entra ID 参加済みのOSが必要になります。
実際に設定してみる (Updated: 2026/05/21)
以降では、公式のドキュメント「Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities on Azure Files」を参考に実際に設定していきます。
参考(Updated)
2026/05/21 現在、日本語ドキュメントはプレビュー時点のままとなっているため、公式ドキュメントのリンクは、英語のものに差し替えています。
以降の記事でも、日本語ドキュメントの反映遅れを考慮して、英語ドキュメントベースでの記載に変更していますが、リンクのみの変更の場合はセクションに対するUpdatedの記載は省略しています。
なお、すべての手順が掲載されているドキュメントは Azure Portal のみとなります。
本記事では、構成設定をできる限りコマンドラインで行いたいと考え、リソースのデプロイには Bicep を利用し、それ以外の設定はすべて Azure CLI を使ったコマンドラインでの検証結果をもとに記載しています。
参考(Update 2026/05/21)
GA 後に再度手順を検証して、検証結果に沿って、手順等は更新済みになります。
今回利用するテンプレートファイルや、コマンドを取りまとめたスクリプトファイルは、ブログの検証ソース公開用のリポジトリにアップロード済みとなります。
ご参考として、併せてご利用ください。
本ブログ記載のコマンド・スクリプトともに、検証用のコードとなりますので、設定等が不足している場合もございます。自己責任でご利用いただくようにお願いいたします。
全体の構成図
今回の検証環境の構成は、以下の図のような構成となります。
この構成のポイントは、以下の通りです
- アクセス元の端末が Entra Join をしている必要があります(Azure Files のクラウド専用 ID による認証の前提条件)
- Entra Join した端末に Entra ID 上のアカウントで RDP するためには、RDP 元の端末も Entra Join 等をしている必要があります (Entra ID 参加に関する拡張機能の制約)
- このため、Azure Bastion から直接 Azure Files のアクセス元端末に RDP できず、踏み台を利用する構成としています
- Azure Bastion のプレビュー機能を利用するとこの限りではないと想定されますが、今回は本構成で検証しています。
謝辞
上記の図に関しては、@aksmm さんの ⚡製図革命2.0⚡draw.io で図を作る AI スキルを作ってみた🚀 のブログで紹介されている AI スキルで作成してみました。
Azure Files をデプロイする
ソースコード中のmain.bicep を利用して、ストレージアカウントをデプロイします。
なお、この bicep を用いたデプロイでは、以下のことを一気に設定します。
- Azure Storage Account をデプロイして、Azure Files を構成する
- Azure Files に対して、Microsoft Entra Kerberos 認証を有効化する
- Azure Files において、共有レベルのアクセス許可を付与する(テンプレートでは「記憶域ファイル データの SMB 共有の管理者特権共同作成者」に設定)
公式ドキュメント では、Enable Microsoft Entra Kerberos authentication、Assign share-level permissions の章を一度に実施する手順となります。
作業をするためにまずは、以下のコマンドで準備をします。
# Azure CLI にログイン
az login
# 検証用のリソースグループを作成(既に存在する場合はスキップ可能)
az group create --name <リソースグループ名> --location <デプロイリージョン>
次に、GitHubから手元にソースコードをダウンロードしたうえで、以下のコマンドを実行します。
az deployment group create --name storage-deployment --resource-group <リソースグループ名> --template-file main.bicep --parameters storageAccountName='<ストレージアカウント名>'
注意
ストレージアカウント名は、全Azureのストレージアカウント名で一意でないといけないため、ストレージアカウント名の重複でエラーが出る場合は、ストレージアカウント名を変えて、再度デプロイしてください。
注意(リージョン制限)
クラウド専用 ID への特定ユーザー/グループへの共有レベル RBAC 割り当ては、
Regional availability for Microsoft Entra Kerberosのみで有効です。
Japan East / Japan West 等の非対象リージョンでは、テンプレートで実施しているように、「既定の共有レベルのアクセス許可」を使用してください。
別途、サポートされているリージョンを利用する場合は、既定の共有レベルのアクセス許可ではなく、グループやユーザ単位で RBAC を付与することが可能です。
検証用の VM 群をデプロイする
Azure Files のデプロイと同様に、bicep を用いてデプロイします。
今回は、main.bicep と同じフォルダ内の vm.bicep を用いて、以下のコマンドを実行します
az deployment group create --name vm-deployment --resource-group <Resource Group Name> --template-file vm.bicep --parameters adminPassword='<Strong Password>'
こちらで、VMが所属する VNet、および踏み台VM、検証用VM と VM に RDP するための Bastion Developer がデプロイされます。
各 VM のローカルアカウントを個別に指定したい場合は、adminUsername パラメータを --parameters オプションに追加してください。
なお、作成した検証用の Azure VM に Entra ID のアカウントでログインできるようにするためには、公式ドキュメント の記載に沿って、 仮想マシンの管理者ログイン もしくは 仮想マシンのユーザー ログイン の権限を付与してください。
Azure Files に関連するMicrosoft Entra アプリケーション に管理者の同意を付与する
公式ドキュメント では、Grant admin consent to the new service principal の章に対応する手順となります。
公式ドキュメントでは、Azure Portal から設定する方法が記載されています。
今回は、Azure CLI で実行したいので、代わりに以下のコマンドを実行します。
STORAGE_ACCOUNT="<Storage Account Name>"
OID=$(az ad sp list --display-name "[Storage Account] ${STORAGE_ACCOUNT}.file.core.windows.net" --query "[0].id" -o tsv)
APP_ID=$(az ad sp show --id ${OID} --query appId -o tsv)
# Microsoft Graph API (00000003-0000-0000-c000-000000000000) に対して、
# User.Read, profile, openid のスコープを許可
az ad app permission grant --id ${APP_ID} --api 00000003-0000-0000-c000-000000000000 --scope User.Read profile openid
上記の Azure CLI コマンドで実施していることは、基本的には Portal の手順と同じで、[ストレージ アカウント] <your-storage-account-name>.file.core.windows.net で表記される Entra ID 上のアプリケーションに対して、必要となる API アクセス許可 (openid、profile、User.Read) の同意を付与しています。
補足
GitHub 上で公開されているソースコードでは、上記のコマンドをまとめて、一つの update_entraid_grant.sh というシェルスクリプトにしていますので、内部の<Storage Account Name> のパラメータのみを変更して、実行いただくことでも代替となります。
Microsoft Entra アプリケーション上でクラウド専用グループのサポートを有効にする
公式ドキュメント では、クラウド専用グループのサポートを有効にする (クラウド専用 ID には必須) の章に対応する手順となります。
こちらの手順は、アプリケーション マニフェスト ファイルに Tag 属性を更新する方法 に記載された手順が、具体的に実施する必要がある手順となります。
この手順も、Azure Portal で実施する方法、Microsoft Graph API を利用して実施する方法と、PowerShell を利用して実施する方法が記載されています。
今回は Azure CLI で実施したいので、代わりに以下のコマンドを実行します。
STORAGE_ACCOUNT="<Storage Account Name>"
OID=$(az ad sp list --display-name "[Storage Account] ${STORAGE_ACCOUNT}.file.core.windows.net" --query "[0].id" -o tsv)
APP_ID=$(az ad sp show --id ${OID} --query appId -o tsv)
# アプリケーションにタグを追加して、KDCでクラウドグループSIDを有効にする
az ad app update --id ${APP_ID} --set tags='["kdc_enable_cloud_group_sids"]'
補足
GitHub 上で公開されているソースコードでは、上記のコマンドをまとめて、一つの update_entra_kerberos.sh というシェルスクリプトにしていますので、内部の<Storage Account Name> と <TENANT_ID>パラメータを変更して、実行いただくことでも代替となります。
アクセス用 VM の OS 設定の構成
公式ドキュメント では、Configure the clients to retrieve Kerberos tickets の章に対応する手順となります。
こちらに関しては、Azure Files にアクセスする VM の設定となります。
今回、Intune や Active Directory Domain Services は準備していないので、最も手軽な方法である レジストリ キー の設定で、対応します。
もちろん、OS にログインして設定もできますが、今回は Azure CLI から、VM の実行コマンドを利用することで、VM にログインせずに設定していきます。
具体的なコマンドは以下の通りです。
# 環境変数の設定
RESOURCE_GROUP="<Resource Group Name>"
VM_NAME="<VM Name>"
# PowerShell コマンドでレジストリ設定を追加
# CloudKerberosTicketRetrievalEnabled を有効化
az vm run-command invoke \
--resource-group ${RESOURCE_GROUP} \
--name ${VM_NAME} \
--command-id RunPowerShellScript \
--scripts "reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1"
補足
GitHub 上で公開されているソースコードでは、上記のコマンドをまとめて、一つの update_client_setting.sh というシェルスクリプトにしていますので、内部の<Resource Group Name> と <VM Name>パラメータを変更して、実行いただくことでも代替となります。
検証
上記で検証環境が作成できましたので、これから実際に以下の内容で検証を行ってみます。
- Azure Files上のフォルダの権限設定を変更する
- 監査設定におけるアクセスログの出力結果を確認する
Azure Files上のフォルダの権限設定を変更する (Updated: 2026/05/21)
Azure Files では、共有レベルのアクセス許可に加えて、フォルダやファイルレベルでのアクセス権限の付与が可能です。
公式ドキュメント の記載から、クラウド専用 ID においては、以下の方法で権限設定を行うことが可能です。
今回は、Azure Portalを使用してWindows ACLを構成する方法を試してみます。
まず、手順に従って、https://aka.ms/portal/fileperms からポータルにアクセスします。
注意
2026/05/19 に GA 後は、通常の https://portal.azure.com からアクセスしても利用可能なようでした。
通常の https://portal.azure.com からアクセスすると、設定変更に必要なメニューが表示されません。これは、検証した 2026/01/20 時点において、機能がプレビュー状態となっているためと想像しますが、指定の短縮URL からアクセスすると「Microsoft_Azure_FileStorage_clientoptimizations=false&feature.customportal=false&exp.filestoragefileperms=true&Microsoft_Azure_FileStorage=flight13」というようないくつかのパラメータが追加される形となっており、これによって表示する UI を切り替えているようです。
(追記 2026/05/21)
アクセス権を付与するためには、Storage File Data Privileged Contributor のロールが必要になりますので、権限を付与するようにしてください。
その後、ドキュメントに記載のある通り、ファイル共有内のBrowse 画面より「Manage access」リンク(日本語の場合は、「参照」画面の「アクセスの管理」リンク) より、権限設定の画面に移行します。
遷移後のアクセス管理の画面では、アクセス許可を付与したいアカウントを、左上の「Entraユーザ/グループの追加」から追加したうえで、実際の権限は、追加したアカウント名の右に表示される鉛筆アイコンから設定可能です。
なお、削除に関しては、ゴミ箱アイコンから削除できます。
また、現時点においては、icacls コマンドや Windows エクスプローラーを使用しての Windows ACL の設定はできません。(公式ドキュメントにも記載あり)
例えば、Windows エクスプローラーを使用して設定を行おうとすると、以下のようにファイル共有がドメインに参加しているかの確認が取れない旨のエラーとなります。
ただ、設定している権限に関しては、Windows エクスプローラーでも確認可能で、以下のように Azure AD ドメインでアカウントが表示されます。
監査設定におけるアクセスログの出力結果を確認する
次に、クラウド専用 ID で SMB アクセスした場合に、診断設定のアクセスログにはどのように出るかを確認してみます。
Azure Files の診断設定の設定手順や、具体的な診断ログの内容は、Microsoft のテクニカルサポートチームのブログ (Azure Files の診断設定を試す) にて詳細が説明されていますので、ここでは、クラウド専用 ID でどのように出力されるか部分のみをまとめます。
以下、実際に検証環境で取得したログのクラウド専用 ID に関する出力抜粋です。
"identity": {
"type": "Kerberos",
"requester": {
"smbPrimarySID": "S-1-12-1-1131909897-1154323479-2578226879-385852149"
}
},
クラウド専用 ID に関しても Kerberos 認証となりますので、identity の type としては、Kerberos として表示されます。
また、アクセスを実施したアカウントの SID が requester 部分に表示されます。
ここまでは、Microsoft のテクニカルサポートチームのブログ で記載の内容とほぼ同じですが、違う点は、 SID が Entra ID 上のアカウントの情報である点です。
このため、SID があらわす User ID や アカウントの表示名を取得するためには、Entra ID からこの情報を取得することが必要となります。
残念ながら、この情報に関して、現時点で Azure Portal から確認する方法は見つけられませんでした。
公式ドキュメント では、Microsoft Graph を利用して取得することが記載されています。
実際に Graph Explorer を開いて、https://graph.microsoft.com/v1.0/users/<Display Name>@<Domain>?$select=securityIdentifier のように GET リクエストを発行すると、以下の様に SID が取得できて、確認することができました。
{
"@odata.context": "https://graph.microsoft.com/v1.0/$metadata#users(securityIdentifier)/$entity",
"securityIdentifier": "S-1-12-1-1131909897-1154323479-2578226879-385852149"
}
他の方法として、Azure CLI でもできないかを探しましたが、ちょっと見つけきれず、代わりに PowerShell での方法は確認できましたので、こちらを記載いたします。
PowerShellの場合は、以下の様に実行することで、SID が取得可能です。
# Microsoft Graph にログイン
Connect-MgGraph -Scopes User.Read.All
# Microsoft Graph に対してリクエストを発行する
Invoke-MgGraphRequest -Uri "/v1.0/users/<Display Name>@<Domain>?`$select=securityIdentifier" -Method Get
# 以下のような結果が表示される
Name Value
---- -----
@odata.context https://graph.microsoft.com/v1.0/$metadata#users(securityIdentifier)/$entity
securityIdentifier S-1-12-1-1131909897-1154323479-2578226879-385852149
検証環境のクリーンアップ
検証が完了したら、リソースグループを削除する等で、不要なリソースを削除してください。
リソースグループごと削除する場合は、以下のコマンドで実行可能です。
# リソースグループを削除(内部のすべてのリソースも削除されます)
az group delete --name <リソースグループ名> --yes
なお、Entra ID に登録された端末の情報は、自動では消えませんので、別途以下の方法で削除してください
# デバイス名からオブジェクトIDを取得
# VM名に関しては、vm.bicep でそのままデプロイした場合は、test-vm と jumpbox になります。
DEVICE_ID=$(az rest --method GET --uri "https://graph.microsoft.com/v1.0/devices?\$filter=displayName eq '<VM Name>'" --query "value[0].id" -o tsv)
az rest --method DELETE --uri "https://graph.microsoft.com/v1.0/devices/$DEVICE_ID"
まとめ
本ブログでは、新しく機能追加されたクラウド専用 ID のAzure Files のアクセス制御を検証しました。
一部、Windows Explorer ではフォルダ/ファイル単位のアクセス権限の設定ができないなど、ファイルサーバの代替として活用するには、現時点ではもう少し機能追加が望まれる状況かと思います。
ただ、まずはクラウド専用 ID が利用できるようになったことが大きな一歩かと思いますので、今後に期待です。
参考リンクまとめ
より最新の情報の共有のために、一部英語記事のリンクを記載しています。
英語記事に関しては、URL の en-us 部分を ja-jp に変えると、日本語記事にアクセスできる場合がありますので、必要に応じてアクセスしてみてください。
- ⚡製図革命2.0⚡draw.io で図を作る AI スキルを作ってみた🚀
- Microsoft Entra Kerberos FAQ
- Enable Microsoft Entra Kerberos authentication for hybrid and cloud-only identities on Azure Files
- Configure directory-level and file-level permissions for Azure file shares
- Azure Bastion を使用して Windows VM への RDP 接続を作成する
- クラウドのみのユーザーのクラウド セキュリティ識別子 (SID) を検索するにはどうすればよいですか?




