Azure サブスクリプションでは Owner を持っているのに、Microsoft Entra ID（旧 Azure AD）ではグローバル管理者ロールを自分に付与できない…。本記事では、その原因となる「アンマネージド（viral）テナント」を分かりやすく解説しつつ、Admin Takeover による復旧手順と、再発防止・セキュリティ強化までを一気通貫で整理します。
現象の概要：Owner なのにグローバル管理者を割り当てられない
よくある相談が次のようなパターンです。
- Azure サブスクリプションでは、自分のアカウントに Owner ロールが付いている
- しかし Microsoft Entra ID（旧 Azure AD）の「ロールと管理者」画面で、グローバル管理者 (Global Administrator) を自分に割り当てようとしても選択肢がグレーアウトしている
- 他のユーザーを探してもグローバル管理者が 1 人も存在しない
「サブスクリプションの Owner なんだから、何でもできるはずでは？」と考えがちですが、実はここに落とし穴があります。
Azure RBAC「Owner」と Entra ID「グローバル管理者」は別物
まず押さえておきたいのは、次の 2 つはまったく別の権限体系だということです。
| 種類 | 代表的なロール | 管理対象 | 主な用途 |
|---|---|---|---|
| Azure RBAC | Owner, Contributor, Reader など | サブスクリプション配下のリソース（VM, ストレージ, VNet 等） | Azure リソースの作成・削除・設定変更 |
| Entra ID ディレクトリ ロール | グローバル管理者, 特権ロール管理者 など | テナント（ユーザー, グループ, アプリ, 認証・ポリシー 等） | ユーザー / グループ管理、認証設定、アプリ登録、セキュリティ構成 |
Azure サブスクリプションの Owner を持っていても、それだけでは Entra ID テナントのディレクトリ ロール（グローバル管理者など）には触れません。そのため、テナント側にグローバル管理者が 1 人もいない場合、誰もロールを割り当てられない「詰み」状態になります。
根本原因：アンマネージド（viral）テナントとして自動生成されている
この「グローバル管理者不在」状態の多くは、テナントが アンマネージド テナント（viral / unmanaged tenant） として勝手に作られたことが原因です。
アンマネージド テナントとは
アンマネージド テナントとは、次のような経路で「誰も正式に管理していないまま」自動生成された Microsoft Entra ID テナントです。
- Power BI, Power Apps, Power Automate などの セルフサービス登録
- Microsoft 365 の試用版を、IT 部門を通さず個人で申し込んだケース
- Visual Studio / Azure の個人契約から組織ドメインで登録したケース
典型的には、次のような流れで発生します。
- 社員が個人の判断で、
[email protected]のような 会社ドメインのメールアドレス で Power BI を利用開始 - その時点で
contoso.comドメインが自動的に Entra ID テナントとして登録される - しかし DNS の所有権確認は行われないため、正式なテナント管理者は存在しない
結果として、「テナントは存在するが、グローバル管理者が 1 人もいない」「Azure サブスクリプションは後から紐づけたが、ディレクトリ ロールには触れない」という状態が生まれます。
アンマネージド テナントが疑われるサイン
- Entra ID ポータルの「ユーザー」「グループ」などがほとんど空
- 「ロールと管理者」にグローバル管理者が 0 件
- Microsoft 365 管理センターにサインインすると、設定項目が非常に少ない
- IT 部門として、このテナントを正式に構築した記憶がない
こうした場合は、「このテナントはアンマネージド状態で、正式なテナント管理者を立てる作業（Admin Takeover）が必要」と考えてください。
推奨解決策：Admin Takeover でテナントの管理者を引き継ぐ
アンマネージド テナント問題の「正攻法」は、組織としてテナントの所有権を証明し、Admin Takeover（管理者引き継ぎ） を行うことです。
全体フローのイメージ
| ステップ | 内容 | ゴール |
|---|---|---|
| 1. 準備 | どのドメインのどのテナントかを確認し、DNS 変更ができる管理者を巻き込む | 対象テナントとドメインの特定、担当者アサイン |
| 2. Admin Takeover 実行 | M365 管理センターまたは PowerShell から引き継ぎを開始し、DNS の TXT レコードで所有権を証明 | テナントの所有者として認識される |
| 3. 最初の管理者アカウント作成 | ウィザード上で新規アカウント作成または既存ユーザーを昇格させ、グローバル管理者を付与 | テナント内に初めてのグローバル管理者が誕生 |
| 4. 本来の運用アカウントへ委譲 | Entra ID で IT 管理者用アカウントや PIM 運用を整備 | 安定したガバナンス体制を構築 |
ステップ 1：準備しておくこと
- 対象ドメイン：例）
contoso.com - DNS 管理者：TXT レコードを追加できる担当者（ドメインレジストラ、DNS サービスの管理者）
- 最初の管理者アカウントを誰にするか：
- IT 管理者専用アカウント（例：
[email protected]）を新規に作る - または既存の利用者アカウントを一時的に昇格させる
- IT 管理者専用アカウント（例：
特に DNS 管理者の協力は必須です。これがない場合、Admin Takeover を途中で完了できません。
ステップ 2：Microsoft 365 管理センターから Admin Takeover を開始
Microsoft 365 管理センターにサインインすると、アンマネージド テナントの場合、管理者引き継ぎウィザードが表示されることが多いです。おおよその流れは次の通りです。
- ブラウザで Microsoft 365 管理センターにサインイン
- 「ドメインの所有権を確認して管理を開始します」といったウィザードを進める
- 対象のカスタムドメイン（例：
contoso.com）を選択 - 表示された TXT レコードの値を控える
ここで示される TXT レコードは、ドメインの所有者であることを証明するための「合言葉」です。
ステップ 3：DNS に TXT レコードを追加して所有権を証明
次に DNS 管理者に依頼し、以下のような形で TXT レコードを追加します（実際の値はウィザードで提示されるものを使用します）。
| 項目 | 例 |
|---|---|
| タイプ | TXT |
| ホスト名 | @ または空欄（DNS プロバイダーによる） |
| 値 | MS=msXXXXXXXX のような文字列 |
| TTL | 3600 秒 など（任意） |
DNS への反映には数分～数十分ほどかかることがあります。ある程度時間をおいてから、ウィザード画面の「確認」ボタンを押して TXT レコードが認識されるか確認します。
ステップ 4：最初のグローバル管理者アカウントを作成・昇格
TXT レコードによる所有権の確認が通ると、ウィザードは次のいずれかの選択肢を提示します。
- 新しい管理者アカウントを作成
- サインイン中のアカウントをグローバル管理者に昇格
ここで選択したアカウントが、このテナントにおける「最初のグローバル管理者」となります。セキュリティと運用性を考えると、以下のような設計が理想的です。
- 普段の業務で使うユーザーとは別に、管理専用のクラウド専用アカウント を作る
- この管理専用アカウントには、MFA（多要素認証）と強力なパスワードポリシーを適用する
どちらを選んだとしても、これでようやくテナント内に 1 人目のグローバル管理者が誕生します。
PowerShell から Admin Takeover を行うパターン
環境によっては、PowerShell（Microsoft Graph PowerShell など）から Admin Takeover を開始することもできます。大まかなステップは、
- 対象ドメインを指定してテナント情報を取得
- Takeover 用のコマンドを実行して TXT レコード情報を取得
- DNS に TXT を設定したうえで、所有権確認を完了
という流れです。GUI での操作が難しい場合や、自動化したいシナリオでは検討してもよいでしょう。
Admin Takeover 完了後：グローバル管理者ロールを割り当てる
Admin Takeover が完了し、最初のグローバル管理者ができたら、次は Entra ID ポータルからロールの整理 を行います。
グローバル管理者・特権ロール管理者の付与
Entra ID ポータルで次のように操作します。
- Entra ID ポータルにグローバル管理者としてサインイン
- 「ID」→「ロールと管理者」へ移動
- グローバル管理者 ロールを開き、必要最低限のアカウントに割り当てる
- 推奨：管理者専用アカウントを 2～3 個程度に絞る
- 続いて 特権ロール管理者 (Privileged Role Administrator) を付与
- グローバル管理者の常設は最小限にし、特権ロール管理者経由でロールを委任する構成を検討
グローバル管理者は「テナント内のほぼすべてを変更できる」強力なロールです。常時付与されているアカウントは可能な限り少なくし、緊急時や作業時のみ一時的に有効化する運用が望ましいです。
PIM（Privileged Identity Management）による最小特権運用
必要に応じて、Microsoft Entra の Privileged Identity Management (PIM) を利用すると、次のような運用が可能になります。
- 通常時はロールが無効な「適格 (Eligible)」状態
- 作業前に自分で昇格を申請し、承認後一定時間だけ有効化
- 利用後は自動的にロールが外れる
- ロールの昇格履歴がログに残るため、監査性が高い
「常時グローバル管理者」状態のアカウントを減らせるため、漏洩や乗っ取り時のリスク軽減にもつながります。
よくある勘違いポイントとチェックリスト
「Azure リソースのアクセス管理」をオンにすれば解決？
Entra ID テナントのプロパティには、「Azure リソースのアクセス管理」 という設定があります。これを「はい」にすると、テナントのグローバル管理者などが Azure RBAC で一部の操作を行えるようになります。
しかしこれはあくまで「Entra 側の管理者が Azure リソースに入りやすくする」ための設定であり、
- グローバル管理者が 1 人も存在しない状態を解消するものではない
- サブスクリプション Owner からグローバル管理者に昇格できるわけではない
という点に注意が必要です。根本原因が「アンマネージド テナントで管理者不在」である場合、この設定を触っても解決にはつながりません。
チェックリスト：本当に Admin Takeover が必要かどうか
| 確認項目 | はい | いいえ |
|---|---|---|
| グローバル管理者が 1 人も存在しない | → Admin Takeover の検討が必須 | 既存管理者にロール付与を依頼 |
| このテナントを IT 部門が意図的に作成した記憶がない | → アンマネージド テナントの可能性が高い | 正式テナントである可能性。管理者に確認 |
| Power BI / Power Apps のセルフサービス利用者が多い | → viral テナントができている可能性 | 他の経路の問題かもしれない |
| 会社ドメインの DNS を変更できる管理者が社内にいる | → Admin Takeover 実施が現実的 | DNS 管理者との調整、または別の選択肢を検討 |
Admin Takeover が難しい場合の選択肢
組織の事情によっては、すぐに Admin Takeover ができない場合もあります。そのときの代表的なシナリオと対応を整理します。
| シナリオ | 追加対応 |
|---|---|
| ドメインの DNS 権限がない | ドメインを管理している部署・会社に連絡し、TXT レコードの追加を依頼します。 例：グループ会社でドメインを一元管理している、外部のホスティング会社に DNS を委託している、など。 |
| そもそもこのテナントを使う予定がない | データを必要な範囲でバックアップしたうえで、不要であればテナントを段階的に削除する選択肢もあります。 その際は、別途用意した「公式テナント」にユーザーを招待し、ライセンス・グループ・アプリなどをそちらに集約します。 |
| すぐに管理者が必要で業務に支障が出ている | Microsoft サポートに「グローバル管理者不在テナントの復旧」として問い合わせることも可能です。 ただし最終的には DNS 所有権の証明が求められるため、根本的な解決には Admin Takeover が必要になります。 |
Admin Takeover をするか・しないかのメリット / デメリット比較
| 選択肢 | メリット | デメリット |
|---|---|---|
| Admin Takeover を実施する | テナントの所有権が明確になり、正式に管理できる グローバル管理者や特権ロール管理者を自由に設計できる MFA・条件付きアクセス・PIM などのセキュリティ設定を適用できる ライセンス管理・監査ログ・コンプライアンス対応がやりやすくなる | DNS 変更や手続きに時間と手間がかかる テナントを正式に管理する責任が IT 部門に乗る すでに乱立したテナントの整理が必要になる場合がある |
| そのまま放置する | 短期的には何もしなくてよい DNS 管理者との調整も不要 | ガバナンス不在のテナントが存在し続ける 利用中のユーザーやライセンスの把握が難しい 不正利用や情報漏えい時に、誰も対処できないリスク |
業務で利用している、あるいは将来的に利用する可能性があるテナントであれば、基本的には Admin Takeover を実施して正式に管理下に置く 方向で検討することを強くおすすめします。
テナント乱立を防ぐ：セルフサービス登録を制御する
アンマネージド テナント問題の多くは、「ユーザーが勝手にセルフサービスで Microsoft のサービスに登録した結果」発生します。Admin Takeover が完了したら、再発防止として 自己サインアップ機能の制御 を検討しましょう。
セルフサービス登録を許可した場合のリスク
- ユーザーが IT を通さずに Power BI / Power Apps / Power Automate などを契約してしまう
- シャドー IT 的に利用が広がり、どこで何が使われているか把握できなくなる
- 部門単位でバラバラにテナントやライセンスが乱立する
これを防ぐために、Microsoft 365 管理センターや Entra ID の設定で、セルフサービスの利用やサインアップを組織ポリシーに合わせて制限します。そのうえで、
- 公式に利用を許可するサービス・テナントを決める
- 利用開始の窓口（IT 部門、情報システム部など）を明確にする
といったルールを整備すると、同じ問題の再発を大きく減らせます。
Admin Takeover 後に必ずやっておきたいセキュリティ強化
Admin Takeover で「突然テナントを手に入れた」状態は、一歩間違うとセキュリティホールにもなり得ます。正式に運用を開始する前に、次のポイントを押さえておきましょう。
グローバル管理者・特権ロール管理者への MFA 適用
- グローバル管理者アカウントには必ず MFA を有効化する
- SMS よりも認証アプリやハードウェアトークンなど、より安全な要素を優先
- 特権ロール管理者やセキュリティ管理者にも同様のポリシーを適用
条件付きアクセスで管理者アカウントを守る
- 管理者アカウントのサインイン元を会社ネットワークや信頼できる場所に制限
- 高リスクのサインインをブロックまたは追加認証を要求
- 管理者アカウントでのモバイル端末利用を最小限に抑える
ログとアラートの整備
- サインインログ・監査ログを有効化し、一定期間保持する
- グローバル管理者ロールの割り当てや PIM の昇格イベントに対してアラートを設定
- 定期的なレポートとして、特権ロールの利用状況をレビュー
まとめ：Owner なのにグローバル管理者を付与できないときの考え方
Azure サブスクリプションの Owner なのに、Microsoft Entra ID のグローバル管理者ロールを自分に割り当てられない場合、単なる権限不足ではなく、
- テナントが アンマネージド（viral）テナント として自動生成されている
- その結果、グローバル管理者が 1 人もいない 状態になっている
という構造的な問題であるケースがほとんどです。
この問題に対しては、
- DNS 所有権を証明して Admin Takeover を実施する
- 最初のグローバル管理者アカウントを作成し、必要なロールを整理する
- PIM や条件付きアクセスを活用して、最小特権かつ安全な運用モデルを作る
- セルフサービス登録の制御によって、テナント乱立を防ぐ
という一連の流れで対処するのが、もっとも健全で再発防止にもつながるアプローチです。
「誰も管理していないテナント」が社内に存在していること自体が大きなリスクとなり得ます。今回紹介した内容をベースに、自社のドメインに紐づくテナント状況を棚卸しし、必要に応じて Admin Takeover とガバナンス整備を早めに進めていきましょう。
コメント