Azure FilesでオンプレミスのAD資格情報を使ってSMB共有にアクセスさせる場合、結論は「ストレージアカウントをAD DSに登録し、Microsoft Entra IDの共有レベル権限とWindows ACLを組み合わせて制御する」ことです。2026年5月9日更新の公式情報では、Enable AD DS Authentication for Azure Filesの設定手順だけでなく、AES-256 Kerberos暗号化、既存RC4構成の見直し、共有レベル権限の確認が重要なチェックポイントになります。(Microsoft Learn)
特に注意すべきなのは、AD DS認証を有効にしただけではユーザーがAzureファイル共有へアクセスできない点です。ストレージアカウント側のIDソース設定、Microsoft Entra ID側のRBAC、ファイル・ディレクトリ単位のWindows ACL、クライアントのKerberos設定までそろって初めて、実運用で使える状態になります。(Microsoft Learn)
Enable AD DS Authentication for Azure Filesの要点
Enable AD DS Authentication for Azure Filesは、Azure FilesのSMBファイル共有に対して、オンプレミスのActive Directory Domain Services、つまりAD DSの資格情報で認証できるようにする設定です。Azure FilesではSMB経由のIDベース認証として、オンプレミスAD DS、Microsoft Entra Domain Services、Microsoft Entra Kerberosをサポートしており、今回の対象はオンプレミスAD DSを使う構成です。(Microsoft Learn)
仕組みとしては、AzureストレージアカウントをAD DSに登録し、AD DS内にストレージアカウントを表すコンピューターアカウント、またはサービスログオンアカウントを作成します。これは、オンプレミスのWindowsファイルサーバーをAD DSに参加させる考え方に近い構成です。機能を有効にすると、同じストレージアカウント内の新規・既存のファイル共有すべてに適用されます。(Microsoft Learn)
このため、設定対象を「ファイル共有単位」ではなく「ストレージアカウント単位」で考える必要があります。部署別、アプリ別、権限設計別に共有を分けていても、同じストレージアカウントに入っていればAD DS認証の有効化対象はまとめて変わります。
何が変わるのか：管理者が押さえるべき変更点
2026年時点で最も大きな実務上のポイントは、Kerberos暗号化をAES-256前提で確認する必要があることです。AzFilesHybridモジュールはAES-256 Kerberos暗号化のみをサポートし、過去にRC4を既定としていた古いAzFilesHybridバージョンで有効化した環境は、AES-256への更新が求められます。(Microsoft Learn)
| 確認ポイント | 影響を受ける環境 | 管理者が取るべき対応 |
|---|---|---|
| AES-256 Kerberos暗号化 | 古い手順や古いAzFilesHybridで構成したAzure Files | RC4利用の有無を棚卸しし、AES-256対応へ更新する |
| ストレージアカウント単位の適用 | 1つのストレージアカウントに複数共有を収容している環境 | 影響範囲を共有単位ではなくアカウント単位で洗い出す |
| Microsoft Entra IDとの同期 | 特定ユーザー・グループへ共有レベルRBACを割り当てる環境 | 対象IDをMicrosoft Entra Connect SyncまたはCloud Syncで同期する |
| 共有レベル権限 | AD DS認証を有効化した全環境 | SMB共有用のAzure RBACロールまたは既定の共有レベル権限を設定する |
| Windows ACL | 既存ファイルサーバーから移行する環境 | 共有レベル権限とファイル・ディレクトリACLの二重チェックを行う |
2026年7月のWindows Server更新では、AD DSの既定Kerberos暗号化の種類がRC4からAES-256へ変わる予定とされています。Azure FilesでオンプレミスAD DSをIDソースにしている環境では、RC4のままだとマウントエラーが発生する可能性があります。カスタムDNSサフィックスやカスタムKerberos SPNを使うストレージアカウントは、2026年4月のWindows Update以降に先行して影響を受ける可能性があるため、早めに確認すべきです。(Microsoft Learn)
対象になる構成と対象外の構成
Enable AD DS Authentication for Azure Filesの対象は、SMB Azureファイル共有です。AD DSに参加済みのWindowsクライアントやAzure VMから、既存のAD DS資格情報を使ってAzureファイル共有をマウントする構成が中心になります。対応クライアントはWindows 8／Windows Server 2012以降、またはUbuntu 18.04以降相当のLinux VMなどが挙げられています。(Microsoft Learn)
一方、NFSファイル共有ではIDベース認証はサポートされません。Azure FilesをNFS用途で使っている場合は、今回のAD DS認証有効化とは別の認証・アクセス制御設計として扱う必要があります。(Microsoft Learn)
また、ストレージアカウントがすでに別のIDソースで構成されている場合、オンプレミスAD DSをIDソースとして有効にする前に、既存のIDソースを無効化する必要があります。Microsoft Entra Domain Services、Microsoft Entra Kerberos、オンプレミスAD DSを場当たり的に切り替えるのではなく、どのIDソースを本番標準にするかを先に決めることが重要です。(Microsoft Learn)
Microsoft EntraとAD DSの役割を混同しない
この設定で混乱しやすいのは、「認証はAD DS」「共有レベルの認可はMicrosoft Entra ID」「細かなファイル権限はWindows ACL」という役割分担です。
| レイヤー | 主な役割 | 実務で確認すること |
|---|---|---|
| AD DS | Kerberos認証、ストレージアカウントを表すADオブジェクトの管理 | コンピューターアカウントまたはサービスログオンアカウント、SPN、パスワード期限、AES-256対応 |
| Microsoft Entra ID | Azure RBACによる共有レベル権限 | ユーザー・グループの同期、ロール割り当て、テナント整合性 |
| Windows ACL | ファイル・ディレクトリ単位のアクセス制御 | 既存ACLの移行、読み取り・変更・所有権の検証 |
| Azure Storage | Azure Filesとストレージアカウント設定 | IDソース、SMBセキュリティ設定、ネットワーク、共有構成 |
特定のMicrosoft Entraユーザーまたはグループに共有レベル権限を割り当てる場合、そのIDはオンプレミスAD DSとMicrosoft Entra IDの両方に存在するハイブリッドIDである必要があります。IDソースがAD DSまたはMicrosoft Entra Kerberosの場合、共有レベル権限を機能させるには、ローカルADのユーザーやグループをMicrosoft Entra Connect SyncまたはMicrosoft Entra Cloud SyncでMicrosoft Entra IDへ同期します。(Microsoft Learn)
ただし、すべての環境で個別IDの同期が必須というわけではありません。既定の共有レベル権限を使うと、オンプレミスIDをMicrosoft Entra IDへ同期しなくても、認証済みユーザー全体に同じ共有レベル権限を付与できます。ただし、この方法は認証済みユーザーに広く同じ権限を与えるため、最小権限を重視する環境では慎重に使うべきです。(Microsoft Learn)
有効化前に確認すべき前提条件
推奨手順はAzFilesHybrid PowerShellモジュールを使う方法です。このモジュールは、ストレージアカウントをオンプレミスAD DSへ参加させ、必要な変更を行って機能を有効化します。実行時にはオンプレミスAD DSと連携するため、セキュリティポリシー、変更管理、権限委任の確認が欠かせません。(Microsoft Learn)
| チェック項目 | 確認内容 | よくある失敗 |
|---|---|---|
| 実行端末 | オンプレミスAD DSにドメイン参加した端末でPowerShell 5.1を使う | PowerShell 7.xやAzure Cloud Shellで手動手順を実行しようとする |
| モジュール | .NET Framework 4.7.2以降、Azure PowerShell、Az.Storage 8.1.0以降、Active Directory PowerShellを用意する | Az.Storageが古く、AzFilesHybridが期待通り動かない |
| Azure権限 | リソースグループのReader、対象ストレージアカウントのContributor以上を確認する | Azure側の権限不足でJoin処理が止まる |
| AD DS権限 | コンピューターアカウントまたはサービスログオンアカウントを作成できる権限を用意する | AD管理者の承認なしに実行し、権限不足になる |
| OU設計 | ストレージアカウントを表すADオブジェクトをどのOUに置くか決める | 既定OUに作成され、パスワード期限や監査ポリシーが合わない |
| パスワード期限 | ADドメインまたはOUのパスワード期限ポリシーを確認する | サービスログオンアカウントのパスワード期限切れで認証失敗する |
手動で有効化する場合は、Active Directory PowerShellを管理者特権で実行し、PowerShell 5.1を使う必要があります。公式情報では、このシナリオでPowerShell 7.xとAzure Cloud Shellは機能しないと明記されています。(Microsoft Learn)
推奨される設定手順
本番環境では、いきなり有効化コマンドを実行するのではなく、次の順序で進めると手戻りを減らせます。
| 手順 | 作業 | 成功条件 |
|---|---|---|
| 設計 | 対象ストレージアカウント、共有、利用者、IDソースを整理する | 影響を受ける共有とユーザーが一覧化されている |
| AD準備 | ストレージアカウントを表すADオブジェクトのOUと種類を決める | コンピューターアカウントまたはサービスログオンアカウントの方針が決まっている |
| 有効化 | AzFilesHybridでJoin-AzStorageAccountを実行する | AD DS参加相当の設定が完了している |
| 暗号化 | AES-256 Kerberos対応を確認する | RC4依存が残っていない |
| 確認 | DirectoryServiceOptionsとActiveDirectoryPropertiesを確認する | AD DSがIDソースとして表示される |
| 共有権限 | Microsoft Entra IDのユーザー・グループへAzure RBACを割り当てる | 共有レベル権限が設定済み |
| ACL | SMB経由でWindows ACLを設定する | ファイル・ディレクトリ単位の権限が意図通り |
| 接続試験 | 利用者端末または検証VMからマウントする | 認証、読み取り、書き込み、削除が権限通りに動く |
有効化後は、次のようにストレージアカウントのIDソースとADプロパティを確認します。公式手順でも、AD DSが有効になっているかをAzureFilesIdentityBasedAuth配下の情報で確認する流れが示されています。(Microsoft Learn)
$storageAccount = Get-AzStorageAccount `
-ResourceGroupName "<resource-group-name>" `
-Name "<storage-account-name>"
$storageAccount.AzureFilesIdentityBasedAuth.DirectoryServiceOptions
$storageAccount.AzureFilesIdentityBasedAuth.ActiveDirectoryPropertiesここでAD DSが有効になっていても、ユーザーがすぐにアクセスできるとは限りません。ユーザーを認証する前に、共有レベルのアクセス許可を割り当てる必要があります。共有レベル権限の変更は通常30分以内に有効になるとされていますが、反映に時間がかかる場合もあるため、検証時は待機時間を考慮しましょう。(Microsoft Learn)
AES-256移行で確認するコマンド
既存環境でまず行うべきことは、AD DS認証を使っているAzure Filesのうち、AES-256へ更新されていない可能性があるストレージアカウントを洗い出すことです。公式トラブルシューティングでは、ドメイン参加済みマシンで次のPowerShellを実行して、msDS-SupportedEncryptionTypesが未設定の対象を確認する方法が示されています。(Microsoft Learn)
Get-ADObject `
-LDAPFilter "(&(servicePrincipalName=*.file.core.windows.net)(!(msDS-SupportedEncryptionTypes=*)))" `
-Properties servicePrincipalName, msDS-SupportedEncryptionTypes |
Select-Object Name, ObjectClass, servicePrincipalName, msDS-SupportedEncryptionTypes結果が返らなければ、対象ストレージアカウントはAES-256をサポートしており、追加対応は不要とされています。結果が返る場合は、対象アカウントをAES-256対応へ更新します。Azure Public以外のクラウドを利用している場合は、LDAPフィルター内の*.file.core.windows.netを利用環境のエンドポイントに合わせて調整します。(Microsoft Learn)
AzFilesHybridを使える場合は、次のように更新します。公式情報では、AzFilesHybridによる更新が推奨されており、この更新処理ではAES-256へ切り替えるために必要なKerberosキーのローテーションも行われます。(Microsoft Learn)
$ResourceGroupName = "<resource-group-name>"
$StorageAccountName = "<storage-account-name>"
Update-AzStorageAccountAuthForAES256 `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName過去にRC4を使っていてAES-256へ更新した場合は、クライアント側で古いKerberosチケットを残さないことも重要です。公式手順では、klist purgeを実行してからファイル共有を再マウントし、AES-256の新しいKerberosチケットを取得するよう案内されています。(Microsoft Learn)
klist purge共有レベル権限は「広く付ける」より「狭く付ける」
Azure Filesの共有レベル権限は、Microsoft Entraユーザー、グループ、サービスプリンシパルに対して構成します。ディレクトリやファイル単位の制御はWindows ACLで行います。公式情報でも、多くのユーザーには特定のMicrosoft Entraユーザーまたはグループに共有レベル権限を割り当て、Windows ACLで詳細制御する構成が最も安全だとされています。(Microsoft Learn)
実務では、次のように分けると設計しやすくなります。
| 利用シーン | 推奨される考え方 |
|---|---|
| 部署共有 | 部署ごとのADグループをMicrosoft Entra IDへ同期し、共有レベルRBACを割り当てる |
| ファイルサーバー移行 | 既存ACLを維持しつつ、共有レベル権限を移行対象グループに限定する |
| 一時検証 | 既定の共有レベル権限を使う場合でも、検証用ストレージアカウントに限定する |
| マルチテナント管理 | 既定の共有レベル権限を使う前に、Windows ACLだけで十分に制御できるか確認する |
| 管理者アクセス | SMB管理者系ロールを日常利用者へ付けず、運用手順と承認フローを分ける |
カスタムロールを使う場合は、アクションやデータアクションにワイルドカードを使わないことも重要です。ワイルドカードを含むカスタムロールは、将来追加されるデータアクションまで許可する可能性があり、意図しない権限拡大につながります。(Microsoft Learn)
管理者・開発者が注意すべき失敗パターン
AD DS認証を有効にしただけでアクセスできると思い込む
AD DS認証は「本人確認」の仕組みです。実際にAzureファイル共有へアクセスするには、共有レベルのAzure RBACまたは既定の共有レベル権限が必要です。さらに、ファイル・ディレクトリ単位ではWindows ACLが効きます。アクセス拒否が出た場合は、AD認証、共有レベル権限、ACLを分けて確認しましょう。(Microsoft Learn)
ストレージアカウントを表すADオブジェクトのパスワード期限を見落とす
Join-AzStorageAccountで作成されるアカウントは、AD DS内でストレージアカウントを表します。コンピューターアカウントでもサービスログオンアカウントでも、ADドメインまたはOUのパスワード期限ポリシーを確認する必要があります。期限切れを放置すると、Azureファイル共有へのアクセス時に認証エラーが発生する可能性があります。(Microsoft Learn)
無効なUPNを同期してMicrosoft Entra Connectエラーを起こす
手動構成でサービスログオンアカウントを扱う場合、UPNやSPNの扱いに注意が必要です。公式情報では、/、スペース、その他サポートされない記号を含む無効なUPNを持つユーザーを同期しないよう警告されています。無効なUPNがオンプレミスディレクトリにある場合は、有効な形式へ更新するか、Microsoft Entra Connectのフィルター規則で同期対象から除外します。(Microsoft Learn)
PowerShell 7.xやCloud Shellで手動作業を進める
Azure側の作業に慣れているとCloud Shellで済ませたくなりますが、AD DS認証の手動有効化ではWindows Server Active Directory PowerShellコマンドレットをPowerShell 5.1で実行する必要があります。PowerShell 7.xとAzure Cloud Shellはこのシナリオでは機能しません。(Microsoft Learn)
複数フォレスト構成を後回しにする
既定では、アクセスはストレージアカウントが登録されているActive Directoryフォレストに制限されます。別フォレストのユーザーからアクセスさせるには、フォレスト信頼を構成する必要があります。合併・買収後のAD統合、海外拠点、子会社テナントを含む環境では、移行直前ではなく設計段階で確認しましょう。(Microsoft Learn)
カスタムSPNやカスタムDNSサフィックスを使っているのにAES-256確認をしない
標準の<storage-account>.file.core.windows.netではなく、カスタムDNSサフィックスやカスタムKerberos SPNを使っているストレージアカウントは、2026年4月以降のWindows Updateで早期に影響を受ける可能性があります。該当する場合は、通常の移行計画より前倒しでAES-256対応を確認するべきです。(Microsoft Learn)
開発者・アプリ担当者が確認すべきこと
開発者やアプリ運用担当者は、Azure Filesを単なるファイル置き場として見るのではなく、「SMB接続時にどのIDで認証され、どの権限で読み書きするのか」を確認する必要があります。特にWindowsサービス、バッチ処理、VDI、FSLogix、社内アプリのログ出力先などでAzure Filesを使っている場合、実行アカウントのADグループ、Microsoft Entra ID同期、共有レベルRBAC、Windows ACLが一致しているかを検証しましょう。(Microsoft Learn)
アプリ側の確認ポイントは次の通りです。
| 確認項目 | 見るべきポイント |
|---|---|
| 実行アカウント | ユーザー、サービスアカウント、gMSA、コンピューターアカウントのどれでアクセスしているか |
| 接続方式 | SMBマウントなのか、別のAzure Storageアクセス方式なのか |
| 権限 | 読み取りだけでよいのか、書き込み・削除・ACL変更まで必要なのか |
| 障害時の症状 | アクセス拒否、マウント失敗、チケット更新失敗、パス解決失敗を切り分けられるか |
| デプロイ手順 | 本番更新後にklist purgeや再マウントが必要な端末・サーバーを洗い出しているか |
CI/CDや構成管理でAzure Filesのマウントを自動化している場合は、AD DS側の作業をAzureだけで完結させようとしないことも重要です。ADオブジェクト作成、SPN設定、Kerberos暗号化、OUポリシーはオンプレミスAD管理の領域なので、Azure管理者とAD管理者の共同作業として手順化してください。
トラブルシューティングで最初に見る場所
マウントに失敗した場合は、いきなり設定を変更するのではなく、原因を分けて確認します。公式情報では、Debug-AzStorageAccountAuthコマンドレットを使って、サインイン中のADユーザーでAD構成の基本チェックを実行できます。このコマンドレットはAD DSおよびMicrosoft Entra Kerberos認証で機能しますが、IDソースとしてMicrosoft Entra Domain Servicesを使うストレージアカウントでは機能しません。(Microsoft Learn)
Debug-AzStorageAccountAuth `
-StorageAccountName $StorageAccountName `
-ResourceGroupName $ResourceGroupName `
-Verbose「システム エラー 5 アクセスが拒否されました」が出る場合は、共有レベルのアクセス許可が正しくない可能性があります。ただし、アクセス拒否は共有レベル権限以外の原因でも発生するため、Azure RBAC、Windows ACL、Kerberos、ネットワーク、クライアント設定を順に確認することが大切です。(Microsoft Learn)
移行・展開時の実務チェックリスト
本番展開前には、最低限次の項目を確認してください。
- 対象ストレージアカウント内のすべてのファイル共有を一覧化する
- 既存のIDソースが有効になっていないか確認する
- AD DS内に作成するストレージアカウント用オブジェクトのOUを決める
- AES-256 Kerberosに対応しているか確認する
- RC4依存の可能性がある古い構成を洗い出す
- Microsoft Entra IDへ同期するユーザー・グループを決める
- 共有レベルRBACとWindows ACLの対応表を作る
- 既定の共有レベル権限を使う場合は、付与範囲を文書化する
- 検証ユーザーで読み取り、書き込み、削除、権限不足時の拒否をテストする
- 更新後に
klist purgeと再マウントが必要な端末を洗い出す - 障害時に
Debug-AzStorageAccountAuthを実行できる端末を用意する
AD DS認証を無効化する場合も注意が必要です。別のIDソースを使うには、ポータル、PowerShell、Azure CLIでAD DS認証を無効化できますが、無効化後は別のIDソースを有効化・構成するまでIDベースのアクセスがなくなります。また、オンプレミスADに作成したストレージアカウント用のAD DS IDは自動削除されないため、不要になった場合は孤立オブジェクトとして残さないよう整理します。(Microsoft Learn)
まずやるべきこと
Enable AD DS Authentication for Azure Filesを安全に進めるには、最初に「対象ストレージアカウント」「AD DS内のストレージアカウント用オブジェクト」「Microsoft Entra IDに同期するユーザー・グループ」「共有レベルRBAC」「Windows ACL」「AES-256対応状況」を1枚の設計表にまとめることから始めてください。
すでにAD DS認証を使っている環境では、新規設定よりもRC4依存の棚卸しが優先です。特に2026年のWindows更新に備え、AES-256対応、カスタムSPNの有無、クライアント側のKerberos設定、再マウント手順を検証環境で確認してから本番へ展開しましょう。
コメント