注意
本記事は、Azure Files のマネージド ID を利用した SMB 認証（プレビュー機能）に関する内容です。記載されている情報は 2026 年 3 月時点で確認したものであり、今後の更新により仕様や動作が変更される可能性があります。最新の情報は 公式ドキュメント をご確認ください。
TL;DR
- Azure Files で、Microsoft Entra ID のマネージド ID を使った SMB 認証(プレビュー)を検証。ストレージアカウントキー不要で、よりセキュアな運用が可能。
- マネージド ID 認証には制約があり、他の ID ベース認証設定(Microsoft Entra Kerberos など)と併用不可である点に注意が必要。
- 検証ログでは、ストレージアカウントキー接続は
NTLMv2、マネージド ID 接続はKerberosとして記録され、認証方式の違いを確認。 - マネージド ID 接続時は ファイル共有内のフルコントロールアクセスを持つことになる。
Azure Files の Microsoft Entra ID でマネージド ID 認証とは
Azure Files には、ファイル共有へのアクセスを制御する方法として、IDベースの認証が提供されています。
この認証方法には、オンプレミスの AD DS を利用した方法、Microsoft Entra Domain Services を利用した方法、 Microsoft Entra ID を利用した方法など、
複数の方法があります。
この記事の執筆時点(2026年3月時点) では、プレビュー機能となりますが、 既存の認証方法に加えて、マネージド ID を利用した認証方法が提供されるようになりました。
マネージド ID を利用することで、ストレージアカウントキーを利用せずに、Azure Files へのアクセスが可能になります。
マイクロソフトの公式ドキュメントにおいて、マネージド ID を利用する理由として以下のような理由が記載されています。
(公式ドキュメント抜粋)
・セキュリティ強化: 管理または公開するストレージ アカウント キーに依存しない
・管理の簡素化: キーのローテーションは必要ありません
・きめ細かいアクセス制御: ID レベルでのロールベースのアクセス
・自動化に優しい: CI/CD パイプライン、Azure Kubernetes Service (AKS) ワークロード、および顧客アプリケーションと簡単に統合できます
・コスト効率: マネージド ID は、追加のストレージ コストなしで使用できます
マネージド ID を利用した認証の条件
マネージド ID を利用した認証を実施する場合は、以下のような制約があります。
- マネージド ID でマウントする場合は、マネージド ID に対して、ストレージアカウントの「Storage File Data SMB MI Admin」の権限を付与する必要があります。
- マネージド ID で接続するクライアントは、どのドメインにも参加していない必要があります。
- マネージド ID で接続する場合、ストレージアカウントで、他のIDベースの認証設定が行われていない必要があります。
- Linux VM では、システム割り当てマネージド ID はサポートされていません。ユーザー割り当てマネージド ID を使用する必要があります。
- Linux VM の場合、サポートされるOSは、Azure Linux 3.0、 Ubuntu 22.04、 もしくは Ubuntu 24.04 となります。
- Windows VM の場合、Windows Server 2019 以降、または Windows 11 が必要です。
実際に試してみる
検証環境の構成と構築手順
今回の検証用には、以下のような環境を構築しました。
- VM
- OS: Windows Server 2022 Datacenter Azure Edition
- SKU: Standard_D4s_v6
- マネージド ID: システム割り当てマネージド ID
- Bastion
- SKU: Developer
- Storage Account (Azure Files)
- SKU: Standard_LRS
- ファイル共有: 1つ作成
- Storage Account (診断設定用)
- SKU: Standard_LRS
構成図は以下の通りとなります。
なお、検証用の環境のデプロイに関しては、基本的に bicep テンプレートを利用しており、こちらのリポジトリにコードを公開しておりますので、もしご興味がある方は、リポジトリをご参照ください。
IDベース認証と併用しようとするとリソースがデプロイできない
前提条件にも記載いたしましたが、マネージド ID を利用した認証を実施する場合は、他のIDベースの認証設定と併用することができません。
そのため、例えば、Microsoft Entra ID を利用した認証方法と、マネージド ID を利用した認証方法を両方とも有効にしようとすると、以下のような設定のコンフリクトに関するエラーとなって、リソースのデプロイが失敗してしまいます。
$ az deployment group create --resource-group <Resource Group Name> --template-file src/files_managedid/main.bicep
A new Bicep release is available: v0.40.2. Upgrade now by running "az bicep upgrade".
{"code": "InvalidTemplateDeployment", "message": "The template deployment 'main' is not valid according to the validation procedure. The tracking id is '<Tracking ID>'. See inner errors for details."}
Inner Errors:
{"code": "PreflightValidationCheckFailed", "message": "Preflight validation failed. Please refer to the details for the specific errors."}
Inner Errors:
{"code": "ConflictFeatureEnabled", "target": "<Storage Account Name>", "message": "This operation is not allowed on a storage account with SmbOAuth set to 'True'. The operation is only allowed on SmbOAuth set to 'False'."}
Inner Errors:
{"code": "ConflictFeatureEnabled", "target": "<Storage Account Name>", "message": "This operation is not allowed on a storage account with directoryServiceOptions set to 'AADKERB'. The operation is only allowed on directoryServiceOptions set to 'None'."}
$
なお、設定のコンフリクトによるエラーになりますので、一度 VM をデプロイした後に、Azure Portal から変更するといった方法もできません。
実際に試すと、同様のエラーとなりました。
認証で利用されているプロトコルの確認
現時点において、Microsoft 公式ドキュメントでも、ストレージアカウント キーを利用することは推奨されていません。
代わりに、新しく提供されたマネージド ID を含む、IDベースの認証を利用した方法が推奨されています。
ストレージアカウント キーが推奨されないことの一つは、キーが漏洩した際のセキュリティリスクが高いことが挙げられます。
しかし、他の理由として、認証に利用されているプロトコルも理由の一つにあるかと思います。
ストレージアカウントキーで接続した場合の認証プロトコル
ストレージアカウント キーを用いて、Azure Files を SMB プロトコルでマウントする場合は、NTLMv2 で認証されます。
以下が、ストレージアカウント キーで接続した場合のログとなります。
{
"time": "2026-03-06T00:21:53.3641087Z",
"resourceId": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>/fileServices/default",
"category": "StorageRead",
<省略>
"callerIpAddress": "10.0.1.4",
"correlationId": "6cfdbffc-c01d-0062-00ff-ac4a09000000",
"identity": {
"type": "NTLMv2" // type が NTLMv2 となっており、NTLMv2認証で接続されていることが分かる
},
"location": "japaneast",
<省略>
"protocol": "SMB",
"resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}
ログからも、NTLMv2で認証されていることが分かります。
また、同様の情報は、パケットキャプチャをとった上で、SMB マウント時の情報を確認しても、NTLMv2で認証されていることがわかります。
マネージド ID で接続した場合の認証プロトコル
次は、マネージド ID を用いて接続した場合のログになります。
マネージド ID を用いて接続した場合は、Kerberos認証での接続となります。
以下が、マネージド ID で接続した場合のログとなります。
{
"time": "2026-02-25T13:18:26.9406839Z",
"resourceId": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>/fileServices/default",
"category": "StorageRead",
<省略>
"callerIpAddress": "10.0.1.4",
"correlationId": "42ad0203-d01d-0038-0059-a689a7000000",
"identity": {
"type": "Kerberos", // type が Kerberos となっており、Kerberos認証で接続されていることが分かる
"requester": {
"objectId": "<Object ID>",
"smbPrimarySID": "S-1-5-32-544"
}
},
"location": "japaneast",
<省略>
"protocol": "SMB",
"resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}
上記のログからも、マネージド ID の場合は、Kerberos認証で接続していることが分かります。
プロトコルの違いに関する考察
認証で利用されるプロトコルを調べての感想となりますが、
Windows Server で削除または開発されなくなった機能 - 開発が中止された機能 や サポートチームのブログ においても、NTLMv1 は Windows Server 2025 で削除され、NTLMv2 も非推奨（deprecated）となり将来のリリースで削除される予定であることが公開されています。
こういった観点でも、よりセキュアにAzure Files を利用するための方法として、マネージド ID を利用した認証が提供されるようになったのではないかと想像します。
マネージド ID で接続した場合のアクセス権限
RBACの権限
マネージド ID で接続する場合は、マネージド ID に対して、ストレージアカウントの「Storage File Data SMB MI Admin」の権限を付与する必要があります。
この権限で、具体的にどういう権限が付与されるかというと、公式ドキュメント に以下の権限があると記載されています。
{
"assignableScopes": [
"/"
],
"description": "Allows for admin-level access for managed identities on files/directories in Azure file shares.",
"id": "/providers/Microsoft.Authorization/roleDefinitions/a235d3ee-5935-4cfb-8cc5-a3303ad5995e",
"name": "a235d3ee-5935-4cfb-8cc5-a3303ad5995e",
"permissions": [
{
"actions": [],
"notActions": [],
"dataActions": [
"Microsoft.Storage/storageAccounts/fileServices/readFileBackupSemantics/action",
"Microsoft.Storage/storageAccounts/fileServices/writeFileBackupSemantics/action",
"Microsoft.Storage/storageAccounts/fileServices/takeOwnership/action",
"Microsoft.Storage/storageAccounts/fileServices/runAsBuiltInFileAdministrator/action",
"Microsoft.Storage/storageAccounts/fileServices/fileshares/files/read",
"Microsoft.Storage/storageAccounts/fileServices/fileshares/files/write",
"Microsoft.Storage/storageAccounts/fileServices/fileshares/files/delete",
"Microsoft.Storage/storageAccounts/fileServices/fileshares/files/modifypermissions/action"
],
"notDataActions": []
}
],
"roleName": "Storage File Data SMB MI Admin",
"roleType": "BuiltInRole",
"type": "Microsoft.Authorization/roleDefinitions"
}
つまり、リソースに対してではなく、Azure Files 内のデータアクセスのみに関連して、ファイルの読み書き・削除や、特権の取得などの権限が付与されることになります。
ただし、Azure Files は、Azure RBAC とファイルシステムのアクセス制御リスト(ACL) の両方を利用して、アクセス制御を行うため、RBAC だけでなく、ファイル・ディレクトリ単位のアクセス権限の設定の確認が重要となります。
ファイル・ディレクトリレベルのアクセス権限
最後に、マネージド ID で接続した場合のディレクトリ、ファイルレベルのアクセス権限についても確認してみました。
先ほどの章におけるマネージド ID で接続した場合のログを確認してみると、identity の部分に、requester として、smbPrimarySID が記載されています。
接続時は、この SID を利用してファイル操作をすることになります。
{
"time": "2026-02-25T13:18:26.9406839Z",
"resourceId": "/subscriptions/<subscription id>/resourceGroups/<resource group name>/providers/Microsoft.Storage/storageAccounts/<storage account name>/fileServices/default",
"category": "StorageRead",
<省略>
"callerIpAddress": "10.0.1.4",
"correlationId": "42ad0203-d01d-0038-0059-a689a7000000",
"identity": {
"type": "Kerberos",
"requester": {
"objectId": "<Object ID>",
"smbPrimarySID": "S-1-5-32-544" // ここに記載されているSIDを利用して、アクセス権限の確認を行う
}
},
"location": "japaneast",
<省略>
"protocol": "SMB",
"resourceType": "Microsoft.Storage/storageAccounts/fileServices"
}
補足
ログに記録されている objectId は、Entra ID 上の マネージド IDのオブジェクトIDとなります。
この smbPrimarySID の値は、"S-1-5-32-544" となっていますが、これは、BuiltInAdministratorsグループのSIDであるため、アクセス権限としては、Administratorsグループのアクセス権限があることになります。
つまり、公式ドキュメントを確認すると、以下の権限が付与されることが分かります。
(公式ドキュメント抜粋)
BUILTIN\Administrators:(OI)(CI)(F)
BUILTIN\Users:(RX)
BUILTIN\Users:(OI)(CI)(IO)(GR,GE)
NT AUTHORITY\Authenticated Users:(OI)(CI)(M)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(F)
CREATOR OWNER:(OI)(CI)(IO)(F)
つまり、フルアクセス権が、オブジェクト継承、コンテナ継承でつく、言い換えると、マウントした領域すべてに対して、既定でフルアクセス権限が付与されることになります。
前節のRBACの権限の内容と合わせて考えても、マネージド ID で接続した場合は、Azure Files 内のファイル共有全体に対して、フルアクセス権限が付与されることになります。
まとめ
今回は、Azure Files のマネージド ID を利用した認証を試してみました。
ストレージアカウントキーと違い、利用に制約があるため、ストレージアカウントキーの代替になるとは言いづらいですが、マネージド ID が利用可能なシナリオでは、こちらの方がよりセキュアかと思いますので、積極的に活用するのがいいと思います。
おまけ：ドキュメントのフィードバック
今回の検証を通して、Microsoft の公式ドキュメントを参照して、マネージド ID を利用した認証を試してみましたが、いくつかドキュメントの改善点があると感じました。
そのため、ドキュメントのフィードバックを行いましたので、以下に共有いたします。
フィードバックの仕方
ドキュメントの右側の「この記事の内容」の下にある、「このページは役に立ちましたか」の部分から「はい」「いいえ」を選ぶことで、フィードバックを送ることができます。
例えば、「はい」を選ぶと以下のようなメニューが出てきますので、適切な項目と、実際にコメントしたい内容を記述して、「送信」を押せばOKです。
今回のフィードバックの内容
今回は、デバッグログを取得する部分がわかりづらかったため、以下のようなフィードバックを行いました。
I learned new Azure Files Feature. for additional improvement, I recommend Microsoft to modify "Troubleshooting" part on this document.
1. file path of AzFilesSmbMILog.log file
I tried this part but, unfortunately, I cannot find AzFilesSmbMILog.log file in any path on local computer. I think if the path for this log is written in this document, we can easily collaborate with Microsoft Team.
2. Exact registry key for log setting
I think the sentence "On Windows clients, use the Registry Editor to set the Data level for verbosity to 0x00000004 (4) for Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure\Storage\Files\SmbAuth." is little bit confusing. so, I recommend Microsoft to write actual PowerShell or CMD command alternatively.
(日本語訳)
Azure Filesの新機能について学びました。さらなる改善のため、Microsoftにはこのドキュメントの「トラブルシューティング」部分の修正をお勧めします。
1. AzFilesSmbMILog.log ファイルのパス
この手順を試みましたが、残念ながらローカルコンピューターのどのパスにも AzFilesSmbMILog.log ファイルが見つかりませんでした。このログのパスが本文書に記載されていれば、Microsoft チームとの連携が容易になると考えます。
2. ログ設定の正確なレジストリキー
「Windowsクライアントでは、レジストリエディターを使用してComputer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Azure\Storage\Files\SmbAuthの詳述レベルを0x00000004 (4)に設定してください」という記述はやや分かりにくいと思います。そのため、Microsoftには代わりに実際のPowerShellまたはCMDコマンドを記載することをお勧めします。