Microsoft Entra Kerberos Authentication for Azure Filesでまず押さえるべき結論は、Azure FilesのSMBファイル共有に対して、ハイブリッドIDだけでなくクラウド専用IDでもKerberos認証を使えるようになる一方、有効化だけではアクセスできないという点です。ストレージアカウントのIDソース、Microsoft Entraアプリへの管理者同意、MFA除外、共有レベルのAzure RBAC、Windows ACL、クライアント側のKerberosチケット取得設定まで確認する必要があります。
2026年5月20日時点で確認すべき公式情報では、Microsoft Learn英語版の該当ドキュメントは2026年5月19日付で更新されており、対象はAzure FilesのSMBファイル共有です。Microsoft Entra IDがSMBアクセスに必要なKerberosチケットを発行することで、特にクラウド専用IDではドメインコントローラーに依存しないAzure Filesアクセスを設計しやすくなります。(GitHub)
Microsoft Entra Kerberos Authentication for Azure Filesで何が変わったか
Microsoft Entra Kerberos Authentication for Azure Filesは、Azure FilesのSMB共有に対するIDベース認証の選択肢です。従来のようにオンプレミスAD DSだけを前提にするのではなく、Microsoft Entra IDがKerberosチケットを発行し、ユーザーがMicrosoft Entraの資格情報でAzureファイル共有へアクセスできる構成を取れます。公式ドキュメントでは、ハイブリッドIDとクラウド専用IDの両方を対象に、構成手順と前提条件が整理されています。(Microsoft Learn)
実務上の変更点は、単に「新しい認証方式が使える」ことではありません。管理者が確認すべきポイントは、次のように権限設計、端末設定、条件付きアクセス、移行設計にまたがります。
| 確認ポイント | 管理者への影響 |
|---|---|
| クラウド専用IDへの対応 | AD DSにユーザーを作成しない環境でも、Azure FilesのSMB共有を利用しやすくなる |
| 1つのストレージアカウントで使えるIDソースは1種類 | AD DS、Microsoft Entra Domain Services、Microsoft Entra Kerberosを同時に有効化できない |
| MFAはストレージアカウントのEntraアプリから除外が必要 | 条件付きアクセスで全アプリにMFAを要求している環境では接続失敗の原因になる |
| クラウド専用IDではアプリマニフェストのタグ設定が必要 | kdc_enable_cloud_group_sidsを追加しないと認証に失敗する可能性がある |
| クライアント側でCloud Kerberosチケット取得を有効化 | Intune、グループポリシー、レジストリのいずれかで端末ごとの設定が必要 |
| AD DS認証のストレージアカウントと併用する端末 | Kerberosレルムマッピングを設定しないと既存接続に影響する可能性がある |
特に注意したいのは、Azure Filesの認証方式をストレージアカウント単位で切り替える点です。既にAD DS認証やMicrosoft Entra Domain Services認証を使っているストレージアカウントでは、既存方式を無効化してからMicrosoft Entra Kerberosを有効化する必要があります。既存環境でいきなり本番ストレージアカウントを切り替えるのではなく、別ストレージアカウントまたは検証用共有で動作確認してから展開するのが安全です。(Microsoft Learn)
影響範囲：対象になる環境とならない環境
対象は、Azure FilesのSMBファイル共有をIDベース認証で利用する環境です。Azure Virtual DesktopのFSLogixプロファイルコンテナー、Windows端末からのファイル共有アクセス、クラウド移行中のファイルサーバー代替などが代表的なユースケースです。
一方で、すべてのユーザーや端末がそのまま対象になるわけではありません。標準的なMicrosoft Entra Kerberos認証フローでは、クライアントがMicrosoft Entra参加またはMicrosoft Entraハイブリッド参加である必要があります。AD参加のみ、またはMicrosoft Entra Domain Services参加のみの端末は、この前提を満たしません。(Microsoft Learn)
ハイブリッドIDで利用する場合
ハイブリッドIDとは、オンプレミスAD DSに存在するユーザーやグループをMicrosoft Entra Connect SyncまたはMicrosoft Entra Cloud SyncでMicrosoft Entra IDへ同期しているIDです。この場合、Azure Filesへの認証にはMicrosoft Entra Kerberosを使えますが、ディレクトリやファイル単位のWindows ACLを設定するには、オンプレミスのドメインコントローラーへ到達できるネットワークが必要です。(Microsoft Learn)
つまり、ユーザーがファイル共有を使うだけならクラウド寄りの構成にできますが、ACLを細かく編集する管理端末については、AD DSへの疎通を残しておく必要があります。
クラウド専用IDで利用する場合
クラウド専用IDとは、オンプレミスAD DSに対応するアカウントを持たず、Microsoft Entra IDだけで作成・管理されるユーザーです。クラウド専用IDでは、ドメインコントローラーなしでAzure FilesのSMB共有へアクセスできる構成が可能になります。ただし、公式情報ではクラウド専用ID関連のサポート範囲やリージョンに制限があり、Microsoft Entra Kerberosのクラウド専用ID対応は一部ドキュメントでPreviewとして扱われています。(Microsoft Learn)
また、クラウド専用IDに対する特定ユーザー・グループ単位のAzure RBACサポートは、2026年5月時点ではAzure Public Cloud内の一部リージョンに限定されています。公式リストにはJapan EastやJapan Westは含まれていないため、日本リージョンでクラウド専用IDと特定ユーザー・グループのRBAC割り当てを前提にする場合は、最新のリージョン対応状況を必ず確認してください。(Microsoft Learn)
有効化前に確認すべき前提条件
Microsoft Entra Kerberos Authentication for Azure Filesは、ポータルでチェックを入れるだけの機能ではありません。次の項目を満たしていないと、設定後に「共有がマウントできない」「資格情報を何度も求められる」「特定ユーザーだけアクセスできない」といったトラブルにつながります。
| 項目 | 確認内容 | 失敗しやすいポイント |
|---|---|---|
| IDソース | ストレージアカウントで既存のAD DS認証やEntra Domain Services認証を使っていないか | 同じストレージアカウントに複数のIDソースを設定しようとする |
| 同期 | ハイブリッドIDではユーザーとグループがEntra IDへ同期されているか | AD側のグループに権限を付けたつもりでも、Entra側に同期されていない |
| クライアント参加状態 | 端末がMicrosoft Entra参加またはハイブリッド参加か | AD参加のみの端末で検証してしまう |
| Windowsサービス | WinHttpAutoProxySvcとiphlpsvcが実行中か | WPAD対策としてサービス自体を停止している |
| MFA | ストレージアカウントのEntraアプリをMFA条件付きアクセスから除外しているか | 全クラウドアプリ対象のMFAポリシーでSMB認証が失敗する |
| 暗号化 | KerberosチケットはAES-256が前提か | 古いKerberos暗号化方式だけを許可するポリシーでマウントに失敗する |
| アプリ管理ポリシー | サービスプリンシパルの対称キー追加や有効期間制限に抵触しないか | パスワード追加ブロックや366日未満の有効期間制限で構成が失敗する |
公式ドキュメントでは、WinHttpAutoProxySvcとiphlpsvcが必要とされています。WPADをセキュリティ上の理由で無効化する場合でも、WinHttpAutoProxySvcサービス全体を停止しないよう注意が必要です。KDC Proxy要求など、Kerberos認証に必要な処理へ影響するためです。(Microsoft Learn)
設定手順の全体像
ストレージアカウントでMicrosoft Entra Kerberosを有効化する
Azure portalでは、対象のストレージアカウントを開き、File sharesのIdentity-based accessからMicrosoft Entra Kerberosを設定します。PowerShellまたはAzure CLIでも有効化できます。
Set-AzStorageAccount `
-ResourceGroupName <resourceGroupName> `
-StorageAccountName <storageAccountName> `
-EnableAzureActiveDirectoryKerberosForFile $trueaz storage account update \
--name <storageaccountname> \
--resource-group <resourcegroupname> \
--enable-files-aadkerb trueハイブリッドIDで、Windows File Explorerからディレクトリ・ファイルレベルの権限を設定したい場合は、オンプレミスADのドメイン名とドメインGUIDも指定します。Get-ADDomainで取得できるDNSRootとObjectGUIDを使います。(Microsoft Learn)
自動作成されたサービスプリンシパルに管理者同意を付与する
Microsoft Entra Kerberosを有効化すると、ストレージアカウントに対応するMicrosoft Entraアプリが作成されます。名前は次の形式です。
[Storage Account] <your-storage-account-name>.file.core.windows.netこのアプリに対して、openid、profile、User.ReadのAPI権限へ管理者同意を付与します。このサービスプリンシパルはファイル共有の認可に使うものではないため、公式手順で指定された内容以外を不用意に変更しないことが重要です。(Microsoft Learn)
クラウド専用IDではアプリマニフェストにタグを追加する
クラウド専用IDを使う場合は、ストレージアカウントに対応するアプリ登録のマニフェストで、tagsに次の値を追加します。
"tags": [
"kdc_enable_cloud_group_sids"
]既に他のタグがある場合は、上書きではなく追加として扱うのが安全です。このタグは、クラウドグループSIDをKerberosチケットに含めるための重要な設定です。Kerberosチケットに含められるグループSID数には1,010という上限があるため、ネストされたグループや動的グループが多い大規模テナントでは、グループ設計もあわせて見直してください。(Microsoft Learn)
権限設計：Azure RBACとWindows ACLを分けて考える
Azure FilesのIDベース認証では、共有レベルのアクセス許可と、ディレクトリ・ファイルレベルのWindows ACLを分けて設計します。
共有レベルではAzure RBACロールを割り当てます。代表的なロールは次の通りです。
| ロール | 主な用途 |
|---|---|
| Storage File Data SMB Share Reader | 読み取り専用アクセス |
| Storage File Data SMB Share Contributor | 読み取り、書き込み、削除 |
| Storage File Data SMB Share Elevated Contributor | 読み取り、書き込み、削除、ACL変更 |
| Storage File Data Privileged Contributor | ACLを上書きして操作できる強い権限 |
| Storage File Data Privileged Reader | ACLを上書きして読み取りできる強い権限 |
| Storage File Data SMB Admin | SMB経由の管理者相当アクセス |
基本方針は、共有レベルでは必要最小限の入口を開け、細かな制御はWindows ACLで行うことです。Microsoft Learnでも、特定のMicrosoft Entraユーザーまたはグループへ共有レベル権限を割り当て、ディレクトリ・ファイル単位ではWindows ACLで制御する構成が安全とされています。(Microsoft Learn)
Windows ACLは、RBACより細かい操作権限を制御します。RBACとWindows ACLの両方が評価されるため、どちらか一方で許可していても、もう一方が制限していればアクセスは制限されます。たとえば、ファイルレベルで書き込み可能でも、共有レベルがReaderなら書き込みはできません。(Microsoft Learn)
クラウド専用IDのACL設定で注意すること
クラウド専用IDでは、Windows File ExplorerやicaclsによるACL設定はサポートされません。公式の対応表では、Microsoft Entra Kerberosのクラウド専用IDに対するACL設定方法として、Azure portalまたはPowerShellのRestSetAclsモジュールが示されています。(Microsoft Learn)
ハイブリッドIDと同じ感覚で、エクスプローラーのセキュリティタブから権限を設定しようとすると、想定通りに管理できません。展開前に、権限設定の運用手順を管理者向けに明文化しておくべきです。
クライアント側でKerberosチケット取得を有効化する
Azure Files側を設定しても、クライアントがMicrosoft Entra Kerberosのチケットを取得できなければSMB共有へ接続できません。各クライアントに対して、Cloud Kerberos TGTをログオン時に取得する設定を有効化します。
代表的な方法は次の3つです。
| 方法 | 設定内容 |
|---|---|
| Intune | Kerberos/CloudKerberosTicketRetrievalEnabledを1に設定 |
| グループポリシー | Administrative Templates\System\Kerberos\Allow retrieving the Azure AD Kerberos Ticket Granting Ticket during logonを有効化 |
| レジストリ | CloudKerberosTicketRetrievalEnabledを1に設定 |
レジストリで設定する場合は、管理者権限のコマンドプロンプトで次のように実行します。
reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1変更は即時反映されるとは限らず、ポリシー更新または再起動が必要です。Azure Virtual Desktopのマルチセッション端末では、IntuneのOMA-URIではなくSettings Catalogを使うよう公式ドキュメントで注意されています。(GitHub)
AD DS認証のAzure Filesと併用する場合の注意点
同じクライアントから、Microsoft Entra Kerberosを使うストレージアカウントと、オンプレミスAD DS統合を使うストレージアカウントの両方へ接続する場合は、Kerberosレルムマッピングを設定します。
設定しないままCloud Kerberosチケット取得を有効化すると、既存のAD DS統合ストレージアカウントへの接続に影響する可能性があります。公式手順では、AD DS統合を使うストレージアカウントごとに、ホスト名からKerberosレルムへのマッピングを追加するよう案内されています。(GitHub)
コマンド例は次の通りです。
ksetup /addhosttorealmmap <storage-account-name>.file.core.windows.net CONTOSO.LOCALKerberosレルム名は大文字小文字を区別します。通常はドメイン名を大文字にした値を使うため、contoso.localではなくCONTOSO.LOCALのように指定します。
MFAと条件付きアクセスで必ず確認すること
Microsoft Entra Kerberosは、Azure FilesのSMBアクセス時にMFAを実行する仕組みをサポートしていません。そのため、条件付きアクセスで「すべてのクラウドアプリにMFAを要求する」ようなポリシーを使っている場合、ストレージアカウントに対応するMicrosoft Entraアプリを除外する必要があります。(Microsoft Learn)
除外対象のアプリ名は、次の形式で検索します。
[Storage Account] <your-storage-account-name>.file.core.windows.netこの除外を忘れると、net useで共有をマウントしようとした際にSystem error 1327が表示されることがあります。認証情報の入力ミスではなく、条件付きアクセスによるポリシー制限が原因になっているケースです。(Microsoft Learn)
ただし、MFA除外はセキュリティを弱める設定にもなり得ます。除外は対象ストレージアカウントのアプリに限定し、ユーザーや場所、デバイス準拠状態、ネットワーク条件など他の制御と組み合わせて設計してください。
Private Endpoint利用時の落とし穴
Private EndpointまたはPrivate Link経由でAzure Filesへ接続する場合、追加の設定が必要になることがあります。Kerberos認証でプライベートリンクFQDNを使うには、そのFQDNをストレージアカウントのMicrosoft Entraアプリへ登録する必要があります。
設定が不足していると、SMBクライアントはKerberosに失敗した後にNTLMへフォールバックしようとします。しかしAzure Filesはドメイン資格情報によるNTLM認証をサポートしないため、Error 1326のような資格情報エラーに見える問題が発生します。(Microsoft Learn)
Private Endpoint構成では、DNS、FQDN、Microsoft Entraアプリの識別子URI、SMB 445番ポートの疎通をセットで確認してください。
トラブルシューティングで見るべきログとコマンド
展開後に接続できない場合は、闇雲にRBACやACLを変更する前に、認証、チケット取得、共有レベル権限、ファイルレベル権限を切り分けます。
まず確認する項目
| 確認内容 | コマンド・確認場所 |
|---|---|
| 端末の参加状態 | dsregcmd /status |
| Cloud TGTの有無 | klist cloud_debug |
| Azure Files向けサービスチケット | klist get cifs/<storage-account-name>.file.core.windows.net |
| Entra側のサインイン失敗 | Microsoft Entra IDのサインインログ |
| Azure Files認証チェック | Debug-AzStorageAccountAuth |
| SMB疎通 | 445番ポート、Private Endpoint、DNS解決 |
Debug-AzStorageAccountAuthは、Microsoft Entra Kerberos認証に対する基本チェックにも利用できます。公式トラブルシューティングでは、ポート445、Entra接続、ストレージアカウントのEntraオブジェクト、レジストリキー、レルムマッピング、管理者同意、WinHttpAutoProxySvc、iphlpsvc、参加状態などを確認対象として挙げています。(Microsoft Learn)
大規模テナントではグループSID数を確認する
KerberosチケットにはグループSID数の上限があります。Microsoft Entra Kerberosでクラウド専用IDを扱う場合、オンプレミス由来のグループSIDとクラウドグループSIDが関係するため、グループ数が多いユーザーでチケット発行に失敗する可能性があります。
Microsoft Entraのサインインログに140011 - KerberosUsersGroupNumberExceededが出る場合は、対象ユーザーのグループメンバーシップ、ネストされたグループ、動的グループを見直します。単にRBACを付け直しても解消しないことがあるため、ユーザー単位のグループ設計を確認することが重要です。(Microsoft Learn)
ネットワーク変更後や長時間利用時の認証切れに注意する
Microsoftのトラブルシューティング情報では、VPN再接続、Wi-Fi変更、スリープ復帰などのネットワーク変更後に、KDC Proxy構成のキャッシュが消え、Azure Filesへのアクセスが一時的に失敗するケースが説明されています。また、Microsoft Entra KerberosではTGT更新に関する制限により、約10時間の連続利用後に再サインインが必要になるケースも示されています。(Microsoft Learn)
Azure Virtual Desktopや常時稼働端末でAzure Filesを利用する場合は、こうした制限をユーザー影響として評価し、必要に応じてクラウドトラスト構成やサインイン運用を検討してください。
管理者・開発者が展開前に決めておくべきこと
Microsoft Entra Kerberos Authentication for Azure Filesは、ID基盤、ストレージ、エンドポイント、ネットワーク、セキュリティポリシーが交差する機能です。展開前に、少なくとも次の方針を決めておきましょう。
| 決めること | 判断基準 |
|---|---|
| ハイブリッドIDかクラウド専用IDか | AD DSを残すか、クラウドID中心へ移行するか |
| 既存ストレージアカウントを切り替えるか | IDソースが1種類しか使えないため、本番影響が大きい場合は新規作成を検討 |
| RBACを個別割り当てにするか、既定共有権限にするか | 最小権限を重視するなら個別ユーザー・グループ割り当て |
| ACL設定の運用方法 | ハイブリッドIDはFile Explorerやicacls、クラウド専用IDはAzure portalやRestSetAclsを検討 |
| MFA除外の範囲 | ストレージアカウントのEntraアプリだけに限定する |
| 端末設定の配布方法 | Intune管理端末ならSettings Catalog、従来管理ならGPO |
| Private Endpoint利用有無 | FQDN登録、DNS、識別子URI、445番疎通まで事前確認 |
| 既存AD DS統合Azure Filesとの併用 | HostToRealmのレルムマッピングを設計する |
開発者や自動化担当者は、Microsoft Graph APIやPowerShellでアプリマニフェストやロール割り当てを変更する場面があります。その場合、既存のtags配列を上書きして消さないこと、サービスプリンシパルを公式手順以外で変更しないこと、カスタムロールでワイルドカードを使いすぎないことに注意してください。Azure FilesのRBACでは、データアクションにワイルドカードを使うと、将来追加される操作まで意図せず許可される可能性があります。(Microsoft Learn)
おすすめの展開手順
本番展開では、次の順序で進めると失敗を減らせます。
- 対象のAzure Files共有、ストレージアカウント、現在のIDソースを棚卸しする
- 利用者をハイブリッドID、クラウド専用ID、ゲストユーザーに分類する
- 端末がMicrosoft Entra参加またはハイブリッド参加か確認する
- 検証用ストレージアカウントでMicrosoft Entra Kerberosを有効化する
- 自動作成されたEntraアプリに管理者同意を付与する
- クラウド専用IDを使う場合は
kdc_enable_cloud_group_sidsタグを追加する - 共有レベルのAzure RBACを割り当てる
- 必要に応じてWindows ACLを設定する
- IntuneまたはGPOでCloud Kerberosチケット取得を有効化する
- MFA除外、Private Endpoint、レルムマッピングを確認する
klist、dsregcmd、Debug-AzStorageAccountAuthで検証する- 小規模ユーザーでパイロット運用し、問題がなければ段階展開する
この手順で重要なのは、Azure Files側の設定、Microsoft Entra側の設定、クライアント側の設定を同じタイミングで確認することです。どれか1つでも抜けると、エラーの見え方は「アクセス拒否」や「ユーザー名またはパスワードが違う」に見えてしまい、原因特定に時間がかかります。
まとめ：次に取るべき行動
Microsoft Entra Kerberos Authentication for Azure Filesは、Azure FilesをクラウドID中心で使うための重要な選択肢です。特にクラウド専用IDでAzure FilesのSMB共有を使いたい組織にとっては、AD DS依存を減らせるメリットがあります。
一方で、展開時の確認ポイントは多くあります。最初に見るべきなのは、ストレージアカウントのIDソース、対象IDの種類、対応リージョン、MFA除外、アプリマニフェストタグ、RBAC、ACL、クライアント側のKerberos設定です。既存のAD DS統合Azure Filesと併用する端末では、レルムマッピングも忘れてはいけません。
まずは本番ストレージアカウントを変更する前に、検証用のAzure Files共有を用意し、対象ユーザー1〜2グループでklist、dsregcmd /status、Debug-AzStorageAccountAuthまで含めて確認しましょう。その結果をもとに、RBAC設計、条件付きアクセス除外、端末設定の配布方法を固めることが、安全な移行の第一歩です。
コメント