はじめに
現在は、Azure Virtual Desktop (AVD) で、ホストプールと仮想マシンを作成する際に、どれだけシンプルな画面からデプロイさせられるか? を研究しています。
その際には、いくつかのハードルがあったのですが、そこで得られたノウハウを記事にしていこうと思っています。
AVDに関する記事は、以下のリンク先で シリーズ化 していますので併せて参照ください。
この記事は、以下の課題に対応するための内容となっています。
AVDを構成する際に MSIXアプリアタッチ や、FSLogix によるユーザープロファイルの保存場所として、ファイル共有が必要になります。
そのファイル共有を Azureストレージアカウントを使って提供する方法があります。
その際に、ストレージアカウントをドメイン参加させる必要があったので、その部分を記事化しました。
ストレージアカウントをドメイン参加させる場合は、以下の3通りのうち いずれか一つを選択する必要がありますが この記事では オンプレミスAD へのドメイン参加を取り上げています。
- オンプレミスの AD DS
- Azure AD Domain Services
- ハイブリッドユーザー用の Azure AD Kerberos
前提事項
- オンプレミスAD と Azure AD が Azure AD Connect で同期されている
- 上記の Azure AD は、ストレージアカウントが存在するAzureサブスクリプションの認証に使われている
その他の制限は、以下を参照ください。
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-identity-auth-active-directory-enable#prerequisites
すでに、この前提事項を満たした環境をお持ちの人は、「ファイル共有をドメイン参加する」の章までスキップしてください。
まだ前提事項の環境がない人は、次章の事前準備から順に進めてください。
事前準備
オンプレミスAD の構築
オンプレミスAD を Azure 上に構築する手順は、以下の私の記事が参考になると思います。
検証を容易に行うために、オンプレミスAD のドメイン名と Azure AD のドメイン名を同一にしておくことをお勧めします。
この記事の通り、クライアントマシンも1台デプロイしてドメイン参加しておいてください。
Azure AD ドメイン名が contoso.onmicrosoft.com なら オンプレAD のドメイン名も、contoso.onmicrosoft.com にしておきます。
オンプレAD のドメイン名が xxx.onmicrosoft.com という形式でも問題なく動作することは 私にて確認済みです。
もし オンプレAD が contoso.local で、Azure AD が contoso.onmicrosoft.com という感じで相違があると Azure AD Connect を構成する際に ユーザーのサフィックスが同一となるような 追加構成 が必要になります。
Azure AD Connect を構成する
オンプレミスAD が構築できたら、オンプレミスAD と Azure AD を Azure AD Connect で接続します。
オンプレミスAD と Azure AD で ドメイン名が一致しているかどうかで 手順が違います。
2通りの手順を紹介していますので、該当する方の作業をおこなってください。
※検証目的なら、ダウンロードしたモジュールは、オンプレミスAD にインストールしてしまって問題ありません。
① オンプレミスのドメイン名と テナント のドメイン名が完全に一致している場合
以下のチュートリアルの通りに作業いただければ大丈夫です。
② オンプレミスのドメイン名と テナントのドメイン名が一致していない場合
対処策を 以下の記事にまとめました。
ストレージアカウントの作成
ストレージアカウントは、データを保存する入れ物の定義です。
これによって、アクセスのためのURL、どの場所にどういう記憶媒体に保存して、災害対策の有無や外部アクセスの有無などの基本設定を行います。これにより課金単価も決まります。
【手順】
1.ストレージアカウント を新規作成します。既存の ストレージアカウント でも構いません。
- リソースグループ:任意
- ストレージアカウント名:任意(英数小文字:グローバルでユニークである必要あり)
- 地域:任意(Azureのリージョンのことです。迷ったら Japan East)
- パフォーマンス:任意(Premium or Standard) ※ Azureファイル共有の料金、パフォーマンスレベルの選択材料
ドメイン参加の接続性をみるだけなら Standardで十分。私は、AVDの検証が目的なのでパフォーマンス重視で Premiumを選択しています。 - Premiumアカウントの種類:ファイル共有(Premium選択時はコレ)
- 冗長性:任意(ローカル冗長ストレージ:LRS で十分です)
2.今回は、「基本」タブの設定のみで十分なため、各項目を入力したら「レビュー」を押します。
3.以下のレビュー画面で、「作成」を押します。
4.1分しないくらいで、デプロイが完了します。「リソースに移動」を押します。
ファイル共有の作成
ファイル共有は、ストレージアカウント内に構成します。
Windows のフォルダ共有と同じような「共有フォルダ」が作成でき、エクスプローラーで参照できます。
【手順】
- ストレージアカウントの概要画面から、「ファイル共有」を押します。
- 「+ファイル共有」を押します。
ここで、緑下線部分が「構成されていません&無効」になっていることを覚えておいてください。ドメイン参加したら 表示が変わります。
- 以下の通り「名前」と「プロビジョニング済みの容量」を設定します。
プロトコルは、「SMB」を選択し、「次へ:バックアップ」を押します。
Premiumでは、プロビジョニングした容量分が月額課金されるので注意してください。
100 GiBで、月額 2,700円くらいです。これが高額だと感じたら Standard にしましょう。
特に、規定値の 1,024 GiBで作ってしまうと、約3万円ですので 注意しましょう。
4.以下の画面では、「バックアップの有効化」は、チェックオフ しましょう(コストに影響)
設定をオフにしたら、「確認および作成」を押します。
5.確認画面です。ここでも バックアップがオフになっていることを再チェックしましょう。
6.ファイル共有が作成されました。
ここでも、赤枠の箇所が意図通りの設定かどうか、再チェックしておきましょう。
7.作成したファイル共有には、以下のストレージブラウザーを使って ディレクトリを作ったりファイルをアップロードしたりすることができます。ですが、Windowsマシンからエクスプローラーで読み書きするためには、ドメイン認証する必要があるので、次章のドメイン参加が必要になります。
ファイル共有をドメイン参加する
いよいよ本題です。
この章では、以下の手順を進めていきます。
- Azure ファイル共有の AD DS 認証を有効にする
- 共有レベルのアクセス許可を割り当てる
- SMB でディレクトリとファイル レベルのアクセス許可を構成する
- Azure ファイル共有をマウントする
- AD DS のストレージ アカウント ID のパスワードを更新する(任意)
Azure ファイル共有の AD DS 認証を有効にする
一連の作業の中で、一番 理解しづらくて 難しく感じる場面だと思います。
私も、これを読んだときに分かりづらくて すぐにやる気が起きませんでした。
何とか成功させられたので、この記事を書こうと思った切っ掛けにもなっています。
ここでは、以下の2通りの方法が説明されているので、どちらか1つをやれば OK です。
この記事では、「オプション1」を取り上げます。
- オプション 1 (推奨):AzFilesHybrid PowerShell モジュールを使用する
- オプション 2:有効化アクションを手動で実行する
前提条件
作業前に 前提条件 を満たす必要がありますが、検証作業なら、オンプレAD サーバーを使うことにすれば、Azure PowerShell を導入するだけで先へ進めます。
-
NET Framework 4.7.2 以降 がインストールされていること
→ Windows Server 2019 や 2022 であれば、既定で入っているので無視して構いません。 -
Azure PowerShell (Az モジュール) と Az.Storage がインストールされていること
→ Windows Server 2019 や 2022 であれば 上記リンクから「 このページ」を見つけて 一番下までスクロールすると msiモジュールがあります。これを入れましょう(なお、Az.Storageは Azモジュールに含まれてたので やらなくてOKでした)
-
Active Directory PowerShell モジュール がインストールされていること
→ オンプレADサーバなら既に入っていると思います。私は入れなくても先へ進めました。
AzFilesHybrid モジュールをダウンロードする
以下のURL へアクセスして、図の赤枠 AzFilesHybrid.zip をダウンロードして 解凍します。
https://github.com/Azure-Samples/azure-files-samples/releases
下図は、ダウンロードして解凍したところ
Join-AzStorageAccount を実行する
以下のURL に記載されているアクションですが、とても難しそうなことが書かれています。
意味としては、オンプレミスのコンピューターをドメイン参加すると、コンピューターのオブジェクトが OU 上に作成されると思いますが、それと同じようなことをしています。
操作に失敗しても、不要なコンピュータオブジェクトができるかどうか くらいしか影響しませんので、安心してください。
手順は、次の章で 順番に画面付きで紹介していきます。
Set-ExecutionPolicy
Change the execution policy to unblock importing AzFilesHybrid.psm1 module
"AzFilesHybrid"のコマンドを実行するために 実行ポリシーを設定します。お約束のコマンド
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Scope CurrentUser
わかりやすい記事があったので、紹介させていただきます。
ダウンロードしたモジュールを PowerShellのパスへコピー
Navigate to where AzFilesHybrid is unzipped and stored and run to copy the files into your path
.\CopyToPSPath.ps1
CopyTpPSPath.ps1 の実行結果。ダウンロードしたファイルを マシン環境上の PowerShellのパスへコピーしているみたいです。
ココにコピーされてました。
Import AzFilesHybrid module
Import-Module -Name AzFilesHybrid
実行結果は、以下の通りです。確認では、"R" を入力して Enter で良いです。
ワーニングが出ていますが、問題ありません。
Azureサブスクリプションにサインイン
Azureにサインインします。もし、ココで失敗したら Azure PowerShrll (Azモジュール)がうまく入っていません。
その点をチェックして、リトライすれば大丈夫です。
Connect-AzAccount
認証ウィンドウが表示されたら、Azure管理者のアカウントでサインインします。
認証に成功したら、以下の画面になります。
目的のサブスクリプションに接続されているか確認しましょう。
パラメータの設定
ドメイン参加するストレージアカウントの情報をパラメータとして事前設定します。
$SubscriptionId = "<your-subscription-id-here>"
$ResourceGroupName = "<resource-group-name-here>"
$StorageAccountName = "<storage-account-name-here>"
$SamAccountName = "<sam-account-name-here>"
$DomainAccountType = "<ComputerAccount|ServiceLogonAccount>" # Default is set as ComputerAccount
$OuDistinguishedName = "<ou-distinguishedname-here>"
$EncryptionType = "<AES256|RC4|AES256,RC4>"
こんな感じでメモ帳でつくって、赤枠部分をコピーし、コマンド画面へペーストします。
実行結果。スペルミスしていても ここでは特にエラーなどは出ません。
作業するサブスクリプションの選択
Select the target subscription for the current session
サインインしたアカウントに 複数の Azureサブスクリプションが紐づいている場合があるので、このコマンドで目的のサブスクリプションを選択します。
Select-AzSubscription -SubscriptionId $SubscriptionId
実行結果。マスクキングばかりでわかりづらいですが、目的のサブスクリプションが選ばれていることを確認します。
Join-AzStorageAccount の実行
これで、必要なモジュールの準備と 目的のサブスクリプションへの接続、パラメータの設定が完了し、ドメイン参加を実施できる材料が揃いました。
このコマンドで ストレージアカウントに該当するコンピュータオブジェクトを オンプレAD に作ります。事前にパラメータの値は設定済みなので、以下の内容のまま実行するだけです。
もしエラーがでたら、パラメータの値を確認して修正して リトライしてみてください。
Join-AzStorageAccount `
-ResourceGroupName $ResourceGroupName `
-StorageAccountName $StorageAccountName `
-SamAccountName $SamAccountName `
-DomainAccountType $DomainAccountType `
-EncryptionType $EncryptionType
"-OrganizationalUnitDistinguishedName $OuDistinguishedName" は、OUの指定をするときだけ追加してください。Null値のまま指定したらエラーがでました。
実行結果。対話では "Y" で応答します。
オンプレAD の Active Directoryユーザーとコンピューターの画面で、作成されたオブジェクトを確認できます。
Azure Portal では、ファイル共有 で、Active Directory (SMB) が、「構成済み」に変更されています。
さらに、「構成済み」をクリックすると、以下の画面になり、認証が Active Directory (オンプレAD)で構成されていることが判ります。
共有レベルのアクセス許可を割り当てる
この操作では、以下の2通りのいずれかを選択して実施すれば OK です。
- 特定の Azure AD ユーザーまたはグループに対する共有レベルのアクセス許可(リンク)
→ 特定の Azure AD ユーザーだけが ファイル共有にアクセスできるようにします(構成は 難しい) - すべての認証済み ID に対する共有レベルのアクセス許可(リンク)
→ オンプレAD で認証された全ユーザーが ファイル共有にアクセスできるようにします(構成は 簡単)
この記事では、"簡単な方" の実施結果を掲載します。
前章で作業を行った最終画面のまま、「手順2:共有レベルのアクセス許可の設定」にて、以下の設定を行います。
- 所定の共有レベルのアクセス許可:「認証されているすべてのユーザーとグループについてアクセス許可を有効にする」
- 認証するロールの選択:「記憶域ファイル データの SMB 共有の共同作成者」
設定が終わったら、「保存」を押します。
以下の赤枠が「有効」に変わります。
SMB でディレクトリとファイル レベルのアクセス許可を構成する
では実際に、エクスプローラーを使って ファイル共有にアクセスしてみましょう。
-
ですが、そのままでは使えません。以下を参考に読み替えてください。
(参照値) https://carol0226storage.file.core.windows.net/share
(読み替え)\\carol0226storage.file.core.windows.net\share
→ "\" は、半角の"¥" マークです。 -
ここで、下図の通り エクスプローラー(緑枠内)で フォルダやファイルを保存すると、Azure Portal のストレージブラウザー(紫枠内)で確認することができます。
Windows側でフォルダの「アクセス許可」を表示させてみると、以下のようになっていました。
「共有」タブは、参照できなくなっているようです。
上記の記事を全部読んでしまうと難しいことが書いてありますが、この記事の手順で進めてきた場合は、オンプレADサーバーや ドメインに参加したクライアントのエクスプローラーが使用できるので、以下のリンク先の作業だけの実施で十分です。
(Windows エクスプローラーを使用して Windows ACL を構成する)
https://learn.microsoft.com/ja-jp/azure/storage/files/storage-files-identity-ad-ds-configure-permissions#configure-windows-acls-with-windows-file-explorer
以上です。ストレージアカウントのファイル共有を オンプレミスのAD ドメインに参加させることに成功しました。
これ以降の説明は、任意ですので、読み飛ばしていただいても大丈夫です。
Azure ファイル共有をマウントする(任意)
ファイル共有は、以下のコマンドで ドライブマウントすることができます。
net use Z: \\<YourStorageAccountName>.file.core.windows.net\<FileShareName>
AD DS のストレージ アカウント ID のパスワードを更新する(任意)
このURLでは、時間経過によって パスワードが失効しないようにローテーションしましょうと書かれています。
検証のために構築して、数か月後には削除してしまう環境であれば、無視して構いません。
運用環境であれば、気を付ける必要がありそうです。
たぶんベストプラクティスは、以下のコメント部分になると思います。
パスワードの定期更新などの意図しないグループポリシーが適用されないように OU の配置を工夫してね・・・ということだと思います。
意図しないパスワードのローテーションを防ぐために、ドメインでの Azure Storage アカウントのオンボード時に、その Azure Storage アカウントを AD DS の異なる組織単位に配置してください。 この組織単位でグループ ポリシーの継承を無効にして、既定のドメイン ポリシーや特定のパスワード ポリシーが適用されないようにします。
参考
本記事と関連のある記事をいくつか見つけたので、こちらも参照してみてください。
特に、作業でハマった際に いろいろみると解決に繋がるかもしれません。
Join-AzStorageAccount を実行したときに エラーが出た時の確認ポイント
くらう道:Azure Files で Active Directory 認証を試す!
オンプレミス AD DS と Azure Files を連携させる
Deep dive - Azure AD Kerberos の仕組み