APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。

株式会社 エーピーコミュニケーションズの技術ブログです。

トップ > Azure > オンプレミス環境からEntra-Only IDでAzure Filesを利用してみる

オンプレミス環境からEntra-Only IDでAzure Filesを利用してみる

Azure Azure Files Azure Arc

はじめに

こんにちは、エーピーコミュニケーションズ ACS事業部の内田です。

先日、「Entra-Only IDでAVDのProfile Containerを構成する」という内容の記事を書きました。

techblog.ap-com.co.jp

今回はそこから派生して、オンプレミス環境からEntra-Only IDでAzure Filesを利用する場合を試してみます。

オンプレミス環境からEntra-Only ID認証でAzure Filesを利用するための前提条件

OSについては以下のいずれかである必要があります。

  • Windows 11 Enterprise/Pro（シングルセッションまたはマルチセッション）
  • 最新の累積更新プログラムがインストールされたWindows Server 2025

その他の前提条件については、以下をご参考ください。

learn.microsoft.com

Azure上のVMでもオンプレミス環境でも前提条件そのものは変わりませんが、 オンプレミス環境のWindows Server 2025に関しては、Entra IDログインするためにひと手間必要となります。

Azure VMでEntra IDログインする場合には、構築時に以下の画像のパラメーターにチェックを入れるだけで可能です。拡張機能（AADLoginForWindows）をインストールすることで、後からEntra IDログインできるようにすることも可能です。

一方、オンプレミスWindows Serverの場合は、以下のいずれかが必要です。

  • Hybrid Entra参加
  • Microsoft Entra Domain Services (Entra DS) の利用
  • Azure Arc + 拡張機能（AADLoginForWindows）の利用

今回はADを使わずEntraだけを利用する想定なので、3番目のAzure Arcを利用する方法で実施します。

[Azure Arc + 拡張機能の利用]パターンの場合、拡張機能の有効化後、オンプレミスWindows ServerがEntra参加状態となります。

オンプレミスActive Directoryや Microsoft Entra Domain Servicesなどの別のドメインに参加することはできないという点にはご注意ください。

参考： learn.microsoft.com

Azure Arcとは？

Azure Arcについて簡単に説明します。

Azure Arcを一言でいうと、「Azureの外にあるサーバーやシステムを、まるでAzure内のリソースであるかのように一元管理できるサービス」です。

通常、Azureの便利な管理ツールはAzure上の仮想マシン（VM）などにしか使えませんが、Azure Arcを使うことでその「境界線」をなくすことができます。

Azure以外の場所にある、以下のようなシステムが対象です。

  • オンプレミスの物理サーバーや仮想マシン（Windows / Linux）
  • 他のクラウド（AWSやGoogle Cloudなど）で動いているサーバー
  • KubernetesクラスターやSQL Serverなどのデータベース

引用： Azure Arc の概要 - Azure Arc | Microsoft Learn

Azure Arcの専用エージェントを対象サーバーに入れるだけで、以下のメリットが得られます。

①「1つの画面」で全部見える

オンプレのサーバーもAWSのサーバーも、すべてAzure Portal（管理画面）に一覧表示され、タグ付けやグループ分けができます。

②セキュリティ・運用の統一

Azureのセキュリティ監視（Microsoft Defender for Cloud）や、システムの自動監視（Azure Monitor）、会社のルールを強制する機能（Azure Policy）を、外にあるサーバーにもそのまま適用できます。

③クラウドの便利機能を外でも使える

「オンプレミスサーバーへのEntra IDログイン」や、「自動パッチ当て（アップデート管理）」、「拡張機能（エージェント）のポータルからのリモートインストール」などが可能になります。

簡潔にまとめると、「自社のバラバラなサーバー環境にAzureの管理ポータルを直結させて、運用をクラウド側から実施できるようにする仕組み」ということになります。

参考： learn.microsoft.com

Entra-Only IDにおけるNTFS ACLについて

これはオンプレミスに限らない話ですが、前回の記事で深く取り上げられていなかった部分なので今回触れておきます。

Entra-Only IDの構成では、ACLの構成に使う上でMicrosoftが推奨しているツールは「Azure portal」と「PowerShell (RestSetAcls モジュール)」のみとなります。「Windowsエクスプローラー」や「icacls」での設定はサポートされていません。

引用： Azure Filesのディレクトリと File-Level のアクセス許可を構成する | Microsoft Learn

また、Entra-Only IDの構成では、

  1. 共有レベル権限（RBAC）
  2. ディレクトリ/ファイルレベル権限（NTFS ACL）

の両方を設定します。

最終的なアクセス権は、「RBACで許可された範囲 ∩ NTFS ACLで許可された範囲」で決まります。

引用： Azure Filesのディレクトリと File-Level のアクセス許可を構成する | Microsoft Learn

参考： learn.microsoft.com

検証

オンプレミス環境に立てたWindows11とWindows Server 2025（今回はVMware Workstation上に仮想マシンを作成）を接続元として利用します。

実施する内容としては以下の通りです。

  • Windows11のEntra参加
  • Windows Server 2025でのEntra ID ログイン（Azure Arc設定）
  • Entra-Only ID認証設定
  • PowerShellを用いたNTFS ACLの設定
  • 接続確認

オンプレミス側の仮想マシン作成、Entraユーザーやストレージアカウントの作成といった部分は事前に実施済みという前提で、今回取り上げたい内容に的を絞って本記事では手順を記載していきます。

なお、本検証で記載しているコマンドを使用する場合は、ご自身の環境に合わせて書き換えて使用してください。

また、今回はPowerShell（RestSetAclsモジュール）を用いたNTFS ACLの設定を実施していきます。

Azure Filesに対して操作を行うユーザーと、共有フォルダーに与える権限は以下のように設定します。

※実際の運用では、RBACは「記憶域ファイルデータのSMB 共有の共同作成者」にして、NTFS ACLで細かな制御を行うと良いでしょう。

  • RBAC
ユーザー名 RBAC
acl-admin（NTFS ACL設定用ユーザー）
  • 記憶域ファイルデータのSMB 共有の管理者特権の共同作成者
  • Storage File Data Privileged Contributor
  • ストレージアカウントキーオペレーターのサービスロール
user01（アクセス確認用ユーザー）
  • 記憶域ファイルデータのSMB 共有の共同作成者
user02（アクセス確認用ユーザー）
  • 記憶域ファイルデータのSMB 共有の閲覧者
  • NTFS ACL
フォルダー名 NTFS ACL
folder01
  • acl-admin：フルコントロール
  • user01：変更
  • user02：読み取り
folder02
  • acl-admin：フルコントロール
  • user01：読み取り
  • user02：変更

上記設定を行うことにより、

ユーザー folder01 folder02
user01 変更可 NTFS ACLの制約により読み取りのみ可
user02 読み取りのみ可 RBACの制約により読み取りのみ可

となる想定です。 acl-adminユーザーは、NTFS ACLの設定用に使用します。

Windows11のEntra ID ログイン

では、さっそくWindows11のEntra ID ログインから進めていきましょう。

こちらについてですが、初回のOSセットアップ時にEntra参加&Entra ID ログインをすることも、あとで設定画面から行うことも可能です。

以下の画面は初回のOSセットアップ時にEntra参加&Entra ID ログインをするパターンです。

Entra ID ログイン後、[Entra ID]-[デバイス]からEntra上にデバイスが登録されていることを確認できます。

Windows11上でも、[設定]-[アカウント]-[職場または学校にアクセスする]と遷移して、Entra参加状態が確認できます。

あとからEntra参加する場合はこの画面からEntraに接続します。

Windows Server 2025でのEntra ID ログイン（Azure Arc設定）

Azure ArcによってWindows Server 2025をAzure環境につなげるために必要なユーザーを用意します。

必要な権限は以下の通りです。

  • スコープ：Azure Arcのリソースを置く先のリソースグループ
    • 閲覧者
    • Azureに接続されたマシンのオンボード

Windows Server 2025にローカルAdministratorでログイン後、Azure Arcの設定をします。

タスクバーにあるAzure Arcのマークを押下し、[Azure Arc セットアップの起動]を押下します。

[次へ]を押下して先に進みます。

Azure Arcのインストール完了後、[構成]を押下します。

Azure Arcの構成の画面に遷移したら、[次へ]を押下します。

[Azureにサインイン]を押下します。

先ほど用意した、必要な権限を持つユーザーでサインインします。

[次へ]を押下します。

テナント、サブスクリプション、リソースグループ、リージョンといった情報を設定し、[次へ]を押下します。

接続が成功したら、[終了]を押下します。

Azure上にAzure Arcのリソースが出来ているのを確認できます。

Windows Server 2025上でも接続できていることが確認できます。

Azure Arcのリソースの[設定]-[Extensions]-[追加]から、Entra ID ログインのために必要な拡張機能の追加を行います。

拡張機能[Microsoft Entra based Windows Server Login]を追加します。

[作成]を押下すると拡張機能がインストールされます。

実際にEntra ID ログインして使うユーザーに、ログインに必要な権限を割り当てます。

割り当てる権限は以下の通りです。

  • スコープ：接続するWindows Server 2025のAzure Arcリソース
    • RBAC：仮想マシンのユーザーログイン（管理者として利用する場合は[仮想マシンの管理者ログイン]）

Windows Server 2025から、Entra ID ログインで利用するアカウントの追加を行います。

[設定]-[アカウント]-[その他のユーザー]-[アカウントの追加]を押下します。

アカウント情報を設定して[追加]を押下します。

追加したユーザーが確認できます。

Windows Server 2025へEntra ID ログインするときは、RDPで接続します。

そのため、事前にWindows Server 2025上でRDP接続を許可しておく必要があります。

また、「デバイスが接続にネットワークレベル認証を使用することを要求する」のチェックは外しておきます。

RDP接続する際は、[詳細設定]-[ユーザー認証]-[Webアカウントを使用して、リモートコンピューターにサインインする]にチェックを入れます。

接続先の指定はIPアドレスではなくコンピューター名を指定します。 ※接続元から名前解決が出来る必要があります。

認証画面に移るので、認証情報を入力します。

[リモートデスクトップ接続を許可しますか？]という表示が出たら[はい]を押下すると、Entraユーザーを使ってWindows Server 2025にRDP接続できます。

Entra-Only ID認証設定

Azure Portalにて、ファイル共有にEntra-Only ID認証設定を入れていきます。

ここでは、ストレージアカウントおよびファイル共有、配下のフォルダー（folder01、folder02）は作成済みのものとします。

[ストレージアカウント]-[クラシックファイル共有]から、[IDベースのアクセス]の下の[構成されていません]を押下します。

[手順1：IDソースを有効にする]の項目にて、[Microsoft Entra Kerberos]の[セットアップ]を押下します。

[Microsoft Entra Kerberos]にチェックを入れ、[保存]を押下します。

必要に応じて、ファイル共有へのアクセス権限の設定をします。

[手順２：共有レベルのアクセス許可の設定]の項目にて、[既定の共有レベルのアクセス許可]を、[認証されているすべてのユーザーとグループについてアクセス許可を有効にする]にします。

[該当するロールの選択]にて、今回は[記憶域ファイルデータのSMB共有の閲覧者]を選択します。

[保存]を押下します。

[Microsoft Entra ID]→[アプリの登録]に遷移し、[すべてのアプリケーション]タブから、利用するストレージアカウント（[Storage Account] <ストレージアカウント名>.file.core.windows.net）を押下します。

[APIのアクセス許可]に遷移し、[構成されたアクセス許可]内にある[<テナント名>に管理者の同意を与えます]を押下します。

[管理者の同意の確認を与えます]の表示が出たら、[はい]を押下します。

Windows Server 2025にて、コマンドでEntra Kerberos機能を有効化します。

reg add HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters /v CloudKerberosTicketRetrievalEnabled /t REG_DWORD /d 1

PowerShellを用いたNTFS ACLの設定

事前に必要な権限を付与しておきます。

[user02]の[記憶域ファイルデータのSMB 共有の閲覧者]については、Entra Kerberosの設定時に、ファイル共有にアクセスするユーザー全員に対して付与されるように設定したので、ここでは設定不要です。

  • スコープ：利用するストレージアカウント
ユーザー名 RBAC
acl-admin
  • 記憶域ファイルデータのSMB 共有の管理者特権の共同作成者
  • Storage File Data Privileged Contributor
  • ストレージアカウントキーオペレーターのサービスロール
user01
  • 記憶域ファイルデータのSMB 共有の共同作成者
user02
  • 記憶域ファイルデータのSMB 共有の閲覧者

Windows Server 2025にacl-adminユーザーでログインしてNTFS ACLの設定を行っていきます。

PowerShellを起動後、以下のコマンドでPowerShell7をインストールします。

winget install --id Microsoft.PowerShell --source winget

PowerShell7に切り替えます。

pwsh

各種モジュールをインストールします。

Install-Module Az -Scope CurrentUser -Force
Install-Module Microsoft.Graph -Scope CurrentUser -Force
Install-Module RestSetAcls -Scope CurrentUser -Force

Azureにログインします。

Connect-AzAccount `
  -DeviceCode `
  -Tenant "<テナントID>"

設定に必要な変数を入れていきます。

$StorageAccountName = "entraonly20260613"
$ResourceGroupName = "test"
$ShareName = "share"

$ctx = New-AzStorageContext `
    -StorageAccountName $StorageAccountName `
    -StorageAccountKey (Get-AzStorageAccountKey -ResourceGroupName $ResourceGroupName -Name $StorageAccountName)[0].Value

NTFS ACLを付与します。

最初にコマンド実行したときに、接続しているアカウントに対してMicrosoft Graphのアクセス許可が求められた場合は、そのまま承諾をして進めます。

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder01" `
    -Principal "acl-admin@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights FullControl `
    -InheritanceFlags ObjectInherit,ContainerInherit

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder02" `
    -Principal "acl-admin@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights FullControl `
    -InheritanceFlags ObjectInherit,ContainerInherit

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder01" `
    -Principal "user01@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights Modify,Synchronize `
    -InheritanceFlags ObjectInherit,ContainerInherit

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder01" `
    -Principal "user02@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights ReadAndExecute,Synchronize `
    -InheritanceFlags ObjectInherit,ContainerInherit

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder02" `
    -Principal "user01@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights ReadAndExecute,Synchronize `
    -InheritanceFlags ObjectInherit,ContainerInherit

Add-AzFileAce `
    -Context $ctx `
    -FileShareName $ShareName `
    -FilePath "/folder02" `
    -Principal "user02@hogehoge.onmicrosoft.com" `
    -Type Allow `
    -AccessRights Modify,Synchronize `
    -InheritanceFlags ObjectInherit,ContainerInherit

不要なACLを削除します。

具体的には、[folder01]と[folder02]から、[Authenticated Users]と[BUILTIN\Users]を削除します。

ここでは、各フォルダーのNTFS ACLをSDDL文字列（Windowsのアクセス権限や監査設定などの複数の構成要素をアルファベットとカッコでつないだもの）として取得し、不要なACE（アクセス制御エントリ。ACLを構成する最小単位のルールのこと）を文字列置換で削除して、Set-AzFileAclでACL全体を上書きしています。

※環境によって取得されるSDDL文字列（ACEの並びや内容）が異なる場合があるため、事前にGet-AzFileAclで現在の設定を確認した上で置換を行ってください。

SDDLについては以下を参考にしてください。

セキュリティ記述子の文字列形式 - Win32 apps | Microsoft Learn

ACE 文字列 - Win32 apps | Microsoft Learn

folder01：

# 現在のACLを取得
$sddl_folder01 = Get-AzFileAcl `
    -Context $ctx `
    -FileShareName "share" `
    -FilePath "/folder01"

# 不要なACEを削除した新しいSDDLを作成
$newSddl_folder01 = $sddl_folder01 `
  -replace '\(A;OICI;0x1301bf;;;AU\)', '' `
  -replace '\(A;OICIIO;GXGR;;;BU\)', '' `
  -replace '\(A;;0x1200a9;;;BU\)', ''

# 編集後ACLで上書き
Set-AzFileAcl `
  -Context $ctx `
  -FileShareName "share" `
  -FilePath "/folder01" `
  -Acl $newSddl_folder01

folder02：

# 現在のACLを取得
$sddl_folder02 = Get-AzFileAcl `
    -Context $ctx `
    -FileShareName "share" `
    -FilePath "/folder02"

# 不要なACEを削除した新しいSDDLを作成
$newSddl_folder02 = $sddl_folder02 `
  -replace '\(A;OICI;0x1301bf;;;AU\)', '' `
  -replace '\(A;OICIIO;GXGR;;;BU\)', '' `
  -replace '\(A;;0x1200a9;;;BU\)', ''

# 編集後ACLで上書き
Set-AzFileAcl `
  -Context $ctx `
  -FileShareName "share" `
  -FilePath "/folder02" `
  -Acl $newSddl_folder02

Azure Portalを確認すると、PowerShellで変更した内容が確認できます。

接続確認

実際に[user01]と[user02]で接続して確認してみます。

以下コマンドでマウントします。

net use Z: \\entraonly20260613.file.core.windows.net\share

[user01]の場合、[folder01]内にはテキストファイルが作成できますが、[folder02]内にはRBAC側の権限はあるもののNTFS ACL側の制限によりテキストファイルが作成できません（閲覧は可能です）。

[user02] の場合、[folder01] 内にはRBACとNTFS ACL両方の制限によりテキストファイルが作成できず、[folder02] 内はNTFS ACLで「変更」が許可されているものの、RBAC側の制限により作成できません（どちらも閲覧は可能です）。

まとめ

今回は、前回取り上げた内容から派生して、個人的に気になった部分の検証をしてみました。

Active DirectoryやEntra Connectの設定をしなくてもオンプレミス環境からAzure FilesのSMB共有のアクセス制御が出来ますが、Windows Server 2025から利用する場合はひと手間必要となったり、Entra-Only IDの構成だとAzure PortalかPowerShell RestSetAclsモジュールしかEntraユーザーへのNTFS ACLの設定がサポートされていないといった制約事項はあったりします。

ただ、今後クラウドネイティブな構成を組んでいく上での選択肢が増えていっているということではあるので、今後のアップデートにも期待しつつ、要件に応じて柔軟に構成を考えていきましょう。

ACS 事業部のご紹介

私達 ACS 事業部はクラウドネイティブ技術、Azure AI サービス、Platform Engineering などを活用し、攻めの DX 成功に向けた開発者体験の向上・内製化のご支援をしております。

www.ap-com.co.jp

www.ap-com.co.jp

また、一緒に働いていただける仲間も募集中です！

今年もまだまだ組織規模拡大中なので、ご興味持っていただけましたらぜひお声がけください。

※求人名の冒頭に【ACSD】と入っている求人が当事業部の求人です

www.ap-com.co.jp

本記事の投稿者: <内田智之>