Azure Files のクラウド専用 ID による ID ベース認証を試してみる

Microsoft Ignite 2025 に参加してきましたので、その中でも発表されていた、Azure Files のクラウド専用 ID での認証について、検証してみました。
クラウド専用 ID とは、Active Directory Domain Service や Entra ID Domain Services を利用せず、Entra ID のみを利用して作成・管理される、Entra ID 上にのみ存在するアカウントのことです。

補足
このクラウド専用 ID での認証は、このブログを執筆時点 ( 検証は 2026年1月20日 時点 ) では、プレビュー機能となります。
今後、仕様が大幅に変わることが想定されますので、必ず最新の情報を確認いただくようにお願いします

TL;DR

このブログでは、Azure Files のクラウド専用 ID によるアクセス制御について以下を実施。

• Azure Files のクラウド専用 ID によるアクセス制御機能(2026/01/20現在 プレビュー機能)を検証
• Azure CLI と bicep を用いた検証環境の構築方法を検証
• 検証の結果として、ファイル共有上のフォルダ・ファイル単位のアクセス制御の設定方法・診断設定ログの確認方法を記載
• 特にクラウド専用 ID における SID と 表示名等の紐づけにはMicrosoft Graph の利用が必須

Azure Files のクラウド専用 ID による ID ベースの認証について

Azure Files を SMB 共有として利用する場合、ID ベースの認証が利用可能です。
これまでは、ID ベースの認証を利用する場合、Microsoft Entra Connect等を利用して、Microsoft Entra ID にオンプレミスから同期されたハイブリッドアカウントや、Microsoft Entra Domain Services の利用が必須でした。
最近、この ID ベースの認証において、クラウド専用 ID、つまりMicrosoft Entra ID上のみで作成・存在しているIDを利用することが可能となりました。(本ブログ作成時点ではまだプレビュー機能です)

これによって、クラウド専用 ID でも、以下の前提条件を満たすことで ID ベースの認証を利用可能になりました。

最小限の前提条件：
Azure 上の構成の要件

• Azure ストレージ アカウント(Azure Files)の認証方法(ID連携で利用する認証方法)には、Microsoft Entra Kerberos を利用すること
• ストレージ アカウントの実体となる Microsoft Entra アプリに対しては、多要素認証 (MFA) を無効にする必要があること
• 利用可能なアカウントはサブスクリプションのテナント配下のアカウントのみであること(B2Bユーザーやゲストユーザーは利用不可)
• Kerberos チケットの暗号化方式は、AES-256のみである
• 既定の共有レベルのアクセス許可 を利用すること

アクセス元の端末の要件

• オペレーティングシステムがWindows 11 Enterprise/Pro のシングルもしくはマルチセッションか、最新の累積更新プログラムがインストールされたWindows Server 2025であること
• WinHTTP Web プロキシ自動検出サービス (WinHttpAutoProxySvc) が実行中の状態であること
• IP ヘルパー サービス (iphlpsvc) が実行中の状態であること

Microsoft Entra Kerberos 利用のための要件

• Microsoft Entra Kerberos は、Microsoft Entra 参加済みまたはハイブリッド参加済みの Windows 10 (2004 以降) および Windows 11 デバイスでサポート

上記は、一見、複雑な要件に見えますが、Azure Files にアクセスする端末が、最新のWindows Updateを適用した、Windows 11やWindows Server 2025 であって、Microsoft Entra ID に参加済みのOSであれば、基本的に利用可能であるということになります。

補足
Microsoft Entra ハイブリッド参加済みになるためには、Active Directory Domain Serviceが必要のため、クラウド専用 ID をEntra IDのみで利用する場合は、Entra ID 参加済みのOSが必要になります。

実際に設定してみる

以降では、公式のドキュメント「Azure Files でハイブリッド ID とクラウド専用 ID (プレビュー) に対して Microsoft Entra Kerberos 認証を有効にする」を参考に実際に設定していきます。

なお、ドキュメントでは、すべての手順が記載されているものが Azure Portal だけとなりますが、リソースの構成や設定をできる限りコマンドラインで設定したいと思い、リソースのデプロイは bicep を利用し、それ以外の構成の設定は、すべて Azure CLI などを利用したコマンドラインで実施していきます。

今回利用するテンプレートファイルや、コマンドを取りまとめたスクリプトファイルは、ブログの検証ソース公開用のリポジトリにアップロード済みとなります。
ご参考として、併せてご利用ください。
なお、本ブログ記載のコマンド・スクリプトともに、検証用のコードとなりますので、設定等が不足している場合もございます。自己責任でご利用いただくようにお願いいたします。

全体の構成図

今回の検証環境の構成は、以下の図のような構成となります。

この構成のポイントは、以下の通りです

• アクセス元の端末が Entra Join をしている必要がある
• Entra Join した端末に Entra ID 上のアカウントで RDP するためには、RDP 元の端末も Entra Join 等をしている必要があること
  • このため、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 共有の管理者特権共同作成者」に設定)

公式ドキュメント では、Microsoft Entra Kerberos 認証を有効にする、共有レベルのアクセス許可を割り当てる の章を一度に実施する手順となります。

作業をするためにまずは、以下のコマンドで準備をします。

# 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のストレージアカウント名で一意でないといけないため、ストレージアカウント名の重複でエラーが出る場合は、ストレージアカウント名を変えて、再度デプロイしてください。

検証用の 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 アプリケーション に管理者の同意を付与する

公式ドキュメント では、新しいサービス プリンシパルに管理者の同意を与える の章に対応する手順となります。

公式ドキュメントでは、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 設定の構成

公式ドキュメント では、クライアントを構成して Kerberos チケットを取得する の章に対応する手順となります。

こちらに関しては、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上のフォルダの権限設定を変更する

Azure Files では、共有レベルのアクセス許可に加えて、フォルダやファイルレベルでのアクセス権限の付与が可能です。
公式ドキュメント の記載から、クラウド専用 ID においては、現時点で、以下の方法で権限設定を行うことが可能です。

• Azure portal を使用して Windows ACL を構成する
• PowerShell を使用してクラウド専用 ID の Windows ACL を構成する

今回は、Azure Portalを使用してWindows ACLを構成する方法を試してみます。
まず、手順に従って、https://aka.ms/portal/fileperms からポータルにアクセスします。

注意
通常の https://portal.azure.com からアクセスすると、設定変更に必要なメニューが表示されません。これは、検証した 2026/01/20 時点において、機能がプレビュー状態となっているためと想像しますが、指定の短縮URL からアクセスすると「Microsoft_Azure_FileStorage_clientoptimizations=false&feature.customportal=false&exp.filestoragefileperms=true&Microsoft_Azure_FileStorage=flight13」というようないくつかのパラメータが追加される形となっており、これによって表示する UI を切り替えているようです。

その後、ドキュメントに記載のある通り、ファイル共有内の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 が利用できるようになったことが大きな一歩かと思いますので、今後に期待です。

参考リンクまとめ

⚡製図革命2.0⚡draw.io で図を作る AI スキルを作ってみた🚀
Microsoft Entra Kerberos FAQ
Azure Files でハイブリッド ID とクラウド専用 ID (プレビュー) に対して Microsoft Entra Kerberos 認証を有効にする
Azure ファイル共有のディレクトリとファイル レベルのアクセス許可を構成する
Azure Bastion を使用して Windows VM への RDP 接続を作成する
クラウドのみのユーザーのクラウド セキュリティ識別子 (SID) を検索するにはどうすればよいですか?