Azure Files と オンプレAD DS の連携（Microsoft Entra ID とは同期しない）

はじめに

Azure Files ではオンプレの AD DS と連携させることができます。公開されている記事では オンプレの AD DS を Microsoft Entra ID に同期することが前提となっている順が多いのですが「同期できない ＝ オンプレの AD DS と連携できない」というわけではないです

本記事では、オンプレの AD DS を Microsoft Entra ID に同期しない場合の構成方法について纏めたいと思います

Microsoft Entra ID に同期しなくても良いの？

調べるとほぼ Microsoft Entra ID に同期している手順ばかりなので、実装できないのでは・・・？ と最初は思っていましたが、公式Docsにちゃんと記載がありました

• 共有レベルのアクセス許可を割り当てる方法を選ぶ

• オンプレミスの AD DS を Microsoft Entra ID に同期できない場合は、既定の共有レベルのアクセス許可を使用できます。 既定の共有レベルのアクセス許可を割り当てると、Microsoft Entra ID で ID に対するアクセス許可を指定する必要がないため、同期要件を回避できます。 その後、ファイルやディレクトリに対して Windows ACL を使用して、アクセス許可をよりきめ細かく適用できます。
  • AD に関連付けられ、Microsoft Entra ID と同期していない ID でも、既定の共有レベル アクセス許可を利用できます。 これには、スタンドアロン管理サービス アカウント (sMSA)、グループ管理サービス アカウント (gMSA)、コンピューター アカウントが含まれる場合があります。
• 使用しているオンプレミスの AD DS が、ファイル共有がデプロイされている Microsoft Entra ID とは別の Microsoft Entra ID に同期されている。
  • これは、マルチテナント環境を管理するときに一般的です。 既定の共有レベルのアクセス許可を使用すると、Microsoft Entra ID ハイブリッド ID の要件を回避できます。 その場合でもファイルやディレクトリに対して Windows ACL を使用してアクセス許可をよりきめ細かく適用できます。
• ファイルとディレクトリ レベルで Windows ACL のみを使用して認証を適用した方がよい。

ということで「既定の共有レベルのアクセス許可」を利用すれば、オンプレの AD DS を Microsoft Entra ID に同期しなくても構成はできるとのことです

既定の共有レベルのアクセス許可ってなに？

既定の共有レベルのアクセス許可 は、Azure Filesにアクセスするユーザー全員に適用される設定となります。特定のユーザーやグループとの関連付けがなくファイル共有全体に対する汎用的な設定なので「本設定を利用する = オンプレの AD DS と Microsoft Entra ID でユーザーの同期が必要ない」ということになります。

すべての認証済み ID に対する共有レベルのアクセス許可

補足
「既定の共有レベルのアクセス許可」は、あくまでも一律のアクセス権を設定するためのもので、特定のユーザーやグループに対して異なるアクセス権を付与することはできません。よって、特定のユーザーやグループに個別のアクセス権を設定したい場合は Windows ACL を利用してアクセス権の設定を実施する必要があります

検証環境の構成図

補足
DNS Resolver 用のサブネットは /24 で作成していますが、 現時点では最小の /28 のサブネットを利用するで問題ないです
詳細は サブネットの制限 をご参照ください

作業の流れ

1. ストレージアカウントの作成
2. Azure DNS Private Resolver の作成
3. AD DS 構築（AD Server）
4. DNS フォワーダー設定 (AD Server)
5. AD DS へドメイン参加 (オンプレVM)
6. AD DS 認証の有効化 (Azure Files)
7. 共有レベルのアクセス許可の割り当て (Azure Files)
8. Windows ACL の構成 (AD Server)
9. 動作確認

補足
以下は事前に実施済みとなります

• VNetの作成
• VNetピアリングの設定
• VMのデプロイ
• VPNGWの作成

Bicepについて
ベース環境を作成する Bicep はこちら
Bicepを利用すると以下が作成されます (Private DNS Resolverは作成されません)

• VNet、VNetピアリング
• VMのデプロイ
• VPNGWの作成
• ストレージアカウント（プライベートエンドポイント構成含む）

1. ストレージアカウントの作成

1-1. ストレージアカウントの作成

1-2. ファイル共有の作成

1-3. プライベートエンドポイントの作成

詳細は公式Docs Azure Storage のプライベート エンドポイントを使用する をご参照ください

2. Azure DNS Private Resolver の作成

オンプレ環境からストレージアカウントに対してプライベートIPアドレスでアクセスするには、AzureのプライベートDNSゾーンへのDNSクエリが必要です。しかし、AzureのDNSサーバ（168.63.129.16）は Azure 内部のリソースのみがアクセス可能なため、オンプレ環境から直接アクセスすることはできません

そこで、Azure DNS Private Resolverを作成し、オンプレ側のAD (DNSサーバ) で DNSフォワーダーを Azure DNS Private Resolver に設定することで、オンプレからのDNSクエリをAzureプライベートDNSゾーンで解決できるように構成する必要があります

[問い合わせのフロー]
クライアント --①--> オンプレAD --➁--> Azure DNS Private Resolver --③--> Azure DNS Server (168.63.129.16) --④--> プライベートDNSゾーン

詳細は以下Docsをご参照ください

• Azure とオンプレミスのドメインを解決する
• Azure DNS Private Resolver を利用してオンプレから名前解決を行う
• 仮想マシンまたは Azure DNS Private Resolver を使用して Azure Files 用の DNS 転送を構成する

2-1. Azure DNS Private Resolver の作成

2-2. 受信エンドポイントの作成

3. AD DS 構築（AD Server）

本手順は検索いただければ記事がヒットするのでそちらを参考に構築してください
個人的には以下の記事がとても分かりやすく纏まっていると思いました

• Active Directory サーバー（ADサーバー）の構築手順を初心者にも分かり易く徹底解説

なお、本検証ではドメイン名を takutsulab.com で作成を実施しています

4. DNS フォワーダー設定 (AD Server)

パブリック DNS ゾーンを指定する理由
Docs の オンプレミス DNS フォワーダーを使用した Azure プライベート リゾルバー に以下の通り記載されています

条件付き転送は、推奨されるパブリック DNS ゾーン フォワーダーに対して行われる必要があります。
たとえば、privatelink.database.windows.net ではなく、database.windows.net です。

これはクライアントはパブリックDNSゾーンの名前を使用して接続を試みるため、条件付き転送をプライベートDNSゾーンで設定してしまうと期待通りの名前解決が行われないため

また、この辺りは同僚の記事 Azure Private Endpoint のための DNS 構成パターン に詳しく記載されているので興味がある方は覗いてみてください

5. AD DS へドメイン参加 (オンプレVM)

5-1. 仮想ネットワークのDNSサーバー設定

オンプレVMのDNS問い合わせ先をオンプレADに向けるため、オンプレVMが接続している仮想ネットワークのDNSサーバーをオンプレADに設定します。指定しない場合、Azure 提供 DNS (WireServer) を利用して名前解決が行われてしまいます

補足

• 仮想ネットワークの DNS サーバーの変更を反映するには接続している仮想マシンの再起動が必要となります
• OSでDNSサーバーを指定するでも問題ありません

5-2. 動作確認

プライベートエンドポイントのIPアドレスを取得できることの確認

cmd

nslookup <ストレージアカウント名>.file.core.windows.net

5-3. ドメインへの参加

6. AD DS 認証の有効化 (Azure Files)

詳細は公式Docs Azure ファイル共有に対して Active Directory Domain Services 認証を有効にする をご参照ください

※本検証では AD Server に モジュールをインストールし作業を実施しています

6-1. 作業前準備 (AD Server)

上記Docsの オプション 1 (推奨):AzFilesHybrid PowerShell モジュールを使用する の手順に従って作業を実施します。

6-1-1. .Net Framework のバージョンを確認する（4.7.2以降であること）

powershell

Get-ChildItem 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full\'

6-1-2. Powershell 7 のインストール

詳細は公式Docs Installing PowerShell on Windows をご参照ください

6-1-3. Azure PowerShell (Az モジュール) のインストール

詳細は公式Docs Install Azure PowerShell on Windows をご参照ください

6-1-3-1. PowerShell 7の起動

6-1-3-2. PowerShell 実行ポリシーの変更

powershell

Get-ExecutionPolicy -List
Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser
Get-ExecutionPolicy -List

6-1-3-3. Azure PowerShell のインストール

powershell

Install-Module -Name Az -Repository PSGallery -Force

6-1-3-4. Azure PowerShell の更新

powershell

Update-Module -Name Az -Force

6-1-4. Az.Storage のインストール

詳細は公式Docs Az.Storage をご参照ください

Az.Storageのインストール

powershell

Install-Module -Name Az.Storage -RequiredVersion 7.3.1

6-1-5. Active Directory PowerShell モジュールのインストール

本検証環境では AD DS をインストールしたVM (AD Server) から作業を実施するため実施不要
（AD DS がインストールされると Windows PowerShell の Active Directory モジュールは併せてインストールされるため）

powershell

Get-WindowsFeature | Where-Object {$_.Installed -eq $true}

AD Server 以外で作業を実施する場合は Windows 用リモート サーバー管理ツール (RSAT) をご参照ください

補足
Windows Server と Client (win11等) では手順が異なりますのでご注意ください。参考までに Windows Server 2022 でインストールする手順を記載しておきます

PowerShell

powershell

Install-WindowsFeature -Name RSAT-AD-PowerShell

GUI

6-1-6. AzFilesHybrid モジュールのダウンロード

以下リンクよりモジュールをダウンロードし、解凍する（設置場所：C:\Tools\AzFilesHybrid）

• azure-files-samples

6-2. AD DS 認証の有効化 (AD Server)

6-2-1. PowerShell 7の起動

補足
オンプレミスの AD DS 資格情報 (ドメイン管理者など) を持つユーザーでログインを行い PowerShell を実行する

6-2-2. AzFilesHybrid.psm1モジュールのインポート許可

powershell

Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser

6-2-3. AzFilesHybrid モジュールが保存されているディレクトリに移動し、スクリプトの実行

powershell

cd C:\Tools\AzFilesHybrid
.\CopyToPSPath.ps1 

6-2-4. AzFilesHybrid モジュールのインポート

powershell

Import-Module -Name AzFilesHybrid

6-2-5. Azureへのログイン

powershell

Connect-AzAccount

Webブラウザが起動するので、アカウントを入力してログインを実施する

補足
以下のAzureロールを持つユーザーでログインを行う

• ターゲット ストレージ アカウントが配置されているリソース グループの閲覧者
• AD DS に参加するストレージ アカウントの共同作成者

6-2-6. パラメータの定義

本検証では、Azure Files をオンプレ AD DS にコンピューターアカウントとして登録する

powershell

$SubscriptionId = "<サブスクリプションID>"
$ResourceGroupName = "<リソースグループ名>"
$StorageAccountName = "<ストレージアカウント名>"
$DomainAccountType = "ComputerAccount" 

補足
本検証では以下のパラメータは指定せずにコマンドを実行する

• $SamAccountName
• $OuDistinguishedName

アカウントタイプの違いは Azure Files と Azure File Sync についてのよくあるご質問 (FAQ) を参照

コンピューター アカウント (既定) または サービスのログオン アカウントのいずれを作成しても、認証が Azure Files でどのように機能するかに違いはありません。ストレージ アカウントをご利用の AD 環境内の ID として表す方法については、自分自身で選択することができます。

6-2-7. サブスクリプションの設定

※ Connect-AzAccount の際に正しいサブスクリプションを指定している場合は本手順はスキップする

powershell

Select-AzSubscription -SubscriptionId $SubscriptionId 

6-2-8. ストレージアカウントをアクティブディレクトリ環境に登録する

powershell

Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-DomainAccountType $DomainAccountType

6-2-9. AD DS にアカウントが作成されていることを確認する

補足
Computers 配下に登録したい場合は $OuDistinguishedName を指定して登録コマンドを実行する

powershell

$OuDistinguishedName = "CN=Computers,DC=takutsulab,DC=com"

Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-DomainAccountType $DomainAccountType `
-OrganizationalUnitDistinguishedName $OuDistinguishedName

6-2-10. ストレージアカウントの設定確認

7. 共有レベルのアクセス許可の割り当て (Azure Files)

詳細は公式Docs Azure ファイル共有に共有レベルのアクセス許可を割り当てる をご参照ください

※「すべての認証済み ID に対する共有レベルのアクセス許可」の手順を実施する

8. Windows ACL の構成 (AD Server)

詳細は公式Docs Azure ファイル共有のディレクトリとファイル レベルのアクセス許可を構成する をご参照ください

8-1. 動作確認用アカウントの作成（user1, user2）

動作確認用ユーザーを作成する

ユーザー名	アクセスを許可するディレクトリ
user1	user1dir
user2	user2dir

8-2. ストレージアカウントキーを利用してファイル共有をマウントする

Windows ACL を構成する前にまず、ストレージアカウントキーを使ってファイル共有をマウントする必要があります。本環境では AD Server からファイル共有をマウントして、作業を実施します

cmd

net use Z: \\<ストレージアカウント名>.file.core.windows.net\<共有名> /user:localhost\<ストレージアカウント名> <ストレージアカウントキー>

補足
ストレージアカウントキーは該当のストレージアカウントのページにて確認可能

コマンド実行後、ファイル共有がマウントされたことを確認する

8-3. Windows ACL を構成する

Windows ACL を構成するには、icacls または Windows エクスプローラーのどちらかを使用する必要があります。本環境では windows エクスプローラーを使用して windows ACL を構成します

8-3-1. ルートフォルダ(ファイル共有)のアクセス権の設定

補足

• BUILTIN\Users と NT AUTHORITY\Authenticated Users のアクセス権を削除（もしくは継承をなしに設定）しないと、ドメイン参加している全てのユーザーがディレクトリにアクセスできてしまうため注意する
• 本検証では BUILTIN\Users を削除、Authenticated Users をルートディレクトリのみアクセス許可（読み取りと実行）で設定を実施している

8-3-2. user1/user2用のディレクトリの作成

ディレクトリを作成し、それぞれのフォルダに対してアクセス権の設定を実施します

9. 動作確認

クライアントにログインを実施する（本検証では オンプレVM がクライアントとなる）

補足
本検証では AD Server から オンプレVM にRDPで接続を行い作業を実施している
その場合、オンプレVM のリモートデスクトップユーザーに TAKUTSULAB\user1 と　TAKUTSULAB\user2 を追加する必要があるため注意する

9-1. ログインを行う (user1)

AD Server から オンプレVM に RDPで接続を行う（ユーザー名：TAKUTSULAB\user1）

9-2. ファイル共有をマウントする (user1)

cmd

net use Z: \\<ストレージアカウント名>.file.core.windows.net\<共有名>

補足
接続を削除するコマンドは以下の通り

cmd

cmdkey /delete:Domain:target=<ストレージアカウント名>.file.core.windows.net
net use Z: /delete

9-3. 動作確認 (user1)

設定したアクセス権が適用されていることを確認する

9-4. 動作確認 (user2)

User2でも 9-1 ~ 9-3 の手順を実施し、設定したアクセス権が適用されていることを確認する

まとめ

今回は Azure Files の ADDS 連携についての手順を纏めました。オンプレの AD DS を Microsoft Entra ID に同期することが前提となっている手順が多かったため、同期しない場合の手順を纏めています。オンプレの File Server を Azure に移行するお客様が多いと思いますが、オンプレの AD DS と Microsoft Entra ID に同期しているが、Azure Files を作成するテナントは別になるというシナリオの場合は、本記事の内容が参考になると思います

オンプレの AD DS を Microsoft Entra ID に同期する場合は 同僚の記事 をご参照ください。とても分かりやすく纏まっていますのでお役に立つと思います

Appendix

公式Docs
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-identity-assign-share-level-permissions?tabs=azure-portal

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-identity-configure-file-level-permissions

https://learn.microsoft.com/ja-jp/azure/storage/common/storage-private-endpoints

https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-identity-ad-ds-enable

Zennの記事
https://zenn.dev/microsoft/articles/azurefiles-privateendpoint

GitHub
https://github.com/takutsu001/azurefiles-base-env