みなさん、こんにちは。ネットワールドでSA（ソリューションアーキテクト）として活動している後藤です。
Azure Localのデプロイには、オンプレミスのActive Directory（AD）ユーザーの他、Azure環境にアクセスするためのMicrosoft Entra IDのユーザーも必要です。
これらのユーザーアカウントにはそれぞれ必要な権限があり、それらについてはMicrosoftのドキュメントに記載がありますが、記述されているページが散らばっていたりして、全体像がイマイチ把握できない状態ではないでしょうか。
今回は、デプロイの他、運用フェーズにおいて必要なユーザーアカウントを整理したいと思います。
- 1：最初に注意事項と免責事項
- 2：デプロイに必要なアカウント
- 3：運用時に必要なユーザーアカウント
- 4：Azure Stack HCI OSのローカル管理者
- 5：必要な権限を持ったMicrosoft Entra IDのユーザー
- 6：Azure Localデプロイ用のADユーザーアカウント
- 7：運用で使用するAzureポータル上での管理権限を持つMicrosoft Entra IDのユーザー
- 8：運用で使用するAzure Stack HCI OSのローカル管理者もしくは同権者のアカウント
- 9：LCM Userアカウント
- 10：最後に
1：最初に注意事項と免責事項
本記事は執筆時点（2026/01初旬）の情報をもとに記述しています。
Azure Localは皆さんご存じの通り「Azureのサービス」であり、オンプレミスに展開されるクラウドサービスです。
したがって、サービスの進化に応じて何かしらの仕様が変更される可能性もありますので、必ずMicrosoftのドキュメントを参照して最新の情報を確認してください。
2：デプロイに必要なアカウント
Azure Localをデプロイするステップとしては、以下の流れになるかと思います。
- Azure Stack HCI OSの導入
- Azure LocalノードのAzure Arc接続
- Azureポータルからのデプロイ
それぞれで必要なユーザーアカウントが存在するわけでして、対応としては以下のようになるかと思います。
- Azure Stack HCI OSのローカル管理者（Local Administrator）
- Azure Arcに登録可能なMicrosoft Entra IDのユーザー
- Azure Localデプロイ実行Microsoft Entra IDのユーザーとデプロイ時に指定するデプロイ用ユーザー（AD）
最小で3つのアカウント、すなわち以下の3つが必要になる、という感じですね。
- Azure Stack HCI OSのローカル管理者
- 必要な権限を持ったMicrosoft Entra IDのユーザー（Azure Arc登録、Azure Localデプロイ）
- Azure Localデプロイ用のADユーザー
3：運用時に必要なユーザーアカウント
運用時に必要なユーザーアカウントとしては、ざっくりシステム管理用のアカウントとユーザーアカウント（利用者アカウント）の2つが必要になりますが、ここではシステム管理用のユーザーアカウントにフォーカスします。
システム管理を行う際、Azure Localの性質上、以下のようなユーザーアカウントが必要です。
- Azureポータル上での管理権限を持つMicrosoft Entra IDのユーザー
- Azure Stack HCI OSのローカル管理者もしくは同権者のアカウント
この辺りは自明だと思いますが、2番についてはオンプレミスでの管理ツールである「Windows Admin Center」でAzure Localクラスターを管理する際にも必要になるので、Azure Stack HCI OSのローカル管理者権限が必要になります。
ドメインのAdministratorやDomain Adminsグループに所属するユーザーアカウントを使用しない場合には、Azure Stack HCI OSでローカルAdministrator権限を付与したユーザーアカウント（ローカルアカウントもしくはドメインアカウント）が必要になります。
他にアカウントが必要かどうか、Microsoftのドキュメントをひっくり返していると、「Active Directory LCM ユーザー資格情報」という記述を見つけることができます。
この「Active Directory LCM ユーザー資格情報」の説明はこんな感じです。
デプロイに適したアクセス許可で作成された新しいユーザー名とパスワード。 このアカウントは、Azure ローカル デプロイで使用されるユーザー アカウントと同じです。
なるほど、Azure Localデプロイ時に指定するADのユーザーアカウントですね。
では、デプロイ時に利用するだけのユーザーなのか、というと、ノード追加のドキュメントにも「AzureStackLCMUser」というアカウントが必要、という記述を見ることができますので、デプロイの他、実運用に入った際にもデプロイ時に指定したADユーザーアカウントが必要だということがわかります。
まとめると、こんな感じでしょうか。
- Azureポータル上での管理権限を持つMicrosoft Entra IDのユーザー
- Azure Stack HCI OSのローカル管理者もしくは同権者のアカウント
- Azure Localデプロイ用のADユーザーアカウント（AzureStackLCMUser）
では、列挙したユーザーアカウントでどのような権限が必要なのかを次項以降で見ていきましょう。
4：Azure Stack HCI OSのローカル管理者
言わずと知れた、Azure Stack HCI OSのAdministratorsグループに所属しているユーザーアカウントです。
Azure Stack HCI OS導入直後は「Administrator」アカウントが有効になっているため、デプロイ時のローカル管理者指定は「Administrator」で問題ないです。もちろん、Azure Stack HCI OSデプロイ後にユーザーを作成し、Administratorsグループに所属させたうえでデプロイ時に当該アカウントを指定しても大丈夫です。
ちなみに、Azure Localデプロイ完了後に「Administrator」ユーザーは「ASBuiltInAdmin」にリネームされます（画面1）。
なお、ユーザー作成、並びに「Administrators」グループへのメンバー追加は、Azure Stack HCI OSのコンソール（Sconfig）の3番の「Add local administrator」やPowerShellコマンドレット（New-LocalUserコマンドレットとAdd-LocalGroupMemberコマンドレット）から実施可能です。
5：必要な権限を持ったMicrosoft Entra IDのユーザー
Azure Localをデプロイする際に必要なAzure ロールはMicrosoftのドキュメントに記載されています。
整理をすると、上記ドキュメントでは3つの作業ごとに必要な権限が記述されています。
1つ目が、Azure Localのデプロイに必要なリソースプロバイダーの登録です。
リソースプロバイダーの登録にはサブスクリプションの「所有者（owner）」か「共同作成者（contributor ）」の権限が必要になります。
この作業はサブスクリプションの管理者しかできませんが、サブスクリプションにAzure Localをデプロイする際、最初の1回だけ行う必要がある作業で、2回目以降のデプロイ時には不要です。
したがって、「所有者」や「共同作成者」という大きな権限をAzure Localのデプロイ用ユーザーに割り当てる必要はありません。
この作業は別枠でとらえたほうが良いですが、「必要な権限をもつMicrosoft Entra IDのユーザー」ということであげておきます。
2つ目がAzure Arcへの登録、3つ目が実際のAzure Localのデプロイ作業ですね。
前者のAzure Arcへの登録では、リソースグループに対して以下のロールが必要だとドキュメントに記述されています。
- Azure Connected Machine Onboarding
- Azure Connected Machine Resource Administrator
後者のAzure Localのデプロイアカウントにはサブスクリプションとリソースグループに対してそれぞれロールの割り当てが必要と記述されており、ドキュメント上サブスクリプションに対して以下の2つになります。
- Azure Stack HCI 管理者
- Reader
リソースグループに対してはドキュメント上以下の4つになります。
- Key Vault データ アクセス管理者
- Key Vault シークレット責任者
- Key Vault 共同作成者
- ストレージ アカウント共同作成者
したがって、Azure Arcへの登録とAzure Localのデプロイを同一アカウントで実施しようとした場合には、上記の8つのロールの割り当てが必要である、ということになりますね。
では実際に割り当てていきましょう……、と作業を始めると、日本語表示のAzureポータルではドキュメントに記載のあるロールが見当たりません。例えば「Azure Stack HCI管理者」を割り当てるために「Azure Stack HCI」で検索を掛けると、画面2のようなものしか表示されません。
この辺はクラウドあるある（？）で、表示言語を英語にすると英語版のドキュメント通りの表記で表示されます。変に翻訳がかかってしまい、ドキュメントとポータルの表記がずれてしまっていますね。
ロールの割り当ての際は、ポータルの表示言語を英語にすることがお勧めです。
参考までに対応表を記載しますが、ポータル側で改善されると役に立たないので、参考程度でお願いします。
| 日本語ドキュメント表記 | 英語表記 | 日本語表記 |
|---|---|---|
| Azure Connected Machine Onboarding | Azure Connected Machine Onboarding | Azure に接続されたマシンのオンボード |
| Azure Connected Machine Resource Administrator | Azure Connected Machine Resource Administrator | Azure に接続されたマシンのリソース管理者 |
| Azure Stack HCI 管理者 | Azure Stack HCI Administrator | Azure Stack HCI registration role |
| Reader | Reader | 閲覧者 |
| Key Vault データ アクセス管理者 | Key Vault Data Access Administrator | Key Vault Data Access Administrator |
| Key Vault シークレット責任者 | Key Vault Secrets Officer | キー コンテナー シークレット責任者 |
| Key Vault 共同作成者 | Key Vault Contributor | Key Vault の共同作成者 |
| ストレージ アカウント共同作成者 | Storage Account Contributor | ストレージ アカウント共同作成者 |
| 表1：ドキュメント/日英表記対応表 | ||
「Azure Stack HCI Administrator」の日本語表示が「Azure Stack HCI registration role」となっているのが謎です。
英語表示のポータルで「Azure Stack HCI Administrator」を割り当ててから日本語表示に戻した結果を記述しているので間違いはないと思いますが、気持ち悪いので英語表示のポータルでロールの割り当てを行っていただいたほうが良いかと思います。
なお、3つの作業で用いる各Microsoft Entra IDのユーザーですが、すべて異なるユーザーであっても同一のユーザーであっても問題ありません。
各作業ごとに必要なロールが割り当てられていれば問題ありません。
6：Azure Localデプロイ用のADユーザーアカウント
Azure Localデプロイ用のADユーザーアカウントは、以下のドキュメントで「New-HciAdObjectsPreCreationコマンドレットを使って作成してください」と記述があります。
このコマンドレットを使うと、Azure Localのデプロイに必要なOUとデプロイユーザーが作成されるのでお手軽なんですが、どのような設定のユーザーとOUが作成されるのでしょうか？
コマンドレットの中を見てみると一目瞭然ではありますが、手動で作成する方法を記述したドキュメントもありますので、そちらを見てみるのも手です。
行っている作業は以下のような感じですね。
- OUの作成
- デプロイユーザーの作成（Domain Userグループに所属）
- OUに対して、「グループポリシーの継承をブロック」する設定を実施
- 必要なアクセス権設定をOUに実施
- （自動作成時に実施）デプロイユーザーのパスワードを無期限に設定
4番のアクセス権設定については、PowerShellのスクリプトが用意されているので、OUやユーザーを手動で作成した場合には、スクリプトを使用して権限の割り当てを行ってください。
上記URLのドキュメントにも記載がありますが、GUIツールでは設定できない項目が含まれているため、必ずPowerShellを使用して設定を行ってください。
5番目については「New-HciAdObjectsPreCreationコマンドレット」を使用してユーザーを作成したときに設定されます。
パスワードを無期限に設定するのはセキュリティーポリシー上許されていない、という会社様もあるでしょう。その場合は、定期的なパスワード更新をAzure Localノード側で行う必要があります。このあたりは項番9で説明したいと思います。
7：運用で使用するAzureポータル上での管理権限を持つMicrosoft Entra IDのユーザー
Azureポータル上でのAzure Localの管理作業としては、リソース監視等の他、論理ネットワークの作成、ストレージパス（ボリューム）の作成などがあります。また、仮想マシンの削除などの作業もあるでしょう。
そういったシステム周りの作業を行う際には「Azure Stack HCI Administrator」のロールが必要になります。
したがって、Azure Localをデプロイする際に使用したMicrosoft Entra IDのユーザーを利用しても問題ありませんし、また同じ権限を持ったMicrosoft Entra IDのユーザーを準備しても大丈夫です。
Key Vaultの権限が不安、という場合には「Azure Stack HCI Administrator」のロールだけを割り当てたユーザーでも問題ないかと思います（その場合はKey Vaultは管理できなくなりますし、関連した管理作業ができなくなる可能性があります）。
筆者にて確認したところ、「Azure Stack HCI Administrator」のロールだけを割り当てたユーザーでも論理ネットワークの作成やストレージパスの作成／削除は正常に行えました。
ただし、分析情報やアラートなどを使用する場合、Log AnalyticeやAzure Monitorに対して適切な権限が必要になるので、それらについては適切なロールを割り当ててください。
8：運用で使用するAzure Stack HCI OSのローカル管理者もしくは同権者のアカウント
Azure Localを運用する際、ハイパーバイザー（Hyper-V）やH/W周りの対応をする場合には、Azureポータルではなくローカルの管理ツールを使用する必要があります。
ローカル管理ツールは、旧来のHyper-Vマネージャ－やフェールオーバークラスターマネージャーをはじめとするRSATやWindows Admin Center（WAC）がありますが、それらのツールを使用する際には管理者権限が必要になります（画面3）。
必要な権限は、Azure Stack HCI OSのローカル管理者権限ですが、Azure Localのノードはドメイン参加していますので、ドメインの管理者権限を持っていれば問題ないです。ドメイン管理者権限ではAzure Localの管理を行いたくない場合には、ローカルのAdministratorsグループに参加しているローカルユーザーやドメインユーザーを作成して、それを管理者アカウントとして使用することができます。
ローカルユーザーの作成方法は項番4で解説した通りですが、ドメインユーザーに対してローカル管理者権限を渡す方が一般的でしょうか。
9：LCM Userアカウント
LCM Userアカウントはデプロイの時に使用するアカウントであるとともに、ノードの追加などの管理作業を行う際にも必要になります。
それだけであれば「普段はアカウントを無効化しておいて、そういった追加作業を行う際に有効化すればいいのでは？」という話が出てくると思いますが、無効化するとAzure Localで予期しないトラブルを誘発する恐れがあるので、お勧めできません。
そもそもLCMは「ライフサイクルマネージャー」の略となっており、Azure Localのライフサイクル作業を行う際に必要なアカウントになっています。
具体的な例で申し上げると、LCM Userを無効化した状態でAzure Localのソリューションアップデートを実施すると準備度チェックで失敗してしまいます（画面4）。
LCM Userを有効化すると準備度チェックに成功するので、このチェックで実行されるスクリプトの実行ユーザーとしてLCM Userが使用されていると考えられます。
また、このあたりの動きを確認している際に、ドメインコントローラーの監査ログを確認していると、LCM Userに関する資格情報確認のログやKerberosのサービスチケット要求などの監査ログが確認されました（画面5）。
デプロイ時にAzure Localノード側にLCM Userアカウントが記録され、その情報に基づいてライフサイクル作業が行われていると考えられます。
どこに記録されているの？ という点については現在調査中ではありますが、以下のトラブルシューティングガイドを参照するとECEストアに格納されているとのこと。
このあたりも深堀が必要そうです。
他のドキュメントをあたってみると「内部シークレット」情報の中にパスワード情報を保持ししているという記述も見ることができるため、LCM Userのパスワードについても保持していると考えられます。
このLCM Userに与えられる権限は項番6にも記載しましたが、デプロイ完了後にAzure Localノードを確認すると、ローカルのAdministratorsグループに追加されていることも確認できました（画面6）。
他にもいろいろとサービス系がAdministratorsグループに追加されていますね。
この辺りも併せて押さえておいたほうが良いかもしれません。
項番6でも説明しましたが、Microsoft提供のPowerShellコマンドレットでデプロイユーザー（LCM User）を作成すると、パスワードが無期限に設定されます。これはAzure Localノードで自動的に使用されるため、パスワードが変更されるとその動きが阻害されてしまうからだと考えられます。
しかしながらセキュリティポリシー上、ユーザーのパスワードを無期限に設定できない場合もあるでしょう。
その場合、Azure Localノード側で「Set-AzureStackLCMUserPassword」コマンドレットを使用してLCM Userのパスワードを変更します。
執筆時点でのトラブルシューティング中なのですが、AD側でパスワードを強制変更した環境（AD側のパスワードとAzure Localノード側で保持しているパスワードが異なる環境）を強制的に作った場合、「Set-AzureStackLCMUserPassword」コマンドレットでエラーが発生してパスワードが変更できなくなる、という状況が生じました。
この状態からどのように復旧するかについては、Microsoftに確認が必要かもしれません。継続して調査します。
セキュリティポリシー次第なところもありますが、極力LCM Userのパスワードは無期限にしたほうが良いかもしれません……。
10：最後に
Azure Localのデプロイ、システム運用にかかわるアカウントおよび権限を整理してみました。
運用に欠かせない重要なアカウントもありますので、適切なアカウント設計や権限付与の参考にしていただければ幸いです。
